Penetration Testing

July 8, 2026

Cloud Security Assessment Checklist 2026: What AWS, Azure & GCP Pentesters Actually Look For

Ivan Stanev

Founder & Senior Security Researcher

Cloud Security Assessment Checklist 2026: What AWS, Azure & GCP Pentesters Actually Look For

What Is a Cloud Security Assessment?

A cloud security assessment is astructured technical review of your cloud environment that identifiesmisconfigured services, excessive permissions, exposed credentials, andexploitable network paths before an attacker does. Unlike a compliancechecklist, a thorough assessment tests whether those misconfigurations can bechained into actual access, because misconfigured IAM roles that arenever exploitable in sequence are a lower priority than a single exposedmetadata endpoint that hands an attacker instance credentials.

Why Automated Scanners Miss the VulnerabilitiesThat Matter

Automated cloud security tools (CSPM platforms,CIS benchmark scanners, DAST proxies) are fast and good at cataloguingconfiguration state. They tell you a policy exists, a bucket is public, or aport is open. What they cannot do is simulate what happens after.

A manual penetration tester does not stop atdetection. When they find an overprivileged Lambda execution role, they testwhether it can read Secrets Manager entries, call STS to assume a cross-accountrole, and persist access through a backdoored CloudFormation stack. That is thedifference between a compliance report and an actual security finding.

The table below shows the gap between what automated tooling reports and what a manual cloud security assessment actually tests.

Check Category	Automated Scanner	Manual Cloud Pen Test
Misconfigured S3/blob permissions	Detects public buckets	Tests chained privilege escalation from bucket access
IAM privilege escalation paths	Flags overprivileged roles	Simulates full attack path from initial access to admin
Network security groups / firewall rules	Identifies open ports	Tests for lateral movement across VPC/VNet segments
Secrets in environment variables	Pattern-matches known secret formats	Tests whether exposed secrets yield live service access
Container security (ECS/EKS/AKS)	CIS benchmark checks	Attempts container escape, host pivot, metadata SSRF
API Gateway exposure	Lists exposed endpoints	Tests auth bypass, parameter manipulation, business logic
Cross-account trust misconfig	Flags trust policy breadth	Exploits trust relationships to pivot between accounts
Logging and monitoring gaps	Checks CloudTrail/Sentinel enabled	Validates detection evasion and dwell-time viability

‍

Cloud Security Assessment Checklist: What Testers Examine by Provider

The specifics of a cloud security assessment shift depending on which platform your workloads run on. AWS, Azure, and GCP have different IAM models, different storage permission hierarchies, and different network architecture defaults. A tester who runs the same checklist across all three is not doing the job properly.

Risk Area	AWS	Azure	GCP
Identity & Access	IAM role chaining, EC2 instance profile abuse	Service principal misconfig, PIM gaps	Workload Identity Federation, service account key exposure
Storage	S3 bucket policies, pre-signed URL scope	Blob SAS token lifetime, public access tiers	GCS bucket ACL vs uniform access, signed URL abuse
Compute	EC2 metadata v1 SSRF, Lambda environment variables	VM IMDS, Azure Functions configuration exposure	GCE metadata server, Cloud Run environment leakage
Networking	Security Group 0.0.0.0/0, VPC peering scope	NSG rules, peering without NVA, ExpressRoute	Firewall rules, Shared VPC trust boundaries
Logging & Detection	CloudTrail gaps, GuardDuty coverage	Diagnostic settings gaps, Defender for Cloud	Cloud Audit Logs, Security Command Center gaps
Container / Serverless	EKS node IAM, ECS task role scope	AKS managed identity, Azure Functions authentication	GKE Workload Identity, Cloud Run ingress

IAM and Identity: The Highest-Leverage Attack Surface

