ISO 27001 Risk Treatment and the Statement of Applicability
ISO 27001 clause 6.1.3 connects assessed risks with treatment decisions, necessary controls and the Statement of Applicability, often called the SoA. It requires more than selecting controls from a list: the organisation determines treatment options and necessary controls, checks these against Annex A, explains applicability, prepares a treatment plan and obtains the required risk-owner approvals and residual-risk acceptance.
What clause 6.1.3 requires in practice
Clause 6.1.3 requires a defined and applied risk treatment process. The organisation selects treatment options in light of the assessment results and determines every control needed to carry them out. A note confirms that controls can be designed or taken from any source.
Those controls are then compared with Annex A to check that nothing necessary has been missed; notes explain that Annex A is a reference list that is not exhaustive. The organisation produces a Statement of Applicability containing the necessary controls, the reason each is included, whether it is implemented, and the justification for leaving out any Annex A control.
A risk treatment plan must be formulated, and risk owners must approve it and accept the residual risks. Documented information about the process is retained. The standard does not require every Annex A control to be implemented; it requires reasoned decisions. Outputs are the Statement of Applicability, the plan and recorded approvals.
Start with treatment, then determine necessary controls
A treatment decision can involve changing an activity or its conditions, using controls or making other suitable choices. Do not assume every risk must be addressed by buying a technical product. The important point is that the chosen treatment responds to the assessed exposure and applicable requirements.
Controls can come from sources beyond Annex A. After determining necessary controls, the organisation compares them with Annex A to check that necessary controls have not been omitted. Annex A contains 93 reference controls, but clause 6.1.3 does not make every one automatically mandatory for every organisation. Conversely, a control should not be excluded simply because implementation would be inconvenient.
Why reasoned risk treatment matters to the business
Risk treatment is where money, effort and accountability meet. A clear link from risk to control shows customers that safeguards are chosen for reasons, not copied from a list, and it lets management explain what has been accepted. The Statement of Applicability is often the first document a customer or assessor asks to see, because it summarises the organisation's security posture. Weak reasoning here causes late surprises: controls claimed but not operating, exclusions that cannot be justified or residual risks nobody agreed to. Strong treatment decisions focus spending, reduce arguments with auditors and make later reviews faster.
How to implement clause 6.1.3
Work from risks to controls, not the reverse. One approach Sterling teams use is to maintain the Statement of Applicability as a living summary of treatment decisions.
- For each prioritised risk, decide whether to reduce, retain, avoid or share it, with a brief reason.
- Determine the controls needed to carry out each decision, drawing on any source.
- Compare the full set with the Annex A reference list and note any that were missed.
- Record, for each Annex A control, whether it applies, why, and whether it is implemented; justify each exclusion.
- Prepare the treatment plan with owners and target dates in your own planning format.
- Obtain approval from risk owners for the plan and for the residual risks, and keep the records.
- Revisit the Statement of Applicability after incidents, audits and changes in scope, so that its statements about implemented controls remain true and its reasons for exclusion still stand when challenged.
Example: access to a software production environment
A software provider identifies a risk that former project contributors retain powerful production access. It considers the actual cause: project membership changes faster than the central identity process. A treatment could combine clearer ownership, a controlled route for temporary access, expiry arrangements and review of exceptions.
The SoA should explain the relevant necessary controls and their implementation status. A treatment plan then addresses any remaining work, responsibilities and agreed consulting and documentation work arrangements. Recording a control as implemented merely because a policy exists would misrepresent the situation if accounts still remain active beyond their approved purpose.
There may also be organisation-specific controls beyond Annex A's descriptions. The reference set supports completeness; it does not limit the organisation's ability to address its own risks.
Example: a construction project's sensitive drawings
A construction design team shares commercially sensitive drawings with several specialist subcontractors. The risk assessment identifies uncontrolled forwarding and uncertain access after subcontract completion. Treatment might change how sharing is authorised, define recipient responsibilities and introduce a workable completion check.
If the project uses a customer-mandated collaboration platform, the organisation still needs to understand its own responsibilities and the customer's control arrangements. It should not list the platform name as if that alone constitutes a complete treatment. The practical evidence concerns who has access, what they can do and how changes are managed.
Make the SoA explain decisions rather than hide them
The SoA includes necessary controls, reasons for inclusion, whether they are implemented, and justification for exclusions from Annex A. Keep the wording specific enough to be meaningful. “Not applicable to our business” provides little explanation if the organisation actually performs the activity or depends on a supplier performing it.
Separate the SoA from a detailed operating procedure and from the risk register. They connect, but serve different purposes. The register describes and evaluates risks; the SoA explains necessary control applicability; the treatment plan directs the work; operating evidence demonstrates what happens. One tool may link these records without making them conceptually identical.
Approve the plan and the remaining exposure
Clause 6.1.3 requires risk owners to approve the treatment plan and accept residual information security risks. This is a decision about the exposure that remains, not an automatic consequence of completing a task. Give owners enough information about limitations, assumptions and requirements to make a considered decision.
Where treatment depends on a supplier or a future change, make that dependency visible. Document the treatment process as required, and connect operational results under clause 8.3 with monitoring and review. A changed risk may require a different treatment decision and corresponding updates to the SoA.
Evidence and frequent mistakes
An auditor may select a significant risk and follow it to treatment, control applicability, implementation evidence and approval. Common problems include an SoA copied from another company, exclusions contradicted by the service model, unclear implementation status and residual acceptance signed by someone without ownership. A beautifully formatted matrix does not resolve these weaknesses.
Frequently asked questions
Does outsourcing justify excluding every related control?
No. Outsourcing changes responsibilities and evidence needs; it does not automatically remove the risk or the need for controls over the relationship.
Is the SoA a public document?
The standard does not make unrestricted public publication the default. Consider relevant requirements, information sensitivity and appropriate access arrangements when deciding how to share it.
Does residual acceptance mean no further monitoring is needed?
No. Acceptance is based on particular evidence and conditions. Continue the applicable operating, monitoring and reassessment arrangements so changes can inform later decisions.
Build a coherent risk-to-control explanation
Discuss treatment and SoA support with Sterling, including scoped use of Effivity ISO & GRC automation software and preparation evidence. Enrol in ISMS Risk Assessment & Statement of Applicability for focused learning. Certification remains an independent decision.
Parent: clause 6. Previous: risk assessment. Next: documented information. Return to the hub.