DHS Imposes New Security Requirements for Restricted Transactions

For years, companies treated cross-border data access mainly as a privacy, contracting, and cybersecurity issue. The federal government has now added another label to the folder: national security. Under the Department of Justice’s Data Security Program, certain transactions involving sensitive American data may be prohibited outright, while others may proceed only when organizations satisfy detailed security requirements developed by the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency, better known as CISA.

The requirements affect far more than companies that describe themselves as data brokers. A healthcare provider using an overseas technology contractor, a software company employing engineers abroad, or a business granting an investor technical access could all face questions under the new framework. In regulatory terms, “we only gave them a login” is not the comforting sentence it once was.

The Data Security Program took effect on April 8, 2025. Additional due-diligence, auditing, reporting, and compliance-program obligations became effective on October 6, 2025. The CISA security requirements are incorporated into the federal regulations, meaning an organization cannot replace them with a homegrown control package simply because its chief technology officer thinks the alternative is “basically the same thing.”

Why DHS Created Security Requirements for Restricted Transactions

Executive Order 14117 directed the federal government to address the risk that countries of concern could acquire and exploit bulk U.S. sensitive personal data or certain government-related information. That data may support espionage, surveillance, blackmail, cyber operations, military planning, artificial intelligence development, or efforts to identify government personnel and other strategically valuable individuals.

Unlike an ordinary consumer privacy rule, the program is not primarily concerned with whether a person clicked “accept” on a privacy notice. Its central question is whether a transaction could enable a country of concern or covered person to access strategically significant American data. DOJ has described the framework as functioning much like an export-control regime for data.

DHS, acting through CISA, was assigned the technical side of the project. CISA developed organizational, system-level, and data-level safeguards intended to reduce the risk created by transactions that are restricted but not categorically banned. DOJ then incorporated the January 2025 version of those requirements into 28 C.F.R. Part 202.

What Counts as a Restricted Transaction?

A restricted transaction is generally a covered data transaction involving a vendor agreement, employment agreement, or investment agreement with a country of concern or covered person. The transaction may proceed only when the U.S. person complies with the CISA security requirements and the other applicable provisions of the Data Security Program.

Vendor agreements

A vendor agreement may include cloud hosting, software development, IT support, data analytics, customer service, cybersecurity monitoring, payroll processing, or other services that permit access to covered systems or data. The vendor does not necessarily need to download a database. Administrative access, remote troubleshooting privileges, or the ability to view records through an application may be enough to trigger a review.

Employment agreements

Employment relationships can become restricted transactions when an employee who qualifies as a covered person receives access to government-related data or bulk U.S. sensitive personal data. This makes workforce geography, remote-access privileges, job duties, and reporting structures relevant compliance factors. Human resources and cybersecurity teams may suddenly discover that they have been in the same movie all along.

Investment agreements

An investment can raise concerns when it conveys data access, governance rights, technical visibility, board participation, or other privileges to a covered person. Passive ownership and transactions already subject to certain CFIUS actions may receive different treatment, but companies should not assume that every investment exemption applies automatically.

The federal rule distinguishes restricted transactions from prohibited ones. Data brokerage involving a country of concern or covered person is generally prohibited, as are covered transactions involving bulk human genomic data or human biospecimens from which such data could be derived. Vendor, employment, and qualifying investment agreements are the principal restricted categories.

Which Countries and People Are Covered?

The designated countries of concern are China, including Hong Kong and Macau; Cuba; Iran; North Korea; Russia; and Venezuela. A covered person may include an entity organized in or principally operating from one of those jurisdictions, an individual who primarily resides there, certain employees or contractors of covered entities, entities owned 50 percent or more by covered persons, and individuals or organizations separately designated by the Attorney General.

That definition requires more than checking a supplier’s mailing address. Ownership, control, employment, residency, subcontracting, and access arrangements may all matter. A vendor incorporated in a neutral country may still present risk if it is owned by a covered entity or relies on personnel located in a country of concern.

What Data Falls Within the Program?

The framework covers specified U.S. government-related data and several categories of bulk U.S. sensitive personal data. These categories include precise geolocation information, biometric identifiers, personal health data, personal financial data, covered personal identifiers, and human genomic or other covered human “omic” data.

Different data categories have different bulk thresholds. Some government-related information is protected without a numerical threshold, particularly information associated with sensitive government locations or personnel. Companies must also consider whether several datasets can be combined, linked, or inferred to reach a regulated category.

The rule does not establish a universal data-localization mandate. Covered information is not automatically required to remain physically inside the United States. Instead, the regulations focus on defined transactions, counterparties, access, data volumes, exemptions, and risk-mitigation controls.

The Organizational and System-Level Security Requirements

