SkypherVisit Website →
← Back to blog

Map PCI DSS v4.x on AWS for Security Teams: Artifacts and Automation

October 8, 2026
Map PCI DSS v4.x on AWS for Security Teams: Artifacts and Automation

AWS holds Level 1 PCI DSS Service Provider status and publishes an Attestation of Compliance and Responsibility Summary through AWS Artifact, but that attestation covers the infrastructure layer only. Your organization still has to isolate its cardholder data environment, configure every service you use correctly, and produce your own evidence before a Qualified Security Assessor will sign off. The first concrete step is pulling the AOC package from AWS Artifact and running a scope confirmation exercise against your actual architecture.

TL;DR:

  • AWS's PCI DSS attestation covers only its physical infrastructure; you must configure, isolate, and document your cardholder data environment yourself.
  • Proper scoping begins with dedicated accounts for CDE workloads, minimizing cross-account access and avoiding legacy connections like long-standing VPC peering.
  • Implementing controls such as MFA, network segmentation, and key management on AWS is crucial for meeting PCI requirements and simplifying assessor reviews.
  • AWS-native tools like Config, Security Hub, and Audit Manager streamline continuous compliance monitoring and evidence collection, reducing manual effort during assessments.
  • Automating recurring checks and early scope validation help prevent scope creep and cut audit preparation time, with tools like Skypher aiding questionnaire responses and evidence sharing.
Skypher
Simplify Security Questionnaire Responses
Skypher helps security and compliance teams automate questionnaire responses, manage evidence, and collaborate across complex enterprise environments.
Visit Skypher

Table of Contents

How AWS supports PCI compliance: artifacts and what they prove

AWS Artifact is the portal where your team retrieves the documentation an assessor will ask for first. It holds the current Attestation of Compliance and Responsibility Summary, and AWS also makes its Report on Compliance available in machine-readable OSCAL format, which helps when you are feeding evidence into automated compliance tooling.

Before you rely on any AWS service for a PCI workload, check the Services in Scope table. AWS updates this list regularly, and a service that looks obviously relevant to payment processing is not automatically covered by the PCI assessment unless it appears there.

What this attestation actually proves:

  • AWS's physical data centers, hypervisor, and managed infrastructure have passed an independent Level 1 PCI assessment.
  • The Responsibility Summary tells you exactly which control objectives AWS has attested to for each in-scope service.
  • Nothing in the AOC validates how you configured security groups, IAM policies, or encryption on top of that infrastructure. That part of the assessment is yours alone.

Shared responsibility and scoping: what you must own

The shared responsibility model splits PCI obligations cleanly once you see it mapped out, as explained in detail by Vadacom's cloud telephony on AWS. AWS handles the physical security of its facilities, the security of the virtualization layer, and patching the infrastructure beneath your instances. You handle everything you configure on top: operating system hardening, network access rules, application code, identity permissions, and encryption key usage.

Reducing audit scope starts with account architecture, not firewall rules. AWS's own segmentation and scoping whitepaper recommends isolating your cardholder data environment in dedicated accounts under AWS Organizations rather than trying to carve out a segment inside a shared account.

A practical sequence for shrinking scope:

  1. Place every workload that stores, processes, or transmits cardholder data into its own AWS account or small set of accounts.
  2. Use Organizational Units to apply guardrails consistently across those CDE accounts and keep non-CDE workloads in separate OUs entirely.
  3. Restrict network paths between CDE and non-CDE accounts to the minimum connections your payment flow actually requires, and document each one.

Pro Tip: Treat every new integration or logging pipeline as a scope question first: if it touches the CDE account, it is in scope until you prove otherwise.

The most common scoping mistake we see is a shared logging or monitoring account that ingests CDE logs alongside everything else, which quietly pulls the whole environment into scope. A second frequent error is leaving a legacy VPC peering connection active long after the workload that needed it has moved.

PCI DSS v4.x changes that matter for cloud deployments

The PCI Security Standards Council published PCI DSS v4.0.1 as a limited revision in mid-2024. It does not add or remove requirements, but it clarifies applicability notes and the timeline for future-dated requirements, several of which become mandatory rather than best practice as their effective dates pass.

