Educational only; not legal advice. SPP explains diligence issue-spotting, evidence collection, risk triage, and the accountant and certified-fraud-examiner workflow. It does not give filing advice, sanctions opinions, privacy opinions, export classifications, CFIUS legal opinions, or DOJ Data Security Program legal opinions. Regulatory status is current as of drafting (2026-06-15); see the status note at the end.
A target can look ordinary on the income statement and still carry the kind of asset the national-security agencies care about most: a database. Not a patent, not a missile part, not a controlled chip, but rows of Americans’ sensitive personal data sitting inside a customer system, health platform, payroll file, location software development kit, biometric login product, advertising exchange, cloud analytics stack, data-broker feed, or genomics research file. The buyer may be looking at revenue quality, customer concentration, gross margin, and churn. The government may be looking at who can touch the data, where that person sits, what country can compel them, and whether the data can be used to target federal employees, military personnel, intelligence-community workers, journalists, dissidents, or other vulnerable groups.
That is the shift behind Executive Order 14117 and the Department of Justice (DOJ) Data Security Program. The rule is not just a privacy rule wearing national-security language. It is a national-security screen that treats access to certain data as the thing being controlled. The operational question is not simply, “Did the target collect personal information?” The diligence question is sharper: “Does a country of concern or covered person get access to government-related data or bulk United States sensitive personal data through a commercial relationship, and if so, is the relationship prohibited, restricted, exempt, licensed, or unresolved?”
That question belongs in a buy-side diligence workflow because the facts that answer it are the same facts a serious diligence team should already be collecting. What data does the target maintain? How many United States persons or devices are in each dataset? Which vendors, offshore support teams, developers, investors, board observers, resellers, data brokers, and ad-tech platforms can access it? Which contracts permit onward transfer? Which systems hold the data, and what controls separate the data from a foreign-access path? If those questions are left to the last week before signing, the answer becomes a scramble. If they are asked during intake, the buyer can put the risk into the model, the diligence request list, the purchase agreement, and the counsel escalation path.
This piece takes the Data Security Program down to the practical layer. It explains why the regime exists, who runs it, what changed from 2024 to 2026, what trips the wire in a deal, what the government can do, what a buyer should ask for, what belongs in the risk memo, and when the issue leaves the accountant’s lane. It also ships two practitioner pieces: a data-flow and foreign-access map for the deal team, and a small Applied DD Lab exercise that checks synthetic data-asset counts against the bulk thresholds in 28 CFR Part 202. The lab produces leads, not findings. The article does the same. The goal is to recognize the risk early enough that counsel can make the legal call before the business team has already committed to the deal structure.
What this regime was built to solve
The old mental model treated data risk as a privacy problem. Did the company have a privacy policy? Did it comply with its notices? Did it have a breach? Did it follow the Health Insurance Portability and Accountability Act (HIPAA), state privacy statutes, sectoral rules, or contract terms? Those questions still matter. They are not the question the Data Security Program was built to answer.
The Data Security Program was built for a different failure mode: the private market can sell, license, host, process, analyze, enrich, or expose sensitive data in ways that create national-security risk, while neither side of the commercial transaction prices the public cost. A data broker can package mobile-device location data. A health platform can route support work through an offshore vendor. A cloud or analytics provider can give administrators access from a country of concern. A private equity buyer can accept a board observer or information rights from an investor tied to a covered person. A genomics company can send research files to a foreign collaborator. In each case, the commercial transaction may make business sense to the parties, while the government sees a different asset moving: the ability to identify, track, profile, pressure, or target Americans at scale.
Executive Order 14117 states the policy in national-security terms. The order says that unrestricted transfers of Americans’ bulk sensitive personal data and United States Government-related data to countries of concern may allow those countries to engage in malicious cyber-enabled activities, espionage, blackmail, surveillance, intimidation, and other national-security harms. The order also makes the access-path point that matters in diligence: the risk is not limited to direct access by a foreign government. It can run through entities and individuals that are owned by, controlled by, subject to the jurisdiction or direction of, or otherwise connected to a country of concern.
That is the externality. A data transaction may be legal-looking, ordinary, and commercially rational, but the country-of-concern access path can create a risk the parties do not bear alone. The DOJ rule drags that risk into a regulatory framework. It does not ban all cross-border data relationships. It does not prohibit hiring every person from a listed country. It does not require every company to send underlying personal data to the government. It does something narrower and more useful for diligence: it identifies categories of data, categories of transactions, categories of counterparties, and categories of access that must be treated as prohibited or restricted unless an exemption, license, or required security posture applies.
The final rule at 90 FR 1636 is explicit about the gap it was designed to fill. CFIUS can review certain foreign investments in United States businesses. Information and communications technology and services authorities can address certain supply-chain risks. Other privacy, cybersecurity, sanctions, and export-control rules can reach pieces of the fact pattern. But before this program, no federal rule broadly created categorical prohibitions and restrictions on commercial data-brokerage, vendor, employment, and investment relationships that give countries of concern or covered persons access to government-related data or bulk United States sensitive personal data. The Data Security Program is the federal answer to that gap.
For a diligence practitioner, the practical move is simple but demanding: treat data like an asset with an ownership chain, an access chain, a control environment, a regulatory status, and a deal-value consequence. The company does not just “have data.” It has specific datasets, counted by category, stored in specific systems, exposed through specific contracts, touched by specific people, and subject to specific legal thresholds.
Who runs, investigates, and enforces this screen
The lead agency is DOJ’s National Security Division (NSD), specifically through the Data Security Program housed on DOJ’s NSD data-security page. That institutional home matters. This is not primarily a consumer-protection program, though consumer data is often the asset. It is not primarily a cyber program, though cybersecurity controls become central for restricted transactions. It sits in the same DOJ division that handles national-security enforcement, foreign-investment review coordination, export-control and sanctions criminal enforcement, and foreign-intelligence-adjacent matters. The signal is deliberate: data-access risk is being treated as national-security risk.
The program is built under Executive Order 14117 and the International Emergency Economic Powers Act (IEEPA). That matters because the penalty spine points back to IEEPA. Section 202.1301 of the regulation says that civil and criminal penalties under section 206 of IEEPA apply to violations of licenses, rulings, regulations, orders, directives, and instructions issued under the Attorney General’s delegated authority for the program. The details of any actual penalty depend on the facts and the enforcement posture, but the diligence point is clear enough: this is not a soft best-practices framework. A violation can become a civil or criminal enforcement matter.
DOJ also built a guidance surface around the rule. Its Data Security page links the current 28 CFR Part 202 text, a correcting amendment, FAQs, a Compliance Guide issued April 11, 2025, an implementation-and-enforcement policy for the first 90 days, and a press release announcing implementation. The final rule became effective on April 8, 2025. The rule delayed compliance with subpart J due diligence and audit requirements and certain reporting requirements until October 6, 2025. By the time of this draft, those later obligations are no longer future obligations; they are part of the live diligence surface.
The Cybersecurity and Infrastructure Security Agency (CISA) is the other institution a buyer has to understand. Restricted transactions can proceed only if the United States person complies with CISA security requirements and the other requirements in the rule. DOJ’s final rule incorporates the CISA requirements by reference, and DOJ’s FAQ explains their role: the requirements are meant to prevent or mitigate access to covered data by countries of concern or covered persons. In diligence terms, CISA is not the deal regulator the buyer files with for a routine transaction, but CISA’s security requirements become the control standard the target must be able to evidence if it is already engaged in, or will engage in, a restricted transaction.
The Federal Trade Commission (FTC) sits next to this regime through the Protecting Americans’ Data from Foreign Adversaries Act of 2024, usually shortened in this series to PADFA. PADFA is codified at 15 U.S.C. 9901 and enforced by the FTC. It makes it unlawful for a data broker to sell, license, rent, trade, transfer, release, disclose, provide access to, or otherwise make available personally identifiable sensitive data of a United States individual to a foreign adversary country or an entity controlled by a foreign adversary. That is adjacent, not identical. PADFA is a data-broker law. The DOJ Data Security Program reaches covered data transactions across data brokerage, vendor agreements, employment agreements, and investment agreements. A diligence memo that blends them into one generic “data transfer rule” will misstate both.
The Committee on Foreign Investment in the United States (CFIUS) is the third institutional neighbor. CFIUS matters because sensitive personal data can be part of a TID United States business analysis under the Foreign Investment Risk Review Modernization Act (FIRRMA), as discussed in A1. DOJ’s final rule recognizes the overlap and contains CFIUS-action provisions. The buyer’s mistake would be to assume that “we are doing CFIUS” automatically means “we are done with the Data Security Program.” The better formulation is narrower: a CFIUS action may affect the DOJ rule only where the rule says it does, and only to the extent the CFIUS action addresses the relevant data-security risk. The two screens are related, but they are not substitutes.
Finally, because the program is part of the same broader national-security diligence stack, it can connect to other remedies. Sanctions and export controls may appear in the same transaction when a vendor, owner, or technology path overlaps with OFAC or BIS issues. Forfeiture can appear in some data/security matters when proceeds, money laundering, sanctions evasion, or other criminal predicates are in play, but forfeiture is not the default remedy for the Data Security Program itself. The article on asset seizure and forfeiture carries that remedy map separately so this piece does not overclaim.
What changed from 2024 to 2026
The first change was conceptual. In February 2024, Executive Order 14117 moved bulk sensitive personal data and government-related data into the national-security control frame. That move did not come from nowhere. CFIUS had already been treating sensitive personal data as part of investment risk after FIRRMA. The public debate over TikTok had already made data flows, recommendation systems, and foreign influence part of the national-security conversation. Commerce’s connected-vehicle rule, a separate authority, later treated vehicle connectivity hardware and software tied to China and Russia as a supply-chain and data-access risk. But EO 14117 made the data-access problem a dedicated federal program, not just a factor inside another regime.
The second change was operative. DOJ published the final rule on January 8, 2025, at 90 FR 1636. It became effective on April 8, 2025. The final rule created the working categories a buyer now has to test: covered data transactions, countries of concern, covered persons, prohibited transactions, restricted transactions, exempt transactions, licenses, advisory opinions, due diligence, audits, reporting, records, and penalties. The rule also built numeric bulk thresholds, which means diligence cannot stay at the level of “the target has sensitive data.” It has to ask how much, of what kind, and over what time window.
The third change was timing. DOJ delayed compliance with subpart J due diligence and audit requirements and sections 202.1103 and 202.1104 reporting requirements until October 6, 2025. That date matters because many 2025 client alerts were written while some obligations were still coming into force. In a 2026 deal file, the buyer should not treat those obligations as prospective. A target engaged in restricted transactions should be able to show its data compliance program, records, audit posture, and reporting process.
The fourth change was that the rule made data counts a diligence fact. Section 202.205 defines “bulk” by category and by threshold. Human genomic data becomes bulk when it is collected about or maintained on more than 100 United States persons. Other human omic data and biometric identifiers use more than 1,000 United States persons. Precise geolocation data uses more than 1,000 United States devices. Personal health data and personal financial data use more than 10,000 United States persons. Covered personal identifiers use more than 100,000 United States persons. Combined data uses the lowest applicable threshold among the categories in the combined set. Section 202.206 then blocks the common escape hatch: data can qualify even if anonymized, pseudonymized, de-identified, or encrypted.
That last point is one of the most important for accountants and forensic practitioners. A target’s management team may say, “It is de-identified,” or “It is encrypted,” and believe that ends the question. It does not. Those facts are relevant to security, privacy, and restricted-transaction controls, but under the bulk definition they do not by themselves keep the data outside the program. The diligence team has to record the data category, the count, the identifier linkage, the access path, and the control environment separately.
The fifth change was that a data relationship can now look like an export-control style issue even when no controlled item is leaving the country. DOJ’s Compliance Guide describes the program as establishing what are effectively export controls that prevent foreign adversaries and those subject to their direction from accessing government-related data and bulk United States sensitive personal data. That analogy is useful, but it has to be handled carefully. The Data Security Program is not the Export Administration Regulations, and the buyer should not tell a client that it has “classified” data the way an export lawyer classifies an item by Export Control Classification Number. The practical lesson is narrower: access itself is regulated. A foreign-access path to covered data can matter the way a shipment, license, or deemed export matters in the trade-control world.
What trips the wire
The rule’s main diligence test has four questions. If the answer to any one of them is unresolved, the risk memo should say unresolved and explain what is missing. Do not round uncertainty down to “clear.”
First, is the data in scope? There are two big buckets. One is government-related data. The DOJ Compliance Guide describes two types. The first is precise geolocation data, regardless of volume, for any location within an area listed on the Government-Related Location Data List in 28 CFR 202.1401. The second is sensitive personal data, regardless of volume, that a transacting party markets as linked or linkable to current or recent former federal employees or contractors, former senior federal officials, military personnel, or intelligence-community personnel; DOJ’s Compliance Guide treats “recent” employees and contractors as those who worked for or provided services to the United States Government within the past two years. The practical point is that government-related data can be in scope without meeting the bulk thresholds that apply to other sensitive personal data.
The second bucket is bulk United States sensitive personal data. The rule defines sensitive personal data by categories: covered personal identifiers, precise geolocation data, biometric identifiers, human omic data, personal health data, personal financial data, and combinations of those categories. The bulk thresholds are not intuitive, and they do not all sit at the same number. That is why the article’s lab uses a threshold checker. A genomics file crosses at a much smaller count than a covered-personal-identifier file. A buyer who treats all data categories as equivalent will miss the most sensitive rows.
Second, who gets access? Access is the operative word, and it is broader than a formal data sale. In a live company, access can run through a cloud administrator, outsourced support desk, offshore developer, analytics tool, software development kit, board observer, investor information right, contract research organization, reseller, data-broker contract, customer-success team, managed-services provider, ad exchange, or parent-company reporting line. The diligence team should map access the way it maps funds flow: who can see it, who can query it, who can administer the system, who can receive exports, who can cause onward transfer, and who can change the controls.
Third, does the access path involve a country of concern or a covered person? Section 202.601 lists the countries of concern for the rule: China, Cuba, Iran, North Korea, Russia, and Venezuela. DOJ’s Compliance Guide states the China designation includes Hong Kong and Macau. A covered person is not just a named person on a list. Section 202.211 defines categories of covered persons, including certain foreign entities organized or headquartered in countries of concern, certain foreign entities owned 50 percent or more by countries of concern or covered persons, certain foreign individuals employed by or contracting for those persons, certain foreign individuals primarily resident in countries of concern, and persons DOJ specifically designates. DOJ’s FAQ makes a practical point a buyer should not miss: the Covered Persons List is not exhaustive. Some persons are covered because they meet a regulatory category even if they are not publicly listed.
Fourth, is the relationship one of the covered transaction types? Section 202.210 reaches data brokerage, vendor agreements, employment agreements, and investment agreements. That list is narrower than “any business relationship” but broader than many business teams expect. Data brokerage includes sale, licensing of access, or similar commercial transactions involving data transfer where the recipient did not collect or process the data directly from the individuals. A vendor agreement can include cloud-computing services. An employment agreement can include an executive, board, committee, operational, or employment-services arrangement. An investment agreement can create risk not only through cash ownership, but through governance, information, and access rights.
Put those four questions together and the diligence triage becomes concrete:
| Diligence question | Evidence to request | Risk memo output |
|---|---|---|
| What data exists? | Data inventory, system list, data dictionary, customer counts, device counts, category mapping | Covered data category, threshold status, government-related status |
| Who can access it? | Vendor list, access-control exports, admin roles, support model, offshore development roster, investor rights | Foreign-access path, unresolved-access gaps |
| Is any party a country of concern or covered person? | Counterparty jurisdictions, ownership charts, headquarters, employment/contractor data, covered-person screening | Country-of-concern or covered-person flag |
| What transaction type applies? | Contracts, statements of work, data-sale/licensing terms, employment arrangements, investment documents | Data brokerage, vendor, employment, investment, exempt, or unresolved |
| What controls exist? | Security architecture, data minimization, tokenization, encryption, access logs, CISA-requirements mapping, audit reports | Restricted-transaction readiness or control gap |
The most common diligence failure will not be a missed statute citation. It will be an incomplete map. The target will produce a vendor list but not access rights. It will produce a data map but not counts. It will produce a cloud contract but not administrator geography. It will identify a parent company but not the foreign contractor who manages production access. The buyer’s job is to keep asking until the map is specific enough to support a conclusion, or to say that the conclusion is unresolved.
What the government can do
The remedy set depends on the transaction class. Subpart C contains prohibited transactions. Section 202.301 prohibits United States persons from knowingly engaging in a covered data transaction involving data brokerage with a country of concern or covered person, unless otherwise authorized or exempt. Section 202.302 reaches certain data-brokerage transactions with foreign persons who are not covered persons unless the United States person contractually prevents onward transfer to countries of concern or covered persons and reports known or suspected violations. Section 202.303 prohibits covered data transactions with a country of concern or covered person involving access to bulk United States sensitive personal data that involves bulk human omic data, or human biospecimens from which such data could be derived. Section 202.304 prohibits evasion, attempts, causing violations, and conspiracies. Section 202.305 prohibits knowingly directing certain prohibited or unauthorized restricted transactions.
Subpart D contains restricted transactions. A restricted transaction is not necessarily dead. It can proceed if the United States person complies with the CISA security requirements and the other applicable requirements in the rule. DOJ’s FAQ explains the core idea in practical terms: restricted transactions are supposed to prevent covered persons and countries of concern from accessing linkable, identifiable, unencrypted, or decryptable data unless the security requirements and data-level mitigations reduce the risk. The target may still be able to use the vendor, hire the person, accept the investment, or maintain the business relationship, but only if the transaction is structured and controlled correctly.
Subparts H and I create processes for licenses and advisory opinions. A specific license is not something an accountant or diligence team should attempt to obtain or interpret. It belongs to counsel. What diligence can do is identify facts that make a license question real enough to escalate. The same is true of exemptions. The rule contains exemptions for categories such as official United States Government business, certain financial services, certain corporate group transactions, transactions required or authorized by federal law or international agreements, telecommunications services, certain drug, biological product, and medical device authorizations, and certain clinical investigations and post-marketing surveillance data. Those exemptions are technical. In the risk memo, they should be flagged as counsel questions, not asserted as free passes unless counsel has validated the fit.
The compliance obligations are not decorative. Section 202.1001 requires a data compliance program for restricted transactions. The program must include risk-based procedures for verifying and logging the data flows involved in restricted transactions, including data types and volumes, the identity and ownership or citizenship/residence of parties, the end use, and the method of transfer. Section 202.1002 requires annual audits for restricted transactions. Section 202.1101 requires full and accurate records that remain available for examination for at least 10 years after the transaction. DOJ’s FAQ says companies do not routinely submit underlying sensitive personal data to the government as part of routine reporting, but top-level transaction descriptions and records can still be required, and DOJ may request or compel information under the rule.
For diligence, the remedy map is not “the government seizes the data.” It is more precise:
| Regime action | What it means in diligence |
|---|---|
| Prohibition | The transaction should not proceed unless an exemption, license, or other authorization applies. |
| Restricted-transaction conditions | The relationship may proceed only with CISA security requirements and the rule’s compliance obligations. |
| Licensing | Counsel evaluates whether an otherwise prohibited or restricted transaction can be authorized. |
| Advisory opinion | Counsel may seek agency guidance on application to a fact pattern. |
| Records and reporting | The buyer should request evidence of records, audit reports, data compliance program documents, and reporting processes. |
| Civil or criminal penalties | Violations can carry IEEPA-backed enforcement exposure. |
| Deal remedy | Conditions precedent, covenants, reps, indemnities, escrows, access restrictions, vendor remediation, data segregation, or walk-away rights. |
That remedy map is less dramatic than forfeiture, but it is the one a buyer is more likely to experience. A target with a prohibited data-broker relationship may lose a revenue stream. A target with a restricted vendor relationship may need to rebuild support operations or segregate data before close. A target with a foreign-access path to genomic data may have to stop the relationship or seek counsel immediately. A target with no data inventory may not be able to prove compliance at all. Those are deal economics, not footnotes.
What a buyer asks for
The buyer’s request list should be designed to produce a map, not a pile of policies. Privacy policies and security certifications are useful, but they do not answer the Data Security Program question by themselves. The request list needs the evidence that links data category, count, system, contract, person, country, access, and control.
Start with the data inventory. Ask for a list of all datasets containing United States person data or United States device data, including customer, patient, employee, user, subscriber, location, financial, biometric, genomic, research, and advertising data. For each dataset, request the data category under 28 CFR Part 202, the approximate count of United States persons or devices over the preceding 12 months, whether the data is linked or linkable to individuals or a discrete group, whether the data is anonymized or de-identified, and whether any government-related data is present. If management says it cannot produce counts, that is not the end of diligence. That is the finding: the target cannot currently measure whether a threshold is crossed.
Next, ask for system and access evidence. The target should provide a system map showing where the data sits, who administers the system, where administrators are located, which service providers can access the data, which support desks can see or query it, what logs exist, and which controls prevent export or onward transfer. Request role-based access-control exports, privileged-user lists, support-team rosters, offshore development locations, cloud regions, data-loss-prevention rules, encryption/key-management documentation, and access-log retention policies. This is not because a CPA is turning into a penetration tester. It is because “foreign access” is an evidence question before it is a legal conclusion.
Then ask for counterparty evidence. Vendor lists should be joined to contract copies, statements of work, subprocessor lists, data-processing addenda, cloud-service terms, software development kit terms, reseller agreements, data-sale and data-license contracts, research collaboration agreements, and investment documents. For each counterparty with a foreign nexus, request headquarters, organization jurisdiction, parent company, ownership, contract location, personnel location where relevant, and whether any individual or entity is a country of concern or covered person under the rule. The buyer should not rely only on a sanctions list screen. Covered-person status under 28 CFR Part 202 can arise from categories even without a public designation.
For investment and governance, request board rights, observer rights, veto rights, information rights, data-room rights, investor reporting rights, technical-information access, and side letters. Investment risk under this program is not just “who owns the stock.” It can be “who gets the data or the governance seat that creates access.” That is why this article cross-links A1. CFIUS asks whether a foreign investor’s rights create national-security risk in a United States business. The Data Security Program asks whether a covered data transaction gives a country of concern or covered person access to government-related data or bulk sensitive personal data. Different legal machines, overlapping facts.
For restricted transactions, request compliance-program evidence. The target should be able to produce policies and procedures that identify covered data transactions, verify and log data flows, screen counterparties according to risk, implement CISA security requirements, maintain records, conduct audits, and escalate reporting obligations. If the target says it is engaged in a restricted transaction but has not built subpart J processes after October 6, 2025, that belongs in the risk memo.
Finally, ask for prior agency contact and legal work. Has the target analyzed EO 14117 or 28 CFR Part 202? Has counsel prepared a memo? Has the target sought an advisory opinion or license? Has it made any report under section 202.1104? Has it rejected a prohibited data-brokerage transaction? Has it been contacted by DOJ, CISA, FTC, CFIUS, Commerce, Treasury, or a state privacy regulator on any matter involving data access by foreign parties? A “no” answer can be useful. A “we do not know” answer is a different kind of evidence.
What belongs in the data-security risk memo
The risk memo should not read like a law-school outline. It should answer the deal question. A useful memo has five parts.
First, it states the data inventory conclusion. For each material dataset, it identifies the data category, the count basis, the approximate count, the threshold, and whether government-related data is present. It should separate management-provided numbers from system-derived numbers. If the count is an estimate, say so. If the target cannot count, say so. If the count is near a threshold, do not call it safe; call it near threshold and request refresh before signing.
Second, it states the access conclusion. The memo should identify every foreign-access path found, including vendors, employees, contractors, investors, board observers, data brokers, resellers, ad-tech tools, cloud systems, and research collaborators. Each path should have an owner, a contract, a system, and a control. If the access path is unresolved, the memo should not smooth that into “no access identified.” It should say “access unresolved” and explain the missing evidence.
Third, it classifies the transaction posture at a diligence level. Is the relationship data brokerage, a vendor agreement, an employment agreement, an investment agreement, exempt-looking, counsel-dependent, or unresolved? Is a country of concern or covered person potentially involved? Is the relationship potentially prohibited, restricted, or outside the rule? The accountant does not give the legal opinion. But the memo can put the facts into the right boxes and identify which boxes counsel needs to confirm.
Fourth, it states the deal response. If a prohibited data-brokerage issue may exist, the response may be a condition precedent requiring termination, license analysis, or restructuring before close. If a restricted vendor relationship exists, the response may be a covenant requiring implementation of security requirements and evidence of a data compliance program before closing. If counts are uncertain, the response may be a special diligence condition, a bring-down certificate, and a walk-away right if thresholds are crossed. If a high-risk dataset is core to the target’s value, the response may be price adjustment, escrow, indemnity, remediation budget, or an express exclusion from the deal.
Fifth, it states escalation. This is where the legal-boundary paragraph becomes operational. The CPA/CFE diligence team can identify data categories, counts, access paths, foreign nexus, document gaps, and control gaps. Counsel determines legal coverage, exemptions, license strategy, reporting, whether a transaction is prohibited or restricted, and how the rule interacts with CFIUS, privacy law, export controls, sanctions, and contracts. The memo should make that handoff explicit.
The risk memo should also include a short table. Here is the format:
| Dataset | Count and threshold | Access path | Transaction type | Preliminary posture | Deal response |
|---|---|---|---|---|---|
| Patient portal | 18,500 United States persons; personal health threshold 10,000 | Offshore support vendor | Vendor agreement | Possible restricted transaction | Counsel review; CISA controls evidence; closing covenant |
| Location SDK | 920 United States devices; precise geolocation threshold 1,000 | Ad-tech exchange | Possible data brokerage | Near threshold; access unresolved | Refresh count; review onward-transfer clause |
| Genomic research file | 125 United States persons; genomic threshold 100 | Foreign research collaborator | Research/data-sharing relationship | Possible prohibited human genomic issue | Immediate counsel escalation |
That table does not prove a violation. It proves a disciplined diligence process.
When to escalate to counsel
Escalation should happen earlier than most teams want. The correct trigger is not “we have confirmed a violation.” If the diligence team could confirm a violation on its own, the matter was escalated too late. The trigger is a fact pattern that could put the transaction into the rule.
Escalate immediately if any dataset appears to cross or approach a bulk threshold and there is any foreign-access path involving a country of concern or a potential covered person. Escalate immediately if government-related data is present, because the volume rule is different. Escalate if the relationship involves data brokerage, because data brokerage is the sharpest prohibited-transaction lane. Escalate if human genomic data, other human omic data, or biospecimens are present and a country-of-concern access path exists. Escalate if management cannot identify who administers the data systems or where privileged access sits. Escalate if a vendor or investor refuses ownership, personnel-location, or onward-transfer information. Escalate if the target relies on an exemption without a counsel memo. Escalate if a buyer intends to grant post-close access rights to a foreign investor, board observer, offshore support team, or parent-company affiliate.
There is one more escalation trigger that belongs in the diligence file: a business-model dependency on questionable data flow. If a material revenue stream depends on data brokerage, ad-tech transfer, offshore processing, foreign research collaboration, or analytics access that could be prohibited or restricted, the issue is not a side compliance matter. It is a quality-of-earnings issue. The buyer may be acquiring revenue that cannot continue in its current form. That belongs in the model and in the purchase agreement.
Escalation does not mean panic. It means the right expert gets the facts while the buyer still has leverage. The diligence team should hand counsel a clean map, not a pile of PDFs. The map should include data category, count, system, access path, counterparty, country nexus, contract, control, and unresolved evidence. Counsel can then decide legal posture, exemption, license, disclosure, reporting, CFIUS interaction, and deal terms.
Practitioner Skill Built By This Article
The skill this article builds is the ability to turn “the target has sensitive data” into a sourced data-security diligence map.
- What you can now recognize: the difference between general privacy risk and DOJ Data Security Program risk; the covered data categories; the bulk thresholds; government-related data; countries of concern; covered persons; data brokerage, vendor, employment, and investment access paths; and the difference between prohibited and restricted transaction posture.
- What source you verify it against: Executive Order 14117 for policy; DOJ’s final rule at 90 FR 1636 and 28 CFR Part 202 for operative rules; DOJ’s Data Security page, Compliance Guide, and FAQs for agency procedure; 15 U.S.C. 9901 and the FTC PADFA page for the adjacent data-broker statute; and the source-status table for current status.
- What you can produce: a data-flow and foreign-access map, a threshold table, a diligence request list, and the data-security section of a buy-side risk memo.
- When you escalate: any plausible prohibited or restricted transaction; any government-related data with a foreign-access path; any crossed or near threshold with a country-of-concern or covered-person nexus; any human genomic, human omic, or biospecimen issue; any claimed exemption; any license, advisory-opinion, or reporting question; and any access path the target cannot document.
The dividing line is important. A CPA or CFE diligence practitioner can identify and document the facts: what data exists, how much, where it sits, who can access it, what contracts govern it, and what gaps remain. Counsel determines whether the rule applies, whether an exemption or license is available, whether a transaction is prohibited or restricted, and what legal notice, reporting, or restructuring is required. The public-source review can leave real unresolved risk, especially where ownership, residence, personnel access, subcontracting, or system administration cannot be verified.
The shipped artifact: data-flow and foreign-access map
Use this map during diligence intake and update it before signing. It is built for a memo, not for a technical architecture diagram.
| Field | What to capture | Evidence |
|---|---|---|
| Dataset ID | A stable label for each material dataset | Data inventory, system owner interview |
| Data category | Genomic, other human omic, biometric, precise geolocation, personal health, personal financial, covered identifiers, combined data, government-related data | Data dictionary, privacy inventory, system export |
| Count basis | United States persons or United States devices in the preceding 12 months | System count, management certification, analytics export |
| Threshold status | Below, near, exceeded, government-related, unknown | 28 CFR 202.205 and 202.206 |
| System location | Application, database, cloud region, data warehouse, backup | Architecture diagram, cloud account inventory |
| Access path | Vendor, employee, contractor, investor, board observer, data broker, reseller, cloud admin, research collaborator | Contracts, role exports, access logs |
| Foreign nexus | Country of concern, covered-person category, ownership, residence, employment, contractor location | Ownership chart, vendor due diligence, HR/vendor roster |
| Transaction type | Data brokerage, vendor agreement, employment agreement, investment agreement, exempt-looking, unresolved | Contracts and side letters |
| Controls | Segmentation, tokenization, encryption, key management, access denial, logging, CISA requirements mapping | Security control evidence |
| Memo conclusion | Possible prohibited, possible restricted, exempt-looking, outside scope, unresolved | Counsel-ready risk memo |
| Deal response | CP, covenant, remediation, price adjustment, escrow, indemnity, walk-away, counsel review | Purchase agreement draft and issue log |
The discipline is to keep unknowns visible. “Unknown” is not a failure of the table. It is the table doing its job.
Applied DD Lab: Replicate the Screen
The C1 lab uses a synthetic data-asset inventory to show how a buyer can test data categories against the numeric thresholds in 28 CFR 202.205. It does not use client data, target data, private records, BOI, or real company names. It does not determine whether a transaction is covered, prohibited, restricted, exempt, licensed, or compliant. It only answers the first screening question: does the supplied count cross or approach the threshold for that data category?
Dataset: data/synthetic/c1_data_assets.csv in the companion repository. The rows are fictional examples such as a synthetic patient portal, a synthetic location software development kit, a synthetic payroll archive, a synthetic genomic research file, and a synthetic payment ledger.
Code: src/ns_diligence/data_threshold_checker.py.
Run:
python -m ns_diligence.data_threshold_checker \
data/synthetic/c1_data_assets.csv \
data/redacted_outputs/c1_data_threshold_sample.csvSample output:
| Asset | Category | Count | Threshold | Output |
|---|---|---|---|---|
| Synthetic patient portal | personal health data | 18,500 United States persons | 10,000 | bulk threshold exceeded |
| Synthetic location SDK | precise geolocation data | 920 United States devices | 1,000 | near threshold |
| Synthetic genomic research file | human genomic data | 125 United States persons | 100 | bulk threshold exceeded |
What the lab can show: a reproducible method for translating a data inventory into threshold flags that can feed a risk memo. It helps a reader understand why the threshold for genomic data is much lower than the threshold for covered personal identifiers, and why near-threshold data should be refreshed before signing.
What it cannot show: whether a real transaction is data brokerage, a vendor agreement, an employment agreement, an investment agreement, exempt, licensed, prohibited, restricted, or compliant with CISA security requirements. It cannot verify ownership, residence, employment, contractor status, country-of-concern nexus, or access controls. It cannot replace counsel. It is a lead generator and teaching tool.
When to escalate from the lab result: any “bulk threshold exceeded” row with a foreign-access path; any “near threshold” row where counts are stale or measurement is weak; any government-related data; any human genomic, human omic, biometric, health, financial, or location data where a vendor, investor, employee, or contractor in a country of concern may have access.
The lab guardrail is the same one used throughout this section: public or synthetic data only, no client data, no target names, no private records, no BOI bulk use, and no finding language.
Terms used in this article
The full glossary lives in the section’s master glossary; the terms you need for this piece:
- DOJ Data Security Program (DSP): the DOJ National Security Division program under EO 14117 and 28 CFR Part 202 that regulates certain data-access transactions involving countries of concern and covered persons.
- Executive Order 14117: the 2024 order directing DOJ to restrict access by countries of concern to Americans’ bulk sensitive personal data and government-related data where the access creates unacceptable national-security risk.
- Bulk U.S. sensitive personal data: sensitive personal data about United States persons that meets the numeric thresholds in 28 CFR 202.205, even if anonymized, pseudonymized, de-identified, or encrypted.
- Government-related data: certain precise geolocation data tied to listed government locations, and certain sensitive personal data marketed as linked or linkable to current or recent federal employees, contractors, military, intelligence-community personnel, or former senior officials.
- Covered data transaction: a transaction involving access by a country of concern or covered person to government-related data or bulk United States sensitive personal data and involving data brokerage, a vendor agreement, an employment agreement, or an investment agreement.
- Country of concern: for 28 CFR Part 202, China, Cuba, Iran, North Korea, Russia, and Venezuela; DOJ guidance states China includes Hong Kong and Macau.
- Covered person: a person or entity that meets the categories in 28 CFR 202.211 or is specifically designated by DOJ.
- Data brokerage: sale, licensing of access, or similar commercial transaction involving transfer of data to a recipient that did not collect or process it directly from the individuals.
- Restricted transaction: a covered data transaction that may proceed only if the United States person satisfies CISA security requirements and other rule obligations.
- Prohibited transaction: a data transaction barred by subpart C unless an exemption, license, or other authorization applies.
- CISA security requirements: cybersecurity and data-security measures incorporated into the rule for restricted transactions.
- PADFA: the Protecting Americans’ Data from Foreign Adversaries Act of 2024, a separate FTC-enforced data-broker statute codified at 15 U.S.C. 9901.
Selected sources
- DOJ National Security Division, Data Security Program, https://www.justice.gov/nsd/data-security
- DOJ final rule, “Preventing Access to U.S. Sensitive Personal Data and Government-Related Data by Countries of Concern or Covered Persons,” 90 FR 1636, Jan. 8, 2025, https://www.govinfo.gov/content/pkg/FR-2025-01-08/pdf/2024-31486.pdf
- eCFR, 28 CFR Part 202, https://www.ecfr.gov/current/title-28/chapter-I/part-202
- DOJ NSD, Data Security Program Compliance Guide, Apr. 11, 2025, https://www.justice.gov/opa/media/1396356/dl
- DOJ NSD, Data Security Program FAQs, updated Sept. 24, 2025, https://justice.gov/nsd/media/1415006/dl
- U.S. Code, 15 U.S.C. Chapter 123, Protecting Americans’ Data from Foreign Adversaries, https://uscode.house.gov/view.xhtml?edition=prelim&path=%2Fprelim%40title15%2Fchapter123
- FTC, Protecting Americans’ Data from Foreign Adversaries Act of 2024, https://www.ftc.gov/legal-library/browse/statutes/protecting-americans-data-foreign-adversaries-act-2024-padfaa
- Commerce/BIS, 15 CFR Part 791, subpart D, connected-vehicle ICTS supply-chain rule, https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-E/part-791/subpart-D
Status note
Last reviewed: 2026-06-15.
Next scheduled review: 2026-09-15.
Current watch items: DOJ Data Security Program FAQ updates; direct CISA security-requirements page re-check; first DOJ Data Security Program enforcement actions; CFIUS/Data Security Program interaction; connected-vehicle supply-chain rule status; human omic and genomic data guidance; any amendments to the countries-of-concern or covered-person framework.
By Noah Green CPA CFE, for Sheepdog Prosperity Partners. Educational only; not legal advice. SPP explains diligence issue-spotting, evidence collection, risk triage, and the accountant and certified-fraud-examiner workflow. SPP does not give filing advice, sanctions opinions, privacy opinions, export classifications, CFIUS legal opinions, or DOJ Data Security Program legal opinions.