Most organizations are building a program that prevents the wrong thing. The Data Security Program does not ask whether you stopped the access. It asks whether you can prove, 18 months later, that it was never possible.
The Department of Justice’s (DOJ’s) Bulk Data Security Program establishes restrictions and security requirements for organizations handling certain categories of sensitive U.S. personal and government-related data, with a particular focus on preventing access by countries of concern and covered persons.
Every advisory published on the DOJ Bulk Data Security Program arrives at the same six controls. Restrict access. Segment the environment. Log activity. Control egress. Govern the AI pipeline. Test and evidence. The list is correct. It is also, at this point, wallpaper. If your organization has read one of these pieces, it has read all of them, and the reason is that the list is not where the difficulty lives.
The difficulty lives in a mismatch that almost nobody is naming. Security programs are built to prevent. This regime is built to be reconstructed. Those are not the same engineering problem, and a program optimized for the first will fail the second even when every control worked exactly as designed.
What the Rule Actually Asks of You
Consider what a DOJ inquiry looks like in practice. It does not begin with a breach. It begins with a question about a specific dataset, a specific date range, and a specific set of persons, and it asks whether access was possible. Not whether it occurred. Whether it was possible.
That verb tense is the entire regime. Prevention answers a question about the present: Are the controls on right now? Reconstruction answers a question about a past you can no longer inspect: Were the controls on then, for whom, under what exception, and what is the artifact that proves it? A control that was working perfectly in March and left no durable record of having done so is, in an enforcement posture, indistinguishable from a control that was not there at all.
This is why the six-control list underdelivers. Each item is written as a preventive instruction. Restrict access. Segment data. Deploy DLP. Read them again as evidentiary instructions and they change shape entirely. The question is not whether you restricted access, it is whether the entitlement history is reconstructible for a date 18 months gone, across a system that has since been migrated, by a person who has since left, under an approval workflow that has since been replaced.
Many organizations would struggle to do this. Not because their controls are weak, but because they were never required to build with retrospection in mind.
Three Failures That Pass Every Audit
The gap shows up in specific, recurring places. None of them is a control deficiency. All of them are evidentiary deficiencies, which is why they survive internal audit.
The first is the entitlement snapshot problem. Identity systems are built to answer what access looks like now. Ask most IAM estates to produce the full entitlement picture for a covered dataset as of a Tuesday last year, including inherited group memberships and nested roles, and you get an approximation assembled by hand. That approximation is what you would be offering a regulator as proof. It is not proof. It is a reconstruction of a reconstruction, and it will not hold.
The second is the vendor inference problem. The rule cares about access, including indirect and constructive access. Your contracts say the vendor cannot reach the data. Your architecture may quietly say otherwise, through a support tunnel, a shared administrative plane, a managed service with break-glass credentials, or an offshore subprocessor two tiers down the chain. Contractual assurance and technical reality diverge silently, and the divergence is only discoverable if someone is actively looking for it rather than filing the attestation.
The third is the model residue problem, and it is the one that ages worst. Once covered data has passed through a training run, a fine-tune, an embedding store, or a retrieval index, the question of who can access it stops having a clean answer. The data is not in the model in the way it is in a database, but it is not absent either. You cannot easily prove non-access to something you cannot easily locate. Organizations are creating this exposure right now, at speed, in the name of productivity, and they are creating it in environments that were never instrumented to answer questions about provenance.
Every one of these would clear a well-run controls review. Every one is a landmine under a reconstruction request.
The Shift This Implies
If the regime is evidentiary, the operating model has to change in ways that are not intuitive to a security organization.
Evidence has to be generated at the time of the event, not assembled at the time of the inquiry. Anything reconstructed after the fact carries the taint of having been reconstructed after the fact. The provenance of your evidence is itself evidence.
Retention has to be designed against the enforcement horizon rather than the operational one. Log retention set at 90 days because that is what the SIEM budget allowed is a policy decision that quietly determines whether you can defend anything at all.
And the standard is adversarial, not procedural. Internal audit asks whether you followed the process. A regulator asks whether the conclusion survives someone actively trying to break it. Those are different tests, and passing the first tells you very little about the second. Anyone who has sat on the other side of an investigation knows the difference between documentation that exists and documentation that holds.
Why This Reframing Matters Commercially
There is a version of this rule that gets treated as a compliance exercise, absorbed into the cyber roadmap, and closed out with a controls matrix and a board slide. That approach may appear diligent and complete, but it is unlikely to withstand the scrutiny and demands of a real inquiry.
There is another version that treats the deliverable as a defensible record, rather than a hardened perimeter, and builds the program backward from the question a regulator will ask rather than forward from the threat model a security team already had. That version costs more, and it is the one that works, because it is the only one built for the test that will actually be administered.
The distinction is not academic. It determines whether the money you are about to spend buys you protection or buys you the appearance of protection. Those look identical on a slide and diverge sharply under scrutiny.
The Test
Strip away the frameworks and the control taxonomies and the maturity models. Three questions determine whether a program is real.
- What data is regulated?
- Who can access it today?
- Can we prove those controls would withstand regulatory scrutiny tomorrow?
Most organizations can answer the first. Many can approximate the second. The third is where programs come apart, and it is the only one the DOJ is ultimately asking.
The answer to the third question is not a control. It is a record. Building the record is a different discipline from building the control, and it requires people who have spent their careers on the wrong end of a document request, watching what happens when a well-intentioned organization discovers that its evidence does not hold. That is the work. Everything else is wallpaper.
Ankura advises organizations on data governance, regulatory compliance, cyber controls, third party risk, AI governance, and forensic readiness as a single operating model rather than as functional silos.
© Copyright 2026. The views expressed herein are those of the author(s) and not necessarily the views of Ankura Consulting Group, LLC, its management, its subsidiaries, its affiliates, or its other professionals. Ankura is not a law firm and cannot provide legal advice.
