From risk to control: making the Statement of Applicability work for your ISMS

When we reviewed the observations raised across recent client ISO 27001 audits, the most consistent theme wasn’t a missing control. It was the gap between the risk register and the Statement of Applicability . Both documents existed. Both had been reviewed. What they didn’t do was talk to each other: risks with no named controls, SoA rows justified with a single word, and controls marked applicable that nobody could connect to anything the organisation was actually worried about.

That gap matters more than it looks. The risk register explains what the organisation is concerned about. The Statement of Applicability should explain what the organisation is doing about it. When the two are disconnected, the ISMS starts to become a collection of ISO documents rather than a working management system, and the SoA becomes something updated once a year, shortly before the auditor arrives.

This piece walks through how to connect them, following one thread from start to finish:

Asset → confidentiality, integrity and availability → risk → treatment → control → SoA → implementation → evidence → residual risk

Key takeaways

• The SoA should be an output of your risk management process, not the starting point for it. Start with what you’re trying to protect, not with the 93 Annex A controls.
• Assets are much more than hardware. Information, processes, SaaS platforms, suppliers and people’s knowledge usually matter more than the devices they sit on.
• Risk-to-control mapping isn’t one-to-one. One risk can need several controls, and one control can reduce several risks.
• Annex A is a reference set for checking you haven’t missed anything, not a checklist to justify. It’s also not a boundary: if a risk needs a control that isn’t in Annex A, add one.
• Mark a control applicable only if you can explain why it’s needed today. Expect an auditor to audit everything you mark applicable.
• Consistent identifiers across the risk register, SoA, policies and evidence let anyone follow the thread from a risk to the proof that it’s being managed, in either direction.

Start with the asset, not the Annex A control

A common pattern in ISO 27001 programmes is to start with the 93 Annex A controls and ask which of them to implement. The better first question is: what are we trying to protect?

The word “asset” doesn’t help here. Most people hear it and think of laptops, servers, phones, firewalls and offices. Those are assets, but they’re a small part of the picture. The assets an information security programme exists to protect also include:

• customer information, contracts and intellectual property
• HR data: employee records, and the CVs and application forms of both successful and unsuccessful candidates
• source code, databases and business applications
• business processes, and the SaaS platforms and cloud services they run on
• key suppliers, critical personnel and specialist knowledge
• physical premises, and the organisation’s reputation

A laptop is rarely valuable because it’s a laptop. It’s valuable because of the information, access and business capability associated with it. Thinking in terms of the information and capabilities the organisation depends on, rather than keeping only a hardware inventory, is what makes the rest of this process meaningful. ISO 27001:2022 reflects this in its own wording: control A.5.9 asks for an inventory of “information and other associated assets”, not a list of equipment.

Strictly, ISO 27001 hasn’t required an asset-based risk assessment since the 2013 edition. Scenario-based approaches are equally valid. In practice, though, starting from what you hold and depend on is the most reliable way to make sure the risk assessment covers the things that matter.

Your RoPA is already half of this work

If you process personal data, you already have a head start. A Record of Processing Activities identifies what personal data the organisation processes, why, where it’s held, who receives it, which suppliers process it, how long it’s kept and how it moves through the organisation. That’s a substantial part of an information asset inventory, already written down.

The two documents ask different questions of the same information. The RoPA records what personal data you hold and how it flows. The ISMS asks what could happen to that information and what controls are needed to protect it. Using the RoPA as an input to asset identification saves effort and keeps the privacy and security pictures consistent.

What matters about the asset: confidentiality, integrity and availability

Once you know what an asset is, the next question is what would hurt if something went wrong with it. The three classic properties, often shortened to CIA , give a simple structure:

• Confidentiality: what happens if the information is disclosed to someone who shouldn’t have it?
• Integrity: what happens if it’s changed, corrupted or can no longer be trusted?
• Availability: what happens if the information or service isn’t there when it’s needed?

Two everyday examples show how different the answers can be:

Not every risk fits neatly into one property, and it doesn’t need to. Ransomware is the standard example of a risk that hits all three: availability through encryption, integrity through corruption, and confidentiality through data stolen before anything is encrypted. The value of the exercise is that it forces risks to be described in terms of their impact on the information or service being protected, rather than as a list of threats in the abstract.

From asset to risk to control

With an asset and its CIA concerns identified, the thread continues into the risk assessment and risk treatment . Following one example through:

That last row makes a point worth stating plainly: risk-to-control mapping doesn’t need to be one-to-one. One risk can require many controls, and one control, such as logging, can reduce many risks. That’s normal, and an SoA that tries to force a single control per risk will misrepresent how the organisation is actually protected.

Is the combination enough?

Linking controls back to risk also answers a question a control list can’t: is what we have actually sufficient? “We use MFA” sounds reassuring. Against R-017, it’s one layer. Privileged identity management, separate administrator accounts, conditional access, break-glass account controls, monitoring and access reviews might all be needed before the residual risk is acceptable.

Risk context changes the question from “do we have this control?” to “is the combination of controls sufficient to reduce this risk to an acceptable level?” That’s the question the risk owner has to answer when they accept the residual risk, and it can only be answered if the link exists.

Where the SoA fits

ISO 27001 clause 6.1.3 sets out the order explicitly. The organisation decides how to treat its risks, determines the controls that treatment needs, then compares those controls with Annex A to check nothing necessary has been missed. The SoA records the result: the necessary controls, why each is included, whether each is implemented, and why any Annex A control is excluded. The risk treatment plan follows, and risk owners approve it and accept the residual risk.

Put as a working sequence:

1. Identify assets and business dependencies.
2. Identify and assess information security risks.
3. Decide how each risk will be treated.
4. Determine which controls the treatment requires.
5. Compare those controls with Annex A.
6. Record applicability and rationale in the SoA.
7. Implement the controls.
8. Retain evidence.
9. Assess whether the controls are effective.
10. Review the residual risk.

The SoA appears at step 6, not step 1. It should be an output of the risk management process, not the starting point for it.

Annex A is a reference set, not a checklist

This is the distinction that most often separates a working ISMS from a documentation exercise. ISO 27001 isn’t a requirement to implement 93 controls. Annex A exists so organisations can check they haven’t overlooked something relevant. The standard says so directly: its notes describe Annex A as a list of possible controls, and state that it isn’t exhaustive.

The thinking should run: what controls do our risks require, and have we overlooked anything relevant in Annex A? Not: here are 93 controls, how do we justify implementing them?

In practice, most organisations still end up with most Annex A controls marked applicable, because most of them address risks almost every organisation has. The difference is that each one then has a reason attached, and that reason is what an auditor, a new security manager or the board can actually use.

Applicable doesn’t mean “maybe one day”

A pattern we see regularly at audit is controls marked applicable because the organisation thinks it might do the relevant activity at some point. “We might develop software eventually, so we’ve marked the development controls applicable.”

Marking a control applicable is a statement. It says there’s a current reason for the control, that it forms part of the control framework, that it’s implemented or being implemented, that someone can explain how it operates, and that evidence exists. If the control is marked applicable, expect the auditor to audit it.

The SoA isn’t a catalogue of controls the organisation might need one day. When the business changes, the ISMS should change with it: new activity, then a review of the risk assessment, then a treatment decision, then a review of the relevant Annex A controls, then an SoA update, then implementation. If the organisation starts developing software next year, that sequence is the ISMS working as designed.

That doesn’t rule out “Applicable: planned”. A control can legitimately be applicable but not yet implemented, provided a current risk needs it and the risk treatment plan says when it will be in place. What the SoA shouldn’t contain is controls that are applicable to nothing in particular. If you can’t explain why a control is needed today, think carefully before marking it applicable.

Be careful with outsourced activities

