Cloud Assurance and Governance

Cloud failure rarely arrives as a misconfiguration. It arrives as a contract with no exit, a provider nobody assessed before the dependency built up, or an outage at a supplier your supplier uses. This assessment asks who owns cloud risk, what was agreed before the first service went live, and what happens when a provider fails, changes its terms or has to be left - the answers outsourcing and operational resilience rules expect you to hold in writing.

• Establishes a named owner for cloud risk who is not the person running the platform.
• Tests whether exit and data return were agreed before the dependency became hard to reverse.
• Covers the suppliers behind your suppliers, which resilience rules now treat as your exposure.
• Gives procurement a security position to hold before the next provider is chosen, rather than after.

136 questions across 12 domains and 37 categories, from provider selection and shared responsibility through key custody, logging, resilience, portability and fourth parties to cloud competence in your own team. It runs as interviews with cloud, procurement, legal and risk, and needs your service inventory, contracts and provider assurance reports to hand rather than console access. The scored report is per domain, and it pairs with a configuration assessment: this one asks the governance questions a platform review never reaches.

• 136 questions, 12 domains, 37 categories; no console access, no agent, no collector.
• The 16-question governance domain and the 12 on contracts and exit are the ones needing legal and procurement in the room.
• Collect first: service inventory, provider assurance reports, contracts, and subprocessor notification records.
• Produces supplier-assurance evidence you can reuse across several audits in the same year.

The twelve domains are ours and follow no external control matrix, because the matrices that cover this ground are licensed for exactly this use. Evidence is the paperwork and the platform facts behind it: which side of the shared responsibility line each control sits on for each significant service, which logs the provider will actually export and at what retention, who holds the encryption keys in practice rather than on the order form, how federation and privileged console access are arranged, and whether backup exists independently of the provider holding the data. 15 identity questions and 12 on secrets and access overlap a technical review, so a weak answer there can be checked against live configuration.

• Twelve domains built from the subject rather than adapted from a licensed framework.
• 11 questions on key custody and lifecycle - whether a hold-your-own-key arrangement is real or nominal.
• The logging domain asks what the provider will hand over, for how long, and whether it satisfies your auditors.
• 10 questions on supply chain and fourth parties: who the provider depends on, and how subprocessor changes reach you.