What it actually means to be PCI DSS compliant on AWS
Being PCI DSS compliant means you satisfy all 12 requirements of the current PCI DSS version, evidenced either by a self-assessment questionnaire or a QSA-led audit, depending on your card transaction volume.
The short answer
PCI DSS compliant means an organisation that stores, processes or transmits cardholder data has implemented and can evidence all 12 requirements of the Payment Card Industry Data Security Standard, currently version 4.0.1. There is no partial compliance. You either meet every applicable requirement or you have gaps that a QSA, acquiring bank, or your own risk register will eventually flag.
What confuses most engineering teams I work with is that PCI DSS is not a certificate you buy. It is a validated state. You prove it through one of two routes: a Self-Assessment Questionnaire (SAQ) if your transaction volume is below the thresholds set by the card brands, or a Report on Compliance (RoC) produced by a Qualified Security Assessor if you process higher volumes or a card brand requires it. Both routes assess the same 12 requirements; only the depth of evidence and who signs off differs.
The 12 requirements, briefly
The requirements group into six control objectives: build and maintain a secure network, protect cardholder data, maintain a vulnerability management programme, implement strong access control, regularly monitor and test networks, and maintain an information security policy. In AWS terms, this translates into concrete engineering work: network segmentation with security groups and NACLs, encryption of cardholder data at rest and in transit, IAM least-privilege with MFA everywhere, centralised logging via CloudTrail and GuardDuty, quarterly vulnerability scans by an Approved Scanning Vendor, and an annual penetration test.
None of this is exotic if you have already built a reasonably locked-down AWS environment. Where teams trip up is documentation: PCI DSS 4.0.1 expects you to show evidence of controls operating over time, not just that they exist on the day of the audit. That means log retention, change management records, and access reviews going back months, not a one-off screenshot.
Merchant levels and what they mean for you
Visa and Mastercard classify merchants into four levels based on annual transaction volume, and the level determines your validation path. Level 1 merchants, generally those processing over six million transactions a year, require an annual RoC from a QSA plus quarterly ASV scans. Levels 2 through 4 typically use an SAQ, though acquirers can require a QSA assessment regardless of volume if they consider the risk profile warrants it. Card-not-present ecommerce businesses using a hosted payment page (SAQ A) have a much lighter burden than those handling raw card data on their own servers (SAQ D).
The practical lesson: architect to reduce your PCI scope before you worry about the audit. If you can route all cardholder data through a PCI-compliant processor like Stripe or Adyen and never let raw card numbers touch your infrastructure, you can often qualify for SAQ A instead of SAQ D. That single architectural decision can be the difference between a two-week compliance exercise and a six-month one.
Where AWS fits and where it does not
AWS itself is PCI DSS Level 1 certified as a service provider, and this matters, but it only covers the physical infrastructure and the services AWS operates. Under the shared responsibility model, everything you configure on top, your VPC design, IAM policies, encryption key management, application code, and how you store or pass cardholder data, is entirely your responsibility. I have seen teams assume AWS's certification covers them and then fail an SAQ because their S3 buckets were publicly readable or their RDS instances had unencrypted storage.
AWS Artifact gives you AWS's own PCI DSS Attestation of Compliance and Responsibility Summary, which you hand to your QSA or acquirer as evidence that the underlying platform is covered. You still need to build and evidence everything above that line: segmentation of the cardholder data environment (CDE), key rotation, WAF rules in front of anything handling card data, and log pipelines that prove nobody accessed cardholder data outside authorised paths.
Common architecture patterns that pass audits
The pattern that consistently works: isolate the CDE into its own VPC or a tightly controlled subnet set, with explicit security group rules rather than broad CIDR ranges. Use AWS Key Management Service with customer-managed keys for anything touching card data, and enable key rotation. Route all inbound traffic through a WAF and a load balancer terminating TLS 1.2 or higher. Centralise CloudTrail logs into a dedicated logging account with object lock enabled, so nobody, including admins, can tamper with audit trails. Use AWS Config rules to continuously check for drift against your CDE baseline rather than relying on point-in-time manual reviews.
Tokenisation is the other lever worth understanding properly. If you replace the primary account number with a token immediately on receipt and never store the real PAN anywhere in your systems, large parts of PCI DSS requirements around storage encryption become moot because there is nothing sensitive to encrypt. This is why most modern SaaS platforms integrate a payment processor's tokenisation API rather than building card storage themselves.
| Validation type | Who performs it | Typical trigger | Evidence produced |
|---|---|---|---|
| SAQ A | Self, merchant | Fully outsourced payment page, no card data touches your servers | Signed questionnaire, attestation |
| SAQ D | Self, merchant | You store, process or transmit card data directly | Extensive questionnaire covering all 12 requirements |
| RoC (Report on Compliance) | QSA | Level 1 merchants or acquirer mandate | Full independent audit report plus AOC |
| ASV scan | Approved Scanning Vendor | Any merchant with internet-facing CDE components | Quarterly external vulnerability scan report |
What actually takes the time
The technical controls are rarely the bottleneck. What eats months is scoping the CDE correctly, writing the policies PCI DSS demands (incident response, data retention, access review cadence), and generating twelve months of consistent evidence if your acquirer or QSA wants a full period rather than a point-in-time snapshot. If you are starting from a greenfield AWS environment, building the landing zone with PCI segmentation baked in from day one is far cheaper than retrofitting it into an environment where application teams already have broad access to production.
Related: I help teams scope and build the AWS environments this requires through PCI DSS consulting, often alongside a secure cloud landing zone build, and for teams that need ongoing security leadership through the audit cycle, a fractional CISO engagement.
Common questions
Is AWS PCI DSS compliant by default?
No. AWS the platform is PCI DSS Level 1 certified as a service provider, meaning the underlying infrastructure meets the standard. Everything you configure on top, including IAM, encryption, networking and application code, is your responsibility under the shared responsibility model and is not covered by AWS's certification.
How long does it take to become PCI DSS compliant?
For a well-scoped SAQ A merchant with a mature AWS setup, a few weeks. For SAQ D or a full RoC with a QSA, expect three to six months, largely driven by evidence collection, policy writing, and remediating gaps found during a gap assessment rather than the technical controls themselves.
What is the difference between PCI DSS certified and compliant?
There is technically no such thing as PCI DSS certification for merchants; the correct term is compliant or validated. Only assessors and some service providers get formally certified status. Merchants demonstrate compliance through a signed SAQ or a QSA-issued Report on Compliance and Attestation of Compliance.
Do I need a QSA if I use Stripe or a similar processor?
Often not for the payment flow itself if you use a hosted or redirected checkout, which typically qualifies for the simpler SAQ A. You still need to self-assess against the applicable requirements and a QSA may still be required if your acquirer classifies you as a higher-risk merchant regardless of processor.
What happens if I am not PCI DSS compliant and have a breach?
Card brands can levy fines through your acquiring bank, ranging from thousands to hundreds of thousands of dollars depending on volume and severity, and you may lose the ability to process card payments entirely. Non-compliance also typically voids any liability protections your processor would otherwise extend to you.
Does PCI DSS 4.0.1 change anything for AWS environments?
Yes, it tightens requirements around continuous evidence rather than point-in-time checks, mandates broader use of MFA, and requires more rigorous scoping justification for the cardholder data environment. Teams already using AWS Config, CloudTrail and centralised IAM are well placed to meet the new evidentiary bar.
How this article was made: drafted with AI assistance from my own engagement notes and lab work, then fact-checked and edited by me (Sahil Dubey) before publishing. Corrections: hi@sahildubey.us.