Which Regulations Actually Require US-Based Developers? HIPAA, ITAR, CMMC and DoD Cloud Rules Explained

Last updated: September 18, 2026

This article explains how US regulations treat the location and nationality of people who build and maintain software. It is general information, not legal advice. Confirm your own obligations with counsel and with the contracting officer or customer who owns the requirement.

Quick answer: Few US regulations name developer location directly. HIPAA permits offshore work with a business associate agreement. ITAR restricts access by nationality, wherever the person sits. IRS Publication 1075 and DoD cloud rules impose true US-only requirements. In practice, contract terms and state rules restrict offshore work more often than federal statutes do.

The bigger mistake is treating every workload as though it carries the same restriction. That can unnecessarily increase development costs, limit access to talent, and slow delivery.

The better approach is to identify exactly which data, systems, and people are subject to restrictions, isolate that scope where possible, and build your sourcing model around it.

Rule	Does it require US-based developers?	What it actually restricts
HIPAA (health data)	No	Requires a BAA and safeguards; offshore storage and access are allowed but raise your risk analysis burden
ITAR (defense technical data)	No, but it requires US persons	Access by nationality, anywhere on earth, including inside your US office
EAR (dual-use technology)	No, but license may be needed	Release of controlled technology to foreign persons (deemed export)
CMMC / DFARS 252.204-7012 (CUI)	No explicit location rule	Security controls, flow-down to subcontractors, 72-hour incident reporting
DoD cloud (DFARS 239.7602-2, Impact Levels)	Effectively yes for the data	Government data must stay in the US or outlying areas unless approved
IRS Publication 1075 (federal tax info)	Yes	FTI cannot be accessed from offshore, by anyone
CJIS Security Policy (criminal justice info)	Effectively yes	US storage and processing, fingerprint-based screening for unescorted access
FedRAMP (federal cloud)	No personnel rule by itself	Cloud provider authorization and control baseline
PCI DSS (payment cards)	No	Control requirements; no data residency mandate
SOC 2 / ISO 27001	No	Voluntary audit frameworks, not law
State contracts (Medicaid, executive orders)	Often yes	Vary by state; some prohibit offshore work or access outright

Two ideas explain most of this table. Some rules restrict where data lives. Others restrict who may see it. Only a few do both, and the ones people fear most often turn out to be the second kind.

Before deciding where developers should sit, answer three questions:

Where can the data live?
Who is allowed to access it?
What does the contract require?

Those answers determine your actual sourcing options.

No. HIPAA does not prohibit health data from being stored, processed, or accessed outside the United States. HHS’s Office for Civil Rights states plainly that a covered entity or business associate may use a cloud provider that stores ePHI on servers outside the United States, provided a business associate agreement is in place and the HIPAA Rules are otherwise followed.

OCR adds two conditions that matter in practice. First, risks to ePHI may vary greatly by geographic location, and offshore arrangements may raise special concerns about whether privacy and security protections can be enforced. Second, organizations must account for those risks in the risk analysis and risk management the Security Rule already requires.

The result is a practical asymmetry: HIPAA permits offshore development, but you keep the liability. If an offshore subcontractor mishandles PHI, regulators have limited practical reach over that entity, while the covered entity still faces breach response, notification, and enforcement exposure at home.

HIPAA may permit offshore development, but outsourcing the work doesn’t outsource your responsibility for protecting PHI. If an offshore subcontractor mishandles PHI, the covered entity still faces breach response, notification, and potential enforcement exposure at home. 

Two things that often override HIPAA’s permissiveness:

• Your customer’s contract. Health plans, hospital systems, and payers routinely write US-only clauses into vendor agreements. That obligation is contractual, not statutory, and it binds you the same way.
• State Medicaid rules. Several states restrict or forbid offshore handling of Medicaid data. Texas’s Uniform Managed Care Contract, for example, prohibits work being performed or information maintained outside the United States, and Ohio executive orders have barred executive agencies from contracting for services performed offshore, extending to subcontractors. Check the state before assuming the federal answer applies.

ITAR is the rule most often misunderstood, because it restricts people, not places.

Under 22 CFR 120.50, an export includes releasing or transferring technical data to a foreign person inside the United States. That is a “deemed export.” The same section adds that such a release is deemed an export to every country in which that person holds, or has held, citizenship or permanent residency.

Three consequences follow, and they surprise people every time:

1. An onshore team is not automatically compliant. A developer working in your Denver office who is not a US person can trigger a violation by viewing controlled technical data, without a byte crossing a border.
2. A US person working abroad is not automatically a violation. Nationality drives the analysis, though sending data abroad raises separate questions.
3. Current citizenship is not the whole question. Because the rule reaches prior citizenship and residency, an HR field showing today’s nationality is not sufficient evidence.