The opposite mistake is just as common. Not performing an activity yourself doesn’t make the related controls irrelevant. An organisation with no developers may still commission software, and so still carry risks around security requirements, source code access, testing, change management and supplier assurance. Controls such as A.8.30 (outsourced development) exist precisely for that situation.

The question isn’t “do we do this ourselves?” It’s: does this control help address a current information security risk, obligation or business requirement within the scope of the ISMS? Our piece on supplier risk covers how much of an organisation’s exposure sits with activities it doesn’t perform directly.

Where ISO 27002 comes in

Annex A control statements are deliberately short, often a single sentence. That’s enough to decide whether a control is needed. It isn’t enough to decide what good looks like.

That’s what ISO 27002 is for. ISO 27001 sets out the management system requirements and provides Annex A as the reference control set. ISO 27002 is the implementation guidance for those same controls, setting out each control’s purpose, guidance on implementing it, and further information. It isn’t certifiable on its own, and it isn’t a list of mandatory steps, but it’s the most useful single reference for turning a selected control into a working one.

The 2022 edition also gives every control a set of attributes, which let you look at your control framework through different lenses:

• Control type: preventive, detective or corrective
• Information security properties: confidentiality, integrity, availability
• Cybersecurity concepts: identify, protect, detect, respond, recover
• Operational capabilities, such as identity and access management or asset management
• Security domains, such as governance or resilience

Filtering by attribute answers questions a plain SoA can’t. Are our availability risks protected only by preventive controls, with nothing detective or corrective behind them? Do our highest confidentiality risks rely on a single capability? That’s where ISO 27002 earns its place in building an actual security framework rather than maintaining a spreadsheet.

The SoA tells you which controls you’ve selected. ISO 27002 helps you understand how those controls may be implemented. Evidence tells you whether they actually work.

What a good SoA contains

Clause 6.1.3 asks for relatively little: the controls, whether they’re included, why, and whether they’re implemented. An SoA can meet that with four columns. A working SoA usually benefits from a few more:

• Control reference: for example, A.5.15 or A.8.24.
• Control name: so the SoA can be read without Annex A open beside it.
• Applicable: a clear yes or no.
• Justification: why the control is or isn’t needed, in your own words. “Not relevant” and “best practice” aren’t justifications.
• Linked risks: the same identifiers used in the risk register, for example R-017.
• Asset or process: what the control protects or supports.
• CIA driver: whether the main concern is confidentiality, integrity, availability or a combination.
• Implementation status: implemented, partially implemented, planned or not implemented.
• Implementation summary: a sentence or two on how the control actually operates here.
• Evidence reference: where the proof lives, such as policies, procedures, configuration exports, reports, tickets, dashboards or records.
• Control owner: who is responsible for keeping it working.
• Review date, so the SoA can’t quietly go stale.
• Notes or actions: planned changes or open improvement items.

Here’s what one row might look like:

And an exclusion that would survive scrutiny: “A.8.30 Outsourced development: not applicable. We don’t commission software development; all in-scope systems are configured SaaS (see asset register). To be reassessed if any development is commissioned.”

A strong SoA lets someone move from control to risk to implementation to evidence without having to guess where the connection is.

Don’t turn the SoA into everything

The opposite failure is an SoA that tries to hold the whole ISMS. It shouldn’t become a second risk register, a policy library, an evidence store, a corrective action log or a long narrative document. Each of those has a proper home. The SoA should reference them.

A sensible balance: control, applicability, rationale, linked risk, implementation summary, evidence reference, owner and status. The detail stays where it belongs.

Consistent references make the ISMS easier to run and to audit

The linkage only works if everything uses the same identifiers. For example:

• Risk: R-017
• Asset: IA-004
• Policy: POL-SEC-03
• Supplier: SUP-021
• Control: A.8.2

Instead of several documents describing the same issue in slightly different words, a single reference can be followed from the risk register through the treatment plan, the SoA and the policy to the evidence. That’s easier to maintain, much faster to audit, and far less likely to drift out of step when something changes.

