The DOJ Data Security Program: Engineering Controls for Restricted and Prohibited Data Transactions

The DOJ Data Security Program is written as a national-security rule, but what it actually demands of you is an engineering artefact: proof of where your covered data goes, who can reach it, and where a prohibited transfer would be stopped.

Most commentary on the Data Security Program reads it as an export-control problem for lawyers. It is that, but the compliance position is built in the data platform, not the legal memo. The rule — 28 CFR Part 202, made under Executive Order 14117 of 28 February 2024 and in effect since 8 April 2025 — restricts and in some cases prohibits giving certain foreign parties access to bulk US sensitive personal data. The obligation it creates is not “sign a clause”. It is “know your data flows well enough to demonstrate a prohibited one cannot happen”. That is a data-lineage and access-governance build, and it is the kind of thing you cannot retrofit after an enforcement enquiry lands.

What the rule actually gates

The programme turns on three moving parts, and you need all three modelled in your systems before any control does useful work.

The data. Six categories of covered data, each with its own bulk threshold measured over a rolling twelve months: human genomic data on more than 100 US persons; other human ‘omic data on more than 1,000; biometric identifiers on more than 1,000; precise geolocation on more than 1,000 US devices; personal health data and personal financial data on more than 10,000 US persons each; and covered personal identifiers on more than 100,000. Plus government-related data, which has no threshold at all. The trap here is that the thresholds apply regardless of whether the data is anonymised, pseudonymised, de-identified or encrypted. “We hashed the identifiers” does not take you out of scope.

The parties. Six countries of concern — China (including Hong Kong and Macau), Cuba, Iran, North Korea, Russia and Venezuela — plus “covered persons”, which sweeps in entities majority-owned by those countries, employees and contractors of them, and individuals primarily resident there. This is the part that defeats a naïve IP-geoblock. A covered person can be an employee of your own offshore vendor, sitting on a support desk with a login.

The transaction. Data brokerage and access to bulk human genomic data or biospecimens with a country of concern or covered person are prohibited outright. Vendor, employment and investment agreements that give such parties access are restricted — permitted only if you meet the CISA security requirements incorporated into the rule and the due-diligence, audit and reporting obligations that became operative on 6 October 2025.

The control you cannot fake: lineage

Every downstream control in this rule assumes you can answer a prior question: which datasets are covered, at what volume, and where do they flow? Firms that have never built a data inventory discover that the honest answer is “we are not sure”, and “not sure” is the one position the programme does not tolerate, because the prohibition is strict. You do not get credit for having meant well about a transfer you could not see.

Practically, that means a covered-data register that tags datasets by category and running twelve-month volume, and lineage that follows those datasets through every hop — the analytics warehouse, the replica in another region, the third-party enrichment API, the support tool that caches records, the backup that lands in a shared cloud tenancy. This is the same class of problem as the technology asset inventory and network map that other regimes are now demanding; I have written about why that is fundamentally a data-model problem rather than a documentation exercise. Get the model wrong and every control built on top of it inherits the error.

Access governance, not perimeter

Because a covered person is defined by ownership, residence and employment rather than by network location, the enforceable control lives in identity and access, not at the firewall. The question your system has to answer at the point of access is: is this principal a covered person, is the data they are reaching covered and in bulk, and does a lawful basis exist for this specific access? That is an authorisation decision, evaluated per request, against attributes you hold about both the subject and the data.

The CISA security requirements for restricted transactions make this sharper. They are explicit that encryption on its own does not discharge the obligation — among other conditions, the keys must not be accessible to a covered person or held in a country of concern, or you have simply moved the exposure to the key. The same logic that governs foreign access to models, weights and training data in an AI supply chain applies to covered personal data: the control is who can decrypt and read, not merely who holds ciphertext.

Enforcing the restriction in the pipeline

A policy you can express as code is a policy you can test, version and produce as evidence. The block below is a policy-as-code rule (Rego, for an Open Policy Agent decision point) that denies access when a covered person or country-of-concern principal reaches a bulk covered dataset without a permitted lawful basis. It is deliberately small; the point is that the decision is explicit and auditable, not buried in application logic.

# DOJ Data Security Program: deny covered-data access by restricted parties
# Evaluated per request at the data access layer. British spelling in comments.
package dsp.access

default allow := false

countries_of_concern := {"CN", "HK", "MO", "CU", "IR", "KP", "RU", "VE"}

# A principal is restricted if resident in, or a covered person of, a country of concern.
restricted_principal if input.principal.residence_country in countries_of_concern
restricted_principal if input.principal.covered_person == true

# The dataset is in scope only if tagged covered AND over its bulk threshold.
in_scope if {
    input.dataset.covered == true
    input.dataset.bulk == true
}

# Data brokerage with a restricted party is prohibited outright: never allow.
prohibited if {
    in_scope
    restricted_principal
    input.transaction.type == "data_brokerage"
}

# Restricted transactions (vendor/employment/investment) require a certified
# lawful basis AND satisfied CISA security requirements to proceed.
allow if {
    in_scope
    restricted_principal
    not prohibited
    input.transaction.type in {"vendor", "employment", "investment"}
    input.lawful_basis.certified == true
    input.cisa_requirements.satisfied == true
}

# Anything in scope for a restricted principal without that basis is denied.
allow if {
    in_scope
    not restricted_principal
}

Note what the policy forces you to have: reliable attributes on the principal (residence, covered-person status), reliable tags on the data (covered, bulk), and a certification that the CISA requirements are actually met rather than assumed. If any of those inputs is guessed, the decision is worthless. The engineering work is upstream, in producing trustworthy inputs, not in the rule itself.

What a supervisor will ask to see

The programme carries a ten-year recordkeeping obligation and, for restricted transactions, an annual independent audit covering the preceding twelve months. That reframes the whole exercise as an evidence problem. It is not enough that a prohibited transfer did not occur; you have to be able to show the control that would have stopped it, the log that it evaluated, and the lineage that told you the data was in scope in the first place. Reconstructing that after an enquiry — stitching lineage together from memory and screenshots — is precisely the position the record obligation exists to punish.

This sits alongside the older US cross-border regime rather than replacing it; if you are mapping the full surface you will still be reconciling it against OFAC sanctions and export-control exposure on the same data. But the Data Security Program is the one that turns a compliance question into an architecture question, because its unit of enforcement is the individual access decision.

You cannot block a prohibited transfer you cannot see. Every firm that treats this as paperwork is quietly betting that no one will ever ask it to prove where its covered data went — and the rule is built to make exactly that request.