Cloud environments are the fastest-changing attack surface most organisations manage. New services are provisioned in minutes, IAM policies are modified for specific integrations and left in place, storage buckets are created with access controls that seem correct at creation and drift over time, and serverless functions accumulate permissions far beyond what the function actually needs.
Traditional penetration testing and network security assessments were designed for environments where infrastructure changes slowly. The cloud is the opposite: an environment where significant security-relevant configuration changes can occur across dozens of services between quarterly assessment cycles, without any single person having a complete view of what the full environment looks like at any given moment.
A cloud security assessment applies the same rigour as traditional security testing to the specific configuration, access control, and architecture challenges that cloud environments create. This guide covers what a cloud security assessment tests across each technical domain, how cloud assessment differs from traditional network and application penetration testing, the misconfiguration classes most consistently found across AWS, Azure, and GCP, and how to evaluate vendors for this type of engagement.
This distinction matters because a traditional penetration tester applied to a cloud environment without cloud-specific methodology produces a different (and less complete) assessment than one designed for cloud infrastructure.
Traditional penetration testing targets the attack surface from the outside in: scan for open ports, enumerate services, exploit vulnerable software, move laterally through the network. The threat model is an attacker who starts outside the perimeter and tries to get in.
Cloud security assessment targets the configuration surface from the inside out: review IAM policies for excessive permissions, test storage bucket access controls, validate network security group rule effectiveness, check logging and monitoring completeness, and verify that the shared responsibility model is correctly implemented. The threat model includes external attackers but equally addresses misconfigured internal access paths that would not appear in any external scan.
The most consequential cloud breaches of the last five years were not caused by unpatched CVEs in network services. They were caused by publicly accessible S3 buckets, IAM roles with wildcard permissions attached to Lambda functions, service accounts with owner-level permissions used for single-purpose automation tasks, and workloads exposed to the internet through misconfigured security groups. None of these are vulnerabilities in the traditional sense. They are misconfigurations that a traditional penetration test would not find.
IAM is the most consistently problematic domain in cloud environments and the highest-priority area for any cloud security assessment. The principle of least privilege is understood in theory and violated in practice in almost every cloud environment.
What IAM assessment tests:
Users with administrator or owner-level permissions who do not require that level of access. Service accounts and roles with permissions far exceeding what the workload they are attached to actually needs. IAM policies with wildcard resource specifications ("Resource": "*") that grant permissions across all resources in an account rather than the specific resources the policy is intended to control. IAM policies that permit privilege escalation: combinations of permissions that individually appear harmless but together allow a lower-privilege identity to create a higher-privilege identity or assume a more privileged role.
Long-lived access keys for IAM users (a significant finding in AWS environments where service accounts should use IAM roles rather than static credentials). Unused permissions and IAM entities that have not been active for extended periods. Cross-account trust relationships that grant external accounts more access than intended.
Provider-specific: AWS IAM, Azure Active Directory and Entra ID roles and permissions, GCP IAM roles and service accounts. Each has distinct permission models requiring platform-specific expertise.
Cloud network security is implemented through security groups, network access control lists (NACLs), virtual private cloud (VPC) configurations, and firewall rules, all of which are software-defined and can be misconfigured silently.
What network assessment tests:
Security group and NSAG rules that permit access from 0.0.0.0/0 (any internet IP) to administrative ports (SSH port 22, RDP port 3389, database ports, administrative interface ports). Overly permissive security groups that allow broad intra-environment traffic where specific port and source restrictions should apply. VPC configurations that allow unexpected traffic paths between environments that should be isolated.
Publicly accessible management interfaces on cloud resources (cloud management consoles, API endpoints, monitoring dashboards, build systems) that should be restricted to known IP ranges or VPN access. Network segmentation validation between production and development environments. Exposed database instances accessible from the internet.
Public cloud storage (S3 buckets, Azure Blob Storage containers, GCP Cloud Storage buckets): each is configured for access at the object and bucket level, and misconfiguration at either level can expose sensitive data without any vulnerability being exploited.
What storage assessment tests:
Buckets and containers with public read or write access that should be private. Buckets accessible to any authenticated AWS/Azure/GCP user (a less obvious but equally serious misconfiguration: restricting access to "authenticated users" in AWS means any AWS account holder, not authenticated users of the target organisation). Object-level ACLs that override bucket-level restrictions to make specific objects public. Server-side encryption configuration for buckets containing sensitive data. Versioning and access logging configuration. Cross-account access policies that expose storage to external accounts.
Virtual machines, container instances, and managed compute services each have distinct security configuration requirements that assessment covers.
What compute assessment tests:
EC2 instances, Azure VMs, and GCP compute instances running with default or overly permissive instance roles. Instance metadata service (IMDS) configuration: AWS IMDSv1 is vulnerable to server-side request forgery attacks that allow any process running on the instance to access the instance role credentials through the metadata endpoint; IMDSv2 requires session-oriented requests that mitigate this attack. OS-level configuration on cloud instances including patch status, services exposed on the instance, and local firewall rules.
Auto-scaling group configurations and launch templates that propagate misconfigured settings to new instances. Snapshots and AMIs shared publicly or with excessive account access. SSH key management and whether key rotation is enforced.
Lambda functions (AWS), Azure Functions, and GCP Cloud Functions introduce a security model distinct from traditional server-based applications: each function is a separate execution environment with its own IAM permissions, and misconfiguration in any function can create an independent attack path.
What serverless assessment tests:
Function execution roles with excessive permissions: Lambda functions that need to read from one S3 bucket are frequently deployed with roles that can access all S3 resources in the account. Environment variables containing sensitive values (API keys, database credentials, secret tokens) that should be stored in secrets management services. Function triggers that accept inputs from untrusted sources without validation, creating injection opportunities. Deployment package contents that include credentials or sensitive configuration. Dead letter queue and error handling configurations that leak sensitive information. Function URL configurations that create public HTTP endpoints without authentication.
Container-based workloads on managed Kubernetes services (EKS, AKS, GKE) or self-managed Kubernetes clusters require assessment at both the container and cluster configuration level.
What container assessment tests:
Kubernetes RBAC configuration: roles and cluster roles with excessive permissions, service accounts with cluster-admin-level access, role bindings that grant broad permissions to namespaces. Kubernetes API server access: whether the API server is exposed to the internet, whether anonymous authentication is disabled, whether the API server audit log is enabled. Pod security: containers running as root, containers with privileged mode enabled, containers with host namespace access (hostPID, hostIPC, hostNetwork). Container image security: known CVEs in base images, images pulled from untrusted registries. Network policies: whether pod-to-pod communication is controlled or unrestricted within the cluster. Secrets management: whether Kubernetes secrets are encrypted at rest and whether applications reference secrets correctly.
Cloud environments generate extensive telemetry, but most organisations have significant gaps in what they are collecting and alerting on. Assessment reveals whether logging and monitoring is configured to detect the attack patterns relevant to the environment.
What logging assessment tests:
CloudTrail (AWS), Azure Monitor activity logs, and GCP Cloud Audit Logs: whether they are enabled for all services, whether they are centralised in a logging account separate from the environments being logged (to prevent an attacker who compromises the production account from deleting their own trail), and whether log integrity validation is enabled. S3 access logging and VPC flow logs: whether access to storage and network traffic is being recorded. Alerting configuration: whether alerts are configured for high-value events (root account usage, console logins from unusual locations, IAM permission changes, security group modifications). SIEM integration: whether cloud logs are ingested into the centralised security monitoring platform.
What data protection assessment tests:
Encryption at rest for all storage services and databases. Key management: whether encryption keys are customer-managed (CMEK/CMK) where required, whether key rotation is configured, and whether key access policies are appropriately restricted. Encryption in transit: TLS configuration for all services, whether unencrypted protocol options are disabled. Backup encryption and retention policies. Data classification and whether sensitive data is handled according to classification.
Across assessments on AWS, Azure, and GCP environments, six misconfiguration classes appear with the highest consistency.
1. Wildcard IAM permissions. Policies granting "Action": "*" or resource-level wildcards appear in almost every cloud environment. Often introduced during initial development for convenience and never restricted as the environment matured.
2. Public storage buckets. S3 buckets, Azure blobs, and GCP storage buckets with public access remain a consistent finding despite increased cloud provider warnings and account-level block settings. Development and staging environments are particularly common sources.
3. Overly permissive security groups. Security groups permitting inbound access from 0.0.0.0/0 on ports beyond HTTP and HTTPS, particularly SSH, RDP, database ports, and application-specific administrative interfaces.
4. IMDSv1 on EC2 instances. The instance metadata service vulnerability enables any SSRF attack against an EC2 workload to retrieve the instance role credentials from the metadata endpoint. IMDSv2 addresses this through session tokens, but many environments have instances still running IMDSv1 from before IMDSv2 was enforced.
5. Secrets in environment variables. Lambda functions and container workloads storing API keys, database credentials, and authentication tokens in environment variables rather than in secrets management services (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
6. Logging gaps. CloudTrail disabled for specific regions, S3 access logging disabled on sensitive buckets, VPC flow logs not enabled, and CloudTrail logs stored in the same account they are monitoring (making log tampering possible after a compromise) appear across virtually all cloud environments assessed.
These terms are often used interchangeably but describe assessments with different emphasis.
Cloud security assessment is primarily a configuration review: examining how the cloud environment is configured against security best practices, the cloud provider's security frameworks (AWS Security Hub, Microsoft Secure Score, GCP Security Command Center), and the organisation's own security policies. It is mostly white-box, examining actual configuration rather than testing from an attacker's perspective.
Cloud penetration testing is primarily exploitation-focused: using attacker techniques against the cloud environment to confirm what is actually exploitable, chain misconfigurations into attack paths, and demonstrate business impact. It includes the configuration review component but extends it with active exploitation attempts.
A thorough cloud security programme benefits from both: configuration assessment to produce a comprehensive picture of the environment's security posture, and penetration testing to confirm which misconfigurations are actually exploitable from attacker positions and what the impact would be.
Cloud environments are an increasingly central component of the external attack surface that attack surface management continuously monitors. Cloud assets discovered through EASM (exposed API endpoints, storage buckets with public access, cloud management interfaces exposed to the internet) feed directly into cloud security assessment scope. External attack surface management vs. traditional pentesting covers how continuous discovery and periodic exploitation validation work together.
Cloud environments also require the same API security testing that application assessments require. Cloud services expose their functionality through APIs, and misconfigured or unauthenticated API endpoints are a significant finding class. API vulnerabilities standard penetration tests miss covers the eight API vulnerability classes most consistently absent from standard assessments.
The velocity at which cloud environments change makes continuous coverage more important here than in any other infrastructure type. A cloud environment assessed thoroughly in January can have hundreds of significant configuration changes by March: new services provisioned, IAM roles modified, security group rules adjusted, storage buckets created, none of which appear in the January report. Continuous penetration testing and how it differs from annual pentests covers the continuous model, and agentic pentesting and continuous security validation covers how agentic testing applies continuous exploitation validation to the cloud application layer.
For compliance purposes: SOC 2 penetration testing: what auditors actually require covers how cloud security assessment evidence maps to SOC 2 CC6 requirements for organisations with cloud-hosted infrastructure in scope. What is inside a VAPT report covers the evidence standard that distinguishes a useful assessment output from a checklist.
For cloud security assessment services in the US alongside application and network testing, VAPT services covering cloud infrastructure, or agentic penetration testing for the application layer that sits on top of the cloud infrastructure being assessed, the 10x Pentest platform covers the application security layer. See pricing or get in touch to discuss scoping cloud infrastructure assessment alongside application security coverage for your environment.
Q1. What is a cloud security assessment?
A cloud security assessment is a structured review of a cloud environment's security configuration, access controls, network controls, logging, and data protection practices. It tests whether the cloud infrastructure is configured according to security best practices and the principle of least privilege, whether storage and compute resources are accessible only to authorised identities, whether logging and monitoring would detect attacker activity, and whether sensitive data is appropriately protected. Cloud security assessment covers the configuration layer that traditional network and application penetration testing was not designed to test.
Q2. What does a cloud security assessment cover?
A thorough cloud security assessment covers eight technical domains: IAM configuration and least privilege enforcement; network security controls including security groups, NACLs, and VPC configuration; storage access controls for S3, Azure Blob, and GCP Storage; compute and workload security including instance roles and metadata service configuration; serverless function security including execution role permissions and secrets handling; container and Kubernetes security including RBAC and pod security; logging and monitoring completeness and integrity; and data protection including encryption at rest, key management, and encryption in transit.
Q3. How is a cloud security assessment different from a penetration test?
A cloud security assessment primarily reviews configuration against security best practices, examining how the cloud environment is set up rather than actively exploiting it from an attacker's position. A cloud penetration test goes further by actively attempting to exploit misconfigurations, chain vulnerabilities into attack paths, and demonstrate business impact. Most thorough cloud security programmes include both: configuration assessment for comprehensive posture coverage and penetration testing to confirm what is actually exploitable. The distinction matters for compliance purposes because some frameworks (PCI DSS, SOC 2) specifically require penetration testing evidence rather than configuration review evidence.
Q4. What are the most common cloud security findings?
The six misconfiguration classes found most consistently across AWS, Azure, and GCP environments are: wildcard IAM policies that grant excessive permissions across all resources; public storage buckets exposing sensitive data without requiring authentication; overly permissive security groups permitting inbound access from any internet IP on sensitive ports; IMDSv1 configuration on EC2 instances enabling metadata service credential theft through SSRF; secrets stored in environment variables rather than in dedicated secrets management services; and logging gaps where CloudTrail, access logging, or VPC flow logs are disabled or stored insecurely. These six classes appear in the majority of cloud environments assessed regardless of organisation size or cloud provider.
Q5. How often should a cloud security assessment be conducted?
Annual cloud security assessment is the common minimum, with assessment following significant infrastructure changes (migrating to a new region, deploying new services, major architecture changes). For actively developing cloud environments where infrastructure changes occur continuously, annual point-in-time assessment misses months of configuration drift. Continuous cloud security posture management (CSPM) tooling provides ongoing configuration monitoring between assessments, and continuous penetration testing of the application layer ensures that workload-level vulnerabilities are identified as deployments occur rather than at the next assessment cycle.
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 
Kubernetes penetration testing covers RBAC misconfigurations, privileged pods, API server exposure, supply chain weaknesses, and container escape paths. This guide maps what each test covers.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