Across all three providers, identity misconfiguration accounts for the majority of initial access and privilege escalation paths we observe. In AWS environments, EC2 instance profiles attached to roles with AdministratorAccess are still common. In Azure, service principals created for one-off tasks accumulate contributor-level permissions and never get rotated. In GCP, service account keys exported for CI/CD pipelines end up in version control.

The IAM review in a cloud security assessment covers role trust policies, permission boundaries, conditional access policies, federated identity configuration, and whether any path from a low-privilege identity reaches administrative scope.

Storage and Secrets Exposure

Public buckets get headlines, but the more common issue is overly permissive access from within the environment. A container that can write to a billing data bucket, a Lambda that can read production secrets from a staging-scoped role, or a pre-signed URL with a 7-day expiry passed through a customer-facing UI all create real exposure that passes automated scans.

Testers also look at environment variables in serverless functions and container task definitions. Credentials embedded in ECS task definitions, Azure Function app settings, or Cloud Run environment variables appear in plaintext to anyone with describe-level access to the resource. That is a direct path to lateral movement.

Network Segmentation and East-West Movement

Cloud network security fails in two directions: north-south (internet-facing exposure) and east-west (lateral movement between workloads). Automated tools catch security groups open to 0.0.0.0/0 reliably. They miss VPC peering relationships that give a development environment access to production database subnets, or Azure NSG rules that allow all internal traffic under the assumption that internal means trusted.

A thorough network review tests whether a compromised workload, once inside the VPC or VNet, can reach systems it should have no business talking to.

Container and Serverless Attack Surface

EKS, AKS, and GKE all introduce a layer of orchestration complexity on top of the base cloud IAM model. Kubernetes service accounts can be mapped to cloud IAM roles, which means a container escape does not just give host access: it potentially gives the attacker the permissions of the workload identity bound to that pod. Container assessments cover image hardening, RBAC configuration, admission controllers, runtime privileges, and the reachability of the cloud metadata endpoint from within the cluster.

When Should You Run a Cloud Security Assessment?

Timing matters. Running an assessment immediately before a compliance audit is the minimum bar, not the target. The most useful assessments happen when architecture is actively changing, because that is when misconfigurations are introduced.

Trigger	Why It Matters	Recommended Scope
Pre-SOC 2 Type II audit	Auditors expect evidence of control testing; penetration testing supports controls such as CC6.1 and CC6.6.	External attack surface assessment, IAM review, and logging validation.
Post-migration to cloud	Architecture changes introduce new misconfigurations that were not present in on-premises environments.	Full cloud configuration review and network segmentation testing.
New environment or product launch	Greenfield infrastructure often inherits default-permissive settings and configuration weaknesses.	Targeted assessment of the new cloud environment.
After a significant infrastructure change	Infrastructure-as-Code (IaC) drift and manual configuration changes can create security blind spots.	Scoped delta assessment compared with the previous security baseline.
Annual compliance cycle	Frameworks such as HIPAA, PCI DSS v4.0, and FedRAMP require periodic technical security testing.	Risk-based full-scope assessment or targeted reassessment.
Before a funding round or M&A due diligence	Investors and acquiring organizations increasingly request independent security validation.	Comprehensive cloud infrastructure and application security assessment.

‍

Compliance Requirements That Mandate Cloud Security Testing

Several major compliance frameworks include explicit or implicit requirements for cloud environment testing.

SOC 2 Type II (CC6.1, CC6.6, CC6.8): The Trust Services Criteria require logical access controls, boundary protection, and change management controls to be tested, not just documented. A cloud security assessment provides the evidence auditors need.

HIPAA 45 CFR §164.308(a)(8): The Security Rule requires covered entities and business associates to perform periodic technical and non-technical evaluations. For healthcare SaaS on AWS or Azure, this includes the cloud infrastructure hosting PHI.

PCI DSS v4.0 (Requirement 11.3): Internal and external penetration tests are required at least annually and after significant infrastructure changes. Cloud environments hosting cardholder data fall within scope.

FedRAMP: Annual penetration testing is a mandatory control for cloud service providers seeking FedRAMP authorization.

