The Department of Justice has stepped into a new role that sounds less like courtroom drama and more like cybersecurity border patrol: enforcing rules on who can access Americans’ bulk sensitive personal data. In plain English, the DOJ’s Data Security Program is designed to stop certain foreign adversaries and people under their control from buying, licensing, receiving, or otherwise accessing large volumes of sensitive U.S. data through ordinary-looking commercial deals.

That may sound like something only defense contractors or mysterious three-letter agencies need to worry about. Not quite. The rule can affect healthcare companies, app developers, data brokers, universities, cloud vendors, financial services firms, ad-tech platforms, HR departments, research teams, and global businesses with employees or vendors in countries the U.S. government considers high-risk. In other words, if your company collects data and says, “We’re probably too small for this,” that is exactly the sentence compliance lawyers hear in their nightmares.

The DOJ’s bulk sensitive data rule grew out of Executive Order 14117, which directed the Attorney General to create restrictions around certain data transactions involving U.S. government-related data or bulk U.S. sensitive personal data. The final rule, now codified at 28 CFR Part 202, creates a national security framework for data access. It treats sensitive data not merely as a privacy issue, but as a strategic resource that can be exploited for espionage, surveillance, coercion, blackmail, cyber operations, artificial intelligence training, and influence campaigns.

What Is the DOJ Bulk Sensitive Data Rule?

The rule is formally part of the DOJ’s Data Security Program. Its core purpose is to prohibit or restrict certain transactions that give countries of concern or covered persons access to bulk U.S. sensitive personal data or U.S. government-related data. The countries of concern currently include China, including Hong Kong and Macau, Cuba, Iran, North Korea, Russia, and Venezuela.

The rule does not simply ban “selling data to bad guys.” That would be too easy, and regulators apparently prefer puzzles with footnotes. Instead, the framework focuses on categories of covered data transactions. A transaction may be covered when it gives a country of concern or covered person access to regulated data and involves data brokerage, a vendor agreement, an employment agreement, or an investment agreement.

This matters because access can happen in many ways. A company may not be “sending a spreadsheet” overseas, but a vendor might have system credentials. A contractor may be able to query a database. A foreign affiliate may receive administrator access. A software development kit may route identifiers or location signals to a third party. Under the rule, access includes logical or physical access, such as the ability to obtain, read, copy, decrypt, edit, divert, release, view, or receive data through systems, networks, software, cloud platforms, or other technology.

Why the DOJ Is Treating Data Like a National Security Asset

The rule reflects a major shift in how the U.S. government views personal data. For years, privacy laws focused mainly on consumer rights, notice, consent, breach response, and whether someone clicked “accept” faster than a caffeinated squirrel. The DOJ’s rule approaches the same data from a national security angle.

Bulk sensitive personal data can reveal patterns that are invisible at the individual record level. Geolocation data can show where people live, work, worship, receive medical care, or travel. Health data can expose vulnerabilities. Financial data can reveal pressure points. Genomic and biometric data can be permanent identifiers. When combined with artificial intelligence, analytics, and other advanced tools, these datasets can help foreign adversaries identify targets, map sensitive facilities, profile government employees, or refine cyber and influence operations.

The DOJ has described the program as functioning much like export controls for data. Instead of regulating the export of chips, aircraft components, or defense articles, the program regulates certain transfers or access rights involving sensitive information. The basic idea is simple: if data can be weaponized, then its movement cannot be treated like ordinary digital exhaust.

What Counts as Bulk Sensitive Personal Data?

The word “bulk” does not mean “every American in one giant database.” The thresholds are much lower than many businesses expect. The rule sets numerical thresholds based on data type, measured over the preceding 12 months and aggregated across certain transactions involving the same U.S. person and the same foreign person or covered person.

Key data categories covered by the rule

Covered sensitive personal data includes human ‘omic data, biometric identifiers, precise geolocation data, personal health data, personal financial data, covered personal identifiers, and combinations of these categories. The thresholds vary. For example, human genomic data becomes bulk at more than 100 U.S. persons, while broader human ‘omic data and biometric identifiers become bulk at more than 1,000 U.S. persons. Precise geolocation data becomes bulk at more than 1,000 U.S. devices. Personal health data and personal financial data become bulk at more than 10,000 U.S. persons. Covered personal identifiers reach the bulk threshold at more than 100,000 U.S. persons.

