Risk Assessment for Compliance: How to Do One Auditors Accept
- A risk assessment is a defensible chain: asset, threat, existing control, likelihood, impact, decision, owner, review date.
- The auditor question that breaks most assessments is "why this rating" - so record the reasoning, not just the number.
- Accepting a risk is a legitimate treatment, as long as it is a dated decision with a named owner rather than an unworked queue item.
- A register that has never been updated is evidence against you: it shows the process ran once.
A risk assessment that satisfies an auditor is a documented, repeatable chain of reasoning: what you are protecting, what could go wrong, what already reduces it, how likely and how bad, what you decided to do, who owns it, and when it gets looked at again. The number at the end matters far less than whether you can explain how you got there.
ISO 27001 makes this a required clause rather than a nice-to-have, and other frameworks lean on it heavily as supporting evidence. It is also the single artefact that most often gets produced the night before fieldwork, which auditors recognise immediately.
The chain, step by step
- Inventory what you are protecting. Systems, data stores, and the data categories inside them. Not a network diagram - an asset list with an owner per line. If you cannot name an owner, that is your first finding.
- Identify what could go wrong. Per asset, not in general. "Ransomware" is not a risk to your product database; "customer data is encrypted by an attacker and we cannot restore within our RTO" is.
- Record the controls you already have. This is the step most teams skip, and it is why their ratings look implausible. A risk with MFA, offsite backups and monitoring in place is not the same risk as one without.
- Rate likelihood and impact. Use a scale, define what each level MEANS in your context, and apply it consistently. A five-point scale with written definitions beats a ten-point scale with none.
- Decide the treatment. Mitigate, transfer, avoid, or accept. Each is legitimate.
- Assign an owner and a date. A risk with no owner is a note.
- Record residual risk. What remains after the treatment. This is what leadership is actually signing off on.
- Review on a schedule. And keep the previous version, because change over time is the evidence that the process is alive.
The question that breaks most assessments
An auditor will point at a row and ask why it is rated the way it is. If the answer is "that felt about right", the assessment stops being evidence.
The fix is cheap: add a sentence of reasoning per row. "Likelihood medium: internet-facing, but authentication is enforced and no exploitation has been observed against this component." That one sentence turns a number into a judgment someone made, which is the whole point.
A risk assessment is not a scoring exercise, it is a record of decisions. The score is how you sort the decisions; the reasoning is what makes them defensible.
Accepting risk is allowed
Teams treat acceptance as an admission of failure and quietly leave things in the queue instead. That is worse. An unworked queue item is an undocumented accepted risk with no owner and no date.
A proper acceptance names the risk, states why the treatment cost is disproportionate, identifies who accepted it and at what level of authority, and sets a date to revisit. Auditors are entirely comfortable with that. What they object to is finding an obvious gap that nobody had noticed or decided about.
Common failure patterns
| Pattern | Why it fails |
|---|---|
| Generic threat catalogue copied in | No link to your assets, so no defensible ratings |
| Ratings with no stated reasoning | Collapses on the first "why this number" |
| Existing controls not recorded | Ratings look invented, because effectively they are |
| Register never updated | Proves the process ran once, which is worse than none |
| Everything rated high | No prioritisation, so nothing was actually decided |
| Owners are teams, not people | Nobody is accountable |
Where technical testing feeds it
A risk assessment is only as good as its inputs, and the weakest input is usually the likelihood of a technical flaw being exploitable. That is a question you can answer with evidence instead of estimating: a validated finding tells you an attack path exists in your application, which changes a rating from a guess to an observation.
This is the argument for feeding test results into the register rather than treating them as a separate report. Our audit preparation guide covers where the register sits among the rest of the evidence, and the compliance hub sets out how each framework treats risk assessment and testing.
Frequently asked questions
What does a compliance risk assessment need to contain?
An asset with a named owner, the specific thing that could go wrong, the controls already in place, likelihood and impact against a defined scale, the treatment decision, an owner, the residual risk, and a review date. Plus a sentence of reasoning per rating.
How do I justify risk ratings to an auditor?
Record the reasoning next to the number. One sentence naming the factors you weighed - exposure, existing controls, observed activity - turns a score into a documented judgment, which is what an auditor is testing for.
Is it acceptable to accept a risk rather than fix it?
Yes, when it is a real decision: the risk named, the disproportionate treatment cost stated, the accepting authority identified, and a date to revisit. What auditors object to is an obvious gap nobody noticed or decided about.
How often should a risk register be reviewed?
On a defined schedule, and after any significant change, with previous versions kept. A register that has never changed is evidence that the process ran once rather than that it operates, which is worse than not having one.