The 93-Control ISMS That Skips Its Own Risk Process
Northwind Logistics has 620 employees and was certified to ISO/IEC 27001 eight months ago. The ISMS scope statement reads: "all logistics and customs-clearance services at the Rotterdam and Antwerp hubs". The most recent risk assessment is dated fourteen months ago, lists eleven risks, assigns no risk owner to any of them, and its risk-criteria section is blank. The Statement of Applicability lists all 93 Annex A controls as applicable, each with the identical justification "all controls are necessary for full compliance". The security manager explains that the register has not been updated because "nothing has changed", and that all controls were implemented from a consultant's checklist before the risk assessment was written. Top management reviewed the ISMS in March; the minutes record only a phishing-statistics presentation.
1. You are the lead auditor reviewing Northwind's risk management approach. Which requirements do you test, and what finding do you expect to raise?
Read the worked answer
An ISMS is a risk-driven management system, not a control catalogue. I would test the process requirements, not the output documents:
- 6.1.2 (risk assessment): is there a defined and applied process, with defined risk-acceptance criteria, analysis and evaluation methods, risk ownership, and repeatability (results comparable between runs)?
- 6.1.3 (risk treatment): are controls selected from risk, is there a treatment plan, is the SoA justified, and are risks approved by their owners?
- 8.2/8.3: risk assessment performed at planned intervals or on significant change, and results recorded.
- 9.3: risk assessment results and treatment status used as management review input.
Evidence points the same way: no criteria means results cannot be evaluated or compared, so 6.1.2 is not fulfilled at all; the assessment defaults because there is no interval or change trigger (8.2); controls were chosen before risk was known, so 6.1.3 is inverted.
Because the defect is systemic and undermines the logic of the whole ISMS, I would raise it as a major nonconformity rather than an isolated lapse.
2. The security manager objects: "All 93 controls are implemented - more than most organizations do. How can that be nonconforming?" How do you answer, and what would conformity require?
Read the worked answer
Conformity is judged against requirements, never against a count of implemented controls. Nothing in ISO/IEC 27001 caps or targets the number of Annex A controls: a defensible risk assessment could legitimately justify all 93, or few. What cannot be defended is how they were selected.
The manager's argument confuses output with process. The standard requires that the organization define risk criteria, identify and evaluate risk, select treatment, and have risk owners approve acceptance - so that the control set is traceable to the organization's own risk picture and remain so as the picture changes.
Conformity would need, at minimum:
- Documented risk criteria and a repeatable assessment method (6.1.2).
- Named risk owners who accept residual risk (6.1.3).
- A SoA whose inclusion/exclusion justifications reference identified risks.
- Re-assessment at defined intervals and on significant change (8.2), with results feeding management review (9.3).
I would say precisely this at the closing meeting: the organization has done much work, but has not yet demonstrated a management system that steers it.
3. Which single clause do you cite for the Statement of Applicability finding, and what objective evidence would you collect to close it?
Read the worked answer
I would cite 6.1.3 d) - the SoA must contain the necessary controls and the justification for inclusions and for exclusions of Annex A controls.
"All controls are necessary for full compliance" is a statement of intent, not a justification: it would read identically in any organization in any sector, and it points back to the standard rather than to Northwind's risk. It gives no reviewer any ability to test whether the control set follows from risk.
Objective evidence I would collect:
- A sample of SoA entries traced back to entries in the risk register (control → risk → owner), recording which trace, and which do not.
- The risk treatment plan required by 6.1.3 e) and the record of risk-owner approval required by 6.1.3 f).
- Management review inputs (9.3) to see whether risk results are actually reviewed.
- Interviews with two or three named risk owners, to test whether they know what they accepted.
I would also note the sampling basis in the working papers, since the finding rests on a sample of SoA lines, not on a review of every line.