Client Guide

Registers

A register is the running log of a compliance activity: risks identified, incidents handled, training delivered. Populated registers are proof to the auditor that the work is actually happening. Rows you add count toward Audit.

Why registers exist

CAB auditors don't want to read your policy. They want to see evidence you are doing what the policy says. A written incident-response policy on its own fails the audit; a populated incident register alongside it passes. Registers close that gap.

The thirteen registers

Open them from the Records menu. The same registers sit in the Documents tree under Registers. The risk register is separate: it lives under Risks → Register (see Risks).

Records page, Do and keep records: the Records box lists all thirteen registers as links, from the Training & Awareness Register to the Vulnerability Register; below it the Read and understood box and the More courses cards
Records lists every register. Click one to open its table.
Register What it tracks
Training & Awareness Awareness sessions and completion
Phishing Test Simulated phishing campaigns with click rate and report rate
Employee Onboarding One row per new hire
Employee Offboarding One row per leaver
Access review Periodic reviews of who has access to what
Backup & Restore Test Restore drills, proving backups actually work
Change Management Significant system changes with risk review
Incident Security incidents with NIS2 24h / 72h / 1-month reporting dates
Management Review Reviews of the security posture by management
Policy Review Review cadence per policy, with approver and outcome
Supplier Third parties with access to systems or data, review cadence
Tabletop & Recovery Exercise IR drills, recovery rehearsals, lessons learned
Vulnerability Vulnerabilities found in scans, patched status

How a populated register becomes evidence

You don't have to separately attach a file to prove the work happened. The moment a register has one or more rows, the platform treats it as virtual evidence for every control it is mapped to:

  1. Add a row to the register (e.g. log one incident in Incident register).
  2. The register is linked to the controls it supports.
  3. The Audit recalculates: the matching controls move toward Audit-ready.
  4. Your readiness percentage goes up. No file upload needed.

Quality over quantity

Registers count because they show real activity. A one-row register may count, but an auditor will still ask "is that really all of them?" Fill them honestly.

Incident Register page with the Add incident button, an empty-state message, and a reminder banner for the NIS2 24-hour, 72-hour, and one-month reporting deadlines
Empty registers show a prompt and a reminder of the relevant audit requirements: here, the NIS2 reporting deadlines.

MSP-facing reports

Two extra pages live alongside the registers but aren't registers themselves. They are management declarations the MSP delivers to the client:

  • Statement of Applicability (reports/statement-of-applicability): declares which controls apply, with justifications for any exclusions. Auditors read this first.
  • Quarterly Business Review (reports/quarterly-business-review), the quarterly readout: posture evolution, highlights, open risks, next-quarter commitments. Copy the page into a PDF each quarter.

Continue with

Audit

See findings close as your registers fill

Attach evidence

Upload policies, screenshots, and reports