PCI Compliance for PayPal Merchants: Full SAQ Guide 2026
PCI compliance for PayPal merchants explained: which SAQ you need, when ASV scans apply, and how the 2026 PCI DSS v4.0.1 rules changed eligibility.
PCI compliance AWS questions almost always start in the wrong place: “Is AWS PCI compliant?” AWS has already answered that for its own infrastructure; it holds a PCI DSS Attestation of Compliance as a Level 1 service provider. The question that actually determines whether your business passes an assessment is narrower: which parts of PCI DSS does AWS’s certification cover, and which parts are yours to prove every quarter with an Approved Scanning Vendor?
This is the single most common misunderstanding merchants run into after migrating to AWS: assuming a certified cloud provider transfers its compliance status to whatever gets deployed on top of it. It doesn’t. If your application stores, processes, or transmits cardholder data, you have a cardholder data environment (CDE), and every applicable PCI DSS control still applies to it, regardless of which cloud it runs on.
This guide breaks down the AWS Shared Responsibility Model in PCI DSS terms, what AWS’s own certification actually covers, your EC2 and scanning obligations, and what changed under PCI DSS v4.0.
PCI DSS: Payment Card Industry Data Security Standard: the requirements that any organisation that stores, processes, or transmits cardholder data must meet.
Cardholder Data Environment (CDE): the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus any connected system components.
Approved Scanning Vendor (ASV): a company certified by the PCI Security Standards Council (PCI SSC) to perform the external vulnerability scans PCI DSS Requirement 11.3.2 mandates, at least once every three months.
AWS Shared Responsibility Model: AWS's framework dividing security obligations: AWS is responsible for security of the cloud (physical infrastructure, hypervisor, network), while the customer is responsible for security in the cloud (guest OS, data, access control, application code).
Attestation of Compliance (AoC): the formal document, produced after a QSA audit, confirming an entity meets PCI DSS requirements. AWS's own AoC covers its infrastructure layer and is available to customers through AWS Artefact.
PCI DSS v4.0: the current version of the standard, with a set of "future-dated" requirements (including MFA for all CDE access and updated scanning rules) that became mandatory on March 31, 2025.
AWS holds a PCI DSS Level 1 Service Provider Attestation of Compliance covering its physical data centres, network, and virtualisation layer, not your applications, configurations, or cardholder data.
AWS undergoes annual audits by an independent Qualified Security Assessor and makes the resulting AoC available through AWS Artefact so customers can present it to their own QSA as evidence that the infrastructure layer is covered. It does not validate your operating system configuration, application code, database access controls, key management, or how cardholder data is handled inside your environment.
Think of it like a landlord certifying that a building meets fire code; the tenants still have to maintain fire safety inside their own units. When you scope your own PCI DSS assessment, AWS’s AoC can reduce the testing burden for the infrastructure controls it covers, but your QSA will still test every control on your side of the line, which is most of them.
Tell us your public-facing AWS assets; Elastic IPs, load balancers, CloudFront distributions, and we'll scope a quarterly scan built for your actual footprint.
The AWS shared responsibility model for PCI splits obligations cleanly: AWS secures the hardware, hypervisor, and global network; you secure the guest operating system, application, data, and network configuration you build on top of it.
AWS’s responsibility | Your responsibility |
|---|---|
Physical data centre security | Guest OS patching on EC2 instances |
Hypervisor and host infrastructure | Security group and network ACL configuration |
Global network infrastructure | IAM policies and credential management |
Patching the underlying platform for managed services (RDS, Lambda) | Database schema, encryption settings, and cardholder data handling |
For managed services like RDS, AWS does more of the work: it patches the database engine itself, but you still own the schema, user permissions, encryption configuration, and the data. Misjudging this boundary is the most common cause of PCI scope errors on AWS: either excluding resources that should be in scope or over-scoping and inflating your compliance burden unnecessarily. Segmenting in-scope resources into dedicated VPCs, subnets, and accounts, with tight security group rules, is the most effective way to keep scope and cost under control.
EC2 instances in your CDE carry the heaviest share of your PCI obligations because EC2 is infrastructure-as-a-service; AWS hands you a virtual machine, and everything above the hypervisor is yours to secure.
Because of that, EC2 PCI compliance means every server-level control in PCI DSS applies directly to your instances:
None of these are things AWS manages on your behalf, even though the instance itself runs on AWS’s infrastructure.
No, not for services on AWS's Permitted Services list. AWS removed the mandatory pre-authorisation requirement for most security testing back in 2019, and customers can now scan their own resources without contacting AWS first.
That permitted list covers what most PCI-scoped environments actually run on: EC2 instances, load balancers, RDS, CloudFront, API Gateway, Lambda, and ECS/Fargate. Two exceptions still apply:
Confirm your scope against AWS’s current permitted-services list before every scan cycle; it’s a published list, not a fixed one. This is a distinct question from whether you need external vulnerability scanning at all, you can read more on what counts as external vulnerability scanning versus a penetration test if you’re scoping both for the same environment.
PCI DSS Requirement 11.3.2 requires external vulnerability scans of every internet-facing IP address in your CDE, performed by a PCI SSC-approved ASV, at least once every three months, and AWS hosting doesn't change that obligation; it just changes what you need to hand your ASV to scope it correctly.
AWS does not run these scans for you. The quarterly external scan is entirely a customer obligation, and it has to be performed by a vendor on the PCI SSC’s approved list, not an internal team and not an unapproved scanner. In an AWS environment, your scan targets typically include:
Getting this list right is itself a compliance task; Elastic IPs in particular get missed after instances are re-provisioned, and a public-facing asset left out of scope is a real gap, not a technicality. See the full breakdown of PCI ASV scan requirements and what an ASV scan actually checks for if you’re building your scan inventory from scratch. If your last scan came back with open findings, here’s what to do after a failed ASV scan and how the required re-scan cycle works.
Not sure where the shared responsibility boundary sits for your setup, or which assets belong in scope? Walk through it with a specialist before your next assessment.
Most AWS compliance failures come from scope gaps, not weak security controls. The finding usually isn't a bad configuration; it's a missed asset.
A short pre-scan checklist: current Elastic IPs, load balancer DNS names, active CloudFront distributions, and in-scope API Gateway endpoints catches most of these before your ASV ever runs a scan. If you’re setting this up for the first time, this guide to preparing for a PCI vulnerability scan walks through the inventory step in more detail.
PCI DSS v4.0 tightened two areas that hit AWS environments directly: authentication and scanning cadence, and both became mandatory on March 31, 2025.
MFA for all CDE access (Requirement 8.4.2): Under the previous standard, MFA was only required for administrative or remote access. Under v4.0, MFA is required for all access into the CDE, from any location, for any user. On AWS, this means every account touching in-scope EC2 instances, RDS databases, or management consoles needs MFA enforced through IAM, not just your admins.
Scanning after significant change (Requirement 11.3.2.1): Beyond the standard quarterly ASV scan, v4.0 requires an additional external scan after any significant change to your environment. In AWS, where autoscaling groups, container redeployments, and infrastructure-as-code changes happen constantly, “significant change” needs a defined trigger: a new public-facing load balancer, an opened security group, or a new CloudFront distribution, not just a calendar reminder. This guide to PCI DSS v4.0 ASV scanning changes covers the full requirement set if you’re updating your scan cadence.
Approval by the PCI SSC is the minimum bar, not every ASV is equally equipped to scan cloud infrastructure well, and the difference shows up in how they scope your assets and interpret findings.
When evaluating an ASV for an AWS-hosted CDE, look for:
See how to choose an ASV vendor for a fuller comparison framework, or what’s included in a standard PCI ASV scan if you’re comparing quotes.
PCI compliance on AWS is not a status you inherit from your cloud provider; it’s a program you build and maintain on top of AWS’s infrastructure certification. AWS’s PCI DSS AoC gives you a credible, auditable foundation at the infrastructure layer, but every control touching your EC2 instances, your applications, your access management, and your cardholder data is yours to implement and prove. The AWS Shared Responsibility Model isn’t ambiguous about this, and PCI DSS v4.0 raised the bar further with MFA for all CDE access and tighter scanning triggers.
The quarterly external ASV scan sits at the centre of that ongoing obligation: a regular, independent check that your public-facing AWS assets are free of known vulnerabilities. Scoping it correctly, working with an ASV that understands cloud environments, and remediating findings promptly is one of the most concrete steps you can take to demonstrate real, sustained PCI compliance on AWS.
From single-instance environments to multi-account enterprise setups, compare scan plans sized to your infrastructure.
AWS holds its own PCI DSS Level 1 Service Provider certification for its infrastructure, but that doesn't make your workloads or cardholder data compliant. You're responsible for every configuration, application, and data-handling practice inside your own AWS environment.
No, not for services on AWS's Permitted Services list, which covers EC2, RDS, load balancers, Lambda, and most common infrastructure. Services outside that list, or tests involving command-and-control simulation, still require prior approval.
At least once every three months under PCI DSS Requirement 11.3.2, plus an additional scan after any significant change to your environment under Requirement 11.3.2.1, this applies on AWS exactly as it does anywhere else.
You remediate the flagged vulnerabilities and re-scan until you get a passing result, all within the same reporting window. AWS's own compliance status has no bearing on your scan result; the scan is entirely against your resources.
Scope your CDE accurately, apply required controls to every in-scope resource, enforce MFA for all CDE access, run quarterly external ASV scans against your public-facing assets, and have a QSA validate your overall posture annually.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.