Abstract
Multi-site manufacturers replicate their file vaults. An engineer in a remote plant should not wait on a transatlantic fetch for a 400 MB assembly, so a replica sits near them and the platform serves whichever copy is closest. Every major PLM supports this and every infrastructure team treats it as what it plainly is: a latency and availability feature.
It is also something else. A replica in another country is a complete copy of your controlled technical data, in another jurisdiction, created automatically, by a schedule, with no human decision attached to it and usually no record that a specific file moved. Under export-control regimes the controlled act is disclosure or transfer of technical data and the question of whether an automated replication constitutes one is a question most organisations have never asked, because the people who configured the replication were solving a different problem.
This paper argues that vault replication deserves to be treated as a governed data-transfer path rather than as plumbing, sets out why the existing access controls do not see it and proposes a design that keeps the performance benefit without the blind spot.
1. Two teams, two vocabularies, one gap
The gap here is organisational before it is technical.
The infrastructure team specifies replication. Their requirements are bandwidth, recovery point, failover and user-perceived latency. They are measured on uptime. From where they sit, a vault replica is a cache — the same bytes, closer to the user, invisible to the application. Nothing about that framing suggests a compliance review.
The compliance team governs access. Their controls are permissions, role assignments, export-control classifications, licence determinations and non-disclosure agreements. They think in terms of people being granted access to data. A replica grants nothing to anybody, so it does not appear on their map at all.
Both are doing their jobs correctly. The data moved across a border, the controls that exist did not fire and no individual made a decision anyone could later point to. This is the shape of most serious compliance failures: not someone defeating a control, but an activity that falls between two control systems that each assumed the other covered it.
2. Why the usual controls cannot see it
Four reasons, each worth stating separately because each defeats a different control.
Replication runs as the system, not as a user. Access control answers "may this person read this file". Replication is not a person. It runs under a service identity with the standing authority to read everything, because that is precisely what a replica requires. Every permission model described in the access-control comparison is therefore silent on it by construction.
It is configured once and then never reconsidered. A replication relationship is set up during a project, validated, documented in an infrastructure runbook and forgotten. The classification of the data flowing through it changes continuously — a new programme, a new customer, a new restricted project — and nothing re-evaluates the pipe when the content changes character.
It is indiscriminate by design. A replica does not select. The entire vault goes, including the drawings for the one restricted programme that the access model carefully fenced off at application level. The fence stops people. It does not stop bytes.
It leaves no per-file record. Replication logs typically record volumes, durations and errors — operational telemetry. They rarely record which file with which classification arrived in which jurisdiction at what time, in a form anyone could produce in an audit. This is the same architectural blind spot described in the file-audit paper, with one aggravating difference: a download at least has a human behind it who can be asked. A replication has nobody.
3. The question an auditor will actually ask
Not "do you have access controls". They will ask something narrower and much harder:
Is a copy of this controlled drawing held on a server outside the country and if so, under what authorisation did it get there?
Three possible positions when that is asked:
You can answer it. You know which files are replicated where, you can show the authorisation and the replication path is documented as a controlled transfer. Rare.
You cannot answer it but the answer is benign. Nothing restricted is in the replicated vault, you just cannot demonstrate that without an investigation. Common, survivable — and it will cost you weeks and credibility.
You cannot answer it and the answer is not benign. Restricted content is on a replica in a jurisdiction where it should not be, created by a job nobody reviewed. This is a disclosure that already happened and the first time anyone examines it is under adversarial conditions.
The gap between the first and second position is not a technical capability. It is whether anybody ever wrote down which data classes may traverse which replication paths.
4. A design that keeps the benefit
The answer is not to switch off replication. The latency problem is real and a remote plant waiting four minutes for an assembly is a genuine operational cost. The answer is to make replication a governed path rather than an ungoverned one. Four moves, in increasing order of effort.
Classify the pipe, not just the data. Write down, as policy, which classifications may be replicated to which geographies. Do this even before you can enforce it, because a documented rule turns an unexamined default into a decision somebody owns — and that alone changes the answer you give an auditor.
Make replication selective. The decisive technical move is that replication should be a property of the data rather than of the vault. If a file's classification determines whether it is eligible for a given replica, the restricted programme stays home while everything else gets its latency benefit. Platforms vary enormously in how well they support this — and it is a precise and unusually revealing question to put to a vendor: can I exclude a classification from a replication target, by rule, without excluding the whole vault?
Log the transfer as a transfer. Each replicated file, its classification, destination and time, recorded in the same place as your other access evidence rather than in an infrastructure log nobody connects to compliance.
Re-evaluate on classification change. When a part is reclassified as restricted, something should ask whether its file is already sitting on a replica — and if it is, that is an incident to handle rather than a setting to change going forward.
5. Where this bites hardest
Export-controlled programmes. The obvious case. ITAR and EAR concern themselves with technical data crossing borders and with access by foreign persons. A replica is both a border crossing and, potentially, standing access for whoever administers that server.
Data-residency regimes. A growing number of jurisdictions require certain data to remain within national boundaries. Replication is the most likely way an organisation breaches a residency commitment without any individual doing anything wrong.
Customer contracts. Primes increasingly impose where-may-my-data-live terms on suppliers. Those clauses are usually answered from the access model, which cannot see replication, so the answer given during the tender may be sincerely wrong.
Joint ventures and divestitures. When a site leaves the group, the replica at that site is a complete copy of the vault as of the separation date. Whether anyone remembers to decommission it is, in most organisations, a matter of luck.
6. The honest counter-arguments
"The replica is inside our own network, under our own control." Often true and not sufficient. The regimes in question are concerned with location and with who can access data in that location, not with who owns the hardware. Local administrators in that jurisdiction can typically reach the files — and that is the exposure.
"Our data is encrypted at rest." Good and largely beside the point. The system that serves the file to local users must be able to decrypt it, so the capability is present locally. Encryption addresses theft of a disk. It does not address jurisdictional presence.
"We are not aerospace, none of this applies." It may well not and the correct response to this paper may be a short written note concluding that no controlled classification exists in your estate. That note is itself the compliance artefact. The failure mode is not having the exposure; it is never having asked.
"Selective replication would hurt performance for the restricted site." Yes, and that is the actual trade-off, honestly stated. Someone should make it deliberately rather than discovering it was made by default during an audit.
7. What to do this week
- Draw the map. Every vault, every replica, every country. One page. Infrastructure has this; compliance has usually never seen it.
- Overlay classification. Which restricted programmes have files in the replicated vault? If the answer requires an investigation, that is the finding.
- Write the policy sentence. "Data classified X may not be replicated to geography Y." One sentence turns a default into a decision.
- Ask the vendor the question. Can replication be excluded by classification rather than by vault?
- Put decommissioning in the site-closure checklist, because nobody will remember otherwise.
None of that is a project. It is an afternoon, a conversation between two teams that do not usually meet and a sentence of policy — and it converts the most likely unexamined data-transfer path in your estate into one you can describe when somebody asks.
White paper. PLMClub implements on Aras Innovator and works on multi-site estates with cross-geography vault replication. This paper describes a control gap and a design response; it is not legal advice and whether a given replication constitutes a controlled transfer under a specific regime is a question for your export-control counsel. If you have addressed this well and would tell us how, we would like to hear it.