One important twist: data can still count even if it is anonymized, pseudonymized, de-identified, or encrypted. That is a big deal. Many companies have long assumed that “de-identified” means “regulatory problem solved.” Under this national security rule, not necessarily. The DOJ is concerned with whether the data, in bulk and in context, can still create risks when accessed by countries of concern or covered persons.

Government-Related Data Gets Special Treatment

The rule also covers U.S. government-related data. This category can apply regardless of volume, which means the “bulk” thresholds are not always the finish line. Government-related data includes certain precise geolocation data tied to sensitive government locations and sensitive personal data marketed as linked or linkable to current or recent former U.S. government employees, contractors, senior officials, military personnel, or intelligence community members.

This is where the rule becomes especially practical. Imagine a data broker selling location data that can identify movement patterns around military bases or federal facilities. Or imagine a dataset marketed as “profiles of defense-sector professionals,” complete with identifiers, job signals, and other attributes. Even if the file is not enormous, the national security implications can be significant. The DOJ’s position is that adversaries do not need every record in America; sometimes the right 1,000 records are enough to create serious risk.

Prohibited vs. Restricted Transactions

The rule divides covered activity into prohibited transactions and restricted transactions. Prohibited transactions are the hard stop signs. Restricted transactions are more like yellow lights with a compliance officer standing nearby, clipboard in hand.

Prohibited transactions

Data brokerage involving covered data and countries of concern or covered persons is generally prohibited. Data brokerage includes selling data, licensing access to data, or engaging in similar commercial transactions where the recipient did not collect or process the data directly from the individuals linked to it. The rule also prohibits certain transactions involving human ‘omic data or human biospecimens from which such data could be derived.

For example, if a U.S. data broker sells bulk precise geolocation data to an entity headquartered in a country of concern, that is the kind of transaction the rule is designed to stop. The same concern may arise if a U.S. app provides bulk identifiers and location signals through ad-tech channels that ultimately give access to covered persons. The transaction may look like advertising plumbing, but the DOJ may see a national security drainpipe.

Restricted transactions

Restricted transactions include certain vendor agreements, employment agreements, and investment agreements that give a country of concern or covered person access to regulated data. These transactions are not automatically banned, but they must satisfy CISA security requirements and additional DOJ compliance obligations.

For instance, a U.S. hospital that contracts with an IT provider headquartered in a country of concern may create a restricted transaction if the provider can access bulk personal health data. A U.S. mobile app company that hires a developer who is primarily resident in a country of concern may need to evaluate whether that worker can access bulk identifiers, biometrics, geolocation data, or other covered information. A U.S. startup receiving investment tied to a covered person may also need to assess whether the investor obtains rights that create access to regulated data.

The Compliance Calendar: April 8, July 8, and October 6

The Data Security Program went into effect on April 8, 2025. The DOJ announced an implementation and enforcement policy for the first 90 days, stating that it would not prioritize civil enforcement for violations occurring from April 8 through July 8, 2025, as long as the person or company made good-faith efforts to comply. That was not a free pass. Egregious, willful violations could still draw penalties, and the DOJ made clear that companies should use the period to map data, review contracts, assess vendors, and implement controls.

Additional obligations tied to due diligence, audits, and certain reporting requirements took effect on October 6, 2025. For organizations engaged in restricted transactions, that date matters because the rule requires a data compliance program, documentation of data flows, verification of transaction parties, analysis of data types and volumes, records of end uses, and annual audits in certain circumstances.

The practical takeaway is simple: “We are still figuring it out” is not a compliance strategy. It is a sentence that belongs in a meeting agenda, not in an enforcement response.

What Companies Should Do Now

Companies should begin with a data map. The DOJ expects U.S. persons to know their data, including what data they collect, how much of it they maintain, where it flows, who can access it, what systems store it, and whether any transaction involves a country of concern or covered person. This is less glamorous than launching a new AI feature, but it is considerably better than discovering during an investigation that your “temporary vendor integration” became a permanent regulatory headache.

1. Identify covered data

Organizations should classify whether they handle human ‘omic data, biometrics, precise geolocation data, health data, financial data, covered personal identifiers, or government-related data. The analysis should include structured databases, cloud environments, analytics tools, backups, data lakes, marketing platforms, HR systems, customer support tools, research files, and vendor-managed systems.

