Risk acceptance and a 'cover everything' Statement of Applicability
Trans-East Logistics has 260 employees and has completed its first ISO/IEC 27001 risk assessment. The register contains 14 risks. The top three are: R1 ransomware on the dispatch system, likelihood 4, impact 5; R2 theft of fuel-card data by a payroll administrator, likelihood 2, impact 5; R3 outage of the single fibre link at the main depot, likelihood 3, impact 4. The scale is 1-5 and the board has just approved a risk appetite statement saying scores above 12 must be treated. Treatment for R1 would cost EUR 85,000; the finance director proposes accepting R1 and R3 because the insurance policy covers EUR 1 million. No risk owners are named. The draft Statement of Applicability lists all 93 Annex A controls as applicable, with the justification 'to be safe'. The certification body visits in ten weeks.
1. Evaluate the finance director's proposal to accept R1 and R3 against ISO/IEC 27001 risk treatment requirements and the board's own appetite.
Read the worked answer
The proposal is not automatically wrong, but as presented it is not a valid acceptance.
First, calculate the scores: R1 = 4 x 5 = 20; R2 = 2 x 5 = 10; R3 = 3 x 4 = 12. The board's statement says scores above 12 must be treated. R1 at 20 clearly breaches the appetite. R3 at 12 does not, so accepting R3 is at least consistent with the stated threshold - but only if the criteria and the calculation are applied consistently and the residual risk is understood.
Second, ISO/IEC 27001 clause 6.1.3 requires the organisation to formulate a risk treatment plan and obtain risk owners' approval of the plan and acceptance of residual risk. There are no named risk owners, so nobody with accountability has accepted anything. The finance director may be influencing the decision, but that is not the same as the dispatch system's risk owner accepting operational risk.
Third, insurance is risk sharing, not risk elimination. It does not restore dispatch operations during an outage, does not address regulatory or contractual duties, and may not pay out for the specific failure mode. Accepting a 20-score risk because of an insurance limit also ignores the board's own approved threshold, which is a governance inconsistency an auditor will spot.
A defensible path: treat R1 with a costed plan and interim controls; document R3 acceptance with rationale, review date and named owner if management decides 12 is tolerable; refer any acceptance above the appetite to top management for explicit, recorded approval with the residual score stated.
2. Critique the draft Statement of Applicability and explain what a defensible SoA contains.
Read the worked answer
'All 93 controls, to be safe' is the opposite of a risk-based SoA.
A SoA is not a wish list. It is the bridge between the risk treatment results and the Annex A control set. ISO/IEC 27001 clause 6.1.3 requires the organisation to compare the controls it has selected with Annex A and produce a Statement of Applicability that records which controls are necessary and why, which are not applicable and why, and the implementation status. Listing everything as applicable makes the statement meaningless: it does not show that R1, R2 or R3 were analysed, and it commits the organisation to implementing and evidencing controls it may not need.
Practical consequences:
- The auditor can test any of the 93 controls; a blanket claim invites a long list of findings.
- Resources are spread across low-value controls while R1 remains unaddressed.
- Exclusions are never justified, so the organisation cannot explain why a control was omitted.
A defensible SoA contains, for each Annex A control: the control reference and name; applicable or not; the justification linked to risk treatment, legal/contractual obligation or business requirement; the implementation status; and a reference to the risk register entry or treatment plan where relevant. For excluded controls, the justification must be specific ('no software development is performed in scope') rather than 'not needed'.
With ten weeks to audit, the realistic action is to rebuild the SoA from the 14 risks, not to trim it cosmetically. A smaller, justified set of implemented controls is stronger evidence than 93 untested claims.
3. What must be added for risk ownership and monitoring before the certification audit, and why does this matter beyond paperwork?
Read the worked answer
Named ownership turns a register into accountability.
Each risk should have a named risk owner - a person with the authority and operational responsibility to accept or treat it - not a department or a committee. For R1 that is likely the dispatch operations manager with IT support; for R2 the payroll/finance manager; for R3 the depot or infrastructure manager. The owner approves the treatment plan, accepts residual risk in writing and is accountable for the review date.
A workable minimum before the audit:
- Recalculate and re-evaluate the top risks against the board's criteria; record the rationale for R3 if it is retained.
- Create treatment plans with actions, owners, budgets, deadlines and expected residual scores. For R1, the EUR 85,000 proposal needs a decision, not an implicit acceptance.
- Add monitoring: clause 9.1 requires the organisation to determine what to monitor, how and when. Risk scores, treatment progress, backup restore results and incident trends are sensible measures.
- Feed the results into management review (clause 9.3) so top management sees residual risk and decides on acceptance.
- Keep the acceptance record time-bound. 'Accepted forever' is not a decision; a review date and trigger conditions are.
This matters beyond the audit because an accepted 20-score ransomware risk can stop dispatch operations, breach customer service levels and make the insurance conversation irrelevant. The auditor will test whether the risk owner really understood the risk, which is why a one-line signature on a spreadsheet is weak evidence.