Identity
Over-broad roles, unused keys, missing MFA on consoles, federation surprises.
IAMEntra IDKeys
Coverage
UK regions, UK data, global attackers
Data stores
Public buckets, snapshots, backups, world-readable queues, leftover staging data in London/Ireland regions.
S3BlobGCS
Control plane
Exposed dashboards, metadata, SSRF-to-cloud, CI/CD that can deploy as prod.
MetadataCI/CD
Compute & containers
IMDSv1, privileged pods, escaped tasks, secrets in env vars.
EKSAKSGKE
Putting the bucket in London does not stop it being public. UK GDPR cares about access, not the sticker on the region. The pentest is how you prove the difference.
Why it matters
Misconfiguration, not exploitation
Cloud breaches are configuration failures
Almost nothing in a real cloud incident involves exploiting the provider. It is a role that trusts too broad a principal, a storage bucket readable by any authenticated AWS user, a security group opened for a migration in 2023, a key that never expires. The work is to find the paths, not the CVEs.
Identity is the perimeter
We follow the privilege escalation paths that matter: a role that can pass a more privileged role, a policy with a wildcard that nobody read carefully, a service account with project-wide permissions because that was the quickest way to make the deploy work. One over-broad trust policy usually connects a low-value foothold to your whole estate.
The pipeline is production
CI/CD holds deployment credentials and frequently gets less scrutiny than the environment it deploys to. A pull request that can run arbitrary build steps against a privileged runner is a route into production that never touches your application at all.
Region labels are not an access-control policy
UK data residency is a contractual and regulatory position, not a security boundary. We check whether the controls that are supposed to keep UK personal data in the UK actually do, because that is the question your customer’s DPO will ask and the one that is rarely tested.
This is a configuration and identity review with a live attack path traced through it, run against AWS, Azure or GCP, and written so both your platform team and your auditor can use it.
How it runs
The engagement, step by step
Scope and authorisation
Accounts, subscriptions or projects in scope, and written CMA 1990 authorisation. We also confirm what your cloud provider’s own testing policy permits, so nothing in the engagement breaches your agreement with them.
Read-only access
A time-limited audit role — SecurityAudit, Reader or the equivalent — plus, where relevant, a low-privileged principal that stands in for a compromised workload. Least privilege for us as well as for you.
Configuration review
IAM policies and trust relationships, storage exposure, encryption at rest and in transit, key management and rotation, network boundaries, logging coverage and retention, and public exposure of anything that should not be public.
Attack path tracing
From a realistic starting point — a compromised workload, a leaked key, an over-permissive role — we trace what an attacker actually reaches, and stop at proof rather than impact.
Pipeline and supply chain
CI/CD permissions, secret handling in build systems, image provenance, and whether a contributor can influence what runs on a privileged runner.
Report and re-test
Findings ordered by exploitable path rather than by tool severity, with the specific policy or setting to change. Re-test of every confirmed finding after remediation, included.
Deliverables
What lands on your desk
Attack paths, drawn
Not a list of 400 misconfigurations. The handful of chains that actually lead somewhere, shown from entry point to impact, with the single change that breaks each chain.
Exact remediation
The policy statement, security group rule or setting to change — written so a platform engineer can act on it directly instead of translating a generic recommendation.
Benchmark alignment
Mapped to CIS Benchmarks for the relevant provider, plus NCSC cloud security principles, ISO 27001 and UK GDPR where data residency or encryption is involved.
Re-test and attestation
Re-test of confirmed findings after you have changed the configuration, included in the fee, and a letter of attestation naming accounts, scope, dates and outcome.
Scoping
What we need from you to start
- Which accounts, subscriptions or projects are in scope, and who owns each of them.
- A time-limited read-only audit role for each, provisioned to us and revocable by you at any moment.
- An architecture sketch, however rough. Ten minutes of whiteboard saves us a day of inference.
- Whether any workload is managed by a third party, so we can confirm you are entitled to authorise testing of it.
- Your data residency commitments, if you make any to UK customers, so we can test them rather than assume them.
- Read access to the CI/CD configuration if the pipeline is in scope.
We work read-only by default. Where a finding can only be confirmed by making a change — assuming a role, writing an object — we ask first, do the minimum, and record exactly what we did and when.
UK compliance
Where this sits in a UK compliance programme
NCSC Cloud Security Principles
The fourteen principles are the reference point most UK public-sector and regulated buyers use. Findings are mapped to them directly, which is usually what the questionnaire in front of you is derived from.
ISO/IEC 27001
Evidences technical vulnerability management, access control and cryptographic controls across the cloud estate, including the accounts that predate your ISMS.
UK GDPR
Storage exposure, encryption and residency findings sit directly against Article 32, and against the transfer questions a customer’s DPO will raise about where UK personal data actually lives.
Cyber Essentials Plus
CE+ does not meaningfully cover cloud configuration. If your estate is mostly IaaS or PaaS, a CE+ certificate is not the assurance your customer thinks it is, and this engagement covers the gap.
Questions
What UK buyers ask before signing
For customer-operated resources the major providers permit testing under their published policies without prior approval, with named exclusions — denial of service being the main one. We check the current policy for your provider at scoping and stay inside it. Certain managed services still require notification, and we will tell you which.
Both, deliberately. A pure configuration review produces hundreds of findings with no sense of which matter. We review the configuration, then trace the paths that are actually exploitable and prioritise those, so your team fixes the five things that break real attack chains first.
We work read-only by default. Where confirming a finding requires an action — assuming a role, writing a test object — we ask first, keep it minimal, and record exactly what was done and when so it appears in your own logs with an explanation.
One to two weeks for a typical single-provider estate, driven by the number of accounts and the size of the IAM surface rather than by instance count. Multi-cloud or heavily federated estates take longer.
Yes — RBAC, workload identity, network policy, secret handling, admission control and the container images themselves. Say so at scoping so it is priced in rather than squeezed into the last afternoon.
Related
Engagements that usually run alongside
01
02
03
Network penetration testing
External perimeter and internal Active Directory, from first foothold to domain impact.
02
API security testing
REST and GraphQL: object-level authorisation, mass assignment, rate limits, schema exposure.
03
Security audit & reporting
The write-up an auditor accepts and a developer can act on, with a re-test to close it out.
Ready to scope a UK engagement?
A thirty-minute call. Assets, timeline, a quote in pounds sterling.
Request a quote