How to structure a security register that stands up to audit

This article covers information security and organizational controls (not safety logs or workplace health documentation). The structure below is an operational model for CISOs, compliance managers and auditors: it helps organise evidence and show traceability but does not replace legal or sector-specific obligations.

Start by agreeing what a record represents

Before you choose fields or a tool, define what a single row/record means. The clearest approach separates the control definition (stable metadata) from each execution (the individual test run).

Example: “Administrative access review” is the control. The review performed for Q2, with the account list and the approver’s decision, is one execution. If you overwrite the same row every time, you lose the historical trail auditors need.

Treat the security register as a verifiable index that links to primary documents, not as a catch‑all where risks, incidents and meeting minutes are mixed together. Risks, incidents and nonconformities are distinct objects with their own lifecycles; they can be referenced from a control execution but should keep separate identities. Similarly, a privacy data‑processing register serves a different purpose and is not replaced by this model.

Core fields auditors expect

Define a minimum set of mandatory fields before selecting software. Split fields between the stable control definition and per‑execution entries.

• Control ID: stable identifier (e.g., SEC-012). Never reuse for different controls.
• Objective: what the control is intended to verify, stated in verifiable terms.
• Scope/Perimeter: systems, processes, sites, vendors included — and relevant exclusions.
• Linked requirements: laws, contractual clauses or internal policies (GDPR, NIS2, DORA, ISO references as applicable).
• Roles: owner, executor and verifier (distinguish governance/management, execution and validation).
• Pass/fail criteria: conditions that define a successful test (declared before execution).
• Frequency and triggers: scheduled cadence and events that require ad‑hoc checks (changes, incidents, deployments).
• Execution ID: identifier for the specific run, linked to the control.
• Execution date and outcome: when it was performed and the result (separate outcome from remediation state).
• Evidences: links to reports, tickets, logs or minutes, with version/date/context.
• Deviations and actions: what failed, who owns the fix and target completion date.
• Validation and history: who validated the execution, when and any reviewer notes; keep an audit trail of significant changes.

A deadline without an owner is hard to enforce; an owner without a pass criterion cannot produce a verifiable result. Avoid free‑text fields like “all OK” — they don’t distinguish a proper test from a simple assertion.

Make every outcome traceable to appropriate evidence

For each execution, the evidence must answer four questions: does it refer to the correct system, cover the required timeframe, document the declared activity, and support the registered outcome?

Linking a file in the register is only the beginning. A report exported in October doesn’t prove a check took place in June. A screenshot of configuration shows a setting at a point in time but doesn’t prove a process was exercised during a test.

Specify the expected evidence type for each control. For an access review, expect the initial account list, approver decisions and ticket records of revocations. For a restore test, expect a test report, measured recovery times and integrity checks of recovered data. See our guide to audit evidences: /en/blog/evidenze-di-audit for how to make evidence verifiable and contextualised.

Map requirements without implying automatic compliance

Regulatory references matter. For instance, GDPR Article 32 requires procedures to regularly test, assess and evaluate the effectiveness of technical and organisational measures. A well‑filled record documents a specific verification, but does not alone prove full regulatory compliance.

Likewise, NIS2 Article 21 expects policies and procedures to evaluate the effectiveness of cybersecurity risk management measures; applying that requirement depends on national transposition and the organisation’s context.

When you map a requirement to a control, explain which part of the requirement the evidence supports. Attaching many legal references to a document without explanation only creates labels, not stronger assurance.

Assign roles and handle exceptions explicitly

The owner keeps the control operational: ensures execution, chases remediation and escalates issues. The executor performs the activity. The verifier judges whether the evidence actually supports the outcome. In small teams roles may overlap, but that overlap must be visible in the record.

Capture three separate states in the register: activity status (was the test run?), test outcome (pass/fail) and remediation status (are fixes complete and effective?). “Executed” is not the same as “Passed”; “ticket closed” is not the same as “Effectiveness verified”.

Exceptions must be recorded with reason, uncovered perimeter, compensating measures and a re‑review date. “Not applicable” needs a verifiable rationale; it must not become a way to avoid obligations.

Keep risk acceptance distinct

Insufficient evidence does not become adequate because someone accepts the risk. Risk acceptance is a separate governance decision and should record the authorised approver, justification, duration and review conditions.

