Someone on your team has proposed sending the AWS Artifact SOC 2 package, or the Azure report from the Service Trust Portal, to the auditor who asked for cloud penetration testing evidence. It will not work, and the reason is not a matter of taste. Every SOC 2 report on a cloud platform is written under description criteria that require the provider to disclose the controls it assumed you would implement. That disclosure, the complementary user entity controls section, is the provider's own auditor writing down the boundary of the report. Everything on your side of that boundary, meaning your configuration, your identity model and your data access, is exactly the layer a cloud penetration test evaluates.
The substitution fails by construction. The provider's report is evidence that the cloud is secure. It is not evidence that your cloud is secure.
What a CSP SOC 2 report actually attests to
A SOC 2 Type 2 examination is performed on controls at a service organization against the AICPA Trust Services Criteria. The service auditor opines on three things: whether the provider's description of its system is presented fairly, whether the controls were suitably designed, and whether they operated effectively across a stated period. The subject matter is the provider's system, not yours, and that scoping is visible in the providers' own documentation.
AWS Artifact distributes SOC 1, SOC 2 and SOC 3 reports, ISO certificates and PCI documents for AWS infrastructure and the AWS services in audit scope. The Microsoft Service Trust Portal carries Azure attestation reports covering Azure, Dynamics 365, Power Platform and selected Microsoft 365 services. Google Cloud Compliance Reports Manager carries SOC reports and ISO certificates for the Google Cloud services named in each audit. Two details from those pages matter more than the reports themselves.
First, AWS's Artifact documentation frames the purpose narrowly. It says you can submit Artifact documents to auditors or regulators to demonstrate the security and compliance of the AWS infrastructure and services that you use, then adds a note that AWS customers are responsible for developing or obtaining the documents demonstrating the security and compliance of their own companies. That note is the whole argument in one sentence, published by the provider whose report is being offered as the substitute.
Second, the reports have a shelf life and a confidentiality wrapper. Microsoft publishes Azure SOC reports on a rolling twelve month audit window, issues new reports twice a year with period ends of 31 March and 30 September, takes roughly six weeks after period end to publish, and covers the gap with quarterly bridge letters. Google marks material in Compliance Reports Manager as confidential information shared under the obligations in your cloud agreement, so you often cannot forward it to the customer who asked without checking the terms.
Complementary user entity controls: the section that ends the argument
The AICPA description criteria for a SOC 2 system description are codified as DC section 200, currently the 2018 criteria with revised implementation guidance issued in 2022. Criterion DC6 requires that where provider management assumed, in designing its system, that certain controls would be implemented by user entities, and those controls are necessary in combination with the provider's own controls to achieve its service commitments and system requirements, the description discloses those complementary user entity controls.
Read that back slowly. The provider is required to write down the controls it is depending on you to run, and its auditor's opinion is only meaningful on the assumption that you are running them. If you were not, the report would say exactly what it says today and still tell you nothing about your risk. Microsoft removes any ambiguity about where to look: its Azure SOC 2 compliance page tells customers that user entity responsibilities appear at the very end of the attestation report, and instructs them to search the document for that phrase.
The contents of any specific report are covered by its confidentiality terms, so this post describes structure rather than reproducing text. The themes recur across every major platform: you provision and revoke access, set authentication strength, manage customer-managed encryption keys, configure security groups and firewall rules, securely configure the services you consume, monitor your own logs, and secure the applications you deploy. Those are your controls, and no provider attestation moves them.
The shared responsibility model translated into audit artefacts
The shared responsibility model is usually drawn as a diagram. For an audit it works better as a table of who produces which artefact.
Layer | Who is responsible, and who may test it | Artefact that proves it |
|---|---|---|
Physical datacentre, network and hosts | Provider; provider's auditor only | CSP SOC 2 or ISO certificate |
Hypervisor and platform services | Provider; provider's auditor only | CSP SOC 2 or ISO certificate |
Guest OS, patching, installed software | Customer (IaaS) | Patch records plus penetration test |
Security groups and firewall rules | Customer (IaaS), shared (PaaS) | Config baseline plus penetration test |
Identities, users and access policy | Customer, every service model | IAM export, access reviews, escalation testing |
Configurations and settings | Customer, every service model | CSPM or IaC baseline plus penetration test |
Application code and authorization logic | Customer (IaaS), shared (PaaS/SaaS) | Application penetration test |
Customer data and classification | Customer, every service model | Data map, encryption config, access testing |
Every row is grounded in published material. AWS assigns to the customer the guest operating system including updates and patches, installed application software, the configuration of the AWS-provided security group on each instance, data management including encryption options, and the use of IAM to apply appropriate permissions. Microsoft's matrix marks customer data, configurations and settings, and identities and users as customer-owned across on-premises, IaaS, PaaS and SaaS alike. Google states the same split from the other direction: the provider always remains responsible for the underlying network and infrastructure, and customers always remain responsible for their access policies and data.
Now the asymmetry that decides the argument. AWS's penetration testing policy permits customer-initiated testing against a defined service list including EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate, and prohibits denial of service, request flooding, Route 53 DNS zone walking and hijacking, and S3 bucket or subdomain takeover. It also states plainly that customers are not permitted to conduct security assessments of AWS infrastructure or of the AWS services themselves.
So the two artefacts are not competing. The provider's report is the only evidence obtainable for the layer you are forbidden to test. A penetration test is the only evidence obtainable for the layer the provider does not attest to. Submitting one in place of the other leaves half the stack unevidenced.
What auditors accept, what they reject, and what they ask for next
PCI DSS v4.0.1 (June 2024) is the cleanest case, because it puts the two obligations in different requirements. Requirement 12.8.4 requires a programme to monitor third-party service providers' PCI DSS compliance status at least once every twelve months, 12.8.5 requires you to maintain information about which requirements are managed by each provider, which by you, and which are shared, and 12.9.2 obliges the provider to supply that on request. That is where the CSP compliance package belongs: it is vendor-management evidence.
Your testing obligation is untouched by it. Requirements 11.4.2 and 11.4.3 require internal and external penetration testing respectively, per your defined methodology, at least once every twelve months and after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party with organisational independence. Requirement 11.4.4 requires exploitable findings to be corrected and the testing repeated. Requirement 11.4.5 requires segmentation controls isolating the cardholder data environment to be tested rather than merely documented.
PCI DSS then anticipates precisely this conversation. Requirement 11.4.7 obliges multi-tenant service providers to support their customers for external penetration testing under 11.4.3 and 11.4.4, and the accompanying guidance states that multi-tenant providers "cannot forbid penetration testing" because doing so would leave customer systems exposed. The standard assumes you will test inside someone else's cloud.
SOC 2 does not name penetration testing as a required control and sets no frequency. Auditors read a pentest as a separate evaluation under CC4.1; CC7.1 is the vulnerability scanning criterion and is a different thing.
ISO/IEC 27001:2022 likewise mandates no penetration test and no cadence. The technical Annex A controls are A.8.8 Management of technical vulnerabilities and A.8.29 Security testing in development and acceptance. The supplier controls are A.5.19 through A.5.22, plus A.5.23 Information security for use of cloud services. The supplier controls are where the provider's report lands and the technical controls are where your own testing lands: separate rows in your Statement of Applicability, for a reason.
Hand an auditor only the CSP report and the follow-up is immediate and predictable: what did you do about the controls the report says are yours?
Mapping the CUEC list to evidence you can actually produce
A two-hour exercise removes the argument permanently. Open the user entity responsibilities section of each provider report you rely on, put every item in a spreadsheet, and add five columns: owner, control implemented, evidence artefact, test method, last validated.
Typical CUEC theme | Evidence you produce | Test method |
|---|---|---|
Provisioning and revoking user access | Joiner/mover/leaver records, access review exports | Sampling plus authorization testing |
Authentication strength and credential policy | Conditional access or IAM policy export, MFA coverage | Configuration review |
Customer-managed encryption keys | KMS key policy, rotation configuration | Configuration review |
Security groups, firewall rules, private endpoints | IaC diff, CSPM findings closed | Config review plus external test |
Secure configuration of consumed services | CIS benchmark output, drift report | Configuration review |
Monitoring, alerting and log review | Detection inventory, alert runbooks | Detection validation |
Security of applications you deploy | Penetration test report and retest | Exploitability testing |
Segregation of your tenants and environments | Architecture diagram plus segmentation results | Exploitability testing |
The last column is the one that matters. Most rows close with a configuration artefact, because they ask whether a control is set. Three do not, because they ask whether a control holds.
The two or three CUEC rows only an exploitability test can close
Authorization enforcement. A policy export proves a rule exists. It cannot prove that user A, authenticated to tenant A, cannot reach tenant B's object by editing an identifier in a request. Broken object level authorization is a defect in application logic, invisible to every configuration scanner, and the most common way multi-tenant isolation fails in practice. This is the row that answers a reviewer's tenant isolation question.
Privilege boundaries in the identity plane. An IAM policy document is a static assertion. What the auditor is really asking is whether a chain exists: a compromised low-privilege workload identity that can assume a role, pass a role, read a secret, and reach administrative access. Escalation paths are compositional, and enumerating policies one at a time will not surface them.
Segmentation between environments. PCI DSS makes this explicit at Requirement 11.4.5 by requiring segmentation controls to be tested rather than described. A diagram showing production and staging as separate does not prove that a foothold in staging stays in staging.
Every provider's CUEC list has rows in those three families, and none close with an export. That is the defensible reason a cloud penetration test is a line item rather than a preference.
What the enterprise security reviewer is really asking when they say "cloud pentest"
The phrase bundles three separate asks, and the review moves faster if you disambiguate before buying anything.
External attack surface of your production estate. Internet-reachable services, exposed storage, forgotten subdomains, edge configuration.
Identity and privilege escalation inside your account, subscription or project. Role assumption chains, over-permissive trust policies, workload identity misuse, secret sprawl.
Authenticated multi-tenant application testing. Whether one customer's session can reach another customer's data through the application layer.
A fourth ask sometimes hides in the same sentence: a configuration benchmark against CIS or a provider baseline. That is posture management, not penetration testing, and buying the wrong one is how this procurement goes sideways. A posture tool enumerates deviations from a baseline; a penetration test establishes whether a deviation is reachable, chainable and consequential. Only the second closes the CUEC rows above. We have covered where CNAPP coverage stops and whether an AWS security agent replaces a cloud penetration test separately.
Three questions back to the reviewer usually shorten the cycle by a week: which system boundary do you need covered, and does it include our cloud control plane or only the application; which questionnaire row or audit criterion does this evidence close; and do you need the full technical report under NDA, or a completion letter with scope, dates and remediation status?
At Stingrai the cloud control plane, identity and segmentation work is a human-led engagement, because escalation chains and segmentation are judgement problems. The application and API tier is where our autonomous agent Snipe runs continuously: black-box dynamic testing plus white-box source review aimed at the classes that close the tenant isolation row, meaning broken object level authorization, business logic flaws and broken access control, with AutoFix pull requests and pull-request gating so regressions do not ship. On the hybrid engagement every finding is validated by a human tester. Autonomous and hybrid both carry our No High or Critical Finding, Don't Pay guarantee. Pricing is published.
The evidence pack: what each artefact proves
Assemble four items. Send all four. The reviewer stops asking.
Artefact | What it proves | Refresh cadence |
|---|---|---|
CSP compliance report (Artifact, Service Trust Portal, Compliance Reports Manager) | The provider's infrastructure and platform controls were designed and operating effectively for a stated period | Per provider cycle; Azure publishes semi-annually with quarterly bridge letters |
Your CUEC responsibility matrix | You have read the provider's user entity responsibilities and assigned each to an owner and an artefact | On each new provider report |
Your configuration baseline and drift evidence | Your controls are configured as intended and deviations are detected | Continuous |
Your penetration test report plus retest | Your controls hold against an attacker: authorization, privilege boundaries, segmentation | At least every twelve months and after significant change |
Order matters when a deal is blocked. Send the CSP report and the responsibility matrix immediately: they cost nothing and they show you understand the boundary. Send the configuration baseline next. Commission the penetration test for the rows none of the first three can close, and scope it to those rows rather than a generic estate sweep. That is how a test gets bought for a reason and read as an answer, instead of arriving as a 90-page PDF that generates a second round of questions.
Related reading: pentest evidence auditors accept across SOC 2, ISO 27001, PCI and CMMC, preparing for a SOC 2 audit, cloud pentest scope for SOC 2 Type II on AWS, and using a pentest to clear an enterprise security review.
Frequently Asked Questions
Can I use the AWS SOC 2 report as my penetration testing evidence?
No. It is an examination of controls at AWS, covering AWS infrastructure and the services in audit scope. AWS's own Artifact documentation states that customers are responsible for developing or obtaining the documents demonstrating the security and compliance of their own companies, and AWS separately prohibits customers from conducting security assessments of AWS infrastructure or the AWS services themselves (AWS Artifact documentation). The two artefacts cover different layers.
What are complementary user entity controls?
Complementary user entity controls, or CUECs, are controls the service organisation's management assumed its customers would implement, and that are necessary in combination with the provider's own controls to give reasonable assurance that the provider's service commitments and system requirements are achieved. The AICPA description criteria for SOC 2, codified as DC section 200, require the provider to disclose them under criterion DC6. In cloud reports they typically cover access provisioning, authentication, key management, network configuration and the security of applications the customer deploys.
Does AWS Artifact satisfy my SOC 2 audit?
It satisfies part of it. Artifact gives your auditor the subservice organisation evidence for the infrastructure and platform layer, free and on demand. It does not evidence any control your auditor assesses at your organisation: access management, configuration, monitoring and application security. The controls the report hands back in its user entity responsibilities section are precisely the ones your own examination will test.
Do I still need a cloud pentest if my provider is certified?
Yes, if any obligation or questionnaire row concerns the layer you operate. The provider's certification covers the provider's layer, which you are forbidden from testing anyway. Under PCI DSS v4.0.1 your internal and external testing obligations at Requirements 11.4.2 and 11.4.3 are unchanged by your provider's compliance status, and Requirement 11.4.7 obliges multi-tenant providers to support customer testing rather than replace it.
Does Azure's compliance documentation cover my application?
No. The Azure SOC 2 Type 2 attestation report covers Azure, Dynamics 365, Power Platform and selected Microsoft 365 services. Microsoft's shared responsibility matrix assigns customer data, configurations and settings, and identities and users to the customer in every deployment model, and assigns applications to the customer in IaaS and a shared position in PaaS and SaaS (Microsoft Learn). Your application code and its tenant isolation are yours to evidence.
What cloud security evidence do auditors accept?
A four-part pack: the provider's current compliance report for the infrastructure layer, a responsibility matrix mapping the provider's user entity responsibilities to your owners, configuration baseline and drift evidence for your own settings, and a scoped penetration test with remediation and retest for controls whose effectiveness configuration cannot show. PCI DSS makes the split explicit, putting provider monitoring in Requirements 12.8.4 and 12.8.5 and your testing obligation in Requirement 11.4.
Is a CSPM report the same as a cloud penetration test?
No. A cloud security posture management report enumerates deviations from a baseline such as CIS, answering whether a control is set. A penetration test establishes whether a deviation is reachable, chainable and consequential, answering whether a control holds. Authorization enforcement, privilege escalation through role assumption, and segmentation between environments are the three areas where only an exploitability test produces the answer.
Who is responsible for cloud misconfiguration under shared responsibility?
The customer, in every published model. AWS assigns guest operating system management, installed application software, security group configuration, data and encryption choices, and IAM permissions to the customer. Microsoft marks configurations and settings as a customer responsibility across on-premises, IaaS, PaaS and SaaS. Google states that customers always remain responsible for their access policies and data.
References
AWS Artifact: What is AWS Artifact? (AWS documentation)
Shared responsibility in the cloud (Microsoft Learn)
System and Organization Controls (SOC) 2 Type 2, Azure compliance (Microsoft Learn)
Google Cloud Compliance Reports Manager (Google Cloud)
Google Cloud shared responsibility and shared fate (Google Cloud Architecture Framework)
PCI DSS Requirements and Testing Procedures v4.0.1, June 2024 (PCI SSC), Requirements 11.4.2 to 11.4.7, 12.8.4, 12.8.5, 12.9.2
ISO/IEC 27001:2022 Annex A control titles verified against a published Statement of Applicability: Euronext Clearing ISO 27001 SoA (secondary)
Cloud Controls Matrix (Cloud Security Alliance)
