How to implement PCI DSS 4.0 yourself: a step by step plan

The cheapest PCI DSS 4.0 program starts by shrinking where card data goes, then confirming with your acquirer or payment brand how you must validate, then closing gaps against the twelve requirements and keeping evidence. Most small merchants can do this themselves with a self-assessment questionnaire. Larger service providers usually need a qualified assessor.

What is PCI DSS 4.0, and which version applies?

PCI DSS is the PCI Security Standards Council's baseline of technical and operational requirements to protect payment account data. The Council's resource hub lists version 4.0 and the limited revision 4.0.1, with companion documents: summary of changes, quick reference guide, prioritized approach, self-assessment questionnaires (SAQs), Report on Compliance (ROC) template and Attestations of Compliance. In a Q&A on its blog, the Council notes that version 3.2.1 was retired on 31 March 2024, that 4.0.1 was released in June 2024, and that of 64 new requirements, 51 were future-dated to 31 March 2025. That date has passed, so all of them now apply.

What are the nine steps?

Step 1: Find out how you must validate. The Council sets the standard, but your acquirer or the card brands set who validates and how. Ask which SAQ or report applies and whether you are a merchant or service provider level. Do this first, because it changes the workload.

Step 2: Reduce scope. The less card data you touch, the fewer requirements apply. Use a hosted payment page or redirect from a compliant provider so card numbers never touch your servers. Stop storing sensitive authentication data. Kill spreadsheets and support tickets containing card numbers. The Council publishes scoping and segmentation guidance for modern architectures, which is worth reading.

Step 3: Map your cardholder data environment. Draw where account data is stored, processed or transmitted, and which systems connect to those. Requirement 12.5.2 asks you to confirm your scope at least annually, so make the diagram a living document.

Step 4: Choose the SAQ or ROC path. Match your payment flow to the SAQ types in the Council's instructions, or plan for a ROC with a qualified assessor if you must.

Step 5: Run a gap assessment against the twelve requirements. Score each as met, not met or not applicable, with evidence.

Step 6: Fix the gaps in priority order. The Prioritized Approach document orders requirements by milestone. Start with the controls that protect data and shrink exposure.

Step 7: Write the policies and assign responsibility. Many version 4.0 requirements focus on documented roles and responsibilities for each activity. Name an owner per requirement.

Step 8: Validate. Complete the SAQ or ROC, run required external scans through an Approved Scanning Vendor if your SAQ calls for them (SAQ A merchants now perform quarterly ASV scans under 11.3.2, per the Council's Q&A), and sign the Attestation of Compliance.

Step 9: Stay compliant. Calendar the recurring tasks: scans, log reviews, access reviews, training, annual scope confirmation and annual policy review.

What do the twelve requirements ask, in plain terms?

1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
3. Protect stored account data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect systems and networks from malicious software.
6. Develop and maintain secure systems and software.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access.
9. Restrict physical access to cardholder data.
10. Log and monitor all access.
11. Test security of systems and networks regularly.
12. Support information security with organizational policies and programs.

What evidence do you keep?

• The scope diagram and data flow with review dates.
• Firewall and network rule reviews.
• Configuration baselines and exceptions.
• Inventory of systems and software.
• Vulnerability scan reports, ASV passes, penetration test reports.
• Change records for in scope systems.
• Access lists and reviews, authentication settings.
• Log review records.
• Training records and signed policy acknowledgments.
• The completed SAQ or ROC and Attestation of Compliance.

Which mistakes recur?

• Starting to implement before scope reduction, so you build controls for systems you could have removed.
• Assuming a payment provider handles everything. Your page that embeds or redirects can still be in scope for some requirements.
• Treating future-dated requirements as optional. They now apply.
• Policies that nobody follows.
• No owner per requirement.

What to do

1. Ask your acquirer how you validate.
2. Shrink scope with hosted payment methods and data cleanup.
3. Draw and approve the cardholder data environment diagram.
4. Download the right SAQ, prioritized approach and summary of changes.
5. Complete the gap assessment and fix in priority order.
6. Assign owners and write the policies.
7. Schedule scans and the recurring tasks.
8. Sign and submit the attestation as your acquirer directs.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between assessments, which frees time for other work. For requirement 6 on secure software, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. Your acquirer, card brands or a qualified assessor decide validation outcomes. Book a call.

Sources

• PCI DSS v4.x Resource Hub, PCI SSC
• Now is the time to adopt the future-dated requirements of PCI DSS v4.x, PCI SSC blog

The standard itself is in the PCI SSC document library, which I could not fetch. Requirement titles above are summarised from general knowledge of the standard, so check them against the current document.

Last reviewed: 18 October 2026.