Cloud misconfiguration and change control
Blue Harbour Retail operates 180 stores and an e-commerce platform. It outsources payment processing to a PCI DSS-certified provider and cloud hosting to a Tier 3 data centre. In 2023, it migrated its order management system to a SaaS platform; the migration was managed by a project team and closed with a 'lessons learned' report, but no change to the risk assessment or SoA. In January 2024, a misconfigured storage bucket exposed 12,000 order records for 36 hours. The incident response plan was last tested in 2021; the test was a tabletop exercise with no technical staff. The new 2022 controls include A.5.24 incident management planning and preparation, A.5.25 assessment and decision on events, A.8.8 management of technical vulnerabilities, A.8.9 configuration management. The operations director says the bucket was a 'one-off human error' and refuses to add configuration management to the SoA because 'we already have change management'.
1. Assess Blue Harbour's operation against clauses 8.1, 8.2 and 8.3 in light of the SaaS migration and the storage-bucket incident. What nonconformities are likely, and what should be done?
Read the worked answer
Clause 8.1 requires planned processes to be implemented and controlled, criteria to be established, and planned changes to be controlled; unintended changes must be reviewed and corrective action taken. Clause 8.2 requires risk assessment at planned intervals or on significant change, and 8.3 requires risk treatment. The SaaS migration was a significant change, yet the risk assessment and SoA were not updated; that is a likely nonconformity against 8.2 and 8.1's change-control requirement. The misconfigured bucket is an unintended change that was not detected, pointing to weak configuration control and monitoring under 8.1 and A.8.9. The incident response plan had not been tested since 2021 and the test excluded technical staff, which undermines operational readiness and A.5.24–A.5.25. Corrective action should include a refreshed risk assessment covering cloud storage, updated SoA entries, a change procedure that requires risk review for migrations, configuration baselines and drift detection, and an incident exercise with technical participation. The 'one-off human error' explanation is not a root-cause analysis; the auditor will ask why the configuration was possible and why it was not detected.
2. The operations director argues configuration management is already covered by change management. How should the ISMS team respond, and what does a defensible SoA justification look like for A.8.9?
Read the worked answer
The team should explain that change management (A.8.32) governs requests, approval and implementation of changes, while configuration management (A.8.9) establishes, documents and monitors baselines and detects drift. The bucket incident shows a gap in the second: a setting changed or was left insecure without a baseline or detection. Saying 'we have change management' is only valid if the implemented change process actually covers configuration items, baselines, verification and monitoring; the evidence suggests it does not. A defensible SoA entry for A.8.9 would state that the control is applicable because Blue Harbour operates cloud storage and SaaS, that the January 2024 incident exposed configuration risk, and that implementation includes defined baselines for storage and identity settings, automated drift alerts, periodic review and records. If the director refuses inclusion, the risk should be formally accepted by top management with a documented rationale, not dismissed. The transition auditor will compare the SoA to the incident record and expect the control decision to reflect what happened.