Taken from Schellman.
Your cloud provider has root access. Your offshore developer has database credentials. Your new AI Agent has been granted unfettered access to millions of personal records. Under the U.S. Department of Justice's (DOJ) new Bulk Data Rule, any one of these connections could trigger a compliance failure, even without a breach.
On April 8, 2025, the DOJ quietly triggered one of the most sweeping data compliance mandates in years. The new Data Security Program (DSP) rule, enacted under Executive Order 14117, gives the DOJ broad authority to restrict or outright prohibit transactions that allow foreign adversaries to access Americans' sensitive data.
This isn't just another checkbox compliance requirement. It redefines national security risk in the context of bulk data exposure, especially when the data can be used to profile, track, or influence U.S. persons.
For IT security leaders and compliance professionals, the implications are immediate and far-reaching. Even if your organization never "sells" data, the way identities interact with sensitive datasets across cloud and on-premise systems may still put you in violation of this rule. That makes identity security not just relevant, but central to maintaining compliance.
Who is subject to the Bulk Data Rule?
The Bulk Data Rule isn't just aimed at Federal agencies or government contractors. It applies broadly to any U.S. organization that collects, processes, or provides access to sensitive personal or government-related data. This includes companies in healthcare, finance, biotechnology, cloud services, data brokerage, and more. You're in scope if your systems contain large datasets tied to U.S. persons or if foreign vendors, cloud operators, or partners can access that data.
The rule applies to U.S. persons and legal entities and covers direct and indirect transactions involving designated countries of concern. Even if your business model doesn't include selling data, access paths via privileged accounts, cloud entitlements, or third-party integrations can all trigger compliance obligations
What the Bulk Data Rule actually says
The rule governs two key types of information: U.S. government-related data and large-scale sensitive personal data sets. The former includes details such as the location of government or military installations and the identities of individuals associated with government functions, and is completely restricted. The latter encompasses data tied to health status, financial information, biometrics, precise location tracking, and similar attributes. The thresholds that trigger regulation are relatively modest. A diagram of a diagram AI-generated content may be incorrect. For instance, a dataset containing a million financial profiles or hundreds of thousands of genetic records could be subject to enforcement.
Consider AncestryDNA, which holds genomic and ancestry data from tens of millions of individuals. If even a portion of that data, such as 100,000 genetic profiles, were made accessible to a third-party vendor affiliated with a foreign adversary, it could trigger scrutiny under the Bulk Data Rule. Likewise, Fitbit and Apple Health collect detailed biometric, health, geolocation, and activity data from millions of users through wearable devices, data that could pose national security concerns if accessed in bulk by entities linked to countries of concern. Similarly, Venmo or PayPal, which process huge volumes of U.S. financial transactions, or credit bureaus like Equifax, which store sensitive financial and identity information, could also fall within the rule's scope if those datasets are accessed or processed through vendors subject to foreign influence.
Moreover, the rule doesn't just ban direct sales of this data. It encompasses numerous forms of data transactions, ranging from licensing arrangements and vendor-managed access to scenarios involving cloud-based services, especially if a "covered person" from a country of concern (like China, Russia, Iran, and others) has access, even if it's incidental.
If your vendor has root access to your database server and happens to be based in or controlled by a foreign adversary, you may already be at risk.
What's the role of identity in bulk data exposure?
At the heart of these risks is one fundamental question: who has access to sensitive data, and under what conditions?
For many organizations, the answer is disturbingly unclear. Privileged accounts with excessive access, misconfigured entitlements in cloud environments, and lax controls over third-party identities can all create exposure paths. Even if your internal security is solid, a compromised identity or an unmonitored service account could be all it takes to violate the rule.
This is where identity security becomes critical. Historically, organizations have focused identity security on human users, such as employees, contractors, and admins. But today's enterprise environment is dominated by non-human identities (NHIs) like application credentials, API tokens, service accounts, and automated scripts. Studies show the ratio of non-human to human identities can be as high as 46:1, creating a vast, often unmanaged attack surface. With the rapid rise of AI, that surface is expanding even further. Organizations are increasingly adopting commercial AI platforms like AWS Bedrock, Azure OpenAI, and Google Vertex AI, and many are beginning to deploy their own AI agents and LLMs on-premises or on VMs in the cloud. These AI workloads require identity, entitlement, and access controls just like human users, yet they are overlooked in traditional access governance models.
Traditional perimeter defenses can't account for insider risk or third-party misuse. Even encryption doesn't help if the threat vector involves an identity authorized to decrypt or access data in bulk. Organizations need a layered approach to securing not just data itself but also the identities that interact with it.
What identity-related risks map to DSP requirements?
Start with privileged access. These accounts often directly access sensitive databases, file shares, or backup systems where bulk data resides. An attacker could exfiltrate data at scale if one of these accounts is compromised or misused. Solutions like Delinea Secret Server and Privilege Control for Servers help limit standing access, enforce just-in-time workflows, and log all access activity for auditability.
Cloud entitlements are another blind spot. Overprivileged roles in AWS, Azure, or GCP often go undetected. DSP violations can happen entirely within cloud platforms if data lakes or storage buckets are accessible through misconfigured policies. Delinea Privilege Control for Cloud Entitlements gives you visibility and control over these risks, ensuring that least privilege is enforced across all identities, human or machine.
Then there are the identities you don't manage directly: vendors, contractors, and service accounts. The rule specifically highlights risks introduced by "covered persons" who may have indirect access to systems or datasets. Delinea Privileged Remote Access and Server Suite supports federated access and ensures these identities and access are properly provisioned, time-boxed, and continuously governed. Identity lifecycle management (joiner/mover/leaver processes) for human users and recertification workflows from Fastpath Access Certification can be key in demonstrating due diligence.
Detection is equally important. Once an identity begins behaving unexpectedly, initiating significant data exports, accessing multiple sensitive systems rapidly, or operating outside normal hours, you need to know quickly. Identity Threat Protection and Privileged Behavior Analytics deliver that visibility, correlating behavior across systems and triggering alerts that can drive incident response or automated revocation of access.
How can identity controls be aligned with DOJ expectations?
The DOJ has clarified that organizations acting in "good faith" to prepare for compliance will be treated more leniently until July 8, 2025. So, enforcement has already begun. By October 6, 2025, additional due diligence, attestation, and auditing requirements kick in. That means the time to map and lock down your identity-to-data access paths is now.
Implementing strong Privileged Access Management (PAM), Cloud Infrastructure Entitlement Management (CIEM), Identity Threat Detection and Response (ITDR), Identity Governance and Administration (IGA), and Governance Risk and Compliance (GRC) isn't just best practice anymore; it's aligned to the risk vectors that DSP is trying to regulate. If you embrace identity security as a foundation for compliance, you will be better positioned to pass audits, respond to enforcement actions, and avoid reputational or legal fallout.
The takeaway is clear. Compliance with the Bulk Data Rule isn't just about protecting data; it's about controlling identity. Identity security isn't optional; it's mission-critical. Now is the time to begin if you're not already on this path.
