PCI DSS Compliance Checklist: How to Stay Compliant with the 12 Requirements

For organisations that store, process, or transmit cardholder data, Payment Card Industry Data Security Standard (PCI DSS) compliance is an ongoing operational requirement.

With PCI DSS v4.0 now fully in effect, organisations are expected to demonstrate stronger security controls, continuous monitoring, and documented risk-based decision-making. Falling short can lead to financial penalties, failed assessments, increased breach risk, and, in serious cases, the suspension or revocation of the ability to process payment cards.

PCI DSS v4.0 organises its requirements around six high-level security goals that work together to protect cardholder data:

Building and maintaining secure networks and systems
Protecting account data
Maintaining a vulnerability management program
Implementing strong access control measures
Regularly monitoring and testing networks
Maintaining a comprehensive information security policy

Together, these goals provide a framework for securing payment environments throughout their lifecycle.

Get in touch

Why PCI DSS 4.0 compliance is a business imperative

PCI DSS compliance determines whether your organisation can continue accepting card payments at all.

Non-compliance penalties from card brands and acquiring banks range typically from $5,000 to $100,000 per month, depending on the severity and duration of violations. But the financial exposure from a data breach dwarfs those figures. Forensic investigations, mandatory customer notifications, litigation, and the cost of losing payment processing privileges altogether can run into the tens of millions. And reputational damage doesn’t show up on a balance sheet, but it shows up in customer churn.

What we see too often is organisations treating PCI compliance as a checkbox exercise handled solely by the security team. The problem is that the approach often breaks down quickly. Compliance touches network architecture, application development, HR policies, physical security, and vendor management. It requires executive sponsorship and cross-functional coordination, not just a firewall ruleset.

PCI DSS v4.0 makes this even clearer. The updated standard introduces more flexibility in how you meet requirements, but also raises the bar on accountability. It expects organisations to treat payment security as an ongoing process embedded in daily operations rather than a periodic audit scramble.

The PCI DSS compliance checklist

Use this checklist to understand what each requirement involves, identify common implementation challenges, and prioritise the actions needed to strengthen your payment environment. Keep in mind that PCI DSS compliance requires continuous monitoring, regular testing, and ongoing improvements as your systems and business processes evolve.

GOAL 2: BUILDING AND MAINTAINING A SECURE NETWORK

Requirement 1: Network security controls

Firewalls and routers are the first line of defence for your cardholder data environment (CDE). Requirement 1 mandates that you install and maintain network security controls, and v4.0 broadens the language beyond traditional firewalls to include cloud-native security groups, software-defined networking controls, and similar technologies.

The real work here is network segmentation. Isolating your CDE from the rest of your corporate network reduces scope (fewer systems to secure and audit) and limits blast radius if a breach occurs. Organisations often underestimate the complexity of accurately defining scope. However, if your segmentation is wrong, your entire compliance effort is built on sand.

Action items:

Document all data flows involving cardholder data, including those crossing cloud and hybrid environments.
Define and enforce inbound and outbound traffic rules with explicit deny-all defaults.
Review network security controls at the frequency required by PCI DSS and your documented procedures.
Implement controls between all wireless networks and the CDE, regardless of whether the wireless network is “trusted.”

Requirement 2: Secure configurations

Default credentials on servers, network devices, and applications are one of the most exploited attack vectors in the industry. Requirement 2 requires you to eliminate vendor-supplied defaults and apply hardening standards across all system components.

This goes beyond changing the admin password on a new router. You need documented configuration standards for every type of system component in your environment, based on industry-accepted hardening guides (CIS Benchmarks, DISA STIGs, or vendor recommendations). V4.0 also requires that you manage all changes to these configurations through a formal change control process.

Where teams trip up: container orchestration platforms and cloud services often ship with permissive defaults that get overlooked. If you’re running Kubernetes clusters or serverless functions that touch cardholder data, those need hardening too.

GOAL 2: PROTECTING STORED ACCOUNT DATA

Requirement 3: Protect stored account data

The simplest way to protect stored data is not to store it. If your business process doesn’t require retaining cardholder data after authorisation, don’t do so. Requirement 3 requires a formal data retention and disposal policy that defines what you keep, why, and for how long.

When storage is necessary, the data must be rendered unreadable. Acceptable methods include strong one-way hash functions, truncation (showing only the first six and last four digits), index tokens with securely stored pads, and strong cryptography with associated key management processes.

PCI DSS v4.0 clarifies that full-disk encryption alone may not satisfy Requirement 3 if cardholder data can still be accessed by authenticated users. Organisations must demonstrate that stored account data is rendered unreadable through approved methods.

Key management is where this requirement gets operationally complex. You need documented procedures for key generation, distribution, storage, rotation, and destruction. Split knowledge and dual control of cryptographic keys aren’t optional.

Requirement 4: Protect cardholder data with strong cryptography during transmission

Any time cardholder data traverses an open or public network, it must be encrypted with strong cryptography. TLS 1.2 or later is generally expected, with TLS 1.3 preferred where supported.

