Who owns the records when a US subsidiary runs on its parent's systems?

Hosting is not the same as owning

Where a record is stored and who owns it are separate questions. A US subsidiary whose mailboxes sit in the parent's Microsoft 365 tenant, or whose orders run through a group SAP instance, does not hand its records to the parent just because headquarters pays for the platform. The answer turns on who created the records, under whose contracts, and what the group's intercompany agreements say.

US copyright law shows why the paperwork matters. Under 17 U.S.C. 201, copyright vests in the author; for a work made for hire the employer counts as the author and owns the rights unless the parties agree otherwise in a signed writing. Ownership can be transferred in whole or in part, and individual exclusive rights can be transferred and owned separately. Documents written by the subsidiary's employees in their jobs therefore generally start out as the subsidiary's, and an intercompany IP agreement can move some or all of those rights to the parent or to a group IP company.

Much of a business record set is factual rather than creative, and contracts, confidentiality terms and privacy promises often matter more than copyright. That is why rights are checked per system and per entity before any license is offered.

This is general information, not legal, tax or financial advice. Confirm with your own counsel before acting.

Which shared systems raise ownership questions

The more a subsidiary relies on group services, the more of these questions apply.

For code in particular, the guide on who owns code written by offshore contractors covers how assignment terms decide what a company can include.

How are rights checked when more than one entity is involved?

Rights review runs between SourceX, the company and its counsel, not through the partner. In a group it typically has to settle six points:

1. Name the licensing entity. The US company that would sign is identified, along with anyone in the group whose approval it needs.
2. Map systems to entities. The company's data inventory is the natural place to note, for each system, its years of history and which entity's people created the content.
3. Read the intercompany paper. IT services, cost-sharing and IP agreements are checked for who controls, owns or may use the content. Some groups hold IP centrally in the parent or a dedicated IP company.
4. Check outward promises. Customer and supplier contracts, employee notices and privacy policies are reviewed. FTC staff wrote in January 2024 that companies' promises not to use customer data for undisclosed purposes, such as training models, are enforceable. The post is staff guidance, not a rule.
5. Flag cross-border personal data. Records about people in the EU can bring the General Data Protection Regulation into play, and it can apply to organizations outside the EU that offer goods or services to, or monitor the behavior of, people there. A European parent sharing one tenant with its US subsidiary makes this a live question.
6. Agree the scope. What the US company can license goes in; what belongs to the parent, sister companies or customers stays out unless the owner consents. Redaction and de-identification rules are agreed before any work starts.

The company can write down what it will and will not share using the approach in documenting a company's data sharing limits.

When a shared system becomes a red flag

The program's rule is plain: data that belongs to someone else, without that owner's consent, is a red flag. Inside a group it tends to look like this:

• The US entity is a sales branch and its CRM entries are the group's master customer records.
• Most content in a shared site or mailbox was written by headquarters staff.
• An intercompany agreement assigns all IP created anywhere in the group to the parent, and the parent will not consent.
• Group policy prohibits exports from the tenant and nobody can authorize an exception.
• The group has already licensed the same records for AI training.

Most of these can be worked through: a parent that owns the rights can consent, and the scope can be cut back to systems the US company clearly controls. Records already licensed for AI training are different, because an existing license may rule them out, so raise that at the start. Each point needs an answer from the company before anything reaches buyers.

What a partner can usefully ask

You never need to see a record to help. Four questions to the US CFO or IT lead surface most of the issue:

• Which systems does the US company run itself, and which are group services?
• Is there an intercompany agreement covering IT services or IP?
• Can the US company's data be exported on its own, by mailbox, company code or site?
• Who at group level signs off on data matters: the group CIO, general counsel or data protection officer?

Once a company decides to proceed, the data inventory builder helps it list systems and records. For the eligibility side, see whether a foreign-owned US company can be referred.

What it means for your introduction and reward

Shared systems add questions to qualification but do not by themselves rule a company out, and the group's internal approvals are the company's to manage. If your relationship is with headquarters, the group CFO email template raises the subject without asking for a single document.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, payable only after the buyer pays and SourceX receives its fee. If rights review narrows the scope, the deal reflects what the company can actually license, and so does any fee SourceX collects. No reward is guaranteed; the program terms set the details.

Next step

If you know a US subsidiary with years of its own records on group systems, ask the four questions above, then register as a partner and make the introduction.