The Certification That Certified the Wrong Thing
Arclight Manufacturing achieved ISO/IEC 27001 certification eight months ago. The scope statement reads: 'The information security management system supporting the corporate IT network at head office.' Since certification, Arclight has acquired a smaller competitor and absorbed its 300 staff, moved production planning onto a cloud SaaS platform, and begun a programme to connect factory-floor operational technology (OT) to the corporate network for real-time reporting. The CISO is preparing for a customer audit and wants to present the certificate as evidence that Arclight protects the customer's design data, which is stored on the SaaS platform and used by the acquired team. The certification body has not been informed of any of these changes.
1. Explain why the certificate does not support the CISO's intended claim, and what the scope statement reveals.
Read the worked answer
The certificate is valid only within its stated scope. The scope covers the corporate IT network at head office. The customer's design data sits on a SaaS platform, is used by staff from an acquired organisation, and increasingly flows through OT connections. None of those are obviously inside 'the corporate IT network at head office', and the acquired entity's people and systems are plainly outside it.
Presenting the certificate as evidence of protection for that data is therefore misrepresentation, even if unintentional. A customer auditor who reads the scope statement will see the gap immediately, and the credibility damage will exceed any short-term benefit. The certificate evidences that a management system exists for a defined boundary; it does not certify the security of every asset the organisation touches.
There is a second problem: the management system has not kept pace with change. The standard requires the ISMS to respond to changes affecting it. An acquisition, a migration to SaaS, and an OT connectivity programme are all significant changes that should have triggered a scope review, a risk assessment update, and a statement of applicability revision. None appears to have happened.
The honest position for the customer audit is to describe the certificate accurately, disclose the changes in progress, and present the actual controls protecting the design data - contractual terms with the SaaS provider, access controls, and the OT segmentation plan - rather than leaning on a badge that does not cover them.
2. Set out the sequence of actions the CISO should take to bring the ISMS back into line.
Read the worked answer
Start with scope, because everything else follows from it. Decide deliberately whether the ISMS should now cover the acquired entity, the SaaS platform, and the OT environment, or whether some are handled under separate arrangements. That is a management decision, not a technical one, and it should be minuted. Widening scope has cost and audit implications, so it needs an owner and a budget.
Next, update the risk assessment and statement of applicability for the new assets and changed architecture. The SaaS platform introduces supplier and data-location risks; the acquisition introduces unknown inherited controls and cultures; OT connectivity introduces availability and safety risks that the existing IT-focused controls may not address. Record which Annex A controls are now applicable and which are excluded, with justification.
Then engage the certification body. Changes to scope and significant changes to the ISMS should be disclosed; the body will advise whether a special audit or a revised certification cycle is needed. Attempting to carry an out-of-date certificate quietly into an audit is the worst option.
In parallel, communicate honestly to the customer: what the certificate covers, what has changed, what compensating controls are in place, and the remediation timeline. Then run the ISMS cycle properly - internal audit, management review, corrective action - so the next surveillance audit finds a system that reflects reality rather than one that has drifted.