An assessor points at requirement 1.2.4 and asks you to prove the data-flow diagram is current. You hand over a drawing. They ask how you know it still matches what the environment did this year. The honest answer, for most cardholder data environments, is that you do not.
That is the gap PCI DSS 4.0 keeps pressing on. The diagram states intent. The assessment now turns on behavior. Since 4.0 fully replaced 3.2.1 in March 2025, the distance between the two has become the thing you have to close.
The bar 4.0 quietly raised
Multi-factor everywhere and the targeted risk analysis model get the headlines. The harder change is the one that asks you to know, and show, where cardholder data actually moves.
Three requirements describe one capability. Requirement 1.2.4 wants an accurate, current data-flow diagram covering all account data flows across systems and networks. Requirement 12.5.2 wants the scope of the cardholder data environment confirmed annually and on significant change, which means proving what touches cardholder data. Requirement 10 wants logging and monitoring that reconstructs events. Together they ask for a current, evidenced account of how cardholder data moves, kept honest by observation rather than by memory. Most environments do not have it.
The diagram is correct on the day it is signed
Someone interviews the teams, reads the runbooks, traces the integrations, and draws the boxes and arrows. The drawing is accurate the day it ships. Then the environment moves.
A new analytics job starts reading from the tokenization service. A vendor integration gets a broader scope than its ticket described. An engineer clones a table to chase a production incident at 2 a.m. and never tears it down. A SaaS connector approved for masked data starts pulling the unmasked field because a default changed upstream.
No rule was broken. Every one of those moves ran on access someone granted on purpose. The diagram still shows the old, clean topology. The assessor is reading a picture of an environment that stopped existing months ago, and the burden is on you to prove the picture is still true. Accuracy is a claim about behavior. A static document cannot attest to behavior.
Scope grows through the channels you allowed
The systems you know are in scope are the easy part. The trouble is the systems that drift into scope because cardholder data started flowing somewhere new through a channel that was always open.
Scope creep does not announce itself. The access already existed. The card data simply reached a place the diagram does not show, and that place is now in scope whether or not anyone updated the document. Find the flow before the assessor does and you have a remediation task. Find it after a disclosure and you have a breach notification.
Each move is permitted, so each tool you own correctly lets it through. The danger is not any single move. It is the pattern across them. The pattern is the breach.
Intent ages, forensics arrive late
You can try to know where cardholder data goes before it moves, from the diagram and the policy. That is intent, and intent goes stale the hour the environment changes. You can try to know after it moves, from the forensic reconstruction that follows an incident. That is the disclosure letter, written once the data is already gone.
The third option is to know while it moves. Watch the movement itself, at runtime, and you get current, falsifiable evidence: where account data actually went, as it went there.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read cardholder data to see that cardholder data moved. Each move resolves to a probabilistic, source-dependent identity: which workload, which job, which destination, and whether this fits what that identity normally does. The output is not a louder log. It is a current map of how cardholder data flows, built from what happened instead of from who remembered what.
The analytics job hits the tokenization service, the move surfaces. The 2 a.m. table clone gets read from, the move surfaces, scored against how that data normally moves. The SaaS connector pulls the unmasked field, the move surfaces, resolved to the job behind it. Diagram and behavior stop being two stories you reconcile by hand.
What the assessor can check instead of trust
For 1.2.4, you stop defending a hand-drawn document. You set it against an observed account of where cardholder data actually moved across the assessment window. The diagram becomes a hypothesis the evidence confirms or breaks, not a claim taken on faith.
For 12.5.2, scope is confirmed by movement. A system is in scope when cardholder data moves to it, and runtime evidence names which systems those are, including the ones that drifted in since the last review. The annual confirmation turns from a re-interview into a comparison against what was observed.
For requirement 10, the case for an anomalous flow comes from the movement: the identity, the job, the destination, and why this pattern reads as unusual against months of normal behavior. It is a case, not an alert. An assessor and an incident responder can both work from it.
Hilt responds with host-level network isolation, quarantine, from the control plane. It never sits inline. It never blocks, drops, or alters cardholder data traffic. For latency-sensitive payment infrastructure the cost is effectively zero, on the order of 0.1% of one core and 4 to 8 MB of memory per host, because the collector watches the move rather than standing in its way. Events stay single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and never leave your account. A cardholder data environment needs exactly that residency posture.
What it is not
This is not a tokenization service, a segmentation control, or a QSA. It does not replace the firewalls in requirement 1, the encryption in requirement 3, or the access controls in requirement 7. Those controls do their jobs, and an assessment still rests on them.
It adds the one layer they were never built to produce: continuous, behavioral evidence that the flows match what you claim. The segmentation control enforces the boundary. It cannot, on its own, prove cardholder data respected that boundary every day for a year. That proof comes from watching the movement.
PCI DSS 4.0 did not invent the requirement to know where cardholder data goes. It raised the bar on proving it. The environment changes faster than the document, the flows that grow your scope were permitted all along, and the only place to produce current, falsifiable evidence is at runtime, on the movement itself.
If your answer to "show me every place cardholder data moved this assessment window, resolved to the job behind it and scored against normal" is a diagram and a promise, that is the gap 4.0 will press on.
If you want to see what runtime data movement evidence looks like against your own cardholder data environment, we are glad to walk an engineer through it in about thirty minutes, kernel to case.