PCI DSS Requirements for AWS: What FinTech Companies Must Know

If you store, process or transmit cardholder data on AWS, the Payment Card Industry Data Security Standard applies to you. This guide covers what PCI DSS means in AWS, where your responsibilities begin, and the key controls to implement. It's a starting point, not a substitute for your Qualified Security Assessor.

Shared responsibility, applied to PCI

AWS is validated as a PCI DSS Level 1 service provider, and you can download its Attestation of Compliance from AWS Artifact. That covers the physical data centres, the hardware and the underlying virtualisation.

It does not cover how you configure the services you use. Security groups, IAM policies, encryption settings, logging and patching of your own instances are your responsibility, and they're what your assessment will focus on.

Start by shrinking your scope

The cheapest PCI control is the one you don't need. Everything that stores, processes or transmits cardholder data, or can affect its security, is in scope.

• Isolate the cardholder data environment (CDE) in dedicated AWS accounts. Account boundaries are the strongest segmentation AWS offers.
• Tokenise early. If a payment provider handles card numbers and you only store tokens, much of your estate can fall out of scope.
• Map data flows. Know every path card data takes, including logs, backups and analytics exports.

Key controls by requirement

PCI DSS v4.0.1 is the current version, and the requirements that were future-dated in v4.0 have been mandatory since 31 March 2025.

Requirement 1: network security controls

Use security groups and network ACLs to restrict traffic into and out of the CDE to what's documented and necessary. Nothing in the CDE should accept traffic from 0.0.0.0/0 unless it's a deliberately public, hardened endpoint.

Requirement 3: protect stored account data

• Encrypt stored card data with AWS KMS, using keys with restricted key policies.
• Never store sensitive authentication data, such as full track data or CVV, after authorisation.
• Mask primary account numbers when displayed.

Requirement 4: encrypt data in transit

Use TLS 1.2 or later for every transmission of card data over open, public networks. Enforce it on load balancers and API Gateway, and disable older protocols.

Requirements 7 and 8: access control and authentication

• Grant least-privilege access through IAM roles, reviewed regularly.
• Require multi-factor authentication for all access into the CDE, not just for administrators. This became mandatory under v4.0.
• Eliminate shared and long-lived credentials.

Requirement 10: logging and monitoring

• Enable CloudTrail across all regions with log file validation.
• Retain audit logs for at least 12 months, with the most recent three months immediately available for analysis.
• Review logs for suspicious activity; services such as GuardDuty help automate this.

Requirement 11: test security regularly

• Run external vulnerability scans at least quarterly through an Approved Scanning Vendor.
• Run internal vulnerability scans and perform penetration testing at least annually and after significant changes.
• Detect unauthorised changes to critical files and configurations.

Make compliance continuous

The hardest part of PCI DSS isn't passing the assessment. It's staying compliant for the eleven months in between, while engineers ship changes every day.

Continuous configuration monitoring closes that gap. Nulink Cloud maps findings in your AWS accounts to PCI DSS controls, so a security group opened to the internet shows up as a failing Requirement 1 control the same day, with the owner attached and the fix explained. When your assessor or a banking partner asks for evidence, you export a report instead of assembling screenshots.