2. Review foreign access

Next, companies should examine whether any country of concern or covered person has access. This includes subsidiaries, contractors, support teams, offshore developers, managed service providers, investors, board observers, joint venture partners, and third-party platforms. Access is not limited to downloads. It can include viewing, querying, administering, decrypting, or otherwise interacting with data.

3. Revisit contracts

Vendor agreements, employment arrangements, investment agreements, and data brokerage contracts should be reviewed for access rights, onward transfer restrictions, audit rights, security controls, subcontracting limits, and termination options. Companies may need to add contractual provisions preventing foreign recipients from reselling or transferring data to countries of concern or covered persons.

4. Implement security controls

For restricted transactions, companies must address CISA security requirements. These may involve organizational, system-level, and data-level controls designed to prevent covered persons from accessing regulated data. In practice, that can mean access segmentation, encryption controls, identity governance, logging, monitoring, data minimization, least-privilege access, vendor oversight, and documented compliance procedures.

5. Prepare documentation before there is a problem

Documentation is the seatbelt of compliance. It may not make the ride exciting, but it helps when things crash. Organizations should document their reasoning, transaction reviews, data volume calculations, country-of-concern screening, vendor diligence, security control implementation, contract updates, and internal approvals.

Industries Most Likely to Feel the Impact

The rule may affect a broad range of sectors, but some industries are especially exposed. Healthcare organizations handle personal health data, genomic data, biospecimens, and research datasets. Financial services firms maintain financial records, account information, transaction histories, fraud signals, and customer identifiers. App developers and ad-tech businesses may process device identifiers, geolocation data, behavioral profiles, and user attributes. Universities and research institutions may work with international collaborators, grants, biospecimens, or human subjects data. Employers with global workforces may maintain HR files, background check information, payroll data, and contractor records.

Companies using artificial intelligence should pay close attention. The rule includes examples involving AI systems trained on sensitive personal data where licensed access could potentially reveal or reproduce regulated data. That does not mean every AI tool violates the rule. It does mean companies should understand training data, retrieval systems, model access, logging, and whether a covered person can obtain sensitive data through prompts, outputs, APIs, or administrative tools.

Specific Examples That Make the Rule Easier to Understand

Consider a U.S. fitness app that collects precise geolocation data from more than 1,000 U.S. devices and sends it through advertising technology to an exchange that makes the data available to advertisers headquartered in a country of concern. Even if the company describes the transaction as monetization, targeting, analytics, or “just how the ecosystem works,” the DOJ may analyze whether the arrangement constitutes data brokerage or creates covered access.

Now consider a medical research company that maintains genomic data on more than 100 U.S. persons. If it enters a grant arrangement requiring it to share that underlying dataset with a university in a country of concern, the transaction may be prohibited or restricted depending on the structure. Research collaboration alone is not automatically covered, but commercial value, grants, required data sharing, and access rights can change the analysis.

Another example: a U.S. company hires a software engineer located in a country of concern. If the engineer works only on public website design and has no access to regulated datasets, the risk may be low. If the engineer has administrator access to a database containing bulk U.S. health, financial, biometric, or geolocation data, the company may be looking at a restricted transaction that requires security controls and compliance documentation.

Penalties and Enforcement Risk

The DOJ’s enforcement authority is backed by the International Emergency Economic Powers Act. Civil penalties can be substantial, and willful violations may carry criminal consequences. Just as important, enforcement can bring operational disruption, reputational damage, investor concern, customer questions, and uncomfortable meetings where everyone suddenly remembers they were “meaning to update the vendor inventory.”

The DOJ has signaled that good-faith compliance matters. Internal reviews, data mapping, vendor due diligence, contract renegotiation, security control implementation, and voluntary cooperation may all help demonstrate that a company took the rule seriously. But the opposite is also true. Ignoring obvious red flags, routing data through shell arrangements, allowing onward transfers, or structuring transactions to evade the rule can make matters much worse.

How This Rule Fits Into the Bigger Data Privacy Landscape

The bulk sensitive data rule does not replace state privacy laws, HIPAA, GLBA, export controls, sanctions, CFIUS, cybersecurity regulations, or sector-specific obligations. It sits beside them, adding a national security layer. A transaction can be lawful under a consumer privacy statute and still create risk under the DOJ Data Security Program. That is the part many businesses may find surprising.

