Does Your Startup Have a National Security Data Problem? The DSP Compliance Checklist Founders Are Missing

Most tech founders have a privacy compliance checklist: draft a privacy policy, handle COPPA if you have kids users, sign BAAs if you touch health data, run GDPR if you have EU users. That checklist is great. But there is a separate compliance regime that went into full enforcement in 2025 — one that your privacy program does not cover and that most startups outside the defense sector have never heard of. It is called the Data Security Program.

Here is what it is, who it reaches, and what to do about it.

The Short Version

The Department of Justice finalized the Data Security Program under Executive Order 14117 in late December 2024 (published in the Federal Register on January 8, 2025). It took effect April 8, 2025. Full enforcement — including the affirmative compliance obligations that require written programs, audits, and recordkeeping — began October 6, 2025.

The DSP is not a privacy regulation. It does not care much about consumer notice or consent. It is built on the same legal authority as export controls (IEEPA), and it works the same way: it restricts who you may transfer covered data to. Specifically, it restricts transfers of certain categories of bulk sensitive personal data to entities and individuals connected to six Countries of Concern — China (including Hong Kong and Macau), Russia, Iran, North Korea, Cuba, and Venezuela.

A companion statute, the Protecting Americans' Data from Foreign Adversaries Act (PADFAA), enforced by the FTC, applies specifically to data brokers and restricts them from transferring sensitive data to entities under foreign adversary control. Note that PADFAA's list is narrower than the DSP's: it reaches four foreign adversaries — China, Russia, Iran, and North Korea — and omits Cuba and Venezuela. So the two frameworks do not map onto the same set of countries.

These frameworks apply regardless of whether you think of your company as a national security actor. They apply based on what data you handle and who can access it.

Does This Apply to Your Startup?

Work through these four questions.

Question 1: What Data Do You Collect?

The Data Security Program (DSP) covers six categories of sensitive personal data. If your product touches any of the following, read on:

• Precise geolocation data
• Biometric identifiers (facial images, fingerprints, voiceprints)
• Human genomic or other 'omic data
• Personal health data
• Personal financial data
• Covered personal identifiers (name combined with SSN, device ID, account credentials, or similar)

Question 2: How Much of It?

The DSP applies once your data collection crosses what it calls a bulk threshold. These thresholds are lower than most founders expect:

Three things make these thresholds more significant than they look. First, they are measured on a rolling 12-month aggregate basis — you cannot structure around them by breaking transfers into smaller pieces. Second, if your dataset contains multiple covered categories, the lowest threshold in the dataset governs the whole thing. A fitness app that collects both health data and geolocation data hits the DSP threshold at 1,000 devices, not 10,000. Third, the DSP covers anonymized, pseudonymized, and de-identified data. Stripping names or encrypting the file does not remove your compliance obligation.

Question 3: Who Has Access to It?

The DSP is triggered by access, not just transfer. If any of the following have access to your covered data, you have a covered data transaction:

• A vendor, cloud provider, or contractor that is headquartered in or majority-owned (50% or more) by a Country of Concern
• An employee or contractor who is primarily a resident of a Country of Concern
• An investor with majority ownership in one of your vendors
• A board member or advisor affiliated with a Country of Concern entity
• A third-party SDK or analytics tool that transfers your users' data to any of the above

That last point deserves specific attention. If your product embeds a third-party analytics SDK, advertising pixel, or tracking library, and that SDK transfers location or device identifier data from more than 1,000 of your U.S. users to an entity connected to a Country of Concern, you have a covered data transaction — even if you never reviewed the SDK's data flow documentation and did not know the transfer was happening. The obligation arises from the integration decision.

Question 4: What Kind of Transaction Is It?

The DSP distinguishes between two categories. Prohibited transactions — primarily data brokerage arrangements and bulk human genomic data transfers to Countries of Concern — cannot proceed at all absent a specific government license. Restricted transactions — vendor agreements, employment agreements, and investment agreements involving Covered Persons — can proceed, but only with a compliant data security program in place.

Most startup DSP exposure falls in the restricted transaction category. The compliance obligation does not require you to terminate existing vendor or employment relationships. It requires you to build a compliance program around them.

What Compliance Actually Requires

If you have restricted transactions, the DSP requires a written, annually certified Data Compliance Program. This is a structured compliance document — not a privacy policy — that must include:

• A designated compliance officer responsible for the program
• A data flow map identifying what covered data you hold, where it goes, and who has access
• Risk-based due diligence procedures for assessing vendors, investors, and employees for Covered Person status
• Implementation of CISA-defined security requirements for restricted transactions — including access controls, data minimization, and encryption standards calibrated to prevent covered data from being accessible to Covered Persons
• Employee training on DSP obligations
• An annual independent audit of the program
• Record keeping maintained for a minimum of ten years

The CISA security requirements are incorporated by reference in the DSP and available at cisa.gov. They are adapted from the NIST Cybersecurity Framework and include organizational, system, and data-level requirements that go beyond standard SOC 2 controls in some respects — particularly around access controls for foreign national employees and vendors.

