To scope a cloud penetration test for SOC 2 Type II on AWS, cover five layers: the external perimeter, the authenticated application and API, IAM and identity attack paths, network segmentation between environments, and the AWS-native services your product actually runs on. Your auditor is not looking for a scan report. They want a scoped engagement tied to your production architecture, clear severity ratings, evidence that findings were remediated, and, in the strongest cases, a retest that confirms the fixes held. This guide maps that scope to the AICPA Trust Services Criteria and to AWS's own penetration testing policy, so the test you buy is the test your auditor accepts.
TL;DR: scoping a SOC 2 Type II cloud pentest on AWS
The five scope layers: external perimeter, authenticated app and API, IAM and identity attack paths, network segmentation, and AWS-native services in your stack.
Does SOC 2 require a pentest? Not literally. The AICPA Trust Services Criteria never print the phrase, but auditors read CC4.1 (monitoring) and CC7.1 (vulnerability detection) as expecting periodic penetration testing (AICPA).
Type II is a window, not a snapshot. A SOC 2 Type II report tests both control design and operating effectiveness across an observation period, commonly 3 to 12 months, so your pentest needs to sit inside that window.
What the auditor wants to see: a scoped report, a documented methodology, severity ratings, evidence of remediation, and ideally a retest or attestation letter.
AWS lets you test most of your stack (EC2, RDS, API Gateway, Lambda, and more) without prior approval, but prohibits denial-of-service testing and requires a Simulated Events form for red-team activity (AWS).
The core question, answered first
Teams scoping their first SOC 2 Type II audit on AWS ask the same thing: how do I scope a cloud penetration test, and what will the auditor actually want to see? Scope follows your production architecture, not a checklist. A SOC 2 pentest assesses the system named in your system description, so the boundary of the test should match the boundary of the system under audit. For a multi-tenant SaaS on AWS, that means the auditor expects the test to reach where a real attacker would go: the login, tenant isolation, the API, the identity plane, and the cloud controls that keep one customer out of another customer's data. Everything below turns that into a repeatable scope map and shows how each layer produces evidence an auditor can rely on.
Does SOC 2 actually require a penetration test?
Here is the honest version, and it matters for scoping. SOC 2 does not literally mandate a penetration test. The AICPA Trust Services Criteria, the standard behind every SOC 2 report, never contain the words "penetration test" as a named, required control. If a vendor tells you SOC 2 "requires" a pentest by rule, they are simplifying.
So why does nearly every SOC 2 Type II report include one? Because auditors interpret two criteria as expecting it. Under CC4.1 (Monitoring Activities), the AICPA's points of focus reference a mix of ongoing and separate evaluations, and penetration testing is a standard example of a separate evaluation. Under CC7.1 (System Operations), the criteria call for detection procedures that identify new vulnerabilities and configuration changes that introduce weaknesses. Automated scanning covers part of that, but scanners are weak exactly where cloud applications break: broken authorization, tenant isolation failures, business logic abuse, and privilege escalation chains. A penetration test is how organizations demonstrate they meet the spirit of CC4.1 and CC7.1, which is why auditors expect one even though no line item demands it.
The practical takeaway: treat the pentest as expected, supporting control evidence for your SOC 2 Type II report rather than a box you can skip. It is one of the most direct ways to show an auditor that your monitoring and vulnerability-management controls actually operate. If you are earlier in the process, our walkthrough on how to prepare for SOC 2 audits covers the surrounding controls.
Type II changes the timing, not the scope
A SOC 2 Type I report evaluates whether controls are designed correctly at a single point in time. A SOC 2 Type II report goes further: it tests whether those controls operated effectively across an observation window, commonly 3 to 12 months. That distinction changes when you test, not what you test.
For Type II, a single scan on the last day of the window does not tell a convincing story. Auditors want to see vulnerability management run as an ongoing process across the period, which means either a penetration test performed inside the window with remediation before the report closes, or a continuous cadence that produces findings and fixes throughout. This is where a PTaaS model fits naturally: testing across the period rather than a single annual event maps cleanly onto the operating-effectiveness question a Type II auditor is trying to answer.
The SOC 2 cloud pentest scope map for AWS
Use these five layers as the backbone of your statement of work. Together they cover the attack surface a SOC 2 auditor cares about on AWS.
1. External perimeter
Everything an anonymous attacker can reach from the internet: your public web app, marketing and admin surfaces, exposed API endpoints, and any internet-facing infrastructure such as load balancers, edge functions, and public buckets. The test confirms that your external attack surface is minimal and hardened, and that nothing sensitive is exposed by default.
2. Authenticated application and API
The largest source of real risk in a SaaS product, and the layer scanners handle worst. Authenticated testing means the tester logs in as one or more roles and probes the app and API from the inside: broken object-level authorization (IDOR), broken function-level authorization, tenant isolation between customers, insecure direct references to another organization's data, and business logic abuse. For a multi-tenant SaaS this is the single most important layer, because a cross-tenant data exposure is both the most damaging finding and the one an auditor most wants ruled out. Our web application penetration testing service is built around exactly this layer.
3. IAM and identity attack paths
This is the cloud-native layer that distinguishes an AWS pentest from a generic web test. It covers overly permissive IAM roles and policies, privilege escalation paths through role assumption, exposed or long-lived access keys, weak trust relationships between accounts, and paths from a low-privilege foothold to broad account access. Identity is the new perimeter on AWS, and misconfigured IAM is one of the most common ways a small compromise becomes a full account takeover. For a deeper treatment of this layer, see our guide to cloud IAM penetration testing.
4. Network segmentation
Auditors want proof that your environments are isolated: production separated from staging and development, sensitive data stores reachable only by the services that need them, and no flat network where one compromised instance can reach everything. Segmentation testing validates security group rules, VPC boundaries, and the blast radius of a single compromised workload. If you run containers or Kubernetes, the segmentation and scoping questions get more involved; our note on Kubernetes penetration testing scope and cost goes deeper there.
5. AWS-native services in your stack
Finally, the specific AWS services your product depends on: S3 bucket policies and access controls, RDS and Aurora exposure, Lambda function permissions and environment secrets, API Gateway authorization, Cognito or other identity services, and secrets management. The goal is to confirm that the managed services you rely on are configured to keep data confidential and access controlled, which maps directly to the Security and Confidentiality categories of the Trust Services Criteria.
Who owns which layer
The five layers split cleanly across a hybrid team. Human-led cloud pentesting owns the identity and infrastructure layers: IAM and privilege-escalation attack paths, cloud configuration review, and network segmentation, where judgment about trust relationships and blast radius matters most. The application and API layer, running on top of that cloud, is where Stingrai's autonomous agent Snipe works. Snipe is a web application pentesting agent that hunts the complex, high-impact classes scanners miss, including IDOR, broken authorization, and business logic flaws, using both black-box testing and white-box source review. It does not test cloud infrastructure; it tests the app and API surface exhaustively, and its findings feed the same report the human team uses for the IAM, config, and segmentation layers.
Which AWS services you can test, and what AWS prohibits
AWS publishes a customer support policy for penetration testing, and scoping around it keeps your engagement inside the rules. Under that policy, customers may test a broad set of services without requesting prior approval, including Amazon EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate, OpenSearch, and more (AWS). That covers the compute and application layers where most SaaS attack surface lives.
AWS also draws hard lines. The policy prohibits denial-of-service and distributed denial-of-service testing, port and protocol flooding, request flooding against login or API endpoints, DNS zone walking or hijacking via Route 53, and S3 or subdomain takeover attempts. Separately, any covert adversarial simulation, command-and-control activity, red, blue, or purple team exercise, simulated phishing, or malware testing requires you to submit a Simulated Events form for review, at least two weeks in advance (AWS). For a standard SOC 2 pentest you almost never touch the prohibited activities, but if your scope includes red teaming, plan for that form early so the timeline does not slip.
Scope decision | What it means for a SOC 2 pentest on AWS |
|---|---|
Test without prior AWS approval | EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate, OpenSearch, and other listed services |
Prohibited by AWS policy | DoS and DDoS, port and protocol flooding, request flooding, DNS attacks via Route 53, S3 and subdomain takeover |
Requires a Simulated Events form | Red, blue, or purple team exercises, covert C2, simulated phishing, and malware testing, submitted at least two weeks in advance |
Always your responsibility | Testing only assets you own or have written authorization to test, and staying within the agreed rules of engagement |
What your auditor actually wants to see
A pentest satisfies an auditor only if it produces the right artifacts. Across SOC 2 Type II engagements, auditors consistently look for the same five things:
A scoped, dated report that names the systems tested and ties to your system description. Scope creep or scope gaps are the fastest way to get a finding questioned.
A documented methodology. The auditor wants to know the test followed a recognized approach and reached the authenticated and identity layers, not just an unauthenticated scan.
Severity ratings and clear findings. Each issue rated by impact and likelihood, so the auditor can see you triage risk rather than treat every finding equally.
Evidence of remediation. This is the part teams underestimate. A Type II report is about operating effectiveness, so the auditor wants to see that findings were fixed, with dates, tickets, or a remediation log inside the observation window.
A retest or attestation of fixes. The strongest evidence is a retest confirming that high and critical findings were closed. It turns "we found issues" into "we found and fixed issues," which is exactly the operating-effectiveness story a Type II report is built to tell.
Stingrai's penetration testing supports your SOC 2 Type II evidence by delivering each of these artifacts: a scoped report, severity-rated findings, a remediation-friendly format your engineers can act on, and retesting to confirm fixes held. The auditor still makes the call on your report; the pentest gives them the evidence to make it confidently.
Common scoping mistakes that weaken SOC 2 evidence
Unauthenticated-only testing. A scan of the login page proves almost nothing about tenant isolation or authorization. Auditors increasingly expect authenticated, role-aware testing.
Leaving IAM out of scope. Treating an AWS pentest like a generic web test skips the identity layer, which is where cloud compromises escalate. Scope IAM in from the start.
Testing after the window closes. A pentest dated after your observation period ends is hard to use as Type II evidence. Test inside the window with time to remediate.
No remediation evidence. Findings without fixes tell an operating-effectiveness auditor the control did not operate. Budget for remediation and a retest, not just the initial test.
Ignoring the AWS Simulated Events form. If your scope drifts into red-team territory, the two-week AWS approval requirement can blow your timeline. Decide early.
For a broader treatment of scoping decisions beyond compliance, our guide on how to scope a penetration test is a useful companion.
Frequently asked questions
How do I scope a cloud penetration test for SOC 2 Type II on AWS?
Scope it to your production system across five layers: the external perimeter, the authenticated application and API, IAM and identity attack paths, network segmentation between environments, and the AWS-native services your product runs on (S3, RDS, Lambda, API Gateway, and similar). The boundary of the test should match the boundary of the system in your SOC 2 system description, and the test should run inside your Type II observation window with time to remediate.
Does SOC 2 require a penetration test?
Not literally. The AICPA Trust Services Criteria do not name penetration testing as a required control. However, auditors read CC4.1 (monitoring activities) and CC7.1 (vulnerability detection) as expecting periodic penetration testing, so nearly every SOC 2 Type II report includes one (AICPA). Treat it as expected supporting evidence rather than an optional extra.
What is the difference between a SOC 2 Type I and Type II pentest?
The difference is timing, not scope. A Type I report evaluates control design at a single point in time, while a Type II report tests operating effectiveness across an observation window, commonly 3 to 12 months. For Type II, auditors want testing and remediation inside that window, which is why continuous or in-window testing beats a single point-in-time scan.
Which AWS services can I test without asking AWS first?
AWS's penetration testing policy lets customers test a broad set of services without prior approval, including EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate, and OpenSearch (AWS). AWS prohibits denial-of-service testing, flooding, DNS attacks via Route 53, and bucket or subdomain takeover, and requires a Simulated Events form for red-team activity.
What evidence does a SOC 2 auditor want from a pentest?
A scoped, dated report tied to your system description, a documented methodology, severity-rated findings, evidence that findings were remediated within the observation window, and ideally a retest confirming the fixes. Remediation and retest evidence matters most for Type II, because the report is about whether controls operated effectively over time.
Does a cloud pentest cover AWS misconfigurations and IAM?
Yes, when it is scoped to. A cloud pentest for AWS should include IAM and identity attack paths, cloud configuration review, and network segmentation alongside the app and API layers. Human-led testing owns the IAM, configuration, and segmentation work, while an application security agent covers the app and API surface running on top of the cloud.
Can I use one pentest for multiple frameworks?
Often, yes. A well-scoped cloud and application pentest supports SOC 2 and frequently maps to ISO 27001, PCI DSS 4.0, and HIPAA, because they share expectations around vulnerability management and secure configuration. Confirm the specific control mappings with your auditor, but one rigorous test usually does most of the work across programs.
How often should we run a pentest for SOC 2 Type II?
At minimum once inside each observation window, with remediation evidence before the report closes. Many teams move to a continuous or PTaaS cadence so testing produces findings throughout the window, which aligns better with the operating-effectiveness question a Type II report is designed to answer.
Scope it once, satisfy the auditor, keep your engineers moving
A SOC 2 Type II pentest on AWS is not a mysterious auditor demand. It is a scoped assessment of the system you already run, across five predictable layers, producing evidence that your monitoring and vulnerability-management controls actually work. Get the scope right, test inside the window, remediate, and retest, and the audit conversation becomes straightforward.
Stingrai runs cloud and application penetration tests that produce exactly the evidence a SOC 2 Type II auditor expects, with human-led IAM and infrastructure testing plus autonomous coverage of your app and API layer. Explore our PTaaS and web application penetration testing services, or see current pricing to scope your SOC 2 engagement.
References
AICPA. Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (SOC suite of services). https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services. The standard behind SOC 2 reports; CC4.1 (monitoring activities) and CC7.1 (vulnerability detection) are the criteria auditors read as expecting penetration testing.
Amazon Web Services. Penetration Testing (Customer Support Policy for Penetration Testing). https://aws.amazon.com/security/penetration-testing/. Lists services customers may test without prior approval, prohibited activities, and the Simulated Events form requirement for adversarial simulations.
