Identity and access management
Users, roles, groups and service accounts; permission escalation paths; unused and over-privileged identities; long-lived access keys and the ones that have never been rotated.
Cloud Security
Cloud breaches are configuration breaches.
Nobody hacks the hypervisor. They find the storage bucket left public, the access key committed to a repository, or the role that can assume every other role in the account.
AWSAzure · GCP
CISBenchmark scored
IAMPermission path analysis
MultiAccount review
The shared responsibility line is where things go wrong
Cloud providers secure the infrastructure. You secure what you put on it — and the boundary between those two is where almost every cloud incident happens. AWS will not stop you making a bucket public. Azure will not stop you granting Owner to a service principal. GCP will not stop you leaving a service account key in a container image. The controls exist; the defaults are rarely what you want; and the person who set it up two years ago has left.
The second problem is accumulation. Cloud permissions are granted quickly, under deadline, and almost never revoked. After a couple of years the identity model is a sediment of policies that nobody can reason about, and the interesting question stops being "who has admin?" and becomes "who can become admin?" — which is a graph problem, not a list.
We assess the configuration against CIS Benchmarks and the provider’s own guidance, then trace the permission paths that matter. The output is not a list of every deviation from a benchmark; it is the handful that would actually let somebody take the account.
Coverage
What we assess
Read-only access to the accounts or subscriptions in scope. We do not need write permission and we do not ask for it.
Storage exposure
Object storage, disks, snapshots and backups checked for public access, weak policies, missing encryption and the snapshot somebody shared publicly for a migration in 2023.
Network configuration
Security groups, network ACLs, peering, ingress rules open to the world, and management ports reachable from anywhere.
Secrets and key management
Where credentials live, whether the key management service is used properly, and secrets embedded in environment variables, images and infrastructure code.
Logging and detection
Whether audit logging is enabled everywhere, retained long enough to be useful, and monitored by anybody — this is the control that decides whether you can investigate an incident at all.
Compute and container configuration
Instance hardening, container and Kubernetes configuration, image provenance and privileged workloads.
Serverless and managed services
Function permissions, event source configuration, and managed database exposure and authentication.
Infrastructure as code
Terraform, CloudFormation and Bicep reviewed before deployment, so the same misconfiguration is not committed and reapplied indefinitely.
Approach
How a cloud assessment runs
Usually five to ten working days depending on account count and service spread.
-
01 · Access and inventory
Read-only role in each account or subscription, then a full inventory of what is deployed — which is often the first surprise.
-
02 · Benchmark assessment
Configuration scored against CIS Benchmarks for the relevant provider and services, producing a pass/fail baseline.
-
03 · Identity analysis
Permission paths traced across identities and accounts to find who can escalate to what, including indirect routes through role assumption.
-
04 · Exposure review
Everything reachable from the internet, and everything reachable from a compromised workload inside the environment.
-
05 · Prioritise
Findings ranked by exploitability rather than benchmark severity, because a failed benchmark check that nobody can reach is not the priority.
-
06 · Report and retest
Fixes specified as configuration changes and infrastructure code where possible, then a free retest.
Run against recognised standards
- CIS BenchmarksAWS, Azure, GCP and Kubernetes
- AWS Well-ArchitectedSecurity pillar
- ISO 27001 Annex AControl mapping
- NIST CSFMaturity view where requested
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Benchmark scorecard
Pass/fail against CIS per account, with the deviations that matter separated from the ones that do not.
Identity risk map
Who can escalate to what, shown as paths rather than as a permissions dump.
Exposure inventory
Everything internet-reachable, with the reason it is reachable.
Fixes as code
Remediation given as concrete configuration or infrastructure-as-code changes where the platform allows it.
Free retest
Re-scored after remediation, so you can show the delta.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You migrated to cloud quickly and the configuration has never been independently reviewed.
- You run multiple accounts or subscriptions and nobody owns the identity model across them.
- You are pursuing ISO 27001 or SOC 2 and need infrastructure evidence.
- Developers can deploy to production and the guardrails are conventions rather than policy.
- You have had a near miss — an exposed bucket, a leaked key — and want to know what else is out there.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
Cloud Security Assessment — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
What access do you need to assess our cloud environment?
A read-only role in each account or subscription in scope — SecurityAudit or ViewOnlyAccess on AWS, Reader plus Security Reader on Azure, or the equivalent viewer roles on GCP. We do not require write access, we do not require console credentials for a human user, and the role can be time-boxed and revoked the moment the engagement ends.
Is this the same as a penetration test?
No, and the difference matters. A cloud configuration assessment reviews the environment from a position of authorised read access — it is comprehensive and finds issues that no external test would reach. A cloud penetration test attacks the environment from outside or from a compromised workload. They complement each other, and most clients get more value from the configuration assessment first because it finds more, faster.
Can you review our Kubernetes clusters?
Yes. Cluster configuration, RBAC, network policy, pod security standards, admission control, secrets handling and image provenance, scored against the CIS Kubernetes Benchmark. Container platforms tend to reproduce the same identity problems as the cloud account around them, so we look at both together.
Do you review infrastructure as code?
Yes, and it is the highest-leverage place to fix things. Reviewing Terraform, CloudFormation or Bicep catches misconfiguration before it is deployed, and fixing it in the module fixes every environment built from it. Where clients have infrastructure code, we deliver remediation as changes to that code rather than as console instructions.
We are multi-cloud. Can you assess all of it?
Yes. Each provider is assessed against its own benchmarks, and then we look at the joins — cross-cloud identity federation, shared secrets and the network paths between environments, which is where multi-cloud estates tend to be weakest because no single team owns the boundary.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.