This requirement also covers internal network transmissions where there’s a risk of interception. V4.0 makes it explicit: if you can’t prove that your internal network is as secure as a private network, you need to encrypt data in transit there too.

Common gaps we encounter: legacy API integrations that still use outdated protocols, internal services communicating over unencrypted channels because “it’s behind the firewall,” and certificate management processes that allow expired or self-signed certificates in production.

Maintain an inventory of all trusted keys and certificates. Automate certificate lifecycle management where possible. Continuously monitor the use of deprecated protocols.

GOAL 3: MAINTAINING A VULNERABILITY MANAGEMENT PROGRAM

Requirement 5: Protect all systems and networks from malicious software

Deploy anti-malware solutions on all systems commonly affected by malicious software. V4.0 expands this to require periodic evaluation of system components not typically considered at risk to confirm they remain not at risk. You can’t simply declare a Linux server exempt and forget about it.

Anti-malware must be actively running, using current signatures or behaviour-based detection, and generating audit logs. Users must not be able to disable or alter the software unless specifically authorised for a documented reason, and even then, only for a limited time.

V4.0 introduces a new requirement to detect and protect against phishing attacks. This means more than just email filtering. You need mechanisms to identify phishing attempts targeting personnel, including combined training and technical controls.

Requirement 6: Develop and maintain secure systems and applications

This requirement hits engineering teams directly. All system components must be protected from known vulnerabilities through timely installation of security patches. Critical or high-risk security patches should be installed within one month of identification.

For organisations developing custom software (which, in our experience, is nearly every mid-to-large enterprise), Requirement 6 mandates secure development practices: code reviews or automated testing for common vulnerabilities, separation of development and production environments, and training for developers on secure coding techniques.

V4.0 significantly strengthens the requirements around web application security. Public-facing web applications must be protected by a web application firewall (WAF) or undergo automated vulnerability security testing on an ongoing basis. The days of annual manual code reviews as your sole control are over.

At Infinum, we build secure development lifecycle practices into every project from the start, because retrofitting security into an application after it’s built is significantly more expensive than building it in from the start.

GOAL 4: IMPLEMENTING STRONG ACCESS CONTROL MEASURES

Requirement 7: Restrict access by business need to know

The principle of least privilege: grant users access only to the cardholder data and system components they need to perform their job function. Nothing more.

This requires a documented access control model. Role-based access control (RBAC) is the most common approach, but whatever model you use, it must be explicitly defined and enforced. V4.0 requires that access privileges be reviewed at least once every six months.

The hard part isn’t setting up RBAC initially. It’s maintaining it as people change roles, projects shift, and new systems get deployed. Access creep is one of the most persistent compliance risks we see.

Requirement 8: Identify users and authenticate access

Every user must have a unique ID. No shared accounts, no generic admin logins. This enables accountability through audit trails.

Multifactor authentication (MFA) is now required for all access to the CDE, not just remote access. That’s one of the most impactful changes in v4.0. If your administrators have been accessing CDE components with only a password while on the corporate network, that’s no longer compliant.

Password requirements have also been updated: a minimum of 12 characters (up from 7 in v3.2.1), or, if the system can’t support 12, a minimum of 8. Passwords must be changed if there’s suspicion of compromise, and the previous requirement to force changes every 90 days can be replaced with continuous monitoring for compromised credentials using automated tools.

Requirement 9: Restrict physical access to cardholder data

Physical security controls often get less attention in technology-focused organisations, but they’re mandatory. Badge access, visitor logs, camera surveillance in sensitive areas, and secure destruction of physical media containing cardholder data are all required.

For environments with point-of-sale devices, Requirement 9 also mandates maintaining an up-to-date list of devices, regular inspections for tampering or substitution, and training for personnel who interact with those devices.

GOAL 5: REGULARLY MONITORING AND TESTING NETWORK

Requirement 10: Log and monitor all access

You need audit trails that track all user access to cardholder data and all actions by anyone with administrative privileges. Logs must capture user identification, event type, date and time, success or failure, event origin, and the identity or name of the affected data, system component, or resource.

V4.0 introduces requirements for automated mechanisms to perform audit log reviews. Manual log review alone is insufficient. You need tools that can detect anomalies and alert your security team in real time.

Log retention: at least 12 months of history, with the most recent three months immediately available for analysis. Time synchronisation across all systems is also mandatory, using a consistent and authoritative time source.

Requirement 11: Test the security of systems and networks regularly

Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV). Internal vulnerability scans must run at least quarterly or after any significant change.

Penetration testing must be performed at least annually and after significant changes to the environment. V4.0 specifies that the penetration test methodology must cover the entire CDE perimeter and critical systems. Internal penetration testing from within the network is also required.

One area that catches organisations off guard: v4.0 requires implementing a change- and tamper-detection mechanism (such as file integrity monitoring) to alert on unauthorised modifications to critical files. This must trigger alerts, not just passively log changes.

Wireless access points also need detection: you must maintain a process to identify and address both authorised and unauthorised wireless access points on a quarterly basis.

