A processor never holds cardholder data still. Authorization requests leave for the card networks. Settlement files go to acquiring banks. Tokenization services pull and return PANs. Reporting jobs aggregate merchant transaction histories. Fraud-scoring vendors take feature payloads. Reconciliation runs across the whole estate every night. The business stops working the day any of those moves stop. So you grant them, on purpose, and they all run permitted.
That is the problem. Your most valuable data leaves on access you granted on purpose. The controls you bought decide whether each move is allowed. None of them was built to read the pattern across moves, and in payments the pattern is where the breach lives.
The stack already catches the obvious
A processor inside PCI DSS scope already runs the right controls. Tokenization and a vault keep raw PANs in as few places as possible. Segmentation walls off the cardholder data environment. Encryption covers transit and rest. Access management lets only named service accounts reach the CDE. Logging feeds a SIEM. A fraud engine scores the transaction stream. Most add DLP on email and endpoints and a CSPM sweep across the cloud accounts.
This is why raw card data is not sitting in plaintext on someone's laptop. Tokenization shrinks the blast radius. Segmentation keeps the CDE apart. Access management confirms it is the settlement service account, not a stranger, talking to the acquirer. Hilt replaces none of it.
But look at what every one of those controls decides. They rule on the move the instant it is requested. Is this account allowed to read the vault? Is this connection inside the segment? Is this payload encrypted? Answer yes and the move proceeds and the control is satisfied. It did its job. The data leaves.
The move no control on that list will stop
A reconciliation service account reads transaction records every night. It is supposed to. It holds a standing grant to the settlement store, it runs from inside the CDE, its traffic is encrypted, and the file it writes lands in an approved reporting bucket. For three weeks it reads a normal slice. Then, across a handful of off-hours runs, the volume climbs, the time window slides, and the destination quietly widens to a second bucket some integration needed once and nobody ever decommissioned.
Walk the controls. The account was allowed. The segment was correct. The encryption held. DLP saw an approved account on an approved channel and stayed quiet. CSPM saw a bucket with a legitimate history. No policy broke. No alert fired. A meaningful slice of cardholder-adjacent data left through a door the business opened on purpose.
This is the threat a processor is least equipped to catch. Not a misconfiguration. Not a stolen credential setting off a failed-access storm. A legitimate identity moving data in a way that reads wrong only as a pattern. A compromised partner integration looks identical to this, and so does a leaked service-account key, and so does an insider who already holds the grant.
Runtime is the only place the pattern is legible
You cannot see the pattern before the move. Predictive tooling is guessing about access that has not happened, and the access here is one you fully intend to grant. You cannot see it after, either. By the time it surfaces in a forensic timeline or a disclosure letter, the data is gone and the only question left is how to notify the card brands. The pattern is readable in one window: at runtime, while the data is moving.
That window is what runtime Data Movement Governance works in. Predictive tools guess in advance. Forensics arrive too late. Hilt watches the movement itself, as it happens.
Hilt watches data movement at the kernel, metadata only by default, off the path. It never sits inline, never stands between the settlement service and the acquirer, never blocks, drops, or alters traffic. It does not read cardholder data to do its job, which lands harder in payments than almost anywhere, because the last system a processor wants is another one in PCI scope that ingests PANs. Hilt establishes that a movement pattern is wrong without inspecting what moved. Content-aware inspection is there when you want it. It is never the price of admission.
Every move resolves to a probabilistic, source-dependent identity: which account, which job behind it, which destination, and whether this fits what that identity has done across months of history. When the reconciliation account drifts, the deviation shows up across layers at once. The job is unusual for that identity. The read is a larger off-hours slice of high-value paths. The destination volume is unusual despite the approved channel. Any one of those, alone, is noise. Together they form a case, not an alert.
How it sits with PCI and your existing controls
PCI DSS expects you to know where cardholder data flows and to monitor access to it. Most of the program rests on controls that gate access and log it. Runtime Data Movement Governance adds to that. It does not replace your tokenization, your segmentation, your access management, or your SIEM. It answers what those controls were never designed to answer: across every permitted move, which sequence is anomalous, resolved to the job behind it, in time to act.
When Hilt surfaces that case, it can respond with host-level network isolation, quarantining the host from the control plane. Off the path, never by filtering packets inline, so the live authorization and settlement traffic the business runs on is not something it can degrade. The collector is single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and the events never leave your account. For a team already carrying PCI scope, the cleanest control is the one that adds visibility without adding another place card data lives.
Overhead is what lets a latency-conscious processor say yes. The collector runs at roughly 0.1% of one core and 4 to 8 MB of memory per host, because it observes the move instead of standing in its way.
Where the next incident forms
Your stack decides whether each move is allowed, and most of your card data moves on access you allowed on purpose. The danger is not the move that breaks a rule. It is the permitted move whose pattern is wrong, run by a legitimate account on an approved channel, off-hours, to a destination that once had a reason to exist.
Ask your controls one question: what did this service account's data actually do last night, resolved to the job behind it and scored against how it normally moves? If they cannot answer, that is the gap, and it is exactly where the next cardholder-data incident forms.
If you want to watch the collector resolve a move to an identity in your own environment, the next step is a 30-minute call, engineer to engineer, no slideware.