Annex A is a starting point, not a boundary

ISO 27001 requires you to determine the controls needed to treat your risks. If a control you need isn’t in Annex A, you can and should add one. This matters more each year, because technology moves faster than standards are revised.

AI is the clearest current example. An organisation using generative or agentic AI may identify risks around prompt injection, sensitive information disclosure, autonomous actions, tool permissions, human oversight, model and configuration changes, output validation, training data provenance, third-party AI providers and AI-specific incidents. Some of that is partly covered by existing Annex A controls on access, logging, suppliers and change management. Some of it isn’t, and justifies organisation-specific controls. For example:

• AI-01: Significant AI system and agent activity must be recorded and traceable.
• AI-02: High-impact autonomous AI actions must have defined human approval requirements.

Controls like these sit in the same SoA as the Annex A controls, with the same linked risks, owners, evidence and review dates. We looked at why the first of them matters in our piece on AI agents and forensic readiness .

Additional controls can come from anywhere: ISO 42001 , NIST CSF , the CIS Controls , NIS2 , sector rules, privacy obligations, customer contracts or your own internal standards. Where a control came from matters much less than the questions every control should be able to answer: what risk does it address, why is it necessary, how is it implemented, who owns it, and how do you know it works?

If the risk exists, treat it, even if the control you need doesn’t appear in Annex A.

The same thread serves internal audit and management review

Once the linkage exists, it pays for itself well beyond certification.

An internal audit can follow the whole chain: risk identified, treatment selected, control chosen, SoA entry, implementation, evidence, residual risk. That’s a far stronger audit than checking Annex A controls as isolated items, and it lets the auditor ask a much more useful question. Not “do you have a policy for this control?” but “show me how this control reduces the risk it was selected to address.”

Management review benefits in the same way. ISO 27001 already requires the results of risk assessment and the status of the risk treatment plan as review inputs. “91 controls are applicable” tells a leadership team almost nothing. “These are our most significant risks, these are the controls we rely on to reduce them, and this is where residual exposure remains” gives them something to decide on. That turns the SoA into part of the organisation’s decision-making rather than an audit artefact.

Risk and the SoA should change together

ISO 27001 expects risk assessments to be repeated at planned intervals and whenever significant changes are proposed or occur. New offices, acquisitions, new SaaS platforms, new suppliers, outsourcing, starting software development, adopting AI, major infrastructure changes and new regulatory requirements can all change the risk picture.

Each should follow the same path: change, then a risk review, then a treatment review, then a control review, then an SoA update. An SoA whose review dates all fall in the fortnight before each audit is a reliable sign that this isn’t happening.

Practical exercise: test the thread in both directions

Take your ten highest information security risks. For each one, ask:

• What asset or process is affected?
• Which CIA property is threatened?
• What treatment decision has been made?
• Which controls support that treatment, and are they represented correctly in the SoA?
• Can the controls be evidenced, and are they operating effectively?
• What residual risk remains, who owns it, and when was it last reviewed?

Then reverse it. Take ten significant controls from your SoA and ask: which risk, obligation or business requirement explains why this control is applicable?

If you can’t make the connection in either direction, there’s a disconnect in the ISMS. Finding it yourself is a great deal better than an auditor finding it for you.

Closing

ISO 27001 isn’t primarily about implementing 93 controls. It’s about understanding your information security risks and building a control environment that fits your organisation. The risk register explains what could go wrong. The Statement of Applicability explains what you’ve chosen to do about it. ISO 27002 helps translate those choices into workable controls, and evidence shows whether they actually work.

A good SoA isn’t a list of 93 yes-or-no answers. It’s the bridge between your assets, your risks and the security framework you’ve built to protect them.

If you’d like help rebuilding the link between your risk register and SoA, or preparing for an audit that will test it, get in touch . Our ISO 27001 and Audits & Reviews services both cover this ground.