Traditional privacy compliance asks: Did we notify users? Did we collect consent? Did we secure the data? Did we honor rights requests? The DOJ rule asks a different question: could this transaction give a country of concern or covered person access to sensitive U.S. data in a way that threatens national security? Same dataset, very different legal lens.

Experience-Based Insights: What Compliance Teams Learn the Hard Way

In real-world compliance work, the hardest part is rarely reading the rule. The hard part is discovering what the company actually does with data after years of growth, integrations, mergers, vendor changes, product experiments, and “temporary” workarounds that somehow became permanent. A privacy team may think customer data sits in one approved platform. Then the data map reveals copies in analytics dashboards, support tools, marketing exports, cloud backups, test environments, and a spreadsheet named “final_final_use_this_one.xlsx.” That is when the room gets quiet.

One practical experience is that access reviews often uncover more risk than transfer reviews. Many teams search for international data transfers, but the DOJ rule is also concerned with access. A foreign contractor who can log into a U.S.-hosted system may matter just as much as a file sent overseas. A vendor support team that can view production data may matter. A cloud administrator with emergency decryption rights may matter. The compliance question becomes not “Where is the server?” but “Who can reach the data, under what conditions, and with what technical limits?”

Another experience is that business units often underestimate identifiers. Teams may recognize health records, bank account details, or biometric templates as sensitive. But they may overlook combinations of device IDs, IP addresses, cookie IDs, advertising IDs, account numbers, demographic details, and location signals. In modern data ecosystems, identifiers are the connective tissue. They allow datasets to be linked, enriched, profiled, and activated. That is why companies should review not only obvious sensitive files, but also marketing data, telemetry, mobile analytics, fraud prevention signals, and customer engagement platforms.

Vendor management also becomes more complicated. A vendor may not be headquartered in a country of concern, but it may subcontract work, employ covered persons, operate support centers abroad, or use tools that create onward access. A strong contract should address not only confidentiality, but also access restrictions, country-of-concern screening, subcontractor approval, audit rights, data localization where appropriate, security requirements, breach notification, deletion obligations, and restrictions on resale or onward transfer. The best time to negotiate these terms is before the vendor is deeply embedded in your production stack and everyone is afraid to touch it.

Companies also learn that compliance cannot live only in legal. Legal can interpret the rule, but engineering controls access. Security monitors systems. Procurement signs vendors. HR manages employees and contractors. Finance understands ownership and investment rights. Product teams decide what data is collected. Compliance works only when these groups talk to each other before a transaction launches, not after a regulator asks questions.

A useful internal practice is to create a simple intake checklist for new vendors, data sales, research collaborations, foreign hires, offshore support arrangements, and investments. The checklist should ask what data is involved, how many U.S. persons or devices are represented, whether the data includes sensitive categories, who can access it, where those people are located, whether any party is owned or controlled by a country of concern, whether onward transfer is possible, and whether CISA security requirements may apply. This does not need to be fancy. A clear process used consistently beats a beautiful policy nobody reads.

Finally, experienced teams know that “minimum necessary” is not just a healthcare phrase; it is a survival tactic. If a vendor does not need production data, do not give it production data. If a contractor needs synthetic data, use synthetic data. If a team can work with aggregated outputs, do not hand over raw records. If access can expire automatically, make it expire. Data minimization is not only good privacy hygiene. Under the DOJ’s bulk sensitive data rule, it can reduce national security exposure, lower compliance burden, and prevent tomorrow’s emergency meeting from becoming today’s avoidable mistake.

Conclusion

The Department of Justice’s enforcement of the bulk sensitive data rule marks a turning point in U.S. data regulation. Sensitive personal data is no longer viewed only as a consumer privacy asset or a business resource. It is also a national security asset. Companies that collect, sell, license, store, analyze, or provide access to large volumes of U.S. sensitive data must understand whether their transactions involve countries of concern or covered persons.

The smartest response is not panic. It is disciplined data governance. Know the data. Know the access. Know the vendors. Know the contracts. Know the thresholds. Then document the decisions. The companies that treat this rule as an operational data-mapping exercise, rather than a last-minute legal memo, will be in a far stronger position.

Note: This article is for informational publishing purposes only and should not be treated as legal advice. Organizations should consult qualified counsel for transaction-specific analysis under the DOJ Data Security Program.