Not every finding gets fixed. A supplier has no patch, a system cannot be upgraded before a migration completes, a fix would break an integration the business depends on. Those are legitimate positions, and they become a problem only when nobody records the decision. ISO 27001 expects risk acceptance to be an explicit act by someone with the authority to accept it, which is a useful standard whether or not you are certified.
What a defensible acceptance contains
Six things, and none of them take long to write. The specific finding and the systems affected. Why it cannot be remediated now, in concrete terms rather than as a general difficulty. What compensating controls are in place and how they reduce the risk. Who owns the exception. Who accepted it, with their role, since a critical finding should not be accepted by the engineer who found it. And an expiry date, which is the field that turns an exception into a decision that gets revisited rather than a permanent condition nobody remembers agreeing to.
Getting the approval level right
Match the approver to the consequence. A low severity finding on an internal system can reasonably be accepted by a technical manager. A critical finding on an internet-facing system holding customer data should go to a director, because the decision is a business one about accepting a risk to customers and to the organisation’s obligations. Publishing that scale in advance removes the awkwardness: nobody has to argue about who signs, because the rule was agreed before the finding appeared.
“The exception register is the first document I ask for on a maturity review, and it tells you more about an organisation than the vulnerability numbers do. A short register with expiry dates and named directors means the process works. A long spreadsheet with entries from 2021 and no owners means the register is where findings go to be forgotten.”
William Fieldhouse, Director, Aardwolf Security Ltd
Compensating controls that mean something
An acceptance is only as good as the controls behind it. Network restriction, additional monitoring, reduced privileges and manual review are all legitimate, and each needs to be verified rather than asserted. If the control is that a vulnerable system is only reachable from one subnet, somebody should test that from another subnet and record the result. Assessors and auditors ask this question routinely, and an organisation that has already tested its own compensating controls answers it in a sentence rather than promising to check and come back.
Keeping the register honest
Review it quarterly and let entries expire rather than rolling them forward automatically. Report the number of open exceptions and their average age alongside your other metrics, since a growing register is a signal that remediation capacity is short. Where an exception has stood for more than a year, treat it as a project rather than a decision, and give it a budget line if that is what resolving it needs. Vulnerability management supportkeeps the underlying data current, and an independent testing partnercan confirm whether the compensating controls hold when somebody actually pushes against them.
Frequently asked questions about risk acceptance
These questions come up whenever a remediation backlog is reviewed.
Can you accept a risk that breaches a regulation?
No. Where a control is required by law, a contract or a certification scheme, acceptance is not available and the position needs escalating rather than documenting. Recording it does not make it acceptable.
How long should an exception last?
No longer than a year, and usually far less. Tie the expiry to a real event where you can, such as a planned migration or a supplier release, so the review has something concrete to consider.
