Twelve years after AWS first published its PCI Responsibility Summary, Qualified Security Assessors are still arguing about who owns what. A January 2026 post on the PCI Guru blog opens with an Internal Security Assessor asking a question that shouldn’t exist this late in the cloud era: how do you define “web server” under PCI DSS when the workload runs in containers orchestrated by Fargate, fronted by an Application Load Balancer, with no operating system the assessed entity can log into. The standard offers no definition. The Council’s Cloud Computing Guidelines date to 2018. And the PCI DSS v4.0.1 specification — mandatory since 31 March 2025 — leaves the hardest cloud questions to assessor judgment.
The result, in 2026, is that two competent QSAs reading the same AWS architecture diagram routinely produce different scopes, different in-scope service lists, and different control inheritance assumptions. The shared responsibility model is not new. The friction is not about the model itself. It’s about how PCI DSS requirements written for racks and hypervisors map onto abstracted, serverless, and managed services that don’t expose the surfaces the standard was written to inspect.
What the AWS Shared Responsibility Model Actually Says for PCI
AWS is a PCI DSS Level 1 Service Provider, assessed annually by Coalfire Systems. The Fall 2025 compliance package, published in January 2026, includes the AWS Attestation of Compliance, the AWS Responsibility Summary, and — uniquely among hyperscalers — a machine-readable version of the report in NIST OSCAL format available through AWS Artifact. AWS’s stated position is unambiguous: AWS secures the cloud (hypervisor, host OS, physical layer, network fabric); the customer secures everything in the cloud (guest OS, application code, IAM configuration, data, encryption keys they control).
For the portion of the cardholder data environment deployed on AWS, a customer’s QSA may rely on the AWS AOC without re-testing the data center physical controls or the underlying virtualization stack. That part is settled. AWS is also explicit that it is not considered a “Shared Hosting Provider” under PCI DSS, so requirement A1.4 does not apply to AWS itself.
What’s not settled is the long middle ground between “obviously AWS’s job” and “obviously the customer’s job.” That middle is where 2026 assessments stall.
Where the Confusion Concentrates
The 2018 Cloud Computing Guidelines list responsibility ambiguity, scope drift, and inherited-control documentation as the top assessment challenges. Eight years later the same three categories dominate QSA disagreements — but the specific services driving them have changed.
The Abstracted Services Problem
The clearest single source of friction is the assessment of services where AWS controls everything below the application logic. AWS Lambda, AWS Fargate, API Gateway, SQS, and the broader category AWS internally calls “abstracted services” expose no host operating system to the customer. There is nothing to patch, no antivirus to install, no SSH session to inspect.
PCI DSS 4.0.1 still contains requirements written for systems where those surfaces exist. Requirement 5.2 expects malware controls. Requirement 6.3.3 expects patch evidence. Requirement 10 expects audit logs of administrative access at the OS layer. AWS’s position, codified in the AWS PCI DSS v4.0 Compliance Guide and the per-service Responsibility Summary, is that for Fargate the customer inherits OS patching and host-level malware controls — AWS performs them, and the AOC covers them. For Lambda, the customer is responsible for the function code itself, the IAM execution role, and any code-change detection above what AWS already does internally.
Two QSAs can read the same documentation and reach different conclusions about whether the customer must produce additional evidence. One treats Fargate inheritance as complete and signs off on the AOC reference. The other asks for a customer-managed change-detection mechanism on the container image, citing the principle that the customer is accountable for what’s deployed even when AWS runs it. Both positions are defensible. Neither is wrong on the face of the standard. That is the problem.
Scope Reduction Has Become the Real Strategy
The pragmatic response — and the one most experienced cloud QSAs now push their clients toward — is aggressive scope reduction rather than control negotiation. The reasoning is straightforward: it is faster and cheaper to remove a service from CDE scope than to argue with a QSA about which controls apply to it.
Scope-reduction tactics that hold up well in 2026 assessments include isolating the CDE in dedicated AWS accounts under AWS Organizations with service control policies preventing cross-account data flow, using tokenization at the edge so that downstream services never see a primary account number, deploying validated point-to-point encryption (P2PE) to remove network segments from PCI applicability entirely, and replacing infrastructure services (EC2, ECS on EC2, EKS on EC2) with abstracted equivalents (Lambda, Fargate, SQS) inside a tightly scoped account.
A widely cited mini case study from a 2025 cloud-PCI guide describes a Level 1 merchant migrating from monolithic EC2 to Lambda plus a tokenized payment gateway and reducing customer-managed Requirement 11 controls by over 30%, with audit prep time down nearly 40%. The number is illustrative rather than universal, but the pattern holds across organizations: shrinking the customer-controlled surface produces better assessment outcomes than trying to win interpretive arguments.
The 4.0.1 Clarifications That Actually Helped — and the One That Didn’t
PCI DSS v4.0.1, published in June 2024 and the only active version since 31 December 2024, is not a content revision. The Council described it as a limited revision focused on errata, applicability notes, and clarifications. For cloud assessments, three changes mattered.
The reversion of Requirement 6.3.3 to v3.2.1 language — patches required within 30 days only for critical vulnerabilities, not critical-and-high — eased one of the most common cloud audit findings. The applicability note added to Requirement 8.4.2 clarified that phishing-resistant authentication factors can satisfy MFA into the CDE, with a May 2025 PCI SSC FAQ confirming that synced FIDO2 passkeys can serve as the single factor under that requirement. And the clarification of Requirement 6.4.3 — managing and authorizing payment-page scripts — finally pinned down which party is responsible when a merchant embeds a third-party payment iframe.
The change that didn’t land cleanly was anything affecting the customized approach. Requirement-by-requirement customized approach objectives are technically available for cloud-specific controls, but the consensus among practicing QSAs — captured bluntly on the PCI Guru blog — is that the documentation and testing burden almost never produces a positive return. The defined approach plus compensating controls remains the dominant path in cloud assessments, and the customized approach remains theoretical for most engagements.
A QSA’s Working Map of AWS Service Categories Under PCI DSS
This map is descriptive, not prescriptive. A QSA may push services up a tier — for example, treating an S3 bucket holding payment-page JavaScript as more than abstracted because the script executes in the customer’s browser, pulling Requirement 6.4.3 into play. The map’s value is in framing the conversation, not closing it.
What Customers Get Wrong
The most common customer-side error in 2026 PCI cloud assessments is not a configuration mistake. It’s the inheritance fallacy: treating “AWS is PCI DSS Level 1 compliant” as equivalent to “my workload running on AWS is PCI DSS compliant.” It is not. AWS’s compliance establishes that AWS-controlled components meet the standard. Whether the customer’s workload meets the standard depends entirely on how the customer configured, segmented, and operated it.
A public S3 bucket holding cardholder data is not an AWS failure. It is a customer failure inside an environment AWS validated as configurable to be compliant. The 2025 IBM Cost of a Data Breach Report puts the average U.S. breach cost at $10.22 million, and breach analyses for cloud incidents continue to point at customer-side misconfiguration — exposed storage, overly permissive IAM, unrotated keys, missing encryption — rather than provider compromise.
The second common error is failing to retrieve the AWS Responsibility Summary from AWS Artifact and walk through it line by line before the assessment. The Summary specifies, per AWS service, which PCI DSS requirements AWS satisfies, which the customer satisfies, and which are shared. Customers who arrive at an assessment without that document mapped to their environment lose days reconstructing what should have been a pre-engagement deliverable.
Frequently Asked Questions
Does AWS being PCI DSS Level 1 mean my application is PCI compliant? No. AWS’s certification covers the AWS-managed components of services in scope. The customer’s application, data handling, IAM, encryption configuration, and operational practices are assessed separately against the customer’s own ROC or SAQ. AWS provides inheritable controls; it does not provide inheritable compliance.
Can my QSA rely on the AWS AOC without testing AWS data centers? Yes. AWS confirms in its PCI FAQs that QSAs do not need to inspect AWS data centers; the AOC is sufficient evidence for physical and infrastructure controls. The QSA still has to assess everything the customer controls, and the inheritance is bounded by the AWS Responsibility Summary.
Is the customized approach worth pursuing for cloud-specific controls? For most organizations, no. The defined approach plus targeted compensating controls produces better assessment economics. The customized approach requires extensive documentation of the security objective, the control design, and ongoing testing — investment that rarely pays back unless the organization has a specific, defensible technical reason no defined-approach control fits.
What changed for payment-page script monitoring under 4.0.1? The clarifications to Requirements 6.4.3 and 11.6.1 made it clearer who is responsible when payment pages are partially or fully outsourced. The merchant retains responsibility for monitoring and authorizing scripts loaded into the consumer browser even when the payment form itself is hosted by a third party. SAQ A merchants now also have to demonstrate quarterly ASV scans where their architecture would previously have made them ineligible for the simpler questionnaire.
Where This Goes Next
The Council has signaled — through speakers at recent community meetings and through the cadence of FAQ clarifications — that a cloud-specific update to the Cloud Computing Guidelines is overdue. The 2018 document predates Fargate’s general availability, predates the modern Lambda execution model, and does not address the IAM-as-segmentation-boundary pattern that now dominates new AWS architectures. Whether that update arrives as a v4 supplement, a guidance refresh, or as part of a future PCI DSS v5 is unclear.
In the meantime, the QSAs who handle cloud assessments well are the ones who treat AWS as a service provider whose AOC is one input among many, who push customers toward scope reduction rather than control negotiation, and who write findings against the customer’s actual configuration rather than against a generic interpretation of the standard. The customers who pass cleanly are the ones who pulled the AWS Responsibility Summary on day one of the engagement and built their evidence package against it. The shared responsibility model is not the source of confusion. The source is treating it as a slogan instead of a document.