For teams running payment pages on AWS-hosted infrastructure, two areas deserve attention now:

  • Requirements covering payment page scripts and tamper detection, which affect how you architect e-commerce front ends even when the payment page itself is outsourced.
  • The future-dated requirements under v4.0.1 that move from "best practice" to mandatory status, which change what your SAQ or ROC will check for at your next assessment cycle.
  • Clarified guidance on how these requirements apply to cloud-hosted and multi-tenant environments, which is directly relevant if your CDE runs on shared AWS infrastructure.

Controls mapping: implementing key PCI controls on AWS

Mapping PCI requirements to AWS configuration choices is where most of the real remediation work happens. A few areas carry disproportionate weight with assessors.

  • Identity: Enforce MFA on every account with CDE access, scope IAM roles tightly to the task they perform, and set session policies that expire credentials quickly rather than relying on long-lived access keys.
  • Segmentation: Build your CDE on a dedicated VPC with security groups and network ACLs that deny by default, and use the multi-account model described above so that a misconfiguration in one account cannot expose another.
  • Encryption: Use AWS KMS for key management on data at rest, consider AWS CloudHSM when your assessor requires dedicated hardware security modules, and evaluate AWS Payment Cryptography for workloads that need PIN processing or card-data tokenization under PCI PIN requirements.
  • Logging and detection: Centralize CloudTrail logs from every CDE account into a dedicated logging account, retain them for the period your QSA expects, and configure alerting on privilege escalation and unusual API activity.

Pro Tip: Keep your CDE logging account separate from your general operations logging account; mixing the two is one of the fastest ways to expand your PCI scope without noticing.

None of this is exotic engineering. It is consistent application of access control, network isolation, and key management, documented well enough that an assessor can trace each control back to a specific configuration.

Automation and AWS-native tools to reduce audit toil

AWS provides several native tools that map directly to PCI control checks, which cuts down the manual evidence gathering that used to consume weeks of an audit cycle.

  • AWS Config conformance packs: AWS publishes sample templates for PCI DSS v4.0, including versions that cover global resource types, which you can deploy to continuously check configuration against defined rules. These are a starting point, not a guarantee: you still need to confirm the rules match what your assessor expects.
  • AWS Security Hub: Its PCI DSS standard runs continuous checks across your accounts and surfaces findings in one dashboard, which helps when you need to show an assessor a running history of control status rather than a point-in-time snapshot.
  • AWS Audit Manager: Paired with the OSCAL-format reports available in AWS Artifact, Audit Manager helps assemble evidence packages automatically instead of your team chasing screenshots across a dozen consoles.

Assessment checklist: evidence, scans, and assessor expectations

Before a QSA engagement or SAQ submission, work through a short list of preparation steps so nothing surfaces as a surprise during the assessment.

  1. Download the current AOC, Responsibility Summary, and OSCAL report package from AWS Artifact.
  2. Schedule Approved Scanning Vendor scans wherever your SAQ type requires external vulnerability scanning, and keep every scan report along with remediation evidence.
  3. Build current network diagrams showing CDE boundaries, and run a formal scope confirmation exercise to catch anything that drifted since the last assessment.
  4. Pull Config snapshots and Security Hub findings history so your QSA has a documented control timeline rather than a single day's view.

Whether you file a Self-Assessment Questionnaire or a full Report on Compliance depends on your transaction volume and acquirer requirements, but the underlying evidence trail looks the same either way.

Skypher's role: automating questionnaires and evidence collection

PCI assessment work overlaps heavily with the security questionnaires your sales and compliance teams answer for customers and partners. We built Skypher's questionnaire automation tool to pull from a centralized knowledge base so your team can answer those recurring PCI-related questions in minutes instead of re-answering the same control descriptions from scratch. Faster questionnaire turnaround and a centralized evidence base reduce the friction that typically slows down both sales cycles and assessor information requests.

Incident response planning and monitoring specific to PCI environments on AWS

An incident response plan for a PCI environment has to account for how AWS and your team split detection and response duties. AWS monitors and responds to incidents affecting the underlying infrastructure, but detecting an incident inside your own CDE, isolating affected resources, and notifying your acquiring bank remain entirely your responsibility.

Build detection around centralized CloudTrail logging, VPC Flow Logs on every CDE subnet, and Security Hub findings tied directly to alerting rather than a dashboard someone checks occasionally. When an alert fires, your runbook should specify exactly which account and resource types are in scope for containment, since CDE accounts isolated under the multi-account model described earlier are far easier to quarantine than a shared account carrying both CDE and non-CDE workloads.

