PCI DSS 4.0 technical controls checklist for engineering teams

PCI DSS 4.0.1 is the current version of the standard, and its 51 future-dated requirements became mandatory on 31 March 2025. For engineers, the work is to shrink the cardholder data environment, then check network, configuration, software, access, logging and testing controls against the twelve principal requirements.

What changed that engineers must know?

The PCI Security Standards Council states that v4.0 had 64 new requirements, 51 of them future dated, and that after 31 March 2025 they are required and must be fully considered in an assessment. Two that hit web teams directly are 6.4.3 and 11.6.1, which concern payment page scripts: scripts must be authorized, checked for integrity and monitored for tampering. The Council also published guidance on preventing e-skimming for these requirements. Requirement 12.3.1, targeted risk analysis, supports 11.6.1. Commentary from assessors also points to MFA for all non console access into the cardholder data environment (8.4.2), an inventory of bespoke and custom software (6.3.2) and authenticated internal scans (11.3.1.2). Check those numbers against the standard text, which you can download from the Council.

How do you reduce scope first?

Every system that stores, processes or transmits account data, or can affect its security, is in scope. Fewer systems means fewer controls to evidence. Use a hosted payment page or an embedded iframe from a compliant provider so card data never touches your servers. Segment the cardholder data environment from everything else, and prove the segmentation with testing. Keep a data flow diagram and a system inventory current.

The checklist, by principal requirement

1. Network security controls: documented rules, default deny, review of rule sets on a schedule, and segmentation between the cardholder environment and the rest.
2. Secure configurations: hardened baselines, no vendor default passwords, one primary function per server where practical, and configuration drift alerts.
3. Protect stored account data: do not store what you do not need, never store sensitive authentication data after authorization, render the primary account number unreadable, and manage keys with documented custody.
4. Protect data in transit: strong cryptography on open public networks, a certificate inventory, and no fallback to weak protocols.
5. Malware protection: anti malware or equivalent controls on applicable systems, kept current.
6. Secure systems and software: software inventory including third party components, a vulnerability intake and patch process with risk ranking, code review or application security testing, change control with separation of environments, and script control on payment pages (6.4.3).
7. Restrict access by need to know: role based access, documented approvals, periodic review of accounts and privileges.
8. Identify and authenticate users: unique IDs, strong authentication, MFA into the cardholder environment, no shared accounts, and controls for service accounts.
9. Restrict physical access: mostly outside engineering, but cover cloud responsibility matrices.
10. Log and monitor: central logs for access to cardholder data and administrative actions, time synchronization, protection from tampering, and a review process that is automated where required.
11. Test regularly: internal and external vulnerability scans, penetration tests, segmentation tests, and change and tamper detection on payment pages (11.6.1).
12. Policies and programs: security policy, risk assessment, targeted risk analyses where the standard allows flexible frequency, awareness training, provider management and an incident response plan.

How should you handle third parties and cloud?

Keep a list of service providers that touch account data or its security, with each one's responsibility matrix and proof of their PCI status. Your cloud provider's compliance does not cover your configuration.

What evidence will assessors ask for?

Diagrams, inventories, configuration exports with dates, scan reports, pen test reports, access review records, change tickets, log samples, training records and risk analyses. Prefer system generated exports with timestamps over screenshots.

What to do

1. Confirm your merchant or service provider level and your assessment route with your acquirer or payment brand.
2. Cut scope with hosted fields or iframes and segmentation.
3. Download PCI DSS v4.0.1 and map each requirement to an owner.
4. Inventory systems, software components and payment page scripts.
5. Put integrity and tamper monitoring on payment pages.
6. Enforce MFA and unique IDs into the cardholder environment.
7. Centralize and protect logs and automate review.
8. Schedule scans, tests and targeted risk analyses.
9. Collect dated evidence monthly.

Quick check

How Safeguard helps automate this

Many of these controls leave technical traces in code and dependencies. 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 between assessments, saving your team time for other work. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which supports the software inventory and vulnerability controls. The agent can open tested fix pull requests for vulnerable dependencies, but it is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare evidence; a Qualified Security Assessor or your acquirer decides compliance. Book a call.

Open the framework mapping demo

Sources

• PCI Security Standards Council, document library
• PCI SSC blog, requirements effective after 31 March 2025

Last reviewed: 18 October 2026.