The Compliance Ledger
Cycles, entries, categories, custom categories, and the five states every entry moves through.
The compliance ledger is the single source of truth for your PCI DSS evidence. It replaces the spreadsheet, the shared drive, and the task tracker with one structure that stays consistent across cycles.
Cycles
A cycle is a time-bounded assessment window — typically your quarterly or annual PCI assessment. Every cycle has:
- An ID (e.g.
Initial-Assessment-2026,2026-Q2) - Start date, end date, and an optional target completion date
- A status (
active,closed,archived) - A seeded set of entries — one per PCI DSS requirement
Ankos workspaces have one active cycle at a time. Close the active cycle before starting a new one — closed cycles stay fully readable (useful during a QSA assessment to cross-reference) but no longer accept edits.
Cycle lifecycle
| Status | Edits allowed | Notes |
|---|---|---|
active | Yes | Uploads, sign-off, owner changes, carry-forward all allowed |
closed | No | Read-only banner shows; uploads + sign-offs blocked. Exports still work. Admins can Reopen if closed by mistake. |
archived | No | Same as closed; archival is reserved for cycles you want to hide from the default list. |
The Cycle detail page exposes Close cycle (admins only, on active cycles) and Reopen cycle (admins, on closed cycles). Reopen is meant for "closed by mistake" recovery — don't close-and-reopen repeatedly or the audit trail gets noisy.
Re-scoping a cycle
The onboarding wizard sets your initial scope from six answers (entity type, payment flow, infra location, urgency, two owners). If your business changes mid-cycle — for example, you start accepting in-person payments — Review scoping on the cycle detail page re-runs the wizard's scoping logic against new answers and applies the safe diff.
The re-scope deliberately skips entries that already have evidence or are
signed off — it only adjusts fresh not_started and previously-N/A
entries. Owner re-assignment is intentionally not re-run; that's a
separate explicit action via bulk assign.
Entries
An entry is one piece of evidence your QSA expects. Each entry carries:
- An entry ID using PCI DSS sub-requirement numbering (e.g.
1.2.3,8.4,12.10.1) - A title and description in plain English
- Expected evidence — what the QSA needs to see
- The PCI DSS requirement(s) it maps to
- Upload instructions, accepted formats, and CLI automation notes
- An owner, a state, a priority, and a sign-off status
Entries live inside a cycle, so evidence for any given entry in your Q1 cycle is separate from evidence for the same entry in Q2 — unless you choose to carry it forward.
Categories
Every entry belongs to one of seven baseline categories derived from PCI DSS v4.0.1 sub-requirements. The full set covers everything a QSA expects to see across an assessment — infrastructure (networking, system configuration, logging), cardholder data protection (storage, transmission, key management), program documents (policies, procedures, training), people (employees, vendors, third parties), and the controls layered on top (vulnerability management, access controls).
The category picker in Ankos Ledger shows every category available in your workspace; sign in or start a free trial to browse them. When you export, the evidence ZIP organizes files into one folder per category, prefixed with the same numeric order the ledger uses.
Custom categories
If your organization groups evidence differently than the baseline — for
example, a company-specific category for a compensating control — admins
can add custom categories from Settings → Manage categories (which
opens the dedicated category editor at /categories). Custom categories
merge with the baseline at read time, so every entry still maps to exactly
one code.
The five states
Every entry sits in one of five states. State describes how far an entry has progressed — not whether the evidence passes. Readiness is sign-off.
| State | Meaning |
|---|---|
not_started | No evidence attached yet. |
in_progress | Evidence attached — from a CLI scan or a manual upload. The state no longer distinguishes the source; each evidence file records where it came from. |
carried_forward | Evidence from a previous cycle, attested as still valid. |
not_applicable | Scoped out with a required justification. |
needs_attention | The collector or reviewer flagged a concern. |
Transitions happen automatically: attaching evidence — whether a successful
CLI scan upload or a manual upload — advances an entry from not_started to
in_progress; a carry-forward action moves it to carried_forward.
State is never a judgment. An entry in in_progress is not
"compliant" — it simply has evidence. Your QSA makes the final compliance
determination.
Navigating the ledger
- Cycles list —
/cycles— all cycles, past and present. - Cycle detail —
/cycles/<cycle-id>— every entry in the cycle, grouped by category, with state and owner visible at a glance. - Entry detail —
/ledger/<cycle-id>/entries/<entry-id>— upload evidence, change state, assign an owner, sign off, or mark N/A.
Why a ledger, not a folder
The ledger is built to compound across cycles, not start fresh each quarter. Three properties make this material:
- Multi-year history stays put. Every cycle's evidence, sign-offs, and narratives remain in the workspace. Open a 2024 cycle next to a 2026 cycle to see exactly what changed — and what stayed the same.
- The audit trail survives team turnover. Sign-offs are anchored to immutable user IDs, not display names. A 2024 attestation by someone who's since left the company remains a valid audit-trail entry your QSA can verify years later.
- Carry-forward is a verifiable continuity claim. When a stable control genuinely hasn't changed, one click attests it — citing the exact prior cycle and entry. Not a free pass; a traceable continuity record your QSA can follow back.
A spreadsheet can mimic the ledger for a single cycle. It can't compound. Year 2 is easier than year 1 because the prior baseline is there; year 5 you can show your QSA five unbroken cycles of sign-off history without opening any old folder.