Enforcement is not limited to regulators finding you. FinCEN has established a whistleblower program under which individuals may receive financial awards for reporting violations that lead to enforcement actions resulting in penalties exceeding one million dollars. A disgruntled offshore contractor or former employee is a live enforcement vector, not a hypothetical one.

The Startup Scenarios Most Likely to Create Exposure

The rule turns on access to covered data, not on whether you intended to send anything abroad. The Covered Person analysis reaches transactions that most product and engineering teams would never flag as data transfers. A handful of common startup patterns are where that gap tends to open.

The analytics SDK you integrated without auditing. A consumer app that embeds a widely used third-party analytics or advertising SDK may be transferring location and device identifier data to an entity with Chinese or Russian ownership without the product team's knowledge. SDK audits are not standard practice at most early-stage startups, which is exactly what makes this scenario easy to miss.

The offshore engineering team. A startup using a development shop in a Country of Concern — or employing engineers based in one — where those engineers have access to a database of health, financial, or location data on more than the applicable bulk threshold of U.S. users likely has a restricted employment transaction.

The Series A investor. A venture fund with Chinese limited partners who hold information rights — which typically include financial statements and operational data — may constitute a Covered Person with access to covered data, depending on the structure of the LP agreement and what data is included in investor reporting.

The cloud provider. A startup using a cloud infrastructure provider with Country of Concern ownership, or a data center operated by a Country of Concern entity, to store covered data likely has a restricted vendor transaction — one that turns on meeting the CISA security requirements rather than an outright ban.

The genomics startup. Any company handling genomic or 'omic data on more than 100 U.S. persons faces the DSP's lowest bulk threshold — and a prohibited transaction bar for transfers to Countries of Concern that applies regardless of compliance program quality. Crossing that line flips the analysis from “build a compliance program” to “you cannot do this transaction at all without a specific license.”

What to Do Now: A Practical Starting Checklist

This is not a complete compliance assessment — DSP analysis requires a facts-and-circumstances review specific to your company's data practices and counterparty relationships. But these steps get you oriented:

1. Data inventory. List every category of sensitive personal data your product collects from U.S. users. Map the volume against the bulk thresholds above. If you cross any threshold, continue.
2. Third-party SDK and pixel audit. Pull a list of every third-party tracking library, analytics SDK, and advertising pixel integrated into your product. For each, identify the corporate parent and verify country of incorporation and ownership. Flag any with Country of Concern ties.
3. Vendor review. Review your cloud provider, data processing vendors, and offshore development relationships. Identify any vendor that is headquartered in, majority-owned by, or operated in a Country of Concern and has access to covered data.
4. Cap table and investment agreement review. If you have received investment from international funds, review your investor list and LP disclosures for Country of Concern connections. Review information rights provisions — what data do your investors receive, and does it include covered categories?
5. Employment and contractor review. Identify any employees or contractors who are primarily residents of a Country of Concern and have access to covered data.
6. Applicability determination. If any of Steps 1 through 5 surfaces a potential covered transaction, get a formal DSP applicability assessment from counsel before building your compliance program. The definitions, thresholds, exemptions, and transaction categories have enough nuance that self-assessment is a reasonable starting point but not a substitute for legal review.
7. If you have prohibited transactions, stop. If your analysis surfaces a potential prohibited transaction — particularly any data brokerage arrangement or genomic data transfer to a Country of Concern — do not proceed with that transaction without counsel. Prohibited transactions cannot be remediated with a compliance program; they require a government license or termination.

The PADFAA Overlay for Data Brokers

If your business model involves aggregating and selling or transferring data about individuals with whom you do not have a direct relationship — advertising data, consumer intelligence, location analytics, B2B data products — the Protecting Americans' Data from Foreign Adversaries Act (PADFAA) applies to you independently of the DSP. On February 9, 2026, the FTC sent letters to thirteen data brokers reminding them of their PADFAA obligations, and current FTC leadership has indicated enforcement is a priority. PADFAA carries civil penalties of up to $53,088 per violation, enforced through the FTC's Section 5 authority.

The practical distinction from the DSP is significant. PADFAA does not require a written compliance program. It imposes a flat prohibition: you may not transfer sensitive data about U.S. persons to foreign adversary-controlled entities. Due diligence on your data purchasers — verifying who is buying your data and whether they have foreign adversary connections — is the core compliance step. Recall that PADFAA's adversary list is the same four-country set: China, Russia, Iran, and North Korea.

One More Thing: Your Privacy Program Does Not Cover This

The DSP and PADFAA are not satisfied by a well-drafted privacy policy, a GDPR-compliant DPA, a HIPAA business associate agreement, or a CCPA-compliant opt-out mechanism. These are separate legal regimes with separate requirements enforced by separate agencies. A startup that is fully current on its privacy obligations may still have unaddressed DSP exposure.

The question the DSP asks is not whether you handled your users' data fairly. It is whether the data you hold could reach a foreign adversary through your vendor relationships, your investor base, your engineering team, or your technology stack. That is a different question, and it requires a different compliance analysis.