Nonconformity Register: Fields and Evidence You

Introduction

An auditor asks who approved a compensating control. What’s produced: a PDF policy, a chain of emails, and an undated screenshot. Nobody may be dishonest—the work could have been done—but you cannot demonstrate who discovered the gap, who owned it, what changed, and who checked the fix. That operational gap is exactly what a structured nonconformity register must eliminate.

Why a reusable, verifiable register matters

A nonconformity register is not a complaint list or a document to tidy before an audit. It is a dated, attributable, and verifiable operational record that lets someone who was not present reconstruct every decision: identification → assignment → remediation → verification of effectiveness.

The guidance below is written for CISO, compliance and risk leads, internal auditors, DPOs, IT/security teams, Supervisory Bodies (OdV), and GRC consultants working in organizations subject to NIS2, DORA, GDPR, ISO frameworks, or related regulations. It is operational guidance, not legal advice. When legal judgment drives a decision, document that judgment and who provided it.

H2: Three distinct situations that must not be mixed

Mixing event types is a frequent source of poor records. Treat these as distinct flows:

Exception to a control (pre-authorized, time-bound): a deliberate, approved deviation with a compensating control and a defined end date.
Nonconformity/audit finding: a control did not work or there is no evidence the control ran—no prior approval for the deviation.
Incident (security or operational): an event that requires containment and recovery first; classification and records follow as facts become available.

Confusing them has consequences: incidents logged as generic tickets lose timelines; exceptions backdated as findings suggest retroactive approval. The audit trail is the same for all: requirement/policy → control → owner → dated evidence → immutable history → finding → remediation → verification.

H2: Essential fields for a nonconformity register

You don’t need a new tool; you need fields that force people to record decisions while facts are current. At minimum, each record should include:

Stable ID and status (open, remediation, pending verification, closed, reopened)
Detection timestamp and awareness timestamp (when the organization officially knew)
Origin (audit, incident, test, privacy, supplier, whistleblowing, manual) — drives handling rules
Scope (asset, process, data processing, critical function, compliance domain)
Control or requirement referenced (internal control plus links to NIS2, DORA, GDPR, ISO, 231 where applicable)
Classification (exception, finding, incident, supplier deficiency, protected whistleblowing report)
Responsible owner and independent verifier
Root cause (explain why the control failed, not just the symptom)
Initial risk and residual risk (scenario, likelihood, impact, treatment, who accepted any residual risk)
Remediation plan (action, responsible party, target date, compensating controls)
Implementation evidence (what was done, by whom, when, file version or secure artefact)
Effectiveness verification (who verified, how, result, and date)

H3: Fields that often look filled but add little

Root cause: “patch not applied” is a symptom. Ask why—no maintenance window? incomplete inventory? vendor failure?
Risk fields: capture scenario, probability, impact, chosen treatment, and if accepted, who accepted it and why.
Status: binary open/closed is insufficient. Include intermediate statuses (in remediation, awaiting evidence, pending verification).

H3: Special dates for personal data breaches

For privacy incidents, record detection and awareness separately. Under GDPR, the 72‑hour notification clock runs from the controller’s awareness, not the first technical signal. Capture: systems and categories affected, containment actions, risk assessment, decision on notification (and rationale), and evidence of remediation. Keep version history of decisions—don’t overwrite earlier rationales.

H2: Roles — who opens, approves, executes, and verifies

A common weakness: one person identifies, fixes, and closes a finding. That shows only self-declaration. Define separate responsibilities and minimum evidence for each handover:

Opening: reporter documents origin, scope, and initial evidence (detection note with timestamp).
Classification: compliance or control owner documents why it’s an exception, finding, or incident.
Risk approval: risk owner approves remediation, compensating controls, or risk acceptance with signed, dated rationale.
Execution: action owner performs remediation and links implementation evidence to the record.
Verification: a different person conducts the effectiveness check and records method and outcome.
Closure/reopen: the verifier closes (or reopens) the ID with notes.
Notification: if required, privacy/incident lead records notification decision and timestamps.

Tooling can automate assignment and preserve non‑overwritable history, but a tool does not take the responsibility away from named decision-makers.

H2: What evidence supports closure?

Closure needs two distinct pieces:

Evidence the remediation was implemented (patch logs, access-review outputs, updated procedures, vendor statements with timestamps). These must be versioned and retrievable by record ID. Screenshots without context are weak evidence.
An independent verification demonstrating the remediation fixed the root cause (retest results, audit of logs, penetration test excerpts, restored backups successfully validated).