‍

What a Cloud Security Assessment Deliverable Should Include

A useful report tells you what an attacker can actually do, not just what configuration violations exist. Every finding should include: the vulnerable component, the attack path that makes it exploitable, the blast radius if exploited, and a specific remediation instruction with a verification step.

Prioritisation should follow a risk-based approach aligned to your environment: a public S3 bucket containing build artefacts is a lower-priority finding than the same bucket containing customer data accessed by a production API. Testers who cannot explain the business context of a finding are handing you a scanner export.

IVASTA delivers a written narrative report, an executive summary appropriate for board-level readers, a technical findings appendix with reproduction steps, and a remediation tracker template. Retest access is included for critical findings.

Run a Cloud Security Assessment Before Your Auditors or Attackers Do

A cloud security assessment is not a compliance checkbox. It is the mechanism that tells you whether your architecture holds under realistic attack conditions. Automated tooling gives you configuration state. A manual tester gives you attack paths.

If your environment is approaching a SOC 2 Type II audit window, preparing for a funding round, or has seen significant infrastructure changes in the past six months, the right time to test is now, not after an incident.

IVASTA's OSCP-certified testers conduct cloud security assessments across AWS, Azure, and GCP, with a written report, retest access for critical findings, and a fixed-price proposal within 48 hours of scoping.

‍
Schedule Your Cloud Security Assessment

IVASTA Security serves SaaS, fintech, and healthcare companies across the United States and Europe. For MSPs and audit firms that need a white-label testing partner, IVASTA Security offers dedicated partnership arrangements with NDA-protected reporting and co-branded deliverable options. Book a scoping call with IVASTA Security.

‍

Frequently Asked Questions

A cloud security assessment covers IAM configuration and privilege escalation paths, storage permissions and data exposure, network segmentation and east-west movement potential, container and serverless attack surface, secrets and credential exposure, and logging gaps that would allow an attacker to operate undetected. A manual assessment also tests whether individual findings can be chained into a realistic attack path, which automated tools cannot replicate.

A compliance audit checks whether controls are documented and configured. A cloud security assessment tests whether those controls hold under attack conditions. Both are necessary: the audit confirms process, the assessment tests reality. For frameworks like SOC 2 and PCI DSS, you need both, and the penetration test evidence is typically what gives auditors confidence that CC6.6 and Requirement 11.3 are genuinely met.

Scope determines timeline. A targeted assessment of a single AWS account with a well-defined workload typically runs 5 to 7 business days of testing time. A multi-account, multi-cloud environment with containerised workloads and microservice APIs will take 2 to 4 weeks. Scoping calls with your tester before engagement starts are the fastest way to get an accurate estimate. Ivasta provides a fixed-price proposal within 48 hours of a scoping call.

A cloud-focused assessment primarily tests the infrastructure layer: IAM, networking, storage, container orchestration, and service configuration. Application-layer vulnerabilities (injection, auth bypass, business logic flaws) are covered by a separate web application or API penetration test. For complete coverage, most SaaS companies run both: the application test finds what the code exposes, and the cloud assessment finds what the infrastructure allows.

Most assessments start from an assumed-breach or authenticated-user position: a read-only IAM role in AWS, a reader-level service principal in Azure, or a Viewer-bound service account in GCP. This simulates what an attacker has after phishing one employee or compromising a low-privilege workload. Some engagements also include an external unauthenticated perspective to test what is reachable before any credential is compromised. Your tester should define the starting access model clearly in the scoping document.

Annual testing satisfies most compliance frameworks, but cloud environments change faster than annual cycles can catch. Best practice for SaaS companies with active development is to run a full-scope assessment annually and a targeted delta assessment after major infrastructure changes: a cloud migration, a new product launch, or a significant IaC refactor. Some organisations also run quarterly lightweight reviews focused specifically on IAM drift and new resource exposure.

‍