Common mistakes include vague control descriptions, no mapping to the original control, and failing to explain why the substitute control reduces risk. Teams also forget evidence, ownership, review dates, and expiry criteria. Good documentation shows the gap, the alternate control, how it is tested, and when the exception ends.
How compensating control documentation goes wrong
compensating control documentation is often weakest where the exception itself is most sensitive. The common failure is not the lack of a substitute control, but the lack of a defensible story that shows what gap exists, what risk remains, and why the alternate control is strong enough to justify temporary acceptance.
Vague language is a frequent problem because it hides the actual security decision. “Additional monitoring” or “manager approval” may sound reassuring, but without a precise description of scope, trigger conditions, and enforcement point, reviewers cannot tell whether the control truly offsets the original weakness or merely adds paperwork around it.
A second common mistake is failing to connect the compensating control back to the original requirement. A good document makes the relationship explicit, showing which control objective is not being met, what risk is introduced by the exception, and how the substitute control reduces that risk enough to be acceptable for a limited period.
What strong documentation needs to show
Strong compensating control documentation reads like a small control case file, not a policy note. It should describe the exact gap, the alternate control, the evidence that proves the alternate control operates, and the date or condition that ends the exception. That structure matters because a control that cannot be tested is hard to trust, and a control that never expires tends to become permanent by accident.
Ownership is another detail teams often leave out. If no one is accountable for testing, reviewing, and renewing the exception, the documentation may survive while the control quietly degrades. Clear ownership also helps reviewers decide whether the control belongs with the control owner, the system owner, or a risk exception process with a defined approver.
Review cadence and expiry criteria are just as important as the control itself. Documentation should state when the exception will be revisited, what evidence is required for renewal, and what event forces closure. Without that, teams lose the ability to distinguish a short-lived workaround from a long-running control gap that should have been remediated.
What good exception evidence looks like in practice
Good evidence is specific to the substitute control, not generic proof that the team is “aware” of the issue. If the alternate control is detective, show what it alerts on and who responds. If it is preventive, show what configuration or approval gate blocks the risky action. If it is procedural, show how often it is performed, by whom, and how failures are tracked.
Useful documentation also shows the test method. That can be a sample review, an access check, a log review, a workflow record, or an attestation process, depending on the control. The key question is whether a reviewer could repeat the test and reach the same conclusion about whether the compensating control is actually working.
For teams that manage exception-heavy programmes, a control mapping discipline helps keep the documentation consistent. NHIMG’s Control Mapping Guide is useful here because it frames control relationships, evidence reuse, and current-state mapping as part of one governed process rather than one-off paperwork.
Where the exception involves privilege, access paths, or conflicting duties, the underlying documentation should be precise enough to show how the alternative control limits misuse. NHIMG’s Segregation of Duties (SoD) Guide is a good reference for understanding how mitigations and compensating controls should be described when a direct preventive control is not possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | Compensating controls must be testable and reassessed over time. |
| CA-5 — Plan of Action and Milestones | Exceptions need tracked remediation, ownership, and expiry management. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Many compensating controls rely on monitoring and review evidence. | |
| Recommendation — Verify compensating controls with repeatable assessments and retain the evidence. Track exceptions with owners, due dates, and closure criteria. Review logs and alerts to confirm the substitute control is operating as intended. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | Exception handling should align with governed policy and approval paths. |
| A.5.36 — Compliance with policies, rules and standards for information security | Compensating controls exist to manage nonconformity against security requirements. | |
| Recommendation — Define exception approval and review rules in policy. Record how the substitute control satisfies the requirement being missed. | ||
Practitioner Guidance
What to verify: Check that every exception record names the broken control, the substitute control, the evidence source, the reviewer, and the expiry condition. If any of those are missing, the documentation is not yet strong enough for audit or operational reliance.
Common mistake: Do not let compensating control writeups become narrative approvals. The document should prove risk reduction, not simply explain why the team needed an exception.
What good looks like: The best records make it easy for a second reviewer to answer three questions quickly: what is missing, what replaces it, and how long that replacement can be trusted.
Practitioner takeaway: Treat compensating control documentation as a temporary control design, not a justification memo. If the gap, the substitute, the evidence, and the sunset are not all explicit, the exception is probably more fragile than the document suggests.