PCI DSS requires a documented incident response plan that your team tests periodically, not just a policy document sitting in a shared drive. On AWS, that testing should include tabletop exercises that walk through revoking IAM credentials, rotating KMS keys, and isolating a compromised instance or account without disrupting payment processing elsewhere in your environment.

PCI incident response sequence on AWS

Retention matters here too. Keep incident-related logs and forensic evidence for the period your QSA and acquirer require, stored separately from your routine operational logs so an assessor can review incident history without wading through unrelated activity. A clear separation between detection, containment, and notification responsibilities, documented in advance, is what turns an incident response plan from a compliance checkbox into something your team can actually execute under pressure.

How to leverage AWS services for continuous PCI compliance monitoring and reporting

Treating PCI compliance as a point-in-time audit event creates unnecessary risk between assessments. AWS gives you the pieces to monitor continuously instead.

Security Hub's PCI DSS standard runs its checks on an ongoing basis, not just when you remember to look, and it can route findings into existing workflows through integrations with ticketing or chat tools your security team already uses. Config conformance packs work the same way: once deployed, they flag configuration drift the moment a resource falls out of compliance with a mapped rule, rather than waiting for a quarterly review to catch it.

For reporting, Audit Manager keeps evidence collection running in the background, assembling records as controls are checked instead of requiring a scramble before each assessment window. Pairing that with the OSCAL-format reports in AWS Artifact gives you a consistent, machine-readable record you can hand to internal stakeholders or external auditors without reformatting anything by hand.

The practical payoff is that your quarterly scan cycle, your Config rule evaluations, and your Security Hub findings history become a running compliance posture rather than three disconnected activities. That matters most when your assessor asks for evidence covering the full assessment period rather than a single snapshot, which is increasingly the expectation under PCI DSS v4.0.1's clarified evidence requirements.

How to leverage AWS services for continuous PCI compliance monitoring and reporting — overview diagram

A pragmatic view on priorities for AWS PCI assessments

Scope reduction comes first. Automate recurring checks with Config and Security Hub before you throw more headcount at manual evidence gathering. Bring your QSA your artifact package and scope assumptions early, not after remediation is already underway.

— Gaspard

Skypher as an adjacent option for questionnaire automation and evidence sharing

Compliance teams preparing for a PCI assessment often lose as much time answering customer security questionnaires as they do gathering assessor evidence. We built Skypher to handle both: our questionnaire automation tool answers recurring PCI and security questions from a shared knowledge base, and our customizable Trust Center gives customers and partners self-service access to the compliance posture you choose to share, cutting down repeat requests for the same documents.

Skypher

If your team spends more time re-answering the same control questions than actually improving controls, visit Skypher to see how questionnaire automation and a Trust Center fit into your existing PCI workflow.

FAQ

What is PCI compliance in AWS?

PCI compliance in AWS means your cardholder data environment meets PCI DSS requirements using AWS infrastructure, where AWS attests to its own infrastructure controls through documents in AWS Artifact while you remain responsible for configuring, segmenting, and evidencing everything you build on top of it.

Is Amazon Pay PCI compliant?

Payment processing services operated by major providers are typically validated under their own PCI assessments, but you should confirm current scope and validation status directly through the provider's own compliance documentation rather than assuming coverage. Check the specific service against AWS's Services in Scope list if it runs on AWS infrastructure.

What are the PCI compliance requirements?

PCI DSS requirements cover areas including network segmentation, access control, encryption of cardholder data, logging and monitoring, vulnerability management, and incident response, all organized under twelve high-level requirements. PCI DSS v4.0.1 clarifies applicability for several of these without adding new requirements.

What is PCI in cloud computing?

PCI in cloud computing refers to applying PCI DSS controls within a shared responsibility model, where the cloud provider attests to infrastructure-level controls and the customer configures, segments, and validates everything running within their own environment. Account isolation and network segmentation are central to keeping cloud-based PCI scope manageable, as described in AWS's segmentation and scoping guidance.

How do I choose between an SAQ and a full ROC?

Your acquiring bank and transaction volume typically determine whether you qualify for a Self-Assessment Questionnaire or need a full Report on Compliance performed by a QSA. Reviewing the SAQ and ROC paths relevant to your payment setup before your assessment cycle helps you prepare the right evidence from the start.

Sources