GOAL 6: MAINTAINING AN INFORMATION SECURITY POLICY

Requirement 12: Information security policy

A documented information security policy must exist, be approved by management, be communicated to all relevant personnel, and be reviewed at least annually. This is the organisational glue that holds the other 11 requirements together.

Key components include:

An incident response plan that’s tested at least annually, with defined roles for communication, containment, and recovery.
Security awareness training for all personnel upon hire and at least annually thereafter. V4.0 adds a training requirement that specifically addresses threats such as phishing and social engineering.
Acceptable use policies for end-user technologies.
A formal risk assessment process is performed at least annually and upon significant changes.
Policies governing relationships with third-party service providers, including written agreements acknowledging their responsibility for cardholder data security.

V4.0 also introduces a requirement for a targeted risk analysis. For any requirement in which the organisation has flexibility in defining the frequency of a periodic control (such as log reviews or vulnerability scans), the organisation must document a targeted risk analysis that justifies the chosen frequency.

PCI DSS v4.0 is in effect. If you’re assessing your compliance posture or preparing for an assessment, talk to our team.

Key changes in PCI DSS v4.0 and how to prepare

The shift from v3.2.1 to v4.0 represents the largest update to the standard since its inception. Here are the changes that demand the most attention:

Customized validation

Organisations can now meet the intent of a requirement through an alternative control, validated with a customised approach. This offers flexibility but requires documentation of how the custom control meets the security objective and a targeted risk analysis. Most organisations should start with the defined approach and explore customised validation only where strict compliance with the defined control is genuinely impractical.

MFA everywhere in the CDE

As mentioned, MFA is no longer limited to remote access. All access to the CDE requires it. Plan for the impact of this change on infrastructure and user experience.

Authenticated vulnerability scanning

Internal vulnerability scans must use authenticated scanning (with credentials) to gain a deeper view of system configurations and patch levels.

Anti-phishing controls

Technical mechanisms to detect and protect against phishing attacks are now explicitly required, alongside training.

Password length increases

The minimum jumps from 7 to 12 characters (or 8 if the system can’t support 12).

Targeted risk analyses

Where the standard allows flexibility in the frequency of a control, you must document a risk analysis justifying your chosen approach.

Service provider scope clarifications

The standard provides greater clarity on managing third-party service provider risk, including new requirements that service providers document and confirm their PCI DSS scope at least every six months.

The timeline: as of March 31, 2024, v3.2.1 was retired, and v4.0 became the only active version. All future-dated PCI DSS v4.0 requirements are now mandatory. Organisations that have not implemented them risk non-compliance during assessments.

Your compliance validation journey

How you validate compliance depends primarily on your transaction volume and your acquirer’s requirements.

Self-Assessment Questionnaire (SAQ)

For merchants with lower transaction volumes (typically under 6 million transactions per year for Visa, though thresholds vary by card brand). SAQs come in multiple types (A, A-EP, B, C, D, and others), each tailored to specific payment processing methods. Choosing the wrong SAQ type is a common and costly mistake.

Report on Compliance (ROC)

For Level 1 merchants (generally over 6 million annual transactions) and for any organisation that has experienced a breach. A ROC requires an on-site assessment by a Qualified Security Assessor (QSA).

Qualified Security Assessor (QSA)

A QSA Company is certified by the PCI Security Standards Council to perform PCI DSS assessments using qualified assessors. The assessor validates that your controls meet each requirement, reviews evidence, interviews personnel, and observes processes. Choosing the right QSA matters. You want assessors who understand your technology stack and business model, not just the standard itself.

Compliance costs vary enormously. A straightforward SAQ for a small e-commerce operation might cost tens of thousands of dollars when you factor in remediation. A full ROC for a large enterprise with complex hybrid infrastructure, custom applications, and multiple business units can run well into the six- or seven-figure range. The largest cost driver isn’t the assessment itself; it’s the remediation work to close gaps identified during scoping and pre-assessment.

Budget for ongoing compliance maintenance, not just initial certification. Annual penetration tests, quarterly ASV scans, continuous monitoring tools, staff training, and policy reviews are recurring costs.

Partnering for secure and compliant digital solutions

Achieving PCI DSS compliance while simultaneously driving digital transformation, integrating AI capabilities, and modernising legacy systems requires more than a good security team. It requires technology partners who understand both the compliance framework and the engineering reality of building modern software.

The biggest challenge for many organisations is translating their understanding of PCI DSS requirements into secure architectures, development practices, and operational processes that withstand an assessment.

Through AMR CyberSecurity – Part of Infinum we help organisations bridge that gap. As a PCI DSS Qualified Security Assessor (QSA) Company and digital engineering partner, we support businesses throughout the compliance lifecycle—from defining PCI scope and designing secure architectures to integrating security into the software development lifecycle and preparing for assessments.

Whether you’re implementing PCI DSS v4.0 for the first time or strengthening an existing compliance program, embedding security into your systems early makes future compliance simpler, more cost-effective, and more resilient.

Get in touch