ISO 27001 Clause 6 Complete Guide: Risk Assessment, Risk Treatment Plan, and SoA Working Together

The Clause 6 triad: what it produces

ISO 27001:2022 Clause 6 (Planning) requires three interconnected outputs. Each is mandatory. Each must be consistent with the others. Together, they form the analytical backbone of the entire ISMS:

Output	Clause	Purpose	Auditor use
Risk Assessment	6.1.2	Identify, analyse, and evaluate information security risks against criteria	Stage 1: verify methodology; Stage 2: verify risks are tracked and treated
Risk Treatment Plan (RTP)	6.1.3	Document treatment decisions, controls, owners, timelines, residual risk	Stage 1: verify completeness; Stage 2: verify controls are implemented per RTP
Statement of Applicability (SoA)	6.1.3(d)	All 93 Annex A controls: applicable/not applicable with justification and status	Stage 1: primary review document; Stage 2: evidence mapped to each applicable control

The correct order of operations

Many organisations produce these documents in the wrong order or in parallel without linking them. The ISO 27001 standard implies a specific sequence:

1. Define risk assessment criteria (Clause 6.1.2(a)) — risk appetite, likelihood and impact scales, acceptance criteria. This happens first because everything else references these criteria.
2. Conduct risk assessment (Clause 6.1.2(b-e)) — identify risks using asset/threat/vulnerability method or scenario-based method; calculate inherent risk scores; evaluate against criteria.
3. Produce risk register — the output of the risk assessment: all identified risks with inherent scores, risk owners, and initial treatment options.
4. Apply risk treatment (Clause 6.1.3(a-c)) — for each risk: select treatment (Mitigate/Transfer/Avoid/Accept); select specific Annex A controls; check Annex A comprehensively to ensure no controls have been missed.
5. Calculate residual risk — after treatment controls are selected, recalculate likelihood and impact to get the residual score; obtain risk owner approval of residual risk.
6. Produce the RTP — formal document combining all of the above: risk → treatment → controls → owner → timeline → residual risk → acceptance.
7. Produce the SoA — extract all controls from the RTP; add any controls applicable for other reasons (legal, contractual); mark all remaining Annex A controls as Not Applicable with justifications.
8. Implement controls — the RTP becomes the implementation roadmap; progress tracked against it.

The critical dependency: the SoA cannot be completed before the RTP. The RTP cannot be completed before the risk assessment. Organisations that start with the SoA and work backwards to fill in the RTP and risk assessment create documentation that looks inconsistent under audit scrutiny.

How auditors use the Clause 6 triad

Stage 1 (Document review)

The Stage 1 audit is primarily a document review. The auditor will:

• Review the risk assessment methodology — is it systematic, repeatable, and consistently applied?
• Sample 5–10 risks from the risk register and trace them through to the RTP — do they have treatment decisions, specific controls, and residual risk scores?
• Cross-reference RTP controls to the SoA — every control selected in the RTP should appear as Applicable in the SoA
• Review exclusion justifications in the SoA — are they plausible and complete?
• Check that risk owner approval is documented
• Verify the RTP has target dates and implementation status fields

Stage 1 findings typically relate to: missing traceability, generic controls without Annex A references, undocumented risk owner approval, SoA controls not linked to any risk or justification.

Stage 2 (Evidence review)

Stage 2 tests whether controls are actually implemented. The auditor will:

• Take each Applicable control in the SoA and ask for evidence of implementation
• For RTP controls marked "In Progress": verify there's an active implementation plan and progress
• For RTP controls marked "Completed": test the control is operating effectively (sample-based testing)
• Review whether residual risk scores in the RTP are realistic given actual control implementation
• Check whether any new risks have emerged since the last assessment that aren't reflected in the RTP

Asset-based vs scenario-based risk assessment: which approach to use

ISO 27001 doesn't mandate a specific risk assessment methodology — it requires the methodology to be documented and consistently applied. Two approaches are common:

Approach	How it works	Best for	Downside
Asset-based	Enumerate assets → identify threats to each asset → identify vulnerabilities → score risk	Large organisations with complex asset inventories	Can become unwieldy — hundreds of risks
Scenario-based	Define realistic threat scenarios (ransomware attack / credential compromise / vendor incident) → score each scenario → identify controls	SMBs and cloud-native SaaS — faster, more actionable	Must show asset coverage; auditors may check for gaps

For most SaaS companies with fewer than 200 people: a scenario-based risk assessment with 10–20 risks is entirely appropriate and much more manageable than an asset-by-asset enumeration. The key is that the methodology is documented, consistently applied, and the scenarios cover your most significant assets and data types.

Managing the Clause 6 documents over time

The three Clause 6 documents are not one-time deliverables — they require ongoing maintenance. Here's a practical cadence for SaaS companies:

Activity	Frequency	Owner	Output
Full risk assessment review	Annual (minimum)	CISO / Head of Security	Updated risk register, new version of RTP and SoA
Ad hoc risk assessment	When triggered (new system, incident, significant change)	CISO + relevant system owner	New risk entry in register; RTP and SoA update if new controls selected
RTP status updates	Monthly / quarterly	Risk owners	Updated implementation status (Not Started → In Progress → Completed)
SoA implementation status	Quarterly	CISO	Updated control statuses (Planned → Partial → Implemented → Reviewed)
Management review	Annual (Clause 9.3)	Senior management + CISO	Formal review of ISMS performance, risk posture, treatment effectiveness

Build all three documents together: the ISO 27001 Risk Assessment Generator (Clause 6.1.2) produces the risk register; the ISO 27001 Risk Treatment Plan Generator (Clause 6.1.3) links each risk to Annex A controls with implementation tracking; the ISO 27001 Statement of Applicability Generator produces the 93-control SoA with exclusion justifications. Use them in sequence to build a consistent, audit-ready Clause 6 package.