Keep the control record showing the factual outcome even when residual risk is formally accepted. That way an auditor can distinguish a known, governed weakness from a control that genuinely passed.

For reading on risk registers and tolerance, see training material such as the linked risk register guide. This is educational context, not a legal source.

Worked example: a failed restore test

Illustrative scenario: control SEC‑012 verifies the restore of a business application. The internal objective is a recovery time objective (RTO) of four hours and a verification of data integrity.

Execution SEC‑012‑2026‑03 was performed on 3 October. The restore took 6 hours 20 minutes — the test was executed but did not meet the time criterion.

A proper register entry should make the following explicit:

• Scope: application, database, test environment and backup copy used.
• Roles: infrastructure lead as owner, technician as executor, service owner as verifier.
• Outcome: failed on recovery time; data integrity check documented separately.
• Evidence: test report, operation logs, start/finish timestamps.
• Remediation: corrective action assigned, deadline and requirement for a retest to validate effectiveness.

Opening a ticket makes the deviation manageable but does not resolve it automatically. Closing the ticket and validating the control are two distinct steps.

Close the remediation without wiping the past

After fixes, run a new execution. If the repeat test finishes in 3 hours 40 minutes with integrity confirmed, the verifier can mark the new execution as passed based on the fresh evidence. The original failed execution remains in the history and is linked to the remediation that resolved it. If the test environment, data volume or conditions differ, document those differences; otherwise comparisons can be misleading.

This historical trail demonstrates not only that the control currently works, but how the prior weakness was identified and remediated.

Prepare an extraction the auditor can reconstruct

An extraction should specify the period and scope. Before the audit, agree a reference date and preserve the register version used to build the audit pack. Later changes must remain distinguishable.

A practical audit pack contains: the index of included controls, executions in the selected period, the referenced evidence and the status of exceptions. Don’t duplicate every document; ensure references remain accessible to authorised recipients and that the inspected versions are identifiable.

Design the register so an auditor can follow the reverse path: from a piece of evidence back to the control, the execution and the applied criteria. A file named “report_final_v3” doesn’t provide that traceability unless it’s tied to a stable record.

Also verify permissions, retention periods and whether referenced materials include personal or sensitive information. Retention should be defined by purpose, applicable obligations and documented needs — not indefinite convenience.

Track which events must be recorded: owner changes, evidence replacement, outcome edits and approval of remediation closure. Our best practices on audit trails explain how to build this reconstruction without conflating change history and execution evidence: /en/blog/audit-trail-best-practices.

Common mistakes that weaken the register

• Overwriting history. Updating “last checked” and removing prior executions prevents demonstrating what happened during the required period.
• Relying only on high‑level indicators. A green status can mask partial checks, missing evidence or open actions. Indicators must be derived from declared criteria with drill‑downs to details.
• Using evidence from the wrong scope. A pilot system test does not prove effectiveness across all production applications unless coverage is explicit.
• Closing on the executor’s claim. When validation is required, the record must show the verifier’s review and the evidence considered, not just “resolved”.
• Confusing lack of evidence with not performed. “Execution not demonstrated” is different from “control not executed”; the response is either to gather the missing evidence or to perform the test.

FAQs

Is there a single mandatory template? No — this is an operational proposal for information security controls. It is not a universal mandate nor a substitute for registers required by other disciplines.

Is a spreadsheet sufficient? For a small scope, yes if it manages IDs, permissions, versions, evidence links and history. It becomes fragile when many manual steps are required or when it’s impossible to trace who changed an outcome.

How often should it be updated? Record executions when they occur and update responsibilities, exceptions and actions when they change. Control frequency should reflect risk, applicable requirements and internal policy; include triggers from changes or incidents.

Does the register prove compliance by itself? No. It connects activities and evidence, but demonstration depends on the relevance of the controls, their actual execution and the quality of the evidence. This article provides organisational guidance, not legal advice.

Practical next steps before your next audit

If the challenge is keeping controls, responsibilities and evidence linked, consider AuditReady for your NIS2 preparation: /en/auditready/lp/nis2. The platform centralises evidence with ownership, versioning and an audit trail while keeping links to risks and remediation. The guiding principle remains concrete: every outcome must be reconstructable and verifiable.

AuditReady evidence pack demo — not legal advice