ISO 27001 Risk Assessment and the Statement of Applicability: The Gap Auditors Find

The most common finding on an ISO 27001 audit is not a missing control. It is a Statement of Applicability that does not reconcile with the risk assessment. Controls sit there marked applicable while treating no identified risk, and identified risks sit there with a treatment option chosen and nothing in the SoA actually doing the treating.

Both documents look fine on their own. That is why it survives so long. The SoA is complete, the risk register is populated, and neither one points at the other. The system reads as finished and is, in practice, two unrelated pieces of paper.

This article covers what clause 6.1 actually asks for, why Annex A is a completeness check rather than a starting point, what the disconnect looks like in both directions, and a twenty minute test you can run on your own system before an auditor runs it for you.

What clause 6.1 actually requires, in order

Clause 6.1 splits into two parts, and the order inside them is the whole point.

6.1.2 Information security risk assessment. You define and apply a risk assessment process that establishes risk criteria, including risk acceptance criteria and criteria for performing assessments. It has to produce consistent, valid and comparable results. You identify risks to confidentiality, integrity and availability, assign a risk owner to each, analyse them (consequences, realistic likelihood, resulting level of risk) and evaluate them against your criteria to set priorities.

6.1.3 Information security risk treatment. Then, in this sequence:

1. Select treatment options appropriate to the assessment results
2. Determine all controls necessary to implement those options
3. Compare those controls against Annex A to verify none have been omitted
4. Produce a Statement of Applicability
5. Formulate a risk treatment plan
6. Obtain risk owners’ approval of the plan and acceptance of the residual risks

Step 2 comes before step 3. You work out what you need from the risks, and then you check Annex A to see whether you missed anything. The standard also makes clear that controls can be designed by you or drawn from any source. Annex A is not the only permitted menu.

Annex A is a cross-check, not a starting point

This is where most systems go wrong, and it is an easy mistake to make because working the other way round feels so much more organised.

You open a spreadsheet of the 93 Annex A controls, go down the list marking each one applicable or not applicable, write a justification in each row, and at the end you have a complete, tidy, professional looking Statement of Applicability. It took a day. It looks like the deliverable.

The problem is that nothing in that process referenced a single risk. You produced a document about Annex A, not a document about your organisation. Read clause 6.1.3 again: the SoA is meant to be the output of deciding how to treat your risks. Starting from the annex inverts the logic, and the inversion is visible in the result.

Tooling makes this worse rather than better. Most compliance platforms open on the control list, because a control list is easy to render as a progress bar. The risk assessment is a separate module you visit later, if at all.

The gap: an SoA that never connects to the risk assessment

Once the annex is the starting point, the two documents drift apart, and the failure shows up in both directions.

Direction one: controls marked applicable that treat no identified risk

A control is marked applicable because it is obviously sensible, because the template had it ticked, or because it felt uncomfortable to exclude. Ask which identified risk it treats and there is no answer, because no risk drove the decision.

This is not a harmless bit of over-inclusion. Every control marked applicable is a control you have to implement, evidence, maintain and be audited against. Marking things applicable to look thorough commits you to work that nothing in your risk assessment asked for, and it is your budget and your team paying for it.

Direction two: risks with a treatment option and no control doing the treating

This is the more serious one. A risk is identified, analysed, evaluated as unacceptable, and given a treatment option of “modify”. Then follow it forward. Which control implements that modification? Is that control in the SoA? Is it marked applicable? Is it implemented?

Very often the chain breaks at the first link. The risk was treated on paper by selecting an option, and nothing was ever nominated to carry it out. The residual risk was then accepted by a risk owner on the basis of a treatment that does not exist.

That is the miss that matters. Controls marked applicable in the Statement of Applicability have to actually be the controls that treat your identified risks. If the SoA and the risk assessment cannot be read against each other, clause 6.1.3 has not been met, no matter how good either document looks in isolation.

Test your own system in twenty minutes

You do not need an auditor to find this. Put the risk assessment and the Statement of Applicability side by side and sample in both directions.

Backwards, from the control. Pick five controls marked applicable, ideally ones that cost you real effort. For each, name the identified risk it treats. If you cannot point at a row in the risk assessment, the control is in your SoA for a reason the standard does not recognise.

Forwards, from the risk. Pick your five highest rated risks. For each, name the control or controls that treat it, find them in the SoA, confirm they are marked applicable, and confirm they are marked implemented. Then look for the evidence that they are operating.

Four failure patterns come out of this, and each has a different fix:

If the sample comes back clean, your system is in better shape than most. If it does not, you have found it in twenty minutes rather than in a certification body’s Stage 2 report.

What the traceability should look like

You do not need special software for this. A reference column in each document is enough, as long as it is maintained. The chain has to run end to end and be readable in both directions:

• Risk with an identifier, an owner, and an evaluated level
• Treatment option chosen for it, appropriate to that level
• Control nominated to carry out the treatment, with its Annex A reference where it has one
• SoA row for that control, marked applicable, with the justification pointing back at the risk identifier
• Implementation status, and where it is not yet implemented, a line in the risk treatment plan with an owner and a date
• Evidence that the control is operating, generated as a by-product of normal work rather than assembled for the audit
• Residual risk re-evaluated and accepted by the risk owner, on the basis of the control as it actually operates

The justification column is where most of the value sits, and it is the column most often filled with something like “industry good practice”. A justification that names the risk it addresses makes the whole chain auditable in one read.

What the Statement of Applicability has to contain

Under ISO/IEC 27001:2022 the SoA is documented information, and it must contain four things:

• The necessary controls, being the ones you determined from your risk treatment
• The justification for including each of them
• Whether each is implemented or not
• The justification for excluding any Annex A control you have left out

Two of those are routinely mishandled. The implementation status is often left implied, so an auditor cannot tell a working control from an intention. And exclusion justifications are often circular, along the lines of “not applicable because we do not do this”, which restates the exclusion rather than justifying it. Say what it is about your scope, your context or your risk profile that makes the control unnecessary.

Worth remembering that “applicable but not yet implemented” is a legitimate position. It is only a problem when it has no owner, no date and no line in the risk treatment plan. Then it is an open gap wearing the costume of a decision.

Three more things worth checking

You are working from the current Annex A. The 2022 revision reorganised the controls into 93 across four themes: organisational, people, physical and technological. The 2013 version had 114 across fourteen clauses. Templates and articles referring to 114 controls are out of date, and search demand for “iso 27001 controls 114” suggests plenty of people are still working from them.

Risk owners have actually approved. Clause 6.1.3 requires risk owners’ approval of the risk treatment plan and acceptance of the residual risks. This is frequently absent, or represented by a single management signature covering everything. Residual risk acceptance is a decision by the person who owns the consequence, not an administrative sign-off.

The assessment is repeatable. Clause 6.1.2 asks for consistent, valid and comparable results. If two people running your process on the same risk would land on materially different ratings, your criteria are not defined tightly enough, and next year’s comparison will be meaningless.

Why this matters beyond passing the audit

A reconciled SoA is not a documentation exercise. It is the only thing that tells you whether the money you are spending on security is pointed at the things that would actually hurt you.

When the two documents are disconnected, you get both errors at once: effort spent on controls nothing asked for, and real risks carrying treatments that were never built. The audit finding is the cheap consequence. The expensive one arrives when something happens and you discover the control you were relying on was a row in a spreadsheet.

This is also what separates a system that reflects how the work actually gets done from a document pack. The evidence for a real control is a by-product of running the business. The evidence for a paper control has to be manufactured, and it never quite reconciles with anything else.

Frequently asked questions

What is a Statement of Applicability?

A required ISO 27001 document listing the controls you have determined are necessary to treat your information security risks, why each is included, whether each is implemented, and why any Annex A control has been excluded. It is the output of your risk treatment, not a checklist you fill in beforehand.

Do I have to use Annex A controls?

No. You determine the controls necessary to treat your risks, from any source, including ones you design yourself. Annex A is then used to check that nothing necessary has been omitted, and you justify any Annex A control you exclude.

How many controls are in Annex A?

93 in ISO/IEC 27001:2022, across four themes. The 2013 version had 114. See our breakdown of the Annex A controls.

Can a control be applicable but not implemented?

Yes, and the SoA has to say so. It needs a corresponding entry in the risk treatment plan with an owner and a target date, and the risk owner needs to have accepted the residual risk in the meantime.

Does ISO 27001 require a risk register?

The standard requires documented information about the risk assessment process and its results. It does not prescribe a register, a format or a tool. A register is a common and sensible way to hold the results, but the requirement is the traceable chain from risk to control to evidence, not the artefact.

If you would rather not untangle this yourself, our ISO 27001 consulting and internal audit service covers scope, risk assessment and the Statement of Applicability, with a free consultation to start.

Do I need ISO 31000 to do this?

No. ISO 27001 does not require any particular risk methodology. ISO 31000 is a useful framework and many organisations use it, but the requirement is that your process is defined and produces consistent, valid and comparable results.