Cloud Penetration Testing

A configuration review reads your settings and compares them with a benchmark; a cloud penetration test proves what an attacker does with the ones that are wrong. This engagement contains both, in that order. Phase two benchmarks the accounts in scope against CIS Benchmarks and provider baselines, covering storage, networking, logging and encryption, and it stands on its own as a misconfiguration list. Phases three to five then take that list somewhere useful: we map roles, policies and trust relationships, follow identity attack paths from a foothold, escalate across roles, and show what the chained path reaches in data stores, secrets and workloads. The difference matters commercially, because a list of two hundred deviations tells you nothing about which three of them put customer data one API call away. If the benchmark scorecard and a remediation runbook are genuinely what you need, our Cloud Security Configuration Assessment is the narrower piece of work and the better buy.

For the ordinary case, no. The major providers let customers test the resources they themselves control under an acceptable-use policy each one publishes, so the bulk of this engagement needs no separate approval from AWS, Azure, GCP, DigitalOcean or Oracle Cloud. We still read the current policy for each provider in scope during phase one rather than relying on what was true last year, because the wording moves and the boundary is the point. That boundary sits where your tenancy ends. Your own workloads, identities, storage and network configuration are yours to authorise. Anything aimed at the provider's shared infrastructure, at other tenants, or at the internals of a managed service you rent rather than run is not, and simulated denial of service or stress testing needs separate arrangement. Physical intrusion and social engineering sit outside this service. What is in scope, what is excluded and who may change it go into the signed Rules of Engagement.

You create the access inside your own identity system and we work within it; nothing here asks you to share a password or an existing administrator's session. There are two tiers in practice. A read-only role at the account, subscription or project level lets us assess configuration in phase two, covering storage and network exposure, logging and monitoring coverage, and encryption at rest and in transit. A limited test principal, scoped to the paths agreed with you, then lets us demonstrate privilege escalation in phase four without improvising permissions mid-test. We ask that both are created for this engagement, time-bound to the testing window and revoked at the end, which leaves your team a clean record of what was touched and by whom. Where you would rather see the unauthenticated view first, we can start from outside with no credentials and report what an attacker reaches before any access is granted.

An account boundary is only real if identity does not cross it, and that is the thing we test. Estates are drawn as separate production, staging and sandbox accounts, then quietly rejoined by a management account, a shared build role, a cross-account trust policy or one identity provider federating into each of them. Phase three maps those roles, policies and trust relationships, so the question we answer is not how many accounts you hold but how few hops separate the weakest one from the account holding customer data. That is usually where the finding worth paying for lives: a pipeline role in a non-production account assuming into production, or a federated group carrying wider entitlements than anyone intended. Our advice is to scope the non-production accounts in wherever those links exist. Leaving them out lowers the quoted figure and leaves untested the exact path we would otherwise have proven.

Run the configuration assessment first if your estate has never been benchmarked, and run this test first if it has. The assessment works from read-only access and exported configuration, measures the accounts against CIS Foundations Benchmarks, and hands back a scorecard per account with a hardening runbook your engineers apply through their own change process. It gives breadth cheaply and can run on live systems during business hours. This cloud VAPT gives depth instead: identity attack paths followed by hand, proof of concept behind each finding, and impact traced to the data a leaked credential reaches. Sequencing them that way means the test spends its time on real attack paths rather than rediscovering a public bucket. Where both sit in one programme, the benchmark work is done once and the findings are written up once. Our guide Cloud Security Best Practices: A Practical 2026 Guide covers the settings teams most often get wrong.