Understanding the Department of Justice (DOJ) Data Security Program

Understanding the Department of Justice Data Security Program

On April 8, 2025, the National Security Division (NSD) of the US Justice Department (DOJ) implemented the Data Security Program (DSP). The DSP addresses threats outlined by the 2024 Executive Order “Preventing Access to Americans’ Bulk Sensitive Personal Data and United States Government-Related Data by Countries of Concern.” According to the DOJ, the DSP established export controls that seek to prevent access to bulk genomic, geolocation, biometric, health, financial, and other sensitive personal data by foreign adversaries and those subject to their control, jurisdiction, ownership, and direction.

While organizations needed to comply with most of the DSP’s requirements as of the April 2025 implementation, the document noted that subsection J focused on due diligence and audit requirements would become enforceable no later than October 6, 2025.

With this new regulatory requirement, organizations should consider their current compliance programs and data sharing activities to determine whether they need to implement additional controls or processes to comply with DOJ Data Security Program requirements.

 

What is the DOJ Data Security Program (DSP)?

The NSD implemented the DSP under 2024’s Executive Order 14117 “Preventing Access to Americans’ Bulk Sensitive Personal Data and United States Government-Related Data by Countries of Concern.” The DSP seeks to address how foreign adversaries use commercial activities to access, exploit, and weaponize US government-related data and bulk sensitive personal data.

The order issues regulations that prohibit or otherwise restrict the transactions that create these risks, seeking to create export controls around data. People or entities that conspire or seek to evade the restrictions or prohibitions could be subject to criminal or civil penalties.

Under the DSP, people and organizations should “know their data,” including the following:

  • Data types and volumes about or maintained on US persons or US devices.
  • Data usage.
  • Engagement in covered data transactions.
  • Ways they market data, especially as regards current recent or former employees, contractors, or former senior officials across the US government, including the military and intelligence community.

 

What are Countries of Concern and Covered Persons?

The DSP explains that countries of concern have demonstrated and intent and capabilities to weaponize US government-related and Americans’ sensitive personal data to threat national security. Additionally, the regulation outlines classes of covered persons, defined as individuals or entity that, whether nor not publicly designated by the DOJ fall into one of the following categories:

  • Foreign entities headquartered in or organized under a country of concern’s laws, including those with 50% or more owned individually or in the aggregate by covered persons or countries of concern.
  • Foreign entities with 50% or more ownership individually or in the aggregate by a country of concern or other covered person.
  • Foreign individuals that are employees or contractors of a country of concern or covered person.
  • Foreign individuals primarily residing in a country of concern.

 

What Type of Data Falls within the DSP?

The DSP defines the following data types that fall within the compliance requirements:

  • Sensitive personal data: personal identifiers, precise geolocation data, biometric identifiers, human ‘omic data, personal health data, personal financial data, or any combinations of these data types.
  • Government-related data: any amount of precise geolocation data for any location listed on the Government-Related Data List, including worksite or duty stations, military installations, facilities, or locations supporting national security, defense, intelligence, law enforcement, or foreign policy missions and any sensitive personal data linked or linkable to current or recent former employees or contractors, or former senior officials, of the United States Government, including the military and Intelligence Community.
  • Covered personal identifiers: any listed identifier in combination with either another listed identifier or other data disclosed by a transacting party as part of the transaction that makes the listed identifier linked or linkable to other listed identifiers or other sensitive personal data.

 

Many data types listed as sensitive personal data in the DSP correlate to other data protection regulations, like financial data or health information. However, organizations should be aware of these newer data classifications specifically outlined in the DSP:

  • Human biospecimens: quantities of tissue, blood, urine, or other human-derived material when used for purposes other than diagnosing, treating, or preventing any disease or medical condition.
  • Human ‘omic data: human genomic data, human epigenomic data, human proteomic data, and human transcriptomic data when not part of pathogen-specific data embedded in human ‘omic datasets.

 

How does the DSP Define Covered Transactions and Prohibited Transactions?

Covered transaction are any transactions that involve a country of concern or covered person having any access to any government-related data or bulk US sensitive personal data prohibits the following data transactions with:

  • Data brokerages.
  • Vendor agreements.
  • Employment agreements.
  • Investment agreements.

 

Prohibited transactions are any data transaction subject to one or more of the following:

  • Prohibited data-brokerage transactions: data transactions that involve data brokerages with a country of concern or covered person or transactions where any foreign person accesses government-related data or bulk US sensitive personal data unless the initial transaction contains a contractual obligation to prevent sharing covered data with countries of concern or covered persons.
  • Prohibited human `omic data and human biospecimen transactions: knowing engaging in any covered data transaction with a country of concern or covered person that involves their ability to access bulk human `omic data, or to human biospecimens from which bulk human `omic data could be derived.
  • Knowingly directing prohibited or restricted transactions: Knowingly engaging in a covered data transaction involving a vendor agreement, employment agreement, or investment agreement with a country of concern or covered person unless the U.S. person complies with the security requirements.

 

What are the requirements for a compliance DSP program?

Under the DSP, organizations must implement a Data Compliance Program that contains, at minimum, the suggested activities:

  • Due diligence: Risk-based procedures for verifying data flows involved in any restricted transactions, including procedures to verify and log types and amounts of covered data involved, entity ownership or citizenship/primary residency of transaction party identities, end-use of data and its data transfer methodology.
  • Vendor management and validation: Risk-based procedures for verifying vendor identities including screening vendors to verify whether current or prospective vendors fall within the definition of covered persons, even as the definition of covered persons changes over time.
  • Written Data Compliance Program policy: Policy and internal controls for the data compliance program and annual certification by appropriate responsible party that reflects daily operations, enables easy compliance, makes compliance straightforward, and prevents employee misconduct.
  • Written Security Requirements Policy: Policy and internal controls as sets for any covered systems listed in the Cybersecurity and Infrastructure Security Agency (CISA) Recur Requirements for Restricted Transactions.
  • Personnel training: At least annual training for all relevant employees to adequately inform and instruct them on how to maintain compliance.
  • Audit: Third-party independent reviews to ensure Data Compliance Program and Security Requirement Policy compliance to be conducted at least once each calendar year.
  • Recordkeeping and reporting: Full and accurate records for each transaction falling within the DSP retained for at least 10 years and annual certification by senior management that includes review of processes for establishing, maintaining, reviewing, testing, and modifying written compliance policies and written supervisory procedures with a report that submitted to the Board of Directors that also indicates any changes in controls or compliance gaps.

 

Best Practices for Implementing and Monitoring Compliance with DSP Security Requirements

The CISA Security Requirements that enable compliance with the DSP outline a series of organizational, system, and data level controls to mitigate risk to covered data.

Implement basic cybersecurity policies and practices

At the organizational and system level, organizations should:

  • Identify, prioritize, and document all assets related to systems that fall within the DSP’s scope.
  • Designate responsible parties who are accountable for cybersecurity and governance, risk, and compliance functions.
  • Remediated known exploited vulnerabilities in internet facing systems with 45 calendar days.
  • Document and maintain all vendor/supplier agreements for covered systems.
  • Develop and maintain accurate network topology for the covered system and when possible any network interfacing with it.
  • Adopt and implement policies for approving new hardware or software for a covered system.
  • Develop and maintain an incident response plan.

 

Network Monitoring

 

Implement logical and physical access controls

At the organizational and system level, organizations should:

  • Enforce multifactor authentication on all covered systems.
  • Promptly revoke individual and shared credentials and any authorized access to covered systems when users change jobs or terminate employment.
  • Collect, secure store, and limit access to logs for covered systems related to access- and security-focused events as necessary for detection and incident response, including but not limited to intrusion detection systems/intrusion prevention systems, firewall, data loss prevention, virtual private network, and detection of unsuccessful login events.
  • Implement secure configurations that deny by default all connections to covered systems and the networks on which they reside.
  • Issue and manage identities and credentials for authorized users, services, and hardware.

 

6.1 Logon Attempts

 

Conduct a data risk assessment

At the organizational and system level, organizations should:

  • Evaluate whether and how to select an overall approach for meeting data-level compliance requirements.
  • Review whether the approach prevents access to covered data that is inkable, identifiable, unencrypted, or decryptable using commonly available technology by covered persons and/or countries of concern.
  • Consider the likelihood of disclosure and the likelihood of harm based on data and transaction types.
  • Include mitigation strategy that outlines implementation to prevent access to the data.

Apply data minimization and data masking strategies

At the data level, organizations should:

  • Reduce the need to collect or sufficiently obfuscate covered data.
  • Maintain and implement a written data retention and deletion policy.
  • Annually review and update the policy as necessary.
  • Process data in a way that renders it no longer covered data or minimizes the linkability to US person entities.
  • Apply techniques like aggregation, pseudonymization, de-identification, or anonymization.
  • Minimize data observability and linkability to ensure no one can infer or extrapolate US person identities from the individual data set or in combination with other data sets that recipients or recipient-linked organizations hold.
  • Base aggregations of covered data on the number of records that designate them as “bulk.”
  • Treat systems implementing these data protection requirements as covered systems.

Apply encryption techniques to protect covered data

At the data level, organizations should:

  • Implement comprehensive data-at-rest and data-in-transit encryption for all covered data in a restricted transaction.
  • Generate and securely manage cryptographic keys used to encrypt covered data.
  • Never colocate encryption keys and covered data.
  • Never store encryption keys virtually or physically in a country of concern.
  • Never authorize covered persons to access encryption keys.
  • Consider and secure all information systems responsible for encryption key storage or access as covered systems.

Apply privacy enhancing technologies or differential privacy techniques to covered data

At the data level, organizations should:

  • Leverage privacy enhancing technologies like privacy preserving computation.
  • Leverage differential privacy techniques, like injecting sufficient noise into data processing to preclude the reconstruction of covered data from the processed data.
  • Ensure covered persons participating in the restricted transaction cannot reasonably use the privacy enhancing technologies to reconstruct covered data, including by linking processed data with other data sets.
  • Consider and secure all information systems responsible for enhancing privacy as covered systems.

Appropriately configure identity and access

At the data level, organizations should ensure that identity and access management techniques deny authorized access to covered data by covered persons and countries of concern within all covered systems.

Anomaly By Username

 

Graylog Security: Enabling Compliance with the DOJ Data Security Program

Graylog Security enables organizations to engage in real-time security monitoring and rapidly investigate potential incidents to manage DSP compliance. With Graylog Security, organizations can streamline their compliance processes while improving their overall security posture.

Using our scalable and customizable detections, security teams can build high-fidelity alerts that reduce alert fatigue and help them focus on the threats that matter most.

To learn more about how Graylog enables strong security outcomes and a lower TCO, contact us today for a demo.

Get the Monthly Tech Blog Roundup

Subscribe to the latest in log management, security, and all things Graylog blog delivered to your inbox once a month.