Why your risk register does not map to your SoA (and how auditors spot it)

Most organisations that approach certification with a credible-looking Statement of Applicability also carry a risk register that tells an entirely different story. Within ten minutes of opening both documents, an experienced auditor can see the gap. This article explains what that gap looks like, why it appears, and how to close it before your stage two or surveillance audit.

What the standard actually requires

ISO 27001:2022 Clause 6.1.2 requires you to identify information security risks, assess them, and then choose treatment options. Annex A controls become relevant at the point of treatment: you select, justify, or exclude them based on the risk picture you have built. The SoA (required by Clause 6.1.3d) is meant to be the output of that treatment decision process - not a separate checklist you fill in independently.

The word "mapped" does not appear in the standard, but the logical chain is inescapable. Every included control in your SoA must have a reason for inclusion, and that reason must trace back to at least one risk, legal obligation, or contractual requirement. Every excluded control must have a credible justification for why the risk does not apply or is addressed another way.

The disconnect auditors see in ten minutes

An auditor will typically open both documents on the same screen and run a basic cross-check. Here are the signals that trip most organisations:

Controls included in the SoA with no corresponding risk. The SoA says A.8.5 (Secure authentication) is applicable. The risk register has nothing about compromised credentials, brute force, or authentication bypass. The auditor asks: "Show me the risk that led to this control being included." Silence, or a vague reference to "general IT risk," is not an answer.

Risks in the register that lead nowhere. The register identifies "unauthorised access to source code repository" as high severity after treatment. No control in the SoA is linked to it. The auditor asks: "How is this risk being treated?" Without a clear control or documented acceptance, the treatment decision is missing.

Boilerplate justifications. Justification cells that read "industry best practice" or "required by policy" appear in almost every SoA that was built from a template without being tailored. They tell the auditor nothing about the organisation's specific risk picture and are almost always a flag for a deeper look.

Different classification schemes. The risk register uses a 5x5 likelihood/impact matrix; the SoA references a different residual risk threshold. The auditor cannot reconcile the treatment decisions because the inputs and outputs use incompatible scales.

Why the gap appears in the first place

The root cause is almost always sequencing. Teams build the risk register as one workstream and the SoA as another, then attempt to link them retrospectively. This is understandable - the SoA is long, the risk assessment is unfamiliar methodology, and time pressure is real - but it produces exactly the disconnect an auditor is trained to find.

A secondary cause is scope creep in the risk register. Registers grow over time, often absorbing operational risks, compliance risks, and IT project risks that were never part of the ISMS scope. When the scope is unclear, it is impossible to verify that every in-scope risk has a treatment decision reflected in the SoA.

Making treatments trace to SoA decisions

The fix is not technically complex, but it does require discipline across both documents.

Add a treatment reference column to your risk register. For every risk where treatment is "mitigate," the register should list the Annex A control reference (or references) that deliver that mitigation. For "accept," the register should record who accepted it and when. For "transfer," it should name the mechanism - insurance, contract clause, or supplier obligation.

Add a risk reference column to your SoA. For every included control, the SoA should list the risk ID or IDs from the register that justify inclusion. A control can be justified by more than one risk; that is fine. What is not fine is a blank field.

Run a two-way trace before you close your internal audit. Start from the risk register and check that every mitigated risk has a mapped control. Then start from the SoA and check that every included control has a mapped risk. Gaps in either direction need to be resolved, not noted for later.

Keep the documents in the same review cycle. If the risk register is reviewed quarterly but the SoA is only reviewed annually, they will drift. The SoA should be reviewed whenever a material change is made to the risk register - at minimum at the same frequency.

Common weak links auditors probe further

Beyond the mapping itself, auditors tend to probe a few specific areas once they have spotted a gap:

• Residual risk sign-off. The standard requires that residual risks are accepted by risk owners. If the risk register records a post-treatment residual rating but has no named risk owner or acceptance signature, the treatment process is incomplete regardless of what the SoA says.
• Exclusions without evidence. Excluding A.5.23 (Information security for use of cloud services) requires a credible argument that cloud services are genuinely out of scope. Auditors will check the asset register and supplier list to test that claim.
• New controls in Annex A 2022. The 2022 revision added eleven new controls, and the transition period closed on 31 October 2025 - all audits now run against the 2022 structure. If your SoA still reflects the 2013 structure without a documented rationale for how the new controls have been considered, an auditor will raise it at any surveillance or recertification visit.

The practical order of operations

If you are building from scratch or rebuilding a broken mapping, the sequence that works is:

1. Agree your ISMS scope and the assets and processes it covers.
2. Identify risks against those assets and processes, using consistent methodology.
3. Select treatment options for each risk above your acceptance threshold.
4. Identify which Annex A controls deliver the treatment, and document that link in both the risk register and the SoA.
5. For controls not selected, write a specific, evidence-backed exclusion justification - not a generic statement.
6. Have risk owners formally accept residual risks.
7. Run the two-way trace described above before any audit.

This order means the SoA is built from the risk assessment, not alongside it. Auditors can see that logic when they open both documents together, and it holds up under questioning.

Where Kellwick fits

At Kellwick, a core part of our readiness assessment is running the two-way risk-to-SoA trace before your auditor does. We identify the gaps, help you resolve the mapping, and make sure exclusion justifications are specific enough to hold up in an audit room - so you are not explaining the disconnect on the day.