Cloud Security

We examine the configuration, architecture and access controls of your AWS, Azure and Google Cloud environments. Cloud security turns on identity and configuration: the IAM policies, trust relationships and resource permissions that decide who can access what. A misconfigured storage bucket, an overpermissive role or a trust policy that allows cross-account access can expose an entire environment.

We test the way attackers target cloud estates rather than against a generic checklist. The consultant who scopes your review delivers it.

Who this is for / when to test

• Significant change: a cloud migration, a new landing zone, or organic growth without a central security team.
• Compliance and assurance: SOC 2, ISO 27001 and PCI-DSS now mandate cloud-specific controls.
• Customer and tender requirements: enterprise buyers ask for evidence of cloud security assurance.
• Mergers and acquisitions: you want an independent review of an environment you are about to acquire or integrate.
• Post-incident: you need to confirm that the root cause of a cloud-related incident is addressed.

What we test

• Identity and access management: least-privilege alignment, privilege-escalation paths through policy combinations, role trust policies and cross-account access, federated identity and SSO, and overbroad managed policies.
• Storage and data exposure: public access, ACL and bucket-policy misconfigurations, CORS exposure, encryption posture and key management, and publicly shared snapshots and backups.
• Network architecture: security groups open to 0.0.0.0/0, permissive NACLs, risky VPC peering, public endpoints, and DNS records vulnerable to subdomain takeover.
• Compute and containers: instance metadata exposure (IMDSv1), secrets in user data, and EKS/AKS/GKE pod security, RBAC and network policy.
• Serverless: overpermissive execution roles, secrets in environment variables and dependency risk.
• Logging and monitoring: CloudTrail, Azure Activity Logs and GCP Audit Logs coverage, retention and tamper protection, and threat-detection services such as GuardDuty and Defender.

Our methodology

We benchmark against the CIS Foundations Benchmarks for AWS, Azure and GCP, the provider Well-Architected security pillars, and map attack paths to the MITRE ATT&CK Cloud Matrix.

1. Scoping: we agree providers, accounts and projects in scope, whether the review is read-only or includes proof-of-concept exploitation, and your compliance drivers.
2. Reconnaissance and enumeration: we inventory accounts, identities, resources and exposure.
3. Mapping and threat modelling: we build the identity and trust graph to find likely escalation paths.
4. Configuration and vulnerability analysis: we combine automated benchmark scanning with manual policy and architecture review.
5. Exploitation: where agreed, we demonstrate escalation or data-exposure paths through controlled proof-of-concept.
6. Reporting and debrief: we give you clear findings with a live walkthrough.
7. Retest: we verify every remediated finding after you apply the fixes.

Testing approaches

• Configuration review (white box): read-only access through an audit role. This assesses a whole estate efficiently and we recommend it by default.
• Grey box: a configuration review with limited credentials, so we can demonstrate real attack paths through proof-of-concept exploitation.
• Black box: external assessment of cloud-hosted exposure with no internal access, simulating an outside attacker.

We recommend a configuration review with grey-box exploitation for the clearest picture of real-world risk.

What you get

• An executive summary covering overall posture and benchmark alignment.
• Technical findings with evidence, affected resources and clear reproduction.
• Per-finding remediation with CLI commands and Terraform/CloudFormation examples where useful.
• A CVSS severity rating alongside a business-risk rating reflecting blast radius and compliance impact.
• Same-day notification of any critical finding.
• A debrief call and a retest of remediated findings, both included.

FAQs

How long does a review take? A single-account review typically takes three to five days; multi-account organisations longer. Confirmed at scoping.

Will it disrupt running workloads? A configuration review is read-only and does not disrupt workloads. We agree any proof-of-concept exploitation in advance and perform it carefully.

Can it be done remotely? Yes. We deliver cloud reviews remotely from the UK through a scoped audit role.

How is this different from a CSPM tool? A posture tool flags misconfigurations continuously but cannot reason about combined privilege-escalation paths or business context. We confirm which findings you can exploit and what they would mean for you.