Cloud Security Review

The shared responsibility boundary

Every cloud provider publishes a shared responsibility model, and almost every organisation we assess has read it and still misjudged where their obligations begin. The boundary moves depending on the service model: more is yours under IaaS, less under SaaS — but data and access are yours in every model, without exception.

A significant proportion of cloud incidents are not provider failures. They are storage left publicly readable, over-permissioned identities, keys committed to source control, and logging that was never enabled. All firmly on the customer side of the line.

What we review

• Identity and access — role design, over-permissioned principals, standing privileged access, service accounts and key rotation, and whether MFA is genuinely enforced rather than merely available.
• Network exposure — internet-facing resources, security group and firewall rules, private connectivity, and whether segmentation holds in practice.
• Data protection — storage permissions, encryption at rest and in transit, key management, backup coverage and retention.
• Logging and monitoring — whether audit logs are enabled across accounts and regions, retained long enough, protected from deletion, and actually monitored.
• Configuration baselines — hardening against a recognised benchmark, and whether drift is detected.
• Infrastructure as code — pipeline controls, policy-as-code guardrails, and secrets handling.
• Multi-account governance — organisational structure, guardrails, and whether a developer can create an unmanaged account.
• Third-party and SaaS integrations — OAuth grants and API keys, which are consistently the least governed part of a cloud estate.

Auditing an estate that changes daily

Sampling server configurations in an auto-scaling environment is close to meaningless — the instances tested will not exist next month. Where the estate is genuinely dynamic we shift emphasis to the controls that govern change: the pipeline, the infrastructure-as-code templates, policy enforcement in the control plane, and the guardrails that make an insecure configuration impossible rather than merely detectable.

This is a real methodological difference and we will raise it at scoping. An auditor who insists on a fixed server sample has misunderstood the environment.

Platforms

AWS, Microsoft Azure and Google Cloud. Where you run more than one, we assess each against its own benchmark and report a consolidated position — multi-cloud estates tend to have inconsistent controls precisely because nobody looks at them together.