6.1.3 Information Security Risk Treatment

Mandatory requirementDocumented information required: Yes

In plain language

In plain language: once risks are assessed (6.1.2), sub-clause 6.1.3 requires you to decide what to do about each one, select the controls needed to do it, and document all of that in a Statement of Applicability (SoA) — the document that formally connects your risk decisions to the 93 controls in Annex A.

Position in the standard

Clause 6 · Planning

6.1 · Actions to address risks and opportunities

6.1.3 · Information security risk treatment ← you are here

Why this requirement exists

A risk register that nobody acts on is just a list of worries. This requirement forces a decision on every significant risk, and makes that decision traceable — so an auditor, a new hire, or your own team six months later can see exactly why a given control was implemented, or deliberately left out.

Scenario: an assessment flags a high risk around a legacy application with no vendor support. Without a treatment decision, the risk simply sits in a spreadsheet. With 6.1.3 properly applied, someone decides to retire the application within six months, documents that decision, assigns an owner and a deadline, and the SoA reflects why related Annex A controls were only partially implemented in the interim — an auditor sees a managed risk, not a gap.

What the standard expects

The standard expects a defined process that, for each assessed risk: selects an appropriate treatment option in light of the assessment results; determines every control necessary to carry out that option, and compares the result against Annex A to make sure nothing necessary was overlooked; produces the Statement of Applicability, listing the controls you have retained, whether each is implemented, and the justification for any exclusion; produces a risk treatment plan describing how the chosen options will actually be carried out; and obtains formal sign-off from risk owners, both on the treatment plan and on any residual risk that remains after treatment.

The four treatment options

Modify

Apply one or more controls to reduce likelihood or impact — the most common option.

Retain

Knowingly accept the risk because it falls within your criteria — a deliberate decision, not an oversight.

Avoid

Remove the source of the risk entirely, for example by discontinuing an activity or a system.

Transfer part of the risk to a third party — insurance, a supplier, or a specialized partner.

In practice

Work through your risk register top-down and assign a treatment option to every risk above your acceptance threshold.
Build the SoA as a single table: the 93 Annex A controls, included or excluded, justification, implementation status, and a link to the risk(s) that drove the decision.
Never exclude a control solely because it is inconvenient — every exclusion needs a risk-based justification an auditor could independently verify.
Get risk owners to sign off in writing, including on residual risk — verbal agreement is not evidence.

Evidence the auditor will ask for

The Statement of Applicability, current and consistent with the risk register.
The risk treatment plan with owners, actions, and deadlines.
Signed risk owner approval of the treatment plan and residual risk.
Justification on file for every Annex A control excluded from the SoA.

Common pitfalls

An SoA copied from a template, with every control marked "included" regardless of actual relevance.
Excluding controls to avoid work, without a documented, risk-based justification.
A treatment plan with no owners or deadlines — good intentions that never close.
Residual risk that was never formally accepted by anyone with the authority to do so.

Related requirements

6.1.2 Risk assessment

The identification and analysis work that feeds this treatment step.

Annex A · 93 controls

The catalogue the SoA selects from.

6.2 Security objectives

Treatment decisions often feed directly into your security objectives.

8.3 Risk treatment (operational)

The recurring implementation of this same treatment discipline.

Parent link: 6.1 Actions to address risks and opportunities

Frequently asked questions

Can I exclude an Annex A control entirely?

Yes, if you can justify with a risk-based rationale that it does not apply to your context. The justification, not the exclusion itself, is what the auditor examines.

Does the SoA have to mirror Annex A exactly?

It has to address all 93 controls — included or excluded, with justification — but you can add your own controls beyond Annex A if your risk assessment calls for them.

Who approves residual risk?

The designated risk owner, who must have the authority and seniority to accept that level of risk on behalf of the organization.

6.1.3 — Information security risk treatment