Ankos
Ankos Ledger

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

StatusEdits allowedNotes
activeYesUploads, sign-off, owner changes, carry-forward all allowed
closedNoRead-only banner shows; uploads + sign-offs blocked. Exports still work. Admins can Reopen if closed by mistake.
archivedNoSame 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.

StateMeaning
not_startedNo evidence attached yet.
in_progressEvidence 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_forwardEvidence from a previous cycle, attested as still valid.
not_applicableScoped out with a required justification.
needs_attentionThe 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.

  • 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.

Next steps