The DSP Rule does not ban offshore service delivery. It conditions it. Restricted transactions — vendor agreements, employment agreements, and investment agreements that grant covered persons access to bulk US sensitive personal data — can proceed, but only if the US company has done the work to qualify them. The Data Compliance Program has to exist on paper and in operation. The CISA Security Requirements have to be implemented. The contracts have to contain the right safeguards. The annual certification has to be honest. The records have to support the certification under audit.
The work is significant. The companies that started in early 2025 are still iterating. The companies that have not yet started are now operating without a good-faith effort defence, with the annual certification deadline of March 1 each year as a recurring exposure point.
This blog is an eight-step playbook for the workforce and vendor compliance build, sequenced the way the work actually has to be done. Each step covers the obligation, where the typical organisation breaks down, and what compliant operational practice looks like. It is written from the experience of working with multinational clients through the first year of active enforcement.
Step One: Map Your Covered Data
The foundation of every DSP compliance programme is an accurate inventory of where covered data sits inside the organisation. The mapping exercise has to identify each of the six sensitive personal data categories — covered personal identifiers, personal health data, personal financial data, biometric identifiers, precise geolocation data, and human ‘omic data — and track them across systems, business processes, vendors, and cross-border data flows.
For HR and BGV operations, the categories that most commonly appear are covered personal identifiers (any combination of two or more listed identifiers — names plus government IDs, names plus financial account numbers, names plus device identifiers, names plus contact information), personal financial data (compensation, BGV credit reports, expense data), biometric identifiers (identity verification at hire, biometric attendance, biometric authentication), and in some cases personal health data (occupational health, employee wellness programmes, drug testing).
The mapping has to be specific. It needs to identify where each data type is collected, where it is stored, where it is processed, where it is archived, and where it is transmitted across systems and across borders. It needs to capture the volume — for each data category, how many US persons’ records are in scope on a rolling twelve-month basis. And it needs to identify each system, vendor, and data flow that touches the data.
Most organisations doing this work for the first time discover that covered data is more pervasive than they expected, particularly in the HR stack. The ATS, the HRIS, the payroll platform, the BGV vendor systems, the benefits administration platforms, the identity provider, the corporate device management system, the security monitoring infrastructure, and various productivity and collaboration tools all typically touch covered data. The mapping needs to extend to all of them.
Step Two: Map Your Covered Persons Exposure
Once the data is mapped, the parallel exercise is mapping the covered persons exposure across the workforce, vendor, and ownership chain.
For the workforce, the exposure analysis covers: employees who are nationals or residents of countries of concern, contractors and consultants with the same exposure, remote employees in third countries who may be covered persons through their nationality, and personnel in offshore operations or GCCs who may have country-of-concern ties. The analysis is at the individual level. Citizenship, residency, and contractor-of-covered-person status all matter.
For vendors, the analysis covers each vendor relationship and asks: where is the vendor entity organised and headquartered, what is its beneficial ownership structure (50% threshold), what is the workforce composition of the vendor’s personnel who have access to the US company’s data, and what is the structure of the vendor’s own sub-processor chain. For large vendors with global operations, this can be an extended analysis. For smaller vendors, the questions are simpler but still need to be asked.
For ownership and investment, the analysis covers the company’s own equity structure — including indirect ownership through holding companies and investment funds — and identifies any country-of-concern exposure at any level.
The output of this work is a heat map of covered persons exposure mapped against covered data flows. Where the two intersect — covered persons with access (logical or physical) to bulk covered data — restricted transactions exist and require qualification under the rule.
Step Three: Build the Data Compliance Program
The DSP Rule requires every US person engaged in restricted transactions to develop, implement, and routinely update an individualised, risk-based, written Data Compliance Program. The DCP is the central artefact of the company’s compliance posture. The DOJ Compliance Guide sets out minimum content requirements.
The DCP must include due diligence procedures for covered data and counterparties. It must describe the company’s risk assessment methodology and how the assessment informs the specific controls in place. It must document the data security measures applied — mapped to the CISA Security Requirements where applicable. It must include vendor management procedures for screening and ongoing oversight of counterparties. It must include recordkeeping and reporting protocols. And it must include training for personnel whose roles touch restricted transactions or the underlying controls.
The DCP has to be annually certified by an officer, executive, or other employee responsible for compliance. The certification covers the implementation and effectiveness of the programme, the implementation of applicable security requirements, and the completeness and accuracy of the recordkeeping. The certification is an attestation under penalty of law. The signing officer has personal exposure if the certification is false.
For most organisations, the DCP is built in tandem with the data mapping and exposure analysis. The compliance team drafts the programme, the legal team reviews against the rule and FAQs, the security and IT teams contribute the technical controls section, and HR and procurement contribute the workforce and vendor sections. The programme then has to be implemented operationally — not just documented — before the certification cycle requires the signing officer to attest to its effectiveness.
Step Four: Implement the CISA Security Requirements
For restricted transactions to be permissible, the CISA Security Requirements must be in place. The requirements are organised into several layers:
Organisation-level controls include maintaining an up-to-date asset inventory, assigning clear cybersecurity accountability, managing vendors and suppliers, conducting annual risk assessments, and maintaining an incident response plan.
Governance controls include vulnerability management with defined patch and remediation timeframes, and controlled network topology and change management through documented approval processes.
System-level controls include strong access controls (multi-factor authentication or sufficiently strong passwords, deny-by-default access, prompt revocation when access is no longer needed), credential and identity management, and restrictions on unauthorised hardware and software.
Monitoring controls include collection and secure retention of system logs sufficient to provide visibility, audit trails, and accountability.
Change and configuration management controls require approvals for new hardware and software and enforcement of secure default configurations on covered systems.
Data-level controls — the most operationally consequential part of the CISA Requirements — require implementation of a combination of mitigations that together prevent access to covered data by covered persons. The mitigations can include data minimisation (collecting and retaining only the data necessary for the purpose), strong encryption of data at rest and in transit, masking and tokenisation, identity and access management controls that deny access to covered data by covered persons, and architectural segregation of covered data from systems accessible to covered persons.
The data-level controls are where most organisations have to do meaningful redesign work. The historic pattern of giving global teams broad logical access to systems containing covered data, with role-based access controls enforcing data segregation, does not satisfy the CISA Requirements as the DOJ has interpreted them. The architecture has to prevent access at the system level, not just deny it at the data level.
Step Five: Renegotiate Vendor Agreements
The vendor agreement overhaul is one of the most time-consuming parts of the DSP compliance build. Each vendor relationship that involves covered data needs to be reopened and updated with DSP-aligned terms.
The contract should require the vendor to: implement equivalent security safeguards (CISA Requirements or equivalent), restrict access to covered data to non-covered persons, provide structured attestation of the vendor’s own covered persons exposure (workforce, ownership, sub-processors), notify the US company of any change in covered persons exposure, support the US company’s annual reporting and audit obligations, agree to specific data flow limitations and onward transfer restrictions, and accept termination rights if the vendor’s status changes in a way that creates restricted transaction exposure that cannot be remediated.
For large vendors with many US clients, the negotiations have tended to produce a relatively standard set of terms over the course of 2025. For smaller vendors, the work has been more case-by-case. For vendors who cannot or will not adopt DSP-aligned terms, US companies have had to make terminate-or-replace decisions.
The vendor mapping exercise from Step Two surfaces which relationships are highest priority for renegotiation. Vendors with deep covered data exposure and high covered persons exposure get attention first. Vendors with low exposure on both axes can be handled later.
Step Six: Restructure Workforce Geographic and Access Posture
For employment relationships that have become restricted transactions, the company has two paths: bring the relationship into compliance (CISA Requirements, security architecture, recordkeeping) or restructure the relationship to remove the covered persons exposure.
The DOJ’s published examples of good-faith effort include “adjusting employee work locations, roles or responsibilities.” The agency has signalled that companies should expect to make personnel and geographic decisions where the covered persons exposure cannot be efficiently managed through technical controls.
The decisions are operationally consequential and need to be made carefully. Options include: relocating employees who are nationals of countries of concern to roles that do not require access to covered data, restructuring roles to eliminate covered data access for affected personnel, partitioning workforce data so that covered data is accessible only to non-covered persons, terminating remote arrangements that create exposure that cannot be remediated, and in extreme cases, ending employment relationships where no compliant structure is workable.
These decisions intersect with employment law, anti-discrimination considerations, and contractual obligations. The DOJ has been clear that employment-related decisions made in compliance with the DSP Rule are not facially discriminatory, but the implementation needs to be careful and well-documented. Companies typically work this stream with parallel HR, legal, and compliance involvement.
Step Seven: Build the Annual Certification, Reporting, and Audit Infrastructure
The DSP Rule includes several ongoing reporting and audit obligations:
Annual compliance certification, signed by a responsible officer, attesting to the DCP implementation, security requirements, and recordkeeping.
Annual reports on restricted transactions, filed by March 1 each year, describing the transactions engaged in during the prior calendar year. The reports are required if the transaction involves cloud computing services or if 25% or more of the US company’s equity is owned by a country of concern or covered person.
Reports on rejected prohibited transactions, filed within fourteen days of rejection, documenting transactions the company declined to enter into because they would have been prohibited.
Annual audits of restricted transactions, conducted by an independent auditor against the DCP and the CISA Security Requirements.
Recordkeeping covering due diligence, restricted transactions, security implementation, and remediation actions — to be maintained for a minimum of ten years.
Building this infrastructure is the work that most companies underestimate. The annual cycle requires sustained capacity, not just a one-time build. The audit requirements need to be supported by infrastructure that produces evidence on demand. The reporting requires structured data collection across the operating environment, not just retrospective document assembly.
Step Eight: Plan for Designation Expansions and Programme Evolution
The DSP Rule is not static. The list of countries of concern can be expanded by the Attorney General. Specific entities and individuals can be designated as covered persons. The CISA Security Requirements can be revised. The bulk thresholds can be adjusted. The FAQ document has been updated multiple times in 2025 and 2026 with clarifications and operational guidance.
A mature DSP compliance posture includes a forward-looking element: someone in the organisation is responsible for monitoring DOJ NSD guidance, FAQ updates, designation announcements, and enforcement patterns; the DCP is reviewed at least annually for needed updates; and the company has a defined approach for incorporating regulatory changes into operations within reasonable timeframes.
For organisations with significant exposure, the forward planning extends to scenario analysis: what would happen if a country in our vendor or workforce mix were added to the list, what would happen if a specific vendor were designated, what is our contingency posture for each high-exposure relationship. The scenario work informs investment decisions about which structural changes to prioritise.
Cross-Functional Ownership
The DSP compliance programme cannot be owned by any single function. The work spans:
Legal — for rule interpretation, contractual work, designation monitoring, and enforcement readiness.
Compliance — for programme design, certification, recordkeeping, and audit oversight.
HR — for workforce mapping, role restructuring, and personnel decisions.
Procurement and vendor management — for vendor due diligence, contract overhaul, and ongoing oversight.
IT and security — for data mapping, CISA Security Requirements implementation, and technical controls.
Finance — for ownership analysis and financial reporting integration.
Executive sponsorship — for the cross-functional alignment, resource allocation, and ultimate certification signing.
The organisations that have completed the first year of compliance successfully are the ones that constituted a standing programme office with explicit cross-functional ownership and senior sponsorship. The organisations that tried to run the work as an ad hoc project, owned by a single function with informal cooperation from others, have generally produced paper compliance that will not survive audit.
What Forward Looks Like
The DSP Rule has fundamentally changed the calculus of offshore workforce and vendor decisions. Decisions that were once made on cost and capability are now also made on structural compliance posture. The vendors who internalised this in 2024 and rebuilt their structures, workforces, and certifications to match are now competing for higher-value work. The vendors who did not are gradually being screened out of US client relationships where DSP exposure is material.
For US companies, the work of building, operating, and continuously updating a real Data Compliance Programme is no longer optional. The grace periods are over. The annual certification clock runs to March 1 each year. The criminal exposure for willful violations and false certifications is personal to the signing officers. Enforcement is active.
The right time to have started this work was early 2025. The next-best time is now. The companies that get to a defensible DSP posture in 2026 will be the ones that treated the rule as a structural change to how they operate, not as a documentation exercise to satisfy. The work is not small. It is unavoidable.
AMS Inform provides background verification and workforce screening services across 160+ countries, with operations structured and documented to support clients’ DSP Rule compliance requirements. For US organisations building or pressure-testing their workforce and vendor compliance posture, visit AMSinform.com to speak with our team.
