What Counts as Sensitive, Bulk, and Government-Related Data?

The DOJ Data Security Program turns on a data-side question before it turns on a contract: what information is being made accessible, in what amount, and with what connection to people, devices, or government activity? This chapter explains how the DSP defines sensitive personal data, bulk data, government-related data, and access. The practical result is a data inventory that can support a counterparty and transaction decision, rather than an ordinary-language guess that a dataset is either harmless or automatically regulated.

Bulk is a measurement rule, not a feeling

The DSP identifies several categories of sensitive personal data: covered personal identifiers, precise geolocation data, biometric identifiers, human ‘omic data, personal health data, and personal financial data. The categories can also be combined. These labels are not simply synonyms for “private information.” They are legal categories that matter because the program is aimed at the scale and strategic usefulness of data that could be accessed by a country of concern or covered person.

The word bulk supplies the measurement rule. Under the current regulation, the relevant amount is measured at any point in the preceding twelve months. A company cannot necessarily avoid the threshold by dividing a transfer into smaller releases: the rule permits aggregation across covered data transactions involving the same U.S. person and the same foreign person or covered person. The counting unit also depends on the data. Some thresholds count U.S. persons; precise geolocation counts U.S. devices.

The principal thresholds are:

  • Human ‘omic data reaches the bulk threshold when it concerns more than 1,000 U.S. persons. Human genomic data has the lower threshold of more than 100 U.S. persons.
  • Biometric identifiers and precise geolocation data reach the threshold at more than 1,000 U.S. persons or, for geolocation, more than 1,000 U.S. devices.
  • Personal health data and personal financial data reach the threshold at more than 10,000 U.S. persons.
  • Covered personal identifiers reach the threshold at more than 100,000 U.S. persons.

These numbers are not interchangeable. A company with 2,000 devices’ precise location records and a company with 2,000 health records are not presenting the same data-side fact, even if both describe their holdings as “customer analytics.” A smaller human-genomic dataset can cross its category threshold while a much larger general contact database may not cross the threshold for covered personal identifiers. The correct question is not “How large is the database?” in the abstract. It is “How many relevant persons or devices are represented in each regulated category, and over what period?”

Combined data creates another reason to inspect relationships among fields. The regulation treats a collection containing more than one category, or a listed identifier linked to certain other categories, according to the lowest applicable threshold when an individual data type meets the relevant threshold in the aggregate. A business may therefore undercount risk if it inventories tables separately even though the transaction exposes them together. The legal significance can arise from the combination, not from one column considered in isolation.

The threshold is also not a test of whether a business considers the data commercially valuable. It is a defined condition for a particular rule. The same records might have low marketing value, be collected for a public-interest purpose, or be stored in a system that the company believes is well protected. None of those descriptions answers whether the data meets the DSP’s category and scale definitions.

The thresholds become clearer when treated as decision boundaries rather than as a ranking of which kinds of data are “most sensitive.” Imagine a company that sends human genomic data about 70 U.S. persons to one foreign counterparty in January and data about another 40 U.S. persons to the same counterparty in November. Looking at either transfer alone would miss the fact that the preceding twelve-month total is more than 100. The same logic can apply to precise geolocation: 700 U.S. devices in one release and 500 in another exceed the more-than-1,000-device threshold when the transactions involve the same relevant parties and fall within the measurement window. The issue is not that the company tried to evade the rule; aggregation is simply part of how the amount is measured.

The thresholds also explain why a larger record count does not always mean a more consequential DSP category. Nine thousand U.S. persons’ health records do not cross the more-than-10,000 health-data threshold on that fact alone, while 150 U.S. persons’ human genomic data exceeds the more-than-100 genomic-data threshold. A business that reports only one overall “customer count” loses the distinction the regulation needs. It should maintain category-specific counts and identify whether a person or device appears in more than one category.

That last point matters for combined data. Suppose a dataset contains covered personal identifiers and personal health data linked to the same people. If the health component reaches its lower category threshold, the combined collection may be assessed using that lower applicable threshold rather than the higher identifier threshold. This does not mean that any combination automatically becomes covered. It means that the categories must be evaluated together when the transaction exposes them together. Separate database teams can therefore produce a misleadingly reassuring answer if each team counts only the fields it owns.

A useful inventory should preserve the facts behind a count. It should say whether the number refers to unique U.S. persons or devices, whether duplicate records were removed, which period was measured, which foreign person or covered person is relevant to aggregation, and which data fields caused a category to be selected. This is not bureaucratic detail for its own sake. If a decision is later questioned, a bare statement such as “we do not have bulk data” cannot show how the company reached that conclusion or whether it counted the right unit.

The threshold analysis also interacts with how a product exposes data. A mobile application might hold precise geolocation for 1,200 U.S. devices but expose only aggregate statistics to an advertising partner. The aggregation may reduce what the partner can learn, yet the business still has to examine the data it maintains and the capability the transaction creates. If a second system supplies identifiers or a description that links the records to individuals or a sensitive population, the data-side picture changes again. The right conclusion cannot be drawn from the product’s marketing phrase “aggregated analytics” without examining the fields, linkage, and access path.

There is a second route into the program that does not depend on a bulk threshold. Government-related data includes precise geolocation data for locations enumerated on the government-related location list, regardless of volume. It also includes sensitive personal data that a transacting party markets as linked or linkable to current or recent former employees or contractors, or former senior officials, of the U.S. Government, including the military and Intelligence Community. In these situations, the way the data is characterized and connected to government-related people or places can matter as much as its count.

That distinction changes how a company should approach inventory. A small set of location records might be important if it corresponds to a listed government-related area. A dataset that contains ordinary-looking personal attributes might become government-related if it is marketed as identifying military personnel or former officials. “Small” and “ordinary” are not reliable substitutes for the regulatory definitions.

Access, linkage, and description can change the category

The DSP’s data analysis cannot be separated from the capability a transaction creates. The regulation defines access broadly as the logical or physical ability to obtain, read, copy, decrypt, edit, divert, release, affect, alter, view, or receive information. The ability can exist through information systems, information-technology systems, cloud-computing platforms, networks, security systems, equipment, or software. A recipient does not have to receive a neatly exported spreadsheet for the access question to arise.

That breadth matters for technical design. A cloud administrator may be able to retrieve records even if no routine workflow sends them a file. An application may allow queries that expose information from a dataset. A software component may transfer identifiers to a third party. An employee’s role may include rights to inspect or transmit records. In each example, the relevant fact is the capability made available through the arrangement, not the organization’s preferred description of the system.

The rule also separates the existence of access from the effect of security measures when deciding whether a transaction is covered. Encryption, pseudonymization, de-identification, and anonymization can be important safeguards, but the definition of bulk U.S. sensitive personal data does not remove data merely because it is stored in one of those forms. Likewise, the regulation says that access is determined without regard to the application or effect of security requirements. A control may reduce the risk that a recipient can use the access, and later may be required to authorize a restricted transaction, but it does not make the original access fact vanish.

This is easier to understand if “data” is treated as a relationship rather than as a pile of fields. Covered personal identifiers often depend on linkage. A single listed identifier in isolation may not satisfy the definition. When it is combined with another listed identifier, or with other data disclosed in the transaction so that it is linked or linkable to sensitive personal data, the result can be different. A device identifier paired with an address, an account identifier paired with a name, or a location record described as belonging to a particular sensitive population may tell the recipient much more than either field conveys alone.

The transaction’s description can be part of that relationship. Suppose a company sells a list of addresses and describes them as the homes of active-duty military officers. The addresses are no longer being presented as generic geography; the description connects them to a government-related population. The same reasoning applies to a list of device identifiers described as coming from people who frequent a particular government building. The disclosure can make records linked or linkable even when the fields look incomplete when viewed in the company’s internal schema.

The practical inventory should therefore record more than table names or broad data labels. At minimum, it should answer six connected questions:

  1. Which DSP category or categories could describe the data?
  2. How many U.S. persons or devices are represented in each category?
  3. What is the relevant twelve-month period, and have separate transactions been aggregated?
  4. Which fields are linked, linkable, or combined with information disclosed by a counterparty?
  5. Is the data tied to a listed government-related location or marketed as connected to current or recent former government personnel?
  6. What logical or physical capabilities would the proposed recipient have through systems, software, cloud services, networks, or people?

The sixth question is intentionally beside the first five. A company may possess data that meets a definition but never create the type of access covered by a particular transaction. Conversely, an organization may describe a transfer as “metadata only” or “service access” even though the recipient can use the system to view or receive protected information. The inventory should make that difference visible before a contract is approved.

classDiagram class DataSet class SensitivePersonalData { identifiers geolocation biometric human_omic health financial } class GovernmentRelatedData { listed_location government_person_link } class BulkThreshold { preceding_12_months persons_or_devices } class Linkage { linked_or_linkable } class AccessContext { logical_or_physical system_cloud_software } DataSet <|-- SensitivePersonalData DataSet <|-- GovernmentRelatedData SensitivePersonalData --> BulkThreshold : category and count SensitivePersonalData --> Linkage : combination matters GovernmentRelatedData --> Linkage : description can connect DataSet --> AccessContext : capability to obtain or view AccessContext --> BulkThreshold : security does not erase status

The diagram captures a sequence of reasoning, not a claim that every dataset follows one identical path. A sensitive-data category may require a bulk check; government-related data can enter through a listed location or a government-person connection regardless of volume. Linkage can change the meaning of fields. Access describes what a recipient can do through the surrounding system. Security remains relevant, but it is not a shortcut around classification.

There are important limits to this inventory. The listed thresholds do not replace the full definitions and exclusions in Part 202. An ordinary name, address, or contact field is not automatically a covered personal identifier merely because it belongs to a person. A government-related location list must be consulted rather than inferred from a general sense that a place is important. And the facts must be connected to the specific transaction and counterparty; data classification in the abstract cannot decide the legal outcome by itself.

The central lesson is that the DSP does not ask only whether a company “has sensitive data.” It asks what kind of data is involved, how much exists, how the pieces are linked or described, and what access the transaction creates. Once that data-side record is concrete, the analysis can move to the other side of the connection: whether the foreign entity or individual is a country of concern or a covered person. That counterparty status can change the consequence of the very same data access.

References