For privacy incidents, the DPO’s or privacy lead’s decision about notification must be recorded separately from technical remediation evidence.

H2: Managing time‑bound control exceptions

An exception must be a decision made before the control fails: assign an ID, a requester, an approver different from the requester, compensating controls, and a review date before expiry. Before the expiry, the owner must choose to:

Close (control restored and evidence available)
Convert to a finding (gap still present and requires remediation)
Renew (new dated decision and new acceptance rationale)

Never simply copy the prior approval—document a new decision. Compensating control evidence must be dated and retrievable (e.g., monitoring logs rather than a sentence that says “we monitor”). If an exception lapses without decision, open a finding for the management process itself.

H2: One finding — multiple regulatory hooks

Create a single operational record and link applicable regulatory requirements (NIS2, DORA, GDPR, ISO, 231) rather than duplicating tickets. That avoids diverging versions while allowing tailored evidence packages for different auditors or regulators.

H3: Three example scenarios

Case 1 — Critical ICT supplier misses a patch deadline

Keep one record linked to internal control, supplier‑management obligations, and any relevant NIS2/DORA clauses. Include vendor evidence (timed remediation notes, change requests), internal risk acceptance (if any), and verification of patch efficacy.

Case 2 — Security event with possible personal data exposure

Track the event and update the record as facts emerge. If personal data is involved, document categories and volume, containment steps, risk assessment for people’s rights and freedoms, and the notification decision with rationale. If notified late, record reasons and approvals.

Case 3 — 231 protocol gap, a protected whistleblowing report, or an AI system issue

Link 231‑related findings to the relevant protocol and OdV review notes. For whistleblowing, store receipt, authorised handlers, and status in an access‑restricted area; do not expose reporter identity in standard tickets. For AI systems under the EU AI Act, document the human responsible, inventory entry for the system, identified limitations, and how obligations are met. The tool can then output different evidence packages for auditors, privacy, or the OdV without duplicating the core record.

H2: Common mistakes that weaken traceability

Retroactive approval: adding an approval date only after an auditor asks. Do not backdate; open a corrective action if approval was missing.
Perpetual exceptions: renewing without a new acceptance and rationale.
Scattered evidence: proofs in chat, personal mailboxes, or unlinked folders.
Closures without verification: the implementer closes their own ticket without an independent check.
Undated screenshots: images without system name, timestamp, or integrity metadata are weak.
Vague descriptions: labels like “security issue” or “low risk” without context don’t reconstruct decisions months later.

Rule of correction: add a new dated decision on the original ID if a decision was legitimately made but not recorded. If it never existed, open a corrective finding instead of backfilling.

H2: Seven checks to run before closing any finding

Apply these checks to each recently closed or open record; define what constitutes a positive result and what triggers escalation:

Timelines: detection and awareness are distinct and dated.
Classification: exception, finding, or incident is chosen and justified.
Regulatory linkage: the affected control and applicable rule (NIS2/DORA/GDPR/ISO/231) are identified.
Role separation: reporter, risk approver, action owner, and verifier are distinct where practical.
Data breach decision (if relevant): data categories, approximate volumes, affected persons, consequences, measures, risk judgment, approver, and revisions are documented.
Effectiveness: implementation evidence plus separate verification of root-cause mitigation.
Evidence retrievability: versioned files retrievable by the record ID.

Sample records or audits fail if closed records lack an effectiveness check or the decision history has been overwritten. Treat such failures as new findings about your register process.

H2: Practical checklist for your first week

Sample a few recently closed findings from audits, suppliers, privacy, and 231 processes using the seven checks. Reopen any that lack verification.
Consolidate scattered findings from emails and chats into the register with proper IDs, assign owners and due dates.
Ensure every open record has a named owner, a deadline, and linked evidence.

H2: What software can and cannot do

A tool can collect findings from audits, incidents, tests, privacy workflows, and manual entries; assign owners; preserve immutable histories and versioned evidence; request proof from suppliers via secure channels; and export an Audit Day pack. It cannot substitute for named responsibility, certify compliance automatically with NIS2/DORA/GDPR, or eliminate risk on your behalf. AuditReady is a platform that supports the operational work: it helps gather findings, owners, and versioned evidence, but decisions and legal accountability remain with the organization.

Conclusion

A tidy register does not prove a control worked by itself. Before the next audit, check that every record connects the initial finding, remediation action, implementation evidence, and a distinct effectiveness verification. Closing before the verification step risks hiding weaknesses rather than resolving them.

Nonconformity Register: Fields and Evidence You Need for Audit Traceability