In IT compliance, exceptions to controls are not mere paperwork — they are the moments when a required control is not applied as intended, is applied differently, or remains temporarily incomplete. Left unmanaged, exceptions become nonconformities that are hard to justify during an audit. Managed with clear owners, rationale, residual risk, compensating controls and a verifiable closure date, they become auditable elements of your control environment.
This article is operational (not legal). It describes a core workflow you can use to show auditors how your organization governs exceptions to IT controls. It does not replace legal, privacy or regulatory advice when those are needed.
A concise workflow for exceptions
An exception arises when a defined control cannot be executed as planned. Examples include: a patch not applied within the SLA, a temporary deviation from a configuration baseline, a privileged account retained past expiry, a delayed backup verification, or a missing vendor evidence package.
Rather than starting from “can we grant a waiver?”, frame the problem from an auditor’s perspective: “what evidence proves this waiver was known, approved, limited and monitored?” That mindset prevents exceptions from living in email threads, chat histories, or only in people’s memories.
A minimum, defensible workflow covers five stages: opening, classification, approval, monitoring, and closure. Each stage should produce evidence — without it, even a reasonable operational decision looks ungoverned.
- Opening: document which control is not met and why (ticket, formal request, asset/process affected)
- Classification: assess impact, risk and urgency (risk assessment, severity, control reference)
- Approval: record who authorized the exception and until when (owner sign-off, expiry date, conditions)
- Monitoring: record how risk is mitigated while the exception is active (compensating controls, periodic checks, logs)
- Closure: demonstrate return to compliance (remediation proof, final verification, audit trail)
When is an exception acceptable — and when is it a finding?
An exception should not be used to normalize an ineffective control. It is acceptable only if it has a clear purpose, a limited timeframe, a defined owner and an explicit residual risk. Missing any of these elements increases the chance the exception becomes a finding or a nonconformity.
Regulations and frameworks use different terminology but converge on the same principles: risk-proportionate controls, defined responsibilities and demonstrable evidence of what was done. For example, NIS2 requires cybersecurity risk management measures for essential entities and important entities; DORA focuses on digital operational resilience in the financial sector; GDPR requires appropriate technical and organizational measures proportionate to processing risk; and ISO/IEC 27001 provides an established information security management standard.
In practice, you do not need to quote a framework in the exception record — you must link the exception to the actual control. If a control exists to mitigate a risk, the waiver must explain what residual risk remains and who accepts it.
Exception, finding and incident are different
- Exception: an authorized, temporary deviation from a control.
- Finding: a shortcoming identified by an audit, assessment or internal review.
- Incident: an event that compromises or threatens confidentiality, integrity, availability or other security goals.
This distinction guides the correct process. A postponed patch with documented approval, a risk assessment and compensating monitoring is an exception. The same postponed patch without approval is a finding. If the vulnerability is exploited, the case follows your incident management process.
The exceptions register: your central piece of evidence
The single most important artifact for managing exceptions is the exceptions register. It should show the universe of deviations from controls, who owns them and which are nearing expiry. A well-maintained register lets CISOs, DPOs, risk managers and internal auditors see whether exceptions are isolated incidents or signs of systemic weakness.
The register must be structured and actionable — not a free-text archive. Each entry should link to the specific control, asset or process, the relevant risk, and a review date. If an exception affects personal data processing, involve privacy experts; if it impacts critical ICT services or third parties, assess resilience and business continuity implications.
Linking the register to evidence already collected in everyday processes — rather than duplicating files — makes it easier to maintain a defensible trail. See also our guidance on evidence management in audit at /en/blog/evidenze-di-audit.
Minimum fields for a usable register
Balance simplicity and completeness. At minimum include:
- Unique exception ID and opening date
- Affected control, requirement or internal policy
- Asset, system, process or vendor involved
- Operational rationale for the deviation
- Control owner and remediation owner
- Risk assessment and residual risk rating
- Active compensating controls
- Required approvals and who provided them
- Expiry date, current status and closure evidence
Those fields let an auditor reconstruct the exception story without chasing information across tools.
Evidence to collect for every exception
Approval alone does not prove an exception was managed. Auditors ask, “how do we know this exception was handled?” Evidence should cover decision, execution and closure. Store verifiable, timestamped artifacts — not ad hoc screenshots without context.
Suggested evidence types:
- Request for exception: shows scope and rationale (ticket with control and asset references)
- Risk assessment: documents residual risk and acceptance (impact, likelihood, justification)
- Approval record: proves accountability (control owner sign-off and any additional required approvals)
- Compensating control evidence: shows temporary mitigations (monitoring rules, segregation, extra access reviews)
- Remediation evidence: confirms return to standard (patch logs, configuration snapshots, re-executed control results)
- Audit trail: preserves integrity of the record (change logs, version history, timestamps and user IDs)
Audit trails deserve special attention: if approvals or changes can be altered without trace, the evidence loses credibility. Follow best practices for audit trails and evidence handling; see /en/blog/audit-trail-best-practices for more.
An end-to-end operational workflow
A usable exceptions workflow must be simple enough for IT teams to adopt and rigorous enough to withstand external review. The guiding principle: separate the roles — the reporter, the approver, the remediation executor and, when risk is material, an independent verifier.
Opening and triage
Open an exception as soon as you know a control will not be met. Waiting until a deadline reduces options for mitigation and lowers the quality of decisions.
In triage, confirm whether the item is really an exception. If the control is obsolete, update the control. If it’s already an audit finding, treat it as such. If an incident is occurring, follow your incident management process.
Approval with owner and residual risk
Approval should not be delegated only to the operational team facing the issue. The control owner must confirm the impact; the risk owner must accept the residual risk; and relevant functions should be engaged if the exception affects personal data, critical services, or key suppliers.
Expiry date is intrinsic to approval. An exception without an end date is an unmanaged permanent change. For longer remediations, set periodic reviews and explicit renewal conditions.
Compensating controls
Compensating controls must be concrete, executable and verifiable. “Enhanced monitoring” is insufficient unless the record defines what is monitored, who performs it, how often, and what evidence is produced.
Examples: increased access reviews, targeted log alerts, temporary network exposure limits, additional segregation, or manual reconciliation procedures. Assign an owner and capture proof of execution for each compensating control.
Closure and independent verification
Closure requires positive evidence that the control returned to the defined standard or that the deviation has been absorbed by an approved control change. When risk is significant, a verifier independent of the remediation activity should validate closure.
The closure record should include date, evidence, verification result and reference to the original exception. If remediation uncovers additional issues, record them separately as new findings or corrective actions.
Common mistakes that weaken an audit position
- Approving exceptions retroactively without documenting why they weren’t opened earlier. Occasional backdating happens, but it must be an exception, not a practice.
- Repeatedly renewing the same exception. If a waiver is extended multiple times, the problem is structural — consider redesigning the control or launching a remediation program.
- Storing evidence across dispersed channels. Approvals in chat, screenshots in personal folders and incomplete tickets do not form a coherent audit trail. Auditors should be able to follow decisions end-to-end.
- Failing to connect exceptions to the internal audit program. Integrating the exceptions register into your internal audit tooling helps convert recurring waivers into signals for control improvement. See /en/blog/software-audit-interno for integration ideas.
Useful metrics for reporting
Keep metrics simple, stable and actionable. Examples:
- Number of open exceptions by affected control
- Average age of exceptions
- Percentage of exceptions past expiry
- Number of renewals per exception
- Distribution of exceptions by owner
- Residual risk severity distribution
- Average time to close
Reporting should distinguish accepted exceptions within thresholds, those nearing expiry, those overdue, and those that must be escalated into structural remediation. For environments subject to NIS2, consider mapping exceptions and controls to relevant security safeguards. See our operational approach to NIS2 controls and evidence at /en/blog/nis2-audit-controlli-evidenze.
Quick checklist: is the exception audit-ready?
Before presenting an exception in audit, verify:
- Is the affected control unambiguously identified?
- Is the operational rationale understandable outside the IT team?
- Has residual risk been assessed and accepted by the appropriate owner?
- Are compensating controls defined with frequency, owner and evidence?
- Is the expiry date explicit and unambiguous?
- Is there a remediation owner and expected proof of closure?
- Does the audit trail show who changed what and when?
If any answer is missing, the exception may be operationally reasonable but weak from an evidence standpoint.
Frequently asked questions
Is an exception always a nonconformity? No. It can be an authorized temporary deviation if it is documented, approved, time-boxed and supported by compensating controls. Without governance, it becomes a finding.
Who should approve an IT exception? It depends on risk and scope. At minimum, involve the control owner and the risk owner. If personal data, critical services or major suppliers are involved, include relevant functions (privacy, continuity, vendor risk).
How long should an exception last? As short as realistically possible. The duration must be justified, approved and periodically reviewed. Repeated renewals usually indicate a structural problem.
What is the most important evidence? There is no single artifact. Auditors expect a chain: the request, the risk assessment, the approval, compensating controls, monitoring, remediation and closure verification.
Does the exceptions register replace the risk register? No. The exceptions register tracks temporary deviations from controls. The risk register documents risks, treatments and owners at a broader level. The two should be linked when an exception changes residual risk.
If you need a practical evidence pack tailored to NIS2 or want to see how AuditReady can help manage controls, exceptions and remediation evidence, consider scheduling a demo at /en/auditready/lp/nis2.
Note: this guidance is operational and not legal advice.