Corvus Media: a stale cloud policy, two unsanctioned SaaS tools and a role that no longer exists
Corvus Media's cloud security policy was approved 34 months ago. It is a 14-page PDF with two appendices: appendix B, superseded six months ago by the current logging standard, is still referenced in the body text. The policy requires all data in cloud services to be encrypted with keys held in the company's hardware security module. Last quarter two business units bought SaaS collaboration tools directly, one of which supports only provider-managed keys; neither went through acquisition review. The policy also assigns cloud configuration review to the IT security manager, a role abolished in a reorganisation. The intranet page hosting the policy shows version 1.0, no approval date, and a link to a withdrawn standard. Internal audit has just raised a finding that cloud responsibilities are not defined, and the CISO wants a remediation plan covering the documents, the two tools and the role gap.
1. Assess the documented information itself. What is wrong, and how should the policy set be restructured - including the encryption clause?
Read the worked answer
What is wrong
- Identity and control: no approver, no approval date, no review date, version 1.0 for 34 months - the document cannot demonstrate it is current or authorised.
- Superseded content: appendix B is withdrawn but still cited by the body text, so readers are pointed at a standard that no longer applies.
- Unachievable requirement: an HSM-only key mandate cannot be met by a SaaS product that offers only provider-managed keys. A requirement that cannot be met by the architecture in use does not raise security; it guarantees informal exceptions.
- Obsolete role: responsibility assigned to a post that no longer exists means the control has no owner.
- Distribution: an intranet page linking to a withdrawn standard is a distribution failure, not a typo.
Restructure
Separate policy (intent, scope, principles), standards (the measurable requirements per data class and service model) and procedures (how each is executed). Give every document an owner, approver, version, effective date, review cycle and change log, and remove retired copies from circulation - the substance of the documented-information requirements in ISO/IEC 27001 clause 7.5.
Rewrite the encryption clause as an outcome ladder: for the highest data class, customer-held keys are mandatory; for lower classes, provider-managed keys with compensating controls (access logging, region restriction, contract terms) are acceptable, with a documented exception route and DPO or security sign-off.
2. What should Corvus do about the two SaaS tools bought outside review, and what governance gap allowed it?
Read the worked answer
Immediate handling. Treat both as unassessed services holding unknown data. For each: identify what data has actually been uploaded (assume the worst until proven), obtain the terms, data processing agreement, security documentation and subprocessor list, and classify the risk. Then choose explicitly - approve with compensating controls, migrate the data out, or terminate. The tool that supports only provider-managed keys needs the exception route from the rewritten standard, not a verbal waiver.
The governance gap. The policy scoped itself to 'cloud services' without defining who must comply, who may approve an exception, or how procurement interfaces with security. Nothing in the process stopped a business unit from buying at the point of need. The enablers of shadow cloud are usually a slow or invisible approval route and an unclear definition of what needs approval.
Fixes
- A procurement gate: no new SaaS contract without a security and privacy review proportional to data class.
- A pre-approved catalogue with defined conditions, so the common, low-risk cases take a day rather than a quarter.
- A named exception workflow with authority levels and expiry.
- A cloud service inventory that the business can add to, plus periodic discovery of what is actually in use.
- An awareness push telling staff the route exists and how to use it.
This maps to the cloud-use control set in ISO/IEC 27001:2022 Annex A (A.5.23 and the supplier controls A.5.19 to A.5.22) and to the ISO/IEC 27017 expectation that responsibilities be allocated and understood.
3. Close the audit finding: how should cloud responsibilities be defined so that they survive the next reorganisation?
Read the worked answer
Diagnosis. The finding is not that a name is wrong; it is that responsibility was defined by job title rather than by role and activity. Titles change, roles persist.
Approach
- Build a responsibility matrix over activities - service approval, configuration baseline, access review, log review, vulnerability triage, incident command, exit management, contract review, DPO input - with columns for the accountable role, the responsible team and the consulted parties.
- Anchor it to roles, not people: 'cloud platform owner', 'service owner', 'security operations lead', 'DPO'. Name current post-holders in a separate register that HR and the security office both maintain.
- Layer the shared-responsibility matrix per service beneath it, so it is clear where Corvus's responsibility starts and the provider's ends - the allocation the ISO/IEC 27017 shared-roles-and-responsibilities control expects.
- Give each row an evidence source: the review record, the ticket, the report. A responsibility with no artefact is a claim.
- Publish, train and test: sample three incidents or changes after go-live and confirm the named roles actually performed the activity.
Audit closure evidence should be the approved matrix, the mapping to job holders, the training record, and one worked example end to end. Presenting a new org chart will not close the finding.