A “US person” under ITAR includes US citizens, lawful permanent residents, and certain protected individuals such as refugees and asylees. Verification, not assumption, is the standard. And the exposure is significant: civil penalties are adjusted annually for inflation and stood at roughly $1.27 million per violation under the January 2025 adjustment, or twice the transaction value, with criminal exposure on top.

For software teams, the practical implication is that ITAR compliance is an access-control problem. Repository permissions, namespace boundaries, environment separation, and screen-sharing discipline are some of the practical controls organizations use to prevent unauthorized access.

An HR policy stating that only US persons may work on a program documents the intent. Your technical controls help enforce it.

The EAR works similarly for dual-use technology: releasing controlled technology to a foreign person is treated as an export to that person’s country, though the licensing analysis and control lists differ.

Not directly. CMMC is a control-verification program layered onto DFARS clauses. It tells you how to protect Controlled Unclassified Information, who must be assessed, and what to report. It does not, by itself, contain a rule saying engineers must sit in the United States.

What does constrain location is the data itself. If the CUI in scope includes export-controlled technical data, ITAR or EAR rules apply on top of CMMC, and those are nationality-based. If the work runs in a DoD cloud environment, the residency rules in the next section apply. A contractor can be fully CMMC-compliant and still commit an export violation.

Where CMMC stands as of September 2026

This is the part most published guides get wrong, because the program moved twice in 2026.

• November 10, 2025: the DFARS rule took effect and Phase 1 began, putting Level 1 and Level 2 self-assessment requirements into applicable solicitations.
• July 13, 2026: the Department suspended Phase 2, which would have required third-party C3PAO certification starting November 10, 2026. Phases 3 and 4 were frozen with it, and a CMMC Reform Task Force began a 60-day review.
• September 2026: a class deviation made the suspension binding on contracting officers. The task force’s recommendations went to the CIO around mid-September and had not been made public as of this article’s date.

Nothing else paused. DFARS 252.204-7012, NIST SP 800-171, SPRS scoring, and the annual affirmation by a named senior official all remain in force, and an inaccurate affirmation still carries False Claims Act exposure. If you were planning your staffing around the November 2026 certification date, the date moved; the security obligations did not.

Yes, for the data. DFARS 239.7602-2 requires cloud service providers to keep all government data that is not on DoD premises within the 50 states, the District of Columbia, or US outlying areas, unless the authorizing official approves otherwise, with written notice from the contracting officer when an exception applies.

Above that sit the DoD cloud Impact Levels, which scale with sensitivity:

Impact Level	Data type	Practical effect on teams
IL2	Public or non-critical unclassified	Standard commercial cloud, FedRAMP Moderate baseline
IL4	CUI that is not national security information	US facilities, personnel screening, NIPRNet connectivity via a cloud access point
IL5	Higher-sensitivity CUI and unclassified national security systems	US-located, dedicated infrastructure and stricter personnel requirements
IL6	Classified up to SECRET	Dedicated classified environments; access limited to cleared US citizens

A terminology trap worth avoiding: IL5 and “Secret” are not the same thing. IL5 is a cloud environment level for controlled unclassified information and unclassified national security systems. Classified information up to SECRET sits at IL6, and “Secret” is a personnel clearance held by a person, not a level assigned to a system. Vendors mix these up constantly. Government buyers notice.

Two frameworks impose the plain prohibition people mistakenly attribute to HIPAA.

IRS Publication 1075: federal tax information

Publication 1075 governs federal tax information held by federal, state, local, and tribal agencies and their contractors. The IRS’s own contractor guidance requires certification that contractor personnel accessing FTI and the systems containing it are all located within the United States or its territories, because FTI is not allowed offshore. Publication 1075 carries a dedicated Offshore Operations section.

If your product touches FTI, whether through a state revenue agency, a health and human services eligibility system, or a child support program, the answer is unambiguous: US-located personnel and US-located systems, with the certification in the contract.

CJIS: criminal justice information

The FBI’s CJIS Security Policy requires that criminal justice information be stored and processed within the United States, and it requires state and national fingerprint-based background checks for anyone with unescorted access to unencrypted CJI, including contractor and cloud provider staff. Private contractors handling CJI also sign the CJIS Security Addendum. Version 6.0, released in December 2024, restructured the policy around NIST SP 800-53 Rev 5.

For a development team, CJIS turns into a screening and access-boundary problem rather than a pure location problem, but the combined effect is that offshore development staff rarely qualify.

Assumption 1: “We’re in healthcare, so our developers must be US-based.” HIPAA says otherwise. Your customer contract, your state’s Medicaid rules, or your own risk appetite may require it. Those are real reasons. HIPAA is not one of them, and confusing the two leads teams to over-restrict some work while under-controlling the access that actually matters.

Assumption 2: “Our team is all onshore, so we’re ITAR-compliant.” Location is not the test. A non-US person with repository access in a US office is the classic deemed-export scenario. The question to answer is who has access, verified by documentation, not where their desk is.

Assumption 3: “FedRAMP or SOC 2 covers us.” FedRAMP authorizes a cloud service’s control baseline; it is not a personnel rule and it is not a certification that your organization is compliant. SOC 2 and ISO 27001 are voluntary audit frameworks, not law, and neither satisfies CMMC, IRS 1075, or CJIS. They are useful evidence, not substitutes.

The goal isn’t to make your entire development organization comply with the strictest requirement anywhere in your environment. It’s to understand your actual obligations, isolate the restricted scope where possible, and apply the right controls to the right work. 

Work through this in order. The answers determine your sourcing options, not the other way around.

1. Inventory the data by category. PHI, CUI, FCI, ITAR or EAR technical data, FTI, CJI, payment card data, and ordinary business data each carry different rules. Most teams discover that only a slice of their system touches the restricted categories.
2. Separate the restricted slice. Environment separation, data minimization, synthetic test data, and tokenization can shrink the scope that needs restricted staffing. This is usually the highest-leverage architectural decision available.
3. Read the contract before the regulation. Customer agreements, prime contract flow-downs, and state terms are frequently stricter than federal law and are what you will actually be audited against.
4. Verify people, not just places. For ITAR or EAR scope, document US-person status. For CJIS, complete fingerprint-based checks. For clearance work, verify the clearance and its level.
5. Enforce it in the system. Role-based access control, repository permissions, separate environments, logging, and egress rules are what prevent a violation. Policy documents only describe the intent.
6. Decide the sourcing model per workload. Restricted slice onshore with verified personnel; the rest wherever it makes sense on cost and overlap. Compare onshore, nearshore, and offshore models →

How to frame the decision with leadership

We don’t need to choose between compliance and cost efficiency. We need to identify which workloads genuinely require restricted access, enforce those requirements technically, and avoid imposing the same cost structure on work that doesn’t carry the same risk.

That’s an important distinction. Over-restricting the entire development environment can increase costs and constrain talent without meaningfully reducing risk. Under-restricting it can create serious compliance exposure.

The goal is clarity about what is restricted, alignment around how it will be protected, and a delivery model built around those realities.

STG can help you identify which workloads carry real location or personnel restrictions, where stronger controls are needed, and where you may have more sourcing flexibility than you think.

Or explore how STG’s US-based engineering teams support regulated and sensitive workloads.

1. HHS Office for Civil Rights, HIPAA FAQ 2083 - cloud providers storing ePHI outside the US. https://www.hhs.gov/hipaa/for-professionals/faq/2083/do-the-hipaa-rules-allow-a-covered-entity-or-business-associate-to-use-a-csp-that-stores-ephi-on-servers-outside-of-the-united-states/index.html
2. eCFR, 22 CFR 120.50 - ITAR definition of export, including deemed exports. https://www.ecfr.gov/current/title-22/chapter-I/subchapter-M/part-120/subpart-C/section-120.50
3. IRS, 45-Day Notifications - contractor certification that FTI is not accessed offshore. https://www.irs.gov/privacy-disclosure/45-day-notifications
4. IRS Publication 1075, Tax Information Security Guidelines (Offshore Operations section). https://www.irs.gov/pub/irs-pdf/p1075.pdf
5. DFARS 239.7602-2, Required storage of data within the United States or outlying areas. [Editor: link the exact clause page on acquisition.gov]
6. FBI CJIS Security Policy (current version). [Editor: link the current PDF from fbi.gov]
7. Federal News Network, Pentagon suspends CMMC phase two requirements, launches review of program (July 2026). https://federalnewsnetwork.com/cybersecurity/2026/07/pentagon-suspends-cmmc-phase-two-requirements-launches-review-of-program/
8. Nextgov/FCW, CMMC’s Phase 2 suspension locked in with binding regulation (September 2026). https://www.nextgov.com/acquisition/2026/09/cmmcs-phase-2-suspension-locked-binding-regulation/415890/
9. 22 CFR 127.10 - ITAR civil penalties, adjusted annually for inflation.
10. Shumaker, Loop & Kendrick, Offshoring Patient Data: What Health Care Providers Need to Know Now (state Medicaid restrictions). https://www.shumaker.com/insight/offshoring-patient-data-what-health-care-providers-need-to-know-now/

Not sure which category your data falls into? Get a free technology strategy assessment → or see how US-based engineering teams fit regulated work.