Evidence an auditor can trust
When an auditor asks what happened, "we think" is not an answer. A useful record explains itself and cannot be quietly changed.
PCI DSS 4.0.1 and data in motion
Two PCI DSS requirements are data loss problems in disguise. Both assume you can find card data and control how it moves.
PCI DSS 4.0.1 asks two things that are really data loss problems. Requirement 3.4.2 wants technical controls that stop people copying or relocating card numbers during remote access. Requirement 12.10.7 wants incident response to start when stored card numbers turn up where they should not be. Both assume you can find card data and control how it moves, including outside the systems you built to hold it.
What changed, and when
PCI DSS 4.0 was published in 2022 and included requirements that stayed optional for a while, so organizations had time to prepare. The Council published version 4.0.1 in June 2024 as a limited revision, with no requirements added or removed. The future-dated requirements became mandatory on 31 March 2025, so an assessor now looks for them.
Most programs put their effort into the cardholder data environment, and rightly so. These two requirements look at the edges of that environment, where card data escapes into everyday work.
Requirement 3.4.2: card numbers in remote sessions
The text is short. When remote-access technologies are used, technical controls must prevent copying or relocating primary account numbers, for everyone except people with documented, explicit authorization and a legitimate business need.
Think about what that covers. A support agent on a remote session can see a card number. Without a control, they can copy it to the clipboard, paste it into a local note, or drag a file onto a personal drive. Nobody needs to be malicious. A helpful habit is enough.
A policy document cannot prevent any of this, because the requirement says technical controls. It also asks you to prove the exceptions: who is allowed, why, and where that is written down. So you need something on the endpoint that sees the action, recognizes the data and makes a decision, along with a record of each exception.
Requirement 12.10.7: card numbers in the wrong place
This one starts from an honest assumption: card numbers will turn up where they do not belong. A support ticket holds a pasted card. An export sits in a downloads folder. A spreadsheet from a long-finished project lingers on a file server.
The requirement says incident response procedures must exist for that moment, and must be started when it happens. They include working out what to do with the data, finding out how it got there, and fixing the cause.
Notice what this assumes. You can only respond to what you detect. If nobody is looking outside the cardholder data environment, the procedure will never run, and the data will simply stay there.
What the two have in common
Both requirements need the same three abilities.
Find the data. Scan endpoints and file servers for card numbers, using checksum validation so that a sixteen-digit order reference does not raise an alarm. A pattern alone produces too much noise to act on.
Control the movement. Clipboard, file copy, removable media and uploads all need rules, on the device, at the moment of the action. A remote session is only one of the routes.
Keep the record. Each event needs to show what was detected, who was involved, where it was going and what happened. That record is what turns a control into evidence.
Questions to prepare for your assessor
Before the next assessment, it is worth having answers to a few plain questions.
- Where outside the cardholder data environment does card data actually turn up?
- Which technical control stops copying during remote access, and how do you know it works?
- Who holds an exception, and where is the reason recorded?
- When did you last find stored card data where it should not be, and what happened next?
If the last question has no answer, that is rarely good news. It usually means nobody has looked.
Start with a scan
The quickest first step is a discovery scan across endpoints and file servers. It shows how much card data sits outside the places you expect, and it gives you a real starting list. From there, set rules for the channels that matter most, in monitor mode first, and move to blocking once you trust what you see.
Your assessor wants evidence, not intentions. The same evidence is useful on the day something goes wrong. Read how GuardStance supports PCI DSS.