PCI DSS 4.0: the operational work behind the March deadline
On 31 March 2025, thirteen days from now, the requirements in PCI DSS 4.0 that were marked as future-dated become mandatory. Version 3.2.1 was retired a year earlier, on 31 March 2024, so if you are assessed annually your last assessment was probably against 4.0 already, with those items not yet required.
A lot of the preparation we see is aimed at the assessor: policies rewritten and a tool bought. Several of the future-dated requirements describe work that has to happen continuously, done by named people, with evidence that builds up as they do it. That work is harder to buy. Which requirements apply to you depends on how your payment pages are built and what your assessor agrees, and the examples below assume they apply.
The payment page needs an owner
The new requirements on payment pages cover two things: managing and authorizing the scripts that run there, and detecting changes to the page or tampering with it. Tools exist for both. The operational question is who owns the list of scripts.
Payment pages collect scripts from several teams: analytics from product, a tag manager from marketing, a chat widget from support, device fingerprinting from fraud. Each addition is reasonable, and each is now a change to an in-scope page that someone has to authorize. If authorization sits with a security team that hears about new tags after they go live, the inventory will be out of date within a month.
Give the payment page one owner, often the product manager for checkout, with the authority to refuse a script. Put the page into your release process so that adding or changing a script goes through the same approval as a code change. Keep the inventory in the repository alongside the page, where a change to one shows up next to the other. Then ask who would notice today if a script appeared on the page that nobody had authorized. If the answer is a tool, ask who reads what the tool sends and how often. If a PSP migration is on your plan for this year, the payment page and its scripts will change with it, and the inventory has to follow.
Change detection creates a different kind of work, which is alerts. A legitimate release changes the page too, so unless detection and releases are connected, every deployment can look like tampering. Decide who receives an alert, how fast they have to look at it, and what they do if they do not recognize the change. Write that down as a runbook, because the response to a real tampering alert, which may mean pulling the page or switching to a hosted payment page from your PSP, involves people well outside security.
If the only time anyone checks the payment page's script inventory is the week before the assessment, the inventory is wrong for most of the year.
MFA and the accounts nobody lists
MFA is now required for all access into the cardholder data environment. Engineers usually have it already. The gaps tend to be elsewhere: support staff using a back-office tool that sits in scope, vendor accounts used for maintenance, older systems that were never connected to single sign-on, and emergency accounts kept for the day everything else fails.
Each of those gaps is closed by a process someone runs. Joiners need MFA enrolled before they get access, and leavers need it removed on the same day as everything else. Vendor accounts need someone who knows when the vendor is expected to log in and can see when they did. Emergency accounts need a written procedure for using them that still meets the MFA requirement, and a check afterward that the credential was rotated.
Set up that way, the evidence is a by-product: the regular access review, the MFA enrolment report, the vendor access log with a named reviewer. Reconstructing the same evidence for a whole year in the last fortnight of March is miserable work, and it rarely convinces anyone.
Risk analyses that someone rereads
Targeted risk analyses are the least technical of the future-dated items and the easiest to write once and forget. Several requirements now rely on one: a short document explaining why you perform a particular task at the frequency you chose.
The trap is that a frequency justified in early 2025 will be tested later against a business that has changed. Each analysis needs an owner, usually the person who runs the activity it covers, and a list of events that send it back for review, such as a new product, a new PSP, a change to the payment page or an incident. Date each analysis and record who approved it, so the next person to open it can see how old the reasoning is. Keep them short enough that the owner will reread them. A two-page analysis written by the person who does the work is more use than a twelve-page one written by a consultant for the assessor, and we say that as consultants.
With under two weeks to go, one check is worth doing now. For each of these items, write down the person who does the work in an ordinary week and where their evidence is kept. The blank spaces in that list are your work for April.
Discuss your operations
