Policy exceptions in ISO 27001: how to approve and track deviations safely

A policy exception is a recorded, approved decision to not follow a policy in a specific case, for a limited time. A legacy system that can't support multi-factor authentication, a contractor who needs a personal laptop for a month, a supplier who can't meet your encryption standard yet: rather than pretending these don't exist, you record them, assess the risk and agree how you'll manage it.

An exception you've approved is good governance. One nobody knows about is a nonconformity waiting to be found.

Why it matters

ISO/IEC 27001:2022 doesn't use the word "exception", but exceptions connect to several requirements:

• Clause 6.1.3: risks that remain must be accepted by their owners. An exception is usually a risk acceptance.
• Annex A 5.1 (policies): policies must be followed, and reviewed. A trail of exceptions shows where a policy may need changing.
• Clause 10.2: an undocumented deviation from a policy is a nonconformity.

What to record

• What the exception is, and which policy or control it departs from.
• Why it's needed, and the business impact of refusing it.
• The risk, and any compensating controls (for example, restricting network access to the legacy system).
• Who approved it: the risk owner, with authority to accept the risk.
• An expiry or review date. Exceptions should end, or be renewed deliberately.

What an auditor looks for

• Exceptions are documented and approved, not informal agreements.
• Each has an end date or review, and expired ones were closed or renewed.
• Compensating controls are in place and can be shown.
• Patterns lead to change. If the same policy needs exceptions every month, it's been reviewed.

Common reasons it fails: the auditor finds a deviation with no record; exceptions with no end date; or exceptions approved by the person who asked for them.

Common mistakes, and how to keep it manageable

• Permanent exceptions. If something will never comply, change the policy or record a long-term risk acceptance instead.
• No compensating control. Always ask what reduces the risk while the exception lasts.
• Lost in email. Keep the request, decision and review in one record.

How to do it in ClearIMS

1. Open Exceptions and record the exception: the policy it departs from, why, the risk and any compensating controls.
2. Send it for approval. Exceptions have their own workflow, so the decision and who made it are recorded. The AI never approves anything.
3. Set a review date so it comes back before it lapses.
4. Link it to the risk it affects in your risk register.

Related pages

• Risk register: the risk an exception accepts.
• Treatment plans: the longer-term fix.
• Controls and policies: the policy being departed from.
• Nonconformities: what an unrecorded exception becomes.