8.3 — Information security risk treatment

A treatment plan is a promise. This requirement is where the standard checks whether you kept it.

Mandatory requirement · Documented information required: yes

In plain language

8.3 requires you to actually carry out the risk treatment plan you produced under 6.1.3—implement the controls it calls for, follow through on the decisions it recorded—and to keep evidence showing that treatment genuinely happened, not just that it was planned.

Why this requirement exists

A beautifully documented risk treatment plan with nothing behind it is worse than useless—it gives the appearance of control without the substance. This requirement exists because plans slip: a control assigned an owner and a deadline in the treatment plan is easy to write down and easy to quietly let lapse without a mechanism forcing follow-through.

Scenario: a risk treatment plan calls for multi-factor authentication to be rolled out to all remote access accounts within 90 days, with a named owner. Six months later, at internal audit, only 60% of accounts have it enabled, and nobody followed up in between. The plan existed and was well written—but 8.3 was never satisfied, because the treatment itself was never completed.

What the standard expects

The standard expects the organization to implement the information security risk treatment plan, and to retain documented information of the results of the information security risk treatment. It is a short, direct requirement precisely because everything hard about risk treatment—deciding what to do, selecting controls, producing the Statement of Applicability—already happened under 6.1.3. What is left is execution and proof.

In practice

• Track every treatment action from the plan through to closure, the same way you would track any project task—status, owner, deadline, evidence.
• When a treatment action slips past its deadline, treat that the same way you would treat a nonconformity—escalate it, do not let it quietly disappear.
• Keep concrete evidence per control—a configuration screenshot, a completion log, a signed-off checklist—not just a status field marked "done".

Evidence the auditor will ask for

• The risk treatment plan alongside evidence each action was actually completed—not just marked complete.
• A record of how overdue or slipped treatment actions were handled.

Common pitfalls

• A treatment plan marked "complete" with no supporting evidence of what was actually done.
• Treatment actions that quietly stall with no escalation mechanism to catch them.

Related requirements

• 6.1.3 Risk treatment (planning)—produces the plan that 8.3 requires you to actually execute.
• 8.2 Risk assessment (operational)—each new assessment cycle produces the risks this treatment cycle addresses.
• Clause 9 Performance evaluation—internal audit and management review are where slipped treatment actions typically get caught.
• Parent clause: Clause 8 Operation.