The ISO 27001 certificate that names the wrong system
Meridian Cloud is a 220-person SaaS provider whose HR platform processes payroll for 1,400 enterprise customers. It holds ISO/IEC 27001:2022 certification from an accredited certification body, but the scope statement reads 'corporate information systems supporting finance, HR and software development at the Dublin and Lisbon offices'. The production platform, running in AWS eu-west-1 and operated by a 60-person SRE team in Bangalore, was excluded two years ago to shorten the audit. A tier-one bank now makes STAR Level 2 registration a condition of a EUR 9m contract, with signature due in ten weeks. Meridian's security lead proposes uploading the existing certificate to the STAR Registry with a cover note stating that CCM domains not covered by ISO 27001 'are addressed by AWS'. The CISO asks you, as an external advisor, whether that submission is defensible and what a realistic path looks like.
1. Can Meridian's existing certificate support a STAR Level 2 submission? Explain the governing requirement rather than the outcome alone.
Read the worked answer
No. The certificate cannot carry a Level 2 claim, for two independent reasons.
- Scope. A Level 2 registry entry asserts that an independent third party assessed the cloud service offered to customers. Meridian's certificate names Dublin and Lisbon corporate systems and explicitly excludes the production platform and the Bangalore SRE function. It is a true statement about a system the bank is not buying, so it is not evidence about the service in scope.
- Framework coverage. Even with the scope corrected, ISO/IEC 27001 certification is the entry ticket for the ISO route, not the whole route. Level 2 requires the assessment to address the CCM: the certification body must evaluate the applicable CCM controls, and the resulting statement or report is what gets published. Annex A and the CCM overlap heavily but are not identical, so a certificate on its own cannot evidence CCM coverage.
Publishing anyway would be a misrepresentation on a public registry. CSA can remove or challenge listings, and the bank's due-diligence team will read the scope statement in the first five minutes. The defensible position is: Level 1 is achievable now, Level 2 is not achievable on this certificate.
2. What does the 'addressed by AWS' cover note fail to satisfy? Use specific CCM domains to show the reasoning.
Read the worked answer
The note confuses inheritance with coverage. Inheritance is real, but it only transfers controls the underlying provider actually operates, and it must be documented rather than asserted.
- Genuinely inherited (partly): infrastructure and datacenter controls in IVS and DCS - physical access, hypervisor patching, host hardening. AWS can evidence these and Meridian can point at AWS artifacts.
- Not inherited: IAM for Meridian's own tenant and admin access, DSP for payroll data (classification, retention, deletion), LOG for application and audit logging the customer relies on, CCC for Meridian's release process, TVM for Meridian's application vulnerabilities, SEF for incident response, and BCR for Meridian's own recovery objectives.
- Actively damaged by the note: the IPY domain covers interoperability and portability - customer data export, API standards, exit terms. AWS cannot satisfy this; it is a property of Meridian's product.
The cover note also conflicts with the CAIQ method: an inherited control is still answered from Meridian's perspective, with the reliance on the underlying provider disclosed, and with a customer responsibility matrix that tells tenants what they must do. 'Addressed by AWS' silently reclassifies Meridian's own obligations as someone else's.
3. Set out a realistic path to Level 2 and say what should be told to the bank in the next ten weeks.
Read the worked answer
Path (working backwards from the requirement):
- Now: publish an accurate STAR Level 1 CAIQ for the production platform. It is self-assessed, so it can go out immediately, and it gives the bank something verifiable while the rest is built.
- Weeks 1-3: run a CCM v4 gap assessment scoped to the payroll platform and the Bangalore operations, recording inherited controls against AWS artifacts and customer-responsibility splits.
- Weeks 3-6: agree a scope extension with the certification body so the certificate covers the production platform and the SRE function, and confirm in writing that the engagement will assess the applicable CCM controls.
- Weeks 6-20+: remediate gaps and complete the extension audit and CCM assessment.
What to tell the bank: the certificate today does not cover the service; a Level 2 entry is targeted for a stated quarter, supported by the Level 1 listing, the gap-assessment summary, a bridge letter, right-to-audit and remediation dates. Do not let sales send the current certificate 'to keep things moving' - the scope statement contradicts the claim and will cost credibility at the exact moment Meridian needs it.