How is this different from a cloud penetration test?

This answers whether the environment is built and governed correctly and whether you would see an attack. A penetration test answers what an attacker can do once they're in, with proof. Assessment covers the whole estate at architecture depth; testing goes narrow and deep with exploitation. Most teams need the assessment first, because there's little point proving an escalation path in an environment with no guardrails to fix it in.

We already run a CSPM tool with a compliance score. What does this add?

A CSPM checks resources against rules. It can't tell you that your organizational unit structure allows any team to undo a guardrail, that federation was designed around a contractor who left, or that four teams each assume someone else watches the alerts. We take your CSPM output as an input, deduplicate it, and spend the engagement on the architecture and ownership questions the tool has no way to ask.

Does this make us compliant, or produce a certificate?

No. We're not an auditor or a certification body, we don't issue attestations, and nothing we produce is a certification — a passing score from us carries no weight with your assessor. What we do is map every finding to the controls your auditors already use, so an evidence request has a documented answer and you can see which gaps are most likely to be challenged before someone raises them. The audit itself stays with your assessor.

How much access do you need, and how much of our team's time will this cost?

Read-only is enough: a role carrying the AWS SecurityAudit and ViewOnlyAccess managed policies, and roles/iam.securityReviewer with roles/viewer in Google Cloud — issued by you, scoped by you, revocable by you at any point. Beyond that, expect a few hours per team: short interviews with whoever owns identity, networking, platform, and detection. We reconstruct the rest from configuration rather than sending a questionnaire and waiting weeks for it to come back half-answered.

Cloud security assessment

A senior review of how your AWS and Google Cloud estate is actually built and governed — scored against a control checklist you keep, and turned into a remediation roadmap your board can read and your engineers can execute.

Book a scoping callHow we work

When you need this

Your board or audit committee asked how secure the cloud environment is, and the only answer available is a compliance percentage from a dashboard.
The estate grew one account at a time. There's no landing zone, new accounts get created by copying an old one, and nobody can say what the guardrails are.
A customer, insurer, or auditor sent a control questionnaire mapped to CIS or ISO, and answering it honestly would take weeks of guessing.
Something happened — a near miss, an exposed bucket, an alert nobody saw — and you need to know where else the same gap exists before you brief anyone.

What we do

The estate before the findings

We start with how the environment is governed, not with a resource list. Organization and organizational unit or folder hierarchy, service control policies and the newer resource control policies in AWS, organization policy constraints and custom constraints in Google Cloud, account vending and how far each account has drifted from the baseline it was created with, network segmentation and shared services, break-glass paths. Collection is automated across every account, project, and region you give us read access to — Prowler for benchmark checks, Cartography to build the relationship graph, and the organization APIs directly — so the engineer on your call spends the engagement judging whether that structure holds rather than assembling it.

Identity structure, not a list of over-permissive roles

How humans get in — IAM Identity Center or your own IdP, permission-set design, session duration, privileged tiers, break-glass accounts — and how workloads get in: OIDC federation versus long-lived access keys, service account impersonation and workload identity federation, and how narrowly role trust policies are written. IAM Access Analyzer external and unused-access findings and Google Cloud IAM Recommender and Policy Analyzer output go in as input, not as the answer. The judgement is about the design: whether permission boundaries, deny guardrails, and role hierarchies constrain anything in practice, or only document intent.

Logging and detection coverage, measured against technique

Coverage gets checked per account and per region, not assumed from one well-configured account. Organization-wide CloudTrail with management and data events, whether the log destination is genuinely tamper-resistant (S3 Object Lock, a Cloud Storage bucket retention lock) rather than just permission-restricted, retention measured against how far back your own investigations reach, which GuardDuty protection plans are on, which Security Command Center tier you actually pay for, and the Google Cloud Data Access audit logs that stay off until someone enables them. We map what you can see to the MITRE ATT&CK Enterprise techniques covering the IaaS and Identity Provider platforms, and record who receives each alert — coverage that reaches nobody is a gap, and we score it as one. This engagement measures coverage and names the gaps; authoring and tuning the rules that close them is separate work, and we'll tell you which gaps justify it.

Data protection and blast radius

Where sensitive data lives, what reaches it, and what a single compromised identity or account would expose. AWS KMS key policies and grants, Cloud KMS IAM bindings at key-ring and key level, and whether keys are separated by data domain or shared across the estate; tenancy boundaries; S3 Block Public Access and public-access prevention on Cloud Storage; VPC Service Controls perimeters and whether their dry-run logs were ever read; backup immutability and whether a restore has actually been performed. Amazon Macie or Google Cloud Sensitive Data Protection informs the picture; neither replaces asking your teams where copies of the data ended up.

What you receive

The control checklist we ran, scored control by control with the evidence behind each score — yours to re-run every quarter without us
Current-state architecture diagram: accounts and projects, trust boundaries, network paths, and where logs flow
Detection coverage as an ATT&CK Navigator layer you can reload later — each uncovered technique named, with the log source it would need and the team that owns it
Target landing zone and guardrail design: the organizational unit or folder structure, the SCP, RCP, and organization policy set, and the account and project baseline, specified so your platform team can implement it
Prioritised remediation roadmap sequenced by risk reduced per unit of engineering effort, with effort estimates
Board-level summary and a control-framework mapping table (CIS AWS Foundations Benchmark and CIS Google Cloud Foundation Benchmark, the AWS Well-Architected Framework security pillar, NIST CSF 2.0, ISO/IEC 27001:2022 Annex A)

How it runs

Scope
days
Accounts and organizations in scope, read-only access issued, fixed price set.
Review
1–3 weeks
Automated configuration collection across every account and region, then architecture review and short interviews with the people who run it.
Readout
days
Working session on the findings, then the scored checklist, roadmap, and board summary.
Re-score
included
After your remediation window we re-run the checklist and update the score, so progress is measured the same way twice.

Durations are indicative. Actual scope and price are fixed after the scoping call.

Questions we get asked

How is this different from a cloud penetration test?: This answers whether the environment is built and governed correctly and whether you would see an attack. A penetration test answers what an attacker can do once they're in, with proof. Assessment covers the whole estate at architecture depth; testing goes narrow and deep with exploitation. Most teams need the assessment first, because there's little point proving an escalation path in an environment with no guardrails to fix it in.
We already run a CSPM tool with a compliance score. What does this add?: A CSPM checks resources against rules. It can't tell you that your organizational unit structure allows any team to undo a guardrail, that federation was designed around a contractor who left, or that four teams each assume someone else watches the alerts. We take your CSPM output as an input, deduplicate it, and spend the engagement on the architecture and ownership questions the tool has no way to ask.
Does this make us compliant, or produce a certificate?: No. We're not an auditor or a certification body, we don't issue attestations, and nothing we produce is a certification — a passing score from us carries no weight with your assessor. What we do is map every finding to the controls your auditors already use, so an evidence request has a documented answer and you can see which gaps are most likely to be challenged before someone raises them. The audit itself stays with your assessor.
How much access do you need, and how much of our team's time will this cost?: Read-only is enough: a role carrying the AWS SecurityAudit and ViewOnlyAccess managed policies, and roles/iam.securityReviewer with roles/viewer in Google Cloud — issued by you, scoped by you, revocable by you at any point. Beyond that, expect a few hours per team: short interviews with whoever owns identity, networking, platform, and detection. We reconstruct the rest from configuration rather than sending a questionnaire and waiting weeks for it to come back half-answered.

Related services

Book a scoping call