How to Structure a Non‑Conformity Register and

A well‑maintained non‑conformity register turns findings, deviations and anomalies into manageable work: clear owners, corrective actions, deadlines, evidence and effectiveness checks. For compliance officers, DPOs, CISOs, risk managers and internal auditors, the register is where a problem becomes traceable from detection to verified closure — not an afterthought.

This guide is practical and operational. It does not interpret laws or replace legal advice. Instead, it shows how to build a register that documents what was found, who is responsible, what was decided and which verifiable proofs demonstrate that the issue has been resolved.

Why a non‑conformity register is more than a list of issues

A weak register contains vague rows such as “policy outdated” or “missing evidence”. A useful register links each finding to: the specific requirement or control, the risk it creates, the remediation steps and the verifiable evidence that the fix actually worked. That distinction matters when an auditor asks not only whether a finding was closed, but how you can prove it.

Across frameworks the operational need is the same: be able to demonstrate controls and decisions. GDPR emphasizes accountability (see Article 5(2) of Regulation (EU) 2016/679), NIS2 focuses on security controls and risk management (Directive (EU) 2022/2555), and DORA targets digital operational resilience and ICT risk (Regulation (EU) 2022/2554). You do not need to quote a legal reference in every record; you need the register to answer three practical questions: what is not working, what risk does it create, and what evidence proves the corrective action is complete.

When to open a non‑conformity

Open a non‑conformity when there is a verifiable deviation from a requirement, an approved procedure, an expected control outcome or a commitment given to an auditor, customer or internal body. Not every anomaly must become a formal non‑conformity, but all relevant anomalies should pass a triage criteria defined in advance.

A pragmatic approach is to define thresholds before audits. For example, a late control run might be recorded as an observation if it has no risk impact, but it becomes a non‑conformity if it prevents demonstrating the intended control. This aligns with evidence‑first audit practices described in our article on demonstrable GDPR compliance (/en/blog/gdpr-audit-conformita-dimostrabile).

Examples of when to open a non‑conformity

Planned control not executed: open if the control is mandatory or critical. Attach control plan, schedule and missing outputs.
Evidence unavailable during internal audit: open if the evidence cannot be recovered or is not traceable. Attach audit checklist and correspondence.
Incident handled outside procedure: open if the procedure applied. Attach tickets, timeline and incident report.
Policy expired but process still operating: open depending on criticality. Attach policy version, approvals and mitigating controls.
Supplier lacks required attestation: open if the requirement is contractual or a control mandate. Attach contract and vendor correspondence.

Minimum fields the register should include

Keep the register detailed enough for auditability but simple enough to keep it updated. Too many fields discourage use; too few break traceability.

Identification and context

The first block must describe the non‑conformity in verifiable terms. Avoid subjective language without facts. Prefer: “Quarterly privileged access review for System X not completed by the procedure deadline” rather than “access control insufficient”.

Essential fields and guidance

Unique ID: progressive code (e.g., NC-2026-014). Avoid duplicate or unordered names.
Detection date: date the finding was formalized, not the incident date.
Source: internal audit, customer audit, automated control, incident, vendor. Don’t write “various”.
Description: observable fact, system/process involved. Don’t assign blame.
Linked requirement/control: policy, standard clause, internal control or contractual clause. Don’t leave implicit.
Scope: map to applicable frameworks (GDPR, NIS2, DORA, ISO 27001, etc.). If one finding affects multiple frameworks, link them rather than creating separate records.

At this stage the register should already map the finding to the affected control — remediation must address root causes, not only symptoms.

Owner, risk and priority

Assign an operational owner (not only a function). “IT” is not specific; “Cloud Infrastructure Owner” or “Access Management Process Owner” is. Prioritization should be risk‑driven (impact, likelihood, audit urgency) rather than ad hoc.

Operational fields to include

Owner: the person responsible for driving closure; record the assignment.
Involved function(s): teams required to act; cross‑reference RACI or org chart.
Severity: potential impact on data, service or risk exposure.
Priority: sequence for remediation based on risk.
Due date: expected closure date and supporting remediation plan or ticket.
Escalation thresholds: rules for involving management or governance when deadlines slip.

From findings to corrective actions

A common weakness is conflating immediate containment with corrective action. Containment mitigates risk now; corrective action addresses the root cause so the issue does not recur. Uploading a missing document after an audit may close the immediate gap but does not explain why the control failed in the first place.

Separate the workflow into four levels: containment, root cause analysis, remediation, and effectiveness verification. Showing all four steps demonstrates to auditors that you’re improving controls, not just closing rows.

Four‑step remediation approach

Containment: what immediate steps reduce risk? Example: temporarily revoke unreviewed privileged access.
Root cause: why did the control fail? Example: no owner was assigned to generate the user extract.
Corrective action: what change prevents recurrence? Example: automate the monthly report and enforce owner approval.
Effectiveness verification: how do we prove the fix works? Example: sample of the next review, logs and recorded approvals.

(Image: a working table with non‑conformity cards, owners, risks, corrective actions and evidence — ready for audit.)

What proves a non‑conformity is closed

Closure should not rely solely on a statement such as “activity completed”. Provide a minimum evidence pack that lets an auditor reconstruct decisions, actions and results. Treat remediation work as an audit pack from the start rather than uploading attachments at the last minute — see our guidance on audit‑grade evidence (/en/blog/evidenze-di-audit).

A robust closure package contains at least four elements

Proof the action was executed — tickets, configuration snapshots, signed minutes, reports or contextualized screenshots.
Approval by the owner or control owner — recorded sign‑off or workflow approval.
Evidence of effectiveness — test results, sample reviews, or monitoring outputs demonstrating the control now works.
Change history for the record — who changed the status, when, why and on which evidence.

Keep an audit trail: it proves integrity, timing and responsibility. For more on maintaining evidentiary trails, see our best practices on audit trails (/en/blog/audit-trail-best-practices).

Common states and entry/exit criteria

Open: finding formalized and assigned. Exit when owner and deadline are confirmed.
In analysis: root cause under review. Exit when remediation plan is approved.
In remediation: actions underway. Exit when evidence uploaded and checked.
In verification: actions reported complete. Exit when effectiveness tests pass.
Closed: successful verification and approved closure.
Reopened: evidence insufficient or recurrence observed; restart root cause analysis.

Practical example: missed privileged access review

Scenario: an internal audit finds the quarterly privileged access review for a system hosting personal data was not completed.

A precise entry would read: “Privileged user review for System X for Q2 was not completed by 30 June as required by procedure IAM‑04. No evidence of approval by the system owner is available.”

Map the finding to the internal procedure, an applicable ISO control or to controls relevant under NIS2/DORA as mapped in your control matrix. Set the owner to the system owner or IAM manager (not compliance). Assess the risk (potential unjustified privileged access). Immediate action: perform an extraordinary access review. Root cause: absent automated user report. Corrective action: schedule an automated recurring report and mandatory owner approval with evidence capture. Verification: next scheduled review shows reports, approvals and logs.

The register becomes the timeline of improvement: detection, assignment, analysis, action, evidence and closure.

Frequent mistakes to avoid

Vague records that don’t identify process, control, requirement and impact. Auditors should not have to interview several people to understand a row.
Closing without effectiveness verification. An updated procedure without proof of application produces documentation, not control.
Assigning owners to generic functions instead of named roles or persons.
Changing deadlines without justification or approval.
Uploading evidence without context, date or link to the control.
Treating recurring non‑conformities as isolated events.
Involving vendors in remediation without tracking requests and responses.

If you run regular internal audits, let the register feed the follow‑up plan so findings become controlled activities rather than static report items. See our article on internal audit software and evidence‑based follow up (/en/blog/software-audit-interno).

Linking a single finding to multiple frameworks

A single finding can affect several frameworks. For example, a missed privileged access review can have implications for GDPR, NIS2, DORA and ISO 27001. Don’t open duplicate records — that creates noise and inconsistent updates.

Best practice: maintain one master finding and map it to multiple requirements. Link the applicable controls and reuse evidence where coherent. This is particularly effective when controls are managed in a unified matrix that ties requirements, owners, risks and evidence.

How to map across frameworks

GDPR: tie to the relevant accountability principle, organizational measure or privacy control and attach proof of the control and its ownership.
NIS2: link to risk management or operational security measures and include remediation plans and test evidence.
DORA: connect to ICT processes, incident handling or resilience measures and attach ICT evidence and timelines.
ISO 27001: reference the relevant information security management control and associated records.

Validate the scope of each linkage with internal stakeholders and keep references precise. For ISO standards, use the standard as a reference for the management system (see ISO/IEC 27001 description at https://www.iso.org/standard/27001).

Review cadence and reporting

A register updated only before audits has limited value. Review frequency should match risk level and regulatory pressure. Many organizations run monthly operational reviews and quarterly management summaries, but define cadence based on context.

Reporting should go beyond counts of opened and closed records. Include trends, overdue actions, recurring issues, areas with clustered findings and reopens. These metrics reveal whether a problem is isolated or symptomatic of a systemic control weakness.

Provide at least three views from the register: an operational view for owners, a risk view for management and committees, and an audit pack for internal/external auditors. The underlying data can be the same; the level of detail should differ by audience.

FAQ

Who should be the owner of a non‑conformity? The owner should be the operational person able to perform or coordinate the remediation. Compliance, DPO or audit may monitor progress but should not own problems that belong to specific systems, processes or vendors.

Does every non‑conformity require a root cause analysis? For relevant findings, yes — without root cause analysis you risk treating symptoms only. For minor anomalies a simplified classification may suffice if applied consistently under predefined criteria.

What evidence is needed to close a non‑conformity? You need proof the action was performed, approval by the owner, verification of effectiveness and an audit trail of changes. Evidence types vary by control: tickets, logs, reports, signed minutes, configurations, attestations or sampled checks.

Can the register cover multiple regulations at once? Yes, if the finding is single and requirements are transparently mapped. Avoid duplication; maintain one record linked to multiple controls with reusable evidence.

Is a non‑conformity register legally required? That depends on applicable obligations and frameworks. This guide is not legal advice. Practically, a structured register helps demonstrate governance, follow‑up and continuous improvement in internal and external audits.

Organizing remediation and evidence without losing traceability

If your team must manage findings and corrective actions under NIS2 or similar regimes, consider AuditReady to orchestrate controls and create audit‑grade evidence packs, centered on ownership, traceability and verifiable proofs. Explore AuditReady for NIS2 programs at /auditready/lp/nis2.

audit‑ready evidence pack demo / not legal advice