1.3 Risk Assessment, Risk Treatment, and the Statement of Applicability (SoA)
Key Takeaways
- Information security risk assessment identifies risks to confidentiality, integrity, and availability within scope, analyses consequence and likelihood to determine risk levels, and evaluates risks against defined criteria with assigned risk owners.
- Risk treatment selects options—typically modify (mitigate), retain (accept), avoid, or share (transfer)—then determines necessary controls, compares them with Annex A, and produces an approved residual-risk decision via risk owners.
- The Statement of Applicability (SoA) is mandatory documented information listing necessary controls, justification for inclusions, implementation status, and justification for any Annex A exclusions.
- Clause 6 defines the risk assessment and treatment processes; Clause 8 requires those processes to be performed at planned intervals and when significant changes occur.
- Lead Auditors trace SoA claims to risk results and then to objective evidence of implementation—never treating Annex A's 93 controls as an automatic full-implementation mandate.
Why risk assessment, treatment, and the SoA dominate auditor judgment
If Clauses 4–10 are the skeleton of ISO/IEC 27001:2022, risk assessment, risk treatment, and the Statement of Applicability (SoA) are the cardiovascular system. They appear in Clause 6 as process requirements and again in Clause 8 as activities that must actually be performed. On the CQI/IRCA PR373 ISO/IEC 27001:2022 Lead Auditor journey (minimum 40-hour course; online exam commonly 40 questions, 1 hour 45 minutes, five sections), weak answers often confuse "we have an SoA spreadsheet" with "we operate a risk-based ISMS."
Annex A remains an informative reference of 93 controls in four themes. The SoA is where the organization shows which of those controls are necessary, which are excluded (with justification), and whether included controls are implemented. Your job as auditor is not to force 93/93 implementation; it is to verify a coherent, criteria-based risk story and truthful implementation claims.
Risk criteria come first
Before identifying individual risks, the organization shall establish and maintain risk criteria, including:
- Criteria for performing information security risk assessments
- Risk acceptance criteria
Criteria make results consistent, valid, and comparable. Without them, two analysts can score the same ransomware scenario as "medium" and "critical" with no governance basis for disagreement. Auditors should ask: Who approved the criteria? When were they last reviewed? Are acceptance thresholds applied as written?
| Criteria element | What "good" looks like | What "theatre" looks like |
|---|---|---|
| Impact scales | Defined consequence levels tied to CIA and business harm | Vague labels with no examples |
| Likelihood scales | Shared definitions of frequency/probability | Analyst gut feel only |
| Acceptance | Clear when residual risk may be retained and by whom | Silent acceptance of every high risk |
| Comparability | Same method reused across cycles and units | Each department invents a new scorecard |
Risk assessment process (identify → analyse → evaluate)
Risk identification
Identify risks associated with loss of confidentiality, integrity, and availability of information within the ISMS scope, and identify risk owners. Identification should be broad enough to cover people, process, and technology scenarios relevant to the scope—not only CVEs from the last scan.
Examples of risk statements (illustrative, not mandated wording):
- Unauthorized disclosure of customer personal data from a misconfigured storage bucket (confidentiality)
- Undetected tampering with financial posting records (integrity)
- Prolonged unavailability of the claims portal after ransomware (availability)
Risk analysis
Assess potential consequences if the risk materializes and the realistic likelihood of occurrence. The combination yields the level of risk. Analysis may be qualitative, quantitative, or hybrid; ISO/IEC 27001 requires a defined process and comparable results, not one universal formula.
Risk evaluation
Compare risk levels with risk criteria to prioritize which risks need treatment and in what order. Evaluation is a decision step: not every identified risk requires the same intensity of treatment.
PDCA link: Defining the methodology is largely Plan (Clause 6). Performing assessments at planned intervals or on significant change is Do (Clause 8.2). Using results in management review and objectives is Check/Act territory (Clauses 9–10 and 6.2).
Risk treatment options
After evaluation, select appropriate risk treatment options. Common teaching categories used in ISMS courses include:
- Modify (mitigate) — Apply controls to reduce likelihood and/or consequence.
- Retain (accept) — Informed decision to accept the risk (typically within acceptance criteria), with risk-owner approval of residual risk as required.
- Avoid — Decide not to start or continue the activity that gives rise to the risk.
- Share (transfer) — Share risk with another party (for example cyber insurance or outsourcing), remembering that accountability for ISMS outcomes is not "outsourced away."
Organizations often combine options (mitigate and insure). Treatment must produce:
- Determination of all controls necessary to implement chosen options
- Comparison with Annex A controls to verify that no necessary controls have been omitted
- A Statement of Applicability
- A risk treatment plan
- Risk owners' approval of residual information security risks
| Treatment option | Example decision | Auditor probe |
|---|---|---|
| Modify | Multi-factor authentication for remote admin | Is the control operated and measured? |
| Retain | Accept residual risk of rare physical archive fire after controls | Is acceptance within criteria and approved? |
| Avoid | Stop collecting unnecessary sensitive biometrics | Was the process actually stopped? |
| Share | Purchase cyber insurance for residual financial impact | Does the organization still control relevant Annex A/people processes? |
The Statement of Applicability (SoA)
The SoA is mandatory documented information. It shall include:
- The necessary controls (from the treatment process)
- Justification for their inclusion
- Whether the necessary controls are implemented or not
- Justification for exclusion of any Annex A controls
Why comparison with Annex A matters
Comparing selected controls with Annex A is a safeguard against blind spots. An organization might mitigate "lost laptop" risk with encryption yet forget related people or physical controls that Annex A would prompt them to consider. Comparison does not mean every Annex A control is compulsory. Exclusions require justification—for example, controls about physical delivery media may be irrelevant to a purely digital service with no such handling, if that justification is true and current.
Implementation status is an evidence claim
Marking a control "implemented" is a statement auditors will test. Objective evidence might include configurations, tickets, access review outputs, visitor logs, secure development records, or supplier agreements—matched to the control's intent and the organization's own description of how the control works.
Clause 6 versus Clause 8 (do not mix them up)
| Topic | Clause 6 role | Clause 8 role |
|---|---|---|
| Risk assessment | Define and apply the process; criteria; produce assessment design/results as planned outputs | Perform assessments at planned intervals or when significant changes proposed/occur; retain results |
| Risk treatment | Select options, determine controls, SoA, treatment plan, residual risk approval | Implement the treatment plan; retain results of treatment |
Exam traps often claim that writing a methodology once forever satisfies Clause 8, or that operating controls without an SoA satisfies Clause 6. Both are incomplete.
Realistic audit scenarios
Scenario 1 — Orphan SoA. The SoA lists 80 controls as implemented, but the risk assessment only identifies five risks and never references those controls. The Lead Auditor should challenge traceability: controls should be necessary for treatment (or otherwise justified), not copied because a tool defaulted to "select all."
Scenario 2 — Unjustified exclusions. Annex A physical controls are excluded with the note "cloud company, no offices," yet the organization runs a large headquarters with badge access to server rooms. Exclusion justification fails factual testing.
Scenario 3 — Stale assessment after change. A fintech migrates core processing to a new cloud region. Risk assessment is unchanged for 18 months. Clause 8.2 significant-change expectations are in play; treatment and SoA may also be outdated.
Scenario 4 — Acceptance without ownership. High residual risks are "accepted" in a slide deck with no risk owner and no link to acceptance criteria. Clause 6 residual-risk approval expectations are not met.
Scenario 5 — Transfer illusion. Management claims ransomware risk is fully transferred via insurance and therefore needs no detection or backup controls. Sharing financial impact does not erase the need to determine necessary controls for CIA outcomes still within the ISMS.
How Lead Auditors should sample the chain
A practical sampling path:
- Read risk criteria and confirm approval/currency
- Sample several risks across CIA and across business units in scope
- Recalculate or walk through analysis/evaluation logic for consistency
- For risks needing treatment, inspect selected options and the treatment plan
- Trace necessary controls into the SoA (inclusion justification and implementation status)
- For sampled Annex A exclusions, test justifications against reality
- For controls marked implemented, gather objective evidence and interview operators
- Check that significant changes triggered reassessment when required
- Confirm management review and objectives reflect risk results where relevant
This chain mirrors PDCA: plan the method, do the assessment/treatment, check performance, act on weaknesses.
Domain 1 and planning questions — precision points
- Level of risk = combination of consequence and likelihood (as analysed), then evaluated against criteria.
- Risk owner is identified during assessment; residual risk approval involves risk owners.
- SoA requires inclusion justification, implementation status, and exclusion justification—not public web publishing or cost ledgers as mandatory SoA fields.
- Annex A: 93 controls, four themes, informative reference.
- Do not invent a CQI/IRCA published passing score when discussing exam readiness.
- Keep ISO 19011 / ISO/IEC 17021 as applicable auditing/certification-body references per course teaching, without false edition-switch claims.
In ISO/IEC 27001 information security risk analysis, what determines the level of risk before evaluation against criteria?
Which set of content is required in the Statement of Applicability (SoA)?
An organization purchases cyber insurance for ransomware-related financial losses while still operating backups and access controls. Which statement best describes this risk treatment approach?