Organizations engaging in restricted transactions must implement mandatory controls around the covered systems that interact with regulated data. A covered system can include an information system used to obtain, read, copy, decrypt, edit, view, collect, process, maintain, share, or dispose of covered data during a restricted transaction. The definition may therefore reach servers, cloud environments, databases, identity platforms, administrative tools, and supporting network infrastructure.

Governance and accountability

An organization must designate an individual responsible for cybersecurity and for governance, risk, and compliance functions. This is not merely a ceremonial title created five minutes before an audit. The responsible person needs authority, access to relevant information, and a workable process for coordinating legal, security, procurement, privacy, human resources, and business teams.

Asset and network visibility

Covered-system assets must be identified, prioritized, and documented. Detailed inventories for relevant IT assets must be updated regularly, including monthly updates for specified information. Organizations also need accurate network topology documentation showing covered systems and, where technically feasible, networks that interface with them.

This requirement can expose an uncomfortable truth: many companies know which laptops they purchased but not which service accounts, application programming interfaces, data pipelines, backup repositories, or subcontractors can reach regulated information.

Vulnerability management

Known exploited vulnerabilities affecting covered systems must be addressed according to CISA’s required process. The final requirements generally call for remediation within 45 calendar days, prioritizing the most critical assets, while permitting documented compensating controls in appropriate circumstances. A vulnerability ticket labeled “circle back next quarter” is not a mitigation strategy.

Identity, credentials, and access

Organizations must enforce multifactor authentication on covered systems or use prescribed strong-password protections when multifactor authentication is not technically feasible. Credentials and access rights must be promptly revoked when a person leaves a role or no longer requires access.

Covered systems should also deny connections by default unless a connection has been specifically authorized. Identity and access management configurations must prevent countries of concern and covered persons from receiving prohibited access to covered data.

Logging and incident response

Access and security-event logs for covered systems must be centrally collected and securely retained for at least 12 months. Organizations need alerting procedures for situations in which critical log sources stop generating or retaining records. Incident response plans applicable to covered systems must be maintained and reviewed at least annually.

Vendor and technology controls

Companies must document vendor and supplier agreements affecting covered systems, including relevant cybersecurity and information-technology provisions. They must also maintain risk-informed approval processes for hardware, firmware, and software deployed on those systems. These controls are summarized consistently across CISA implementation analyses and professional compliance guidance.

Data-Level Requirements: Protecting the Information Itself

The data-level controls provide more flexibility, but flexibility should not be confused with optional compliance. Organizations must select a combination of safeguards that, based on a documented risk assessment, effectively prevents a country of concern or covered person from accessing covered data in a linkable, identifiable, unencrypted, or readily decryptable form.

Data minimization and masking

Businesses should reduce the amount of covered data made available and remove fields that are not necessary for the transaction. Aggregation, masking, pseudonymization, de-identification, and anonymization may help, but the result must resist re-identification and inference when combined with other information available to the organization or recipient.

A written retention and deletion policy is also important. Keeping twelve years of customer records “because storage is cheap” becomes less charming when the data creates national-security compliance obligations.

Comprehensive encryption

Covered data used in a restricted transaction should be encrypted both in transit and at rest. Encryption keys must be properly managed and kept beyond the access of covered persons. Storing the encrypted database and the decryption key in the same foreign administrator’s account is the digital equivalent of locking the door and taping the key to the handle.

Privacy-enhancing technologies

Organizations may use technologies such as differential privacy, secure multiparty computation, or homomorphic encryption where appropriate. These approaches can allow useful analysis while limiting disclosure of the underlying records. However, covered persons should not occupy trusted roles that allow them to defeat the privacy-preserving design or reconstruct protected information.

Access-management restrictions

Identity and access management controls can be used to deny covered persons authorized access to regulated data while permitting them to perform unrelated functions. For example, an overseas developer might be allowed to work with synthetic test data while being technically blocked from the production environment containing American health records.

CISA’s framework allows organizations to combine these approaches according to risk, but basic compliance with the NIST Cybersecurity Framework does not automatically establish compliance with the transaction-specific requirements.

Due Diligence, Audits, and Recordkeeping

Security controls are only one portion of the compliance package. A U.S. person engaging in restricted transactions must maintain a risk-based data compliance program. The program should include written policies, procedures for verifying data flows, counterparty screening, transaction review, security-control documentation, employee training, and processes for escalating suspicious or noncompliant activity.

An independent auditor must examine restricted transactions for each applicable calendar year. The auditor may be internal if sufficiently independent and qualified, but cannot be a covered person. The audit must evaluate the data compliance program, required records, security requirements, control effectiveness, vulnerabilities, deficiencies, and failures that could permit unauthorized access.

Organizations must also create and preserve auditable records concerning restricted transactions. Relevant documents can include contracts, transaction descriptions, data types and volumes, counterparty information, security measures, risk assessments, audit reports, and annual certifications. Records generally must be retained for 10 years, so “we changed ticketing systems and lost the evidence” is unlikely to earn applause.

A Practical Compliance Roadmap

The most effective approach begins with data and access rather than with a generic policy template. Organizations should first identify sensitive American datasets, determine their volumes, map where they are stored, and document which systems interact with them.

Next, companies should identify foreign access. That review should cover employees, contractors, vendors, cloud administrators, parent companies, affiliates, investors, subprocessors, support teams, and anyone capable of reaching production systems. Legal and procurement teams can then classify the relevant arrangements as data brokerage, vendor, employment, investment, exempt, prohibited, restricted, or outside the rule.

Security teams should compare covered systems against every CISA requirement, not merely against a broad framework certification. Gaps should be assigned owners, deadlines, evidence requirements, and escalation procedures. Contract templates should address access restrictions, subcontractors, cooperation with audits, logging, security controls, breach notification, and termination rights.

Finally, the company should test the program. A tabletop exercise can reveal whether the organization can actually suspend a covered user’s access, trace affected data, preserve records, notify leadership, and determine whether a report or voluntary disclosure is appropriate.

Implementation Experience: What the Requirements Look Like in Practice

Organizations working through the restricted-transactions framework often discover that the hardest problem is not encryption or multifactor authentication. It is determining who can access what. The first project meeting may begin with a confident statement that no sensitive information is accessible from a country of concern. Twenty minutes later, someone remembers a global help desk, a legacy cloud account, an overseas quality-assurance team, and a contractor who still has administrator privileges from a migration completed three years ago.

A productive implementation exercise usually starts with a narrow pilot. Consider a fictional U.S. healthcare software company that stores bulk patient information and uses a foreign development vendor. Rather than attempting to map every byte in the enterprise, the company selects one product environment, identifies the databases containing U.S. health data, lists the systems that interact with those databases, and reviews every human and machine identity with potential access.

The review finds that foreign developers cannot query the production database directly, which sounds promising. However, they can view application logs containing patient identifiers, copy production records into support tickets, and request temporary administrator access during outages. The lesson is important: access pathways frequently hide in operational processes rather than in the main database permissions.

The company then redesigns support procedures. Production logs are filtered and masked before reaching the foreign team. Support tickets automatically remove regulated fields. Development uses synthetic records. Emergency access requires approval from a U.S.-based security manager, expires automatically, and is recorded in a centralized logging platform. Encryption keys remain under the control of authorized U.S. personnel.

Procurement also revises the vendor agreement. The contract limits subcontracting, defines permitted personnel and locations, requires cooperation with audits, mandates prompt notification of access changes, and allows termination when the vendor cannot maintain required safeguards. These terms do not replace technical controls, but they give the company leverage when operational reality starts wandering away from the compliance plan.

Another common experience involves employee mobility. A worker hired in one country may relocate, begin an extended assignment, or access systems while traveling. If the organization screens only at onboarding, its original risk assessment may become stale. Mature programs therefore connect human-resources updates with identity governance, access reviews, and compliance screening.

Documentation is another practical challenge. A company may have strong security but weak evidence. An auditor cannot reliably verify a monthly inventory that exists only as an administrator’s memory, nor can the company demonstrate timely credential revocation without logs or tickets. Successful programs treat evidence generation as part of the control: inventories are timestamped, approvals are retained, access reviews are signed, vulnerability exceptions are documented, and risk decisions identify responsible officials.

The most durable takeaway is that restricted-transaction compliance works best as an operating system, not a one-time project. Data changes, vendors add subprocessors, employees move, networks evolve, and software quietly grows new integrations. Regular reviews, automated access controls, contract governance, and reliable audit trails keep the program aligned with those changes.

Conclusion

DHS and CISA’s security requirements transform certain cross-border data arrangements from routine commercial decisions into regulated national-security transactions. Organizations dealing with sensitive American data must understand their information, counterparties, systems, access paths, contracts, and technical safeguards.

The rule does not require every company to seal its servers in a bunker beneath a cornfield. It does, however, demand measurable controls, informed risk decisions, documented due diligence, and evidence that covered persons cannot obtain impermissible access. Companies that map their data early and integrate legal, security, procurement, and workforce processes will be better prepared than those relying on privacy notices, vague vendor promises, and crossed fingers.

Note: This article synthesizes information from U.S. government regulations, DHS/CISA materials, DOJ implementation guidance, federal cybersecurity frameworks, and professional legal and security analyses. It provides general educational information and is not legal advice.