Cloud Security Assessment: A Buyer's Guide

Who this is for

You're an engineering leader or security team tasked with evaluating cloud security assessment vendors. You've kicked tires on AWS Security Competency Partners, Azure Security MSPs, or GCP consultants. Maybe you've run Wiz, Prisma Cloud, or Orca scans in-house and learned that a security score doesn't tell you if your architecture is defensible.

Here's the thing: most cloud security assessments are CSPM scanner exports with a slide deck. A real assessment reviews your IAM architecture, blast radius logic, identity plane design, and cross-account trust — the things a scanner categorically cannot evaluate. This guide separates the two.

1. What a cloud security assessment should cover

A credible assessment touches five architectural layers: identity and access management, network segmentation and data exfiltration risk, data protection at rest and in transit, logging and detection coverage, and workload identity federation. In multi-cloud and multi-account setups, it also maps cross-boundary trust and blast radius — the blast radius being the set of accounts, projects, or subscriptions a compromised identity can affect.

Assessments should diagram your actual trust relationships, not describe them in prose. You should leave with a visual map of where a compromised service account, human principal, or API key can escalate and move laterally. That map is the foundation of everything else.

2. CSPM vs manual assessment: what each can and cannot do

Wiz, Prisma Cloud, Orca, and CloudSploit are CSPM tools. They're query engines: they ask your cloud environment "is this S3 bucket public?" or "is this IAM role overpermissioned?" and flag deviations from a policy library. They are excellent at finding misconfigurations, especially in large estates where humans can't read every policy.

They cannot assess whether your multi-account architecture makes sense, whether your cross-account role chain is defensible, or whether your identity plane is segmented. They cannot tell you the blast radius of a compromised Lambda execution role or trace the trust path from an external OIDC provider into your AWS accounts. They can flag that a role has {AdministratorAccess}, but they cannot say whether that role needs to exist or how to redesign it.

A manual assessment is a code review of your IAM policies, organization structure, and identity architecture. It's slow, expensive, and requires expertise in your specific cloud environment. It's also the only way to answer the questions that matter.

3. What certifications mean — and what they don't

AWS Security Specialty, AZ-500, and GCP Professional Cloud Security Engineer are real credentials. They require study and demonstrate technical depth. But they're prerequisites, not proofs of assessment capability.

Someone with AWS Security Specialty understands IAM, encryption, and Detective Controls. But assessing an organization's cloud architecture requires experience shipping and defending infrastructure in production, watching how real people mess things up, and learning what breaks in the field. Certifications validate fundamentals. Scars validate judgment.

4. AWS assessment: the points that matter

In AWS, focus on IAM policy analysis (inline policies are a smell; Service Control Policies should constrain the blast radius of each account; roles should be read-only until they need write access). CloudTrail coverage is essential — it should write to a dedicated account, be immutable via S3 Object Lock, and be monitored by a SIEM or rule engine. Ask about GuardDuty baseline: is it enabled in all regions, on all account types, with findings exported to your alert channel?

S3 bucket policies and bucket public access blocks are the second frontier. Cross-account roles are the third: trace the trust relationships between accounts and verify that assume-role policies constrain principals by ARN, not by account ID alone. If you see a role assumable by an entire AWS account, you've found a lateral movement vector.

5. Azure assessment: the points that matter

In Azure, the equivalent of IAM is Entra ID (formerly Azure AD) + Azure RBAC. A real assessment maps Entra ID conditional access policies, Privileged Identity Management enrollment, and role assignments across management groups and subscriptions. Assess the maturity of your Workload Identity Federation — if you're still using service principals with secrets, your threat model is weaker than it needs to be.

Azure Policy and Management Groups are your blast radius boundary. A policy set at the root management group applies to all subscriptions and resource groups underneath. An assessment should verify that your policies prevent deletion of audit logs, enforce encryption, and lock down network access. Network Security Groups (NSGs) and Azure Firewall rules are the segmentation layer; application security groups (ASGs) in NSG rules allow for more granular segmentation than subnet-level control.

6. GCP assessment: the points that matter

GCP security is organized around organization policies, VPC Service Controls, and IAM bindings at the organization, folder, and project level. An assessment should map the blast radius of each service account and verify that organization policies prevent public IAM bindings and require Cloud Audit Logs for sensitive operations.

VPC Service Controls create security perimeters; a real assessment determines whether you're using them to ring-fence projects that handle sensitive data. Workload Identity Federation is GCP's equivalent to Azure Workload Identity and AWS OIDC federation; an assessment should verify that your Kubernetes clusters, CI/CD pipelines, and external systems use federation instead of long-lived keys. Cloud Audit Logs should be exported to a dedicated project, immutable, and scanned for privilege escalation attempts.

7. What deliverables to expect

You should leave with architecture diagrams annotated with risk. Not a CSV of findings. Not a security score. Diagrams that show your account structure, identity flows, trust boundaries, and the blast radius of each principal. You should get a remediation plan prioritized by impact and effort, not severity score inflation.

You should get a baseline for what "normal" looks like in your environment — normal CloudTrail volume, normal API calls per role, normal data exfiltration patterns — so your detection rules don't alarm on business-as-usual. You should leave with a roadmap: quarter one, fix this. Quarter two, refactor that. Not "you have 47 high-severity findings."

8. Questions to ask before signing

Ask the vendor: "Will you diagram my architecture?" If they say they'll run a scanner and present the findings, pass. Ask: "Can you trace a compromised service account through my environment and tell me what it can access?" If they can't answer that, they won't uncover your real risks.

Ask for references from companies with infrastructure similar to yours, and call them. Ask what the assessment missed or misunderstood. Ask what surprised the vendor about the findings. Red flags: vendors who lead with compliance frameworks (CIS, NIST), claim a "full assessment" in three days, or deliver findings in an automated report format without architectural context.

Field observations

Observation 1: Most teams assume their CSPM tool is their assessment tool. After running a scan, they see a high count of medium and low findings and convince themselves they've done security work. In practice, the findings are noise. We worked with a company that had Prisma Cloud's attention on 189 "critical" findings; 187 of them were overpermissioned roles that had been in place for five years and never triggered a permission denial. We spent two weeks mapping which roles actually needed to exist and redesigned them. The scanner never suggested a delete.

Observation 2: Cross-account roles are harder to defend than most teams think. We found a team whose development account role was assumable by the entire production account, because the assume-role policy was {\"Principal\": {\"AWS\": \"arn:aws:iam::PROD-ACCOUNT-ID:root\"}}. In production, a compromised Lambda execution role could assume the development account role and steal source code and secrets. The security team had never mapped that trust chain.

Observation 3: Azure teams often inherit Conditional Access policies from an on-premises identity team and never revisit them. We audited a shop with 30+ policies, many of them contradicting each other (require MFA on login, except for logins from three IP ranges that were wrong). A manual assessment means sitting down with identity and access control and rebuilding the policy tree from scratch.

The short version

A cloud security assessment is not a CSPM scanner run. It's a code review of your IAM policies, identity architecture, account structure, and trust relationships. You need diagrams of your blast radius, a remediation plan tied to business impact, and a detection baseline. The vendor should demonstrate depth in your specific cloud environment (AWS IAM and SCPs, Azure RBAC and Entra ID, or GCP IAM and organization policies) and be able to trace a compromised identity through your environment to show you what it can access. CSPMs and scanners are good at finding misconfigs. Assessments are the only way to know if your architecture is defensible.