SCADA Data Residency, Retention & Export: Buyer's Guide

Back to Blog

Explore the full security & certification article series - 60+ practitioner guides.

Why Data Questions Belong at the Top of Your Evaluation

Process telemetry is not exhaust. It is the evidence base for regulatory reporting, custody transfer disputes, incident investigations, environmental compliance, warranty claims against equipment vendors, and every optimization project you will ever run. A decade of one-minute data from a gas gathering system or a water treatment train is an asset - and when it lives on a vendor's platform, your practical control over that asset is defined entirely by contract language and export tooling.

The failure mode is predictable. An operator signs a three-year agreement, accumulates years of history, and then discovers at renewal time that the vendor's quote has doubled - and that "getting the data out" means a professional-services engagement, a proprietary binary format, or a per-tag export fee. That is how switching costs build up, enforced not by product quality but by the gravity of your own data. The fix costs nothing: ask the four questions in this guide during procurement, when you still have leverage, and make the answers part of the contract. This is the same discipline covered in our enterprise SCADA buyer's guide - applied specifically to the data layer.

Data Ownership: What the Contract Must Actually Say

Ownership sounds obvious - you generated the data, so it is yours - but contracts do not run on obviousness. The agreement should state, in plain terms, that the customer owns all process data, configuration, and derived records, and that the vendor receives only a limited license to store and process that data for the purpose of delivering the service. Anything broader deserves scrutiny.

Clauses to read twice:

• Aggregate and anonymized use. Many vendors reserve the right to use "de-identified" or "aggregated" customer data for benchmarking or product improvement. That may be acceptable - but you should know it is there, know what "de-identified" means for a dataset where a single large compressor station is identifiable from its profile, and be able to opt out if your policy requires it.
• Derived works and analytics. If the vendor trains models or builds industry benchmarks on your data, who owns the output? Silence favors the vendor.
• Data as collateral. Watch for language that conditions data access or return on account standing. A billing dispute should never be able to hold your historian hostage.
• Subprocessors. Cloud platforms build on other clouds. The contract should list subprocessors, commit to flow down equivalent protections, and notify you when the list changes.

None of this is exotic. Reputable vendors agree to customer-ownership language readily, because the alternative - arguing that they own your pipeline pressures - is not a position anyone defends out loud. The tell is how the first draft arrives: a contract that starts from customer ownership signals a vendor that has thought about the question.

Data Residency: Where Your Telemetry Physically Lives

Residency is the "where" question: which country and which cloud regions hold your primary data, where backups and replicas live, and which jurisdictions the vendor's staff access it from. For most US operators the driver is policy and contract rather than statute - but the drivers are multiplying. Customer flow-down requirements, cyber-insurance questionnaires, state-level rules for critical infrastructure, and international operations (Canadian pipeline data, EU manufacturing sites subject to GDPR-adjacent expectations) can each impose residency constraints. If you operate assets in multiple countries, assume at least one of them cares.

Questions that surface the real answer:

• Which cloud region holds primary data, and can we choose or restrict the region?
• Where do backups, replicas, and disaster-recovery copies live? Residency promises that cover production but not backups are half-promises.
• Can support engineers in other jurisdictions access customer data, and is that access logged and reviewable? Remote support access is jurisdictional access.
• In a multi-tenant platform, how is our data isolated from other tenants sharing the same infrastructure?

That last question matters more than most buyers realize. In a shared platform, isolation is what makes residency meaningful. Merobix enforces tenant isolation in the database itself - PostgreSQL row-level security on customer-owned records, with a signed database request context that prevents unauthorized changes of tenant context, and logging plus security alerts on any cross-tenant denial. The techniques, and how to verify any vendor's version of them, are covered in depth in our multi-tenant SCADA isolation guide.

And when policy rules out shared cloud entirely, the residency question has a structural answer: keep the data inside the fence. Merobix offers an on-premise, air-gapped-capable deployment option in which the platform runs on customer infrastructure with full data residency - the trade-offs between the two models are worked through in our cloud vs on-premise comparison.

Retention: How Long, at What Resolution, Deleted How

Retention design has three axes: duration (how long records are kept), resolution (at what granularity), and disposition (what provably happens at end of life). Regulated industries set the floor - pipeline operators face obligations under TSA's pipeline security directives, water utilities certify risk-and-resilience documentation under AWIA Section 2013, and pharmaceutical electronic records fall under FDA 21 CFR Part 11 - multi-year record-keeping expectations are common, and exact figures vary by jurisdiction and record type, so confirm them with your compliance team rather than a vendor's sales deck. A common pattern: high-resolution telemetry retained one to two years for operational analysis, rolled-up hourly or daily trends kept for many years, and audit or security records kept longest of all, because they are the record of who did what.

What to verify on the platform side:

• Configurable retention - can you set retention per data class to match your obligations, rather than accepting one global default?
• Deletion as a workflow, not an assumption. When retention expires, is data actually removed - including from backups on their own cycle - and can the vendor describe that process in writing? NIST SP 800-88's media sanitization guidelines are the reference standard for what "removed" should mean.
• Retention does not silently truncate. Some platforms quietly downsample or purge old data at plan thresholds. Discovering that during an incident investigation is the wrong time.
• Audit trail retention is separate and longer. Operational data answers what the process did; audit records answer who touched the system. Regulators and insurers ask for the second first - see our SCADA audit trail guide.

Merobix treats retention and export as first-class workflows: data-retention policies and customer-export are built platform capabilities, backup archives are validated rather than assumed good, and restores run through controlled tooling - because a retention promise backed by an unrestorable backup is fiction. Backup validation and restore drills get their own treatment in our backup and disaster recovery guide.

Export Rights: Getting Your Data Out

Export is where contractual ownership becomes practical ownership. Owning your data on paper means little if the only path out is a support ticket answered in weeks. Evaluate export the way you evaluate drivers - as a technical capability you test, not a checkbox you trust:

Export Mechanism	What It's For	What to Verify
On-demand export (CSV / open formats)	Reports, ad-hoc analysis, regulator requests	Self-service from the UI; timestamps, units, and quality codes included; no per-export fees
API access	Continuous feeds to data warehouses, analytics, corporate historians	Documented, rate-limited API with scoped keys; historical range queries, not just live values
Bulk historian export	Full offboarding or migration	Complete history in an open, documented format; realistic delivery timeline; cost stated in the contract
Audit and security log export	SIEM, compliance evidence, forensics	Event export to your SIEM or archive; log formats documented
Configuration export	Rebuilding elsewhere: tags, alarms, screens, users	Often the forgotten one - ask specifically; even partial (tag lists, alarm setpoints) beats nothing

Two details separate genuine portability from checkbox portability. First, context travels with the values: an export of bare numbers without timestamps, quality codes, and site/device attribution is technically data and practically useless. Merobix telemetry carries its identity through the pipeline - sample ID, timestamp, quality, device, site, and tenant - so an export is a usable record, not a spreadsheet mystery. Second, test it during the pilot. Export a month of real data, load it into another tool, and check what survived. Ten minutes of testing tells you more than ten pages of contract.

Offboarding and Portability: Plan the Exit Before You Sign

Every vendor relationship ends eventually - by acquisition, by price increase, by a better platform, or by the vendor exiting the market. The offboarding terms you negotiate on day one determine whether that ending is a scheduled migration or a hostage negotiation. Put these in the contract:

• A defined export window after termination - 30 to 90 days is common - during which full export remains available regardless of why the contract ended.
• Export format and cost stated up front. Open formats, at no cost or a pre-agreed reasonable cost. "Professional services engagement, quoted at time of request" is a red flag.
• Deletion attestation. Written confirmation that your data has been removed from production and, on their backup cycle, from backups after the window closes.
• Survival of terms. Ownership, confidentiality, and export obligations must explicitly survive termination.
• No data-hostage clauses. Export rights must not be suspendable during fee disputes.
• Vendor failure protection. What happens if the vendor is acquired or shuts down? Continuity commitments - or at minimum the ongoing export capability you have already tested - are your insurance.

Offboarding is also one of the cleanest lenses on the shared responsibility model: the vendor owes you working export tooling and honest contract terms; you owe yourself a tested export, an offline copy of anything irreplaceable, and a written exit plan filed next to your incident response plan.

How Merobix Approaches Residency, Retention, and Export

Merobix builds the data layer on the assumption that it is customer property being held in trust. Sensitive application data is encrypted, with blind indexes used so that even encrypted identifiers such as email addresses remain searchable without being stored in the clear. Customer records sit behind row-level security with a signed request context, so tenant boundaries are enforced by the database, not just the application. Data-retention and customer-export workflows are product features rather than support favors; backup archives are validated and restores run through controlled tooling; and sensitive events are written to immutable, chained audit records so the history of the system is as durable as the history of the process. For operators whose policy requires it, the same platform deploys on-premise, air-gapped, with complete residency. The full picture is on our security architecture page.

Ten Questions to Put in Front of Every Vendor

1. Does the contract state that we own all process data, configuration, and derived records? Ask for the clause number.
2. What rights do you retain over aggregated or anonymized customer data, and can we opt out?
3. Which regions hold our primary data and our backups, and can we restrict them?
4. Can we deploy fully on-premise or air-gapped if policy requires it, and what changes?
5. Is retention configurable per data class, and what happens - provably - when it expires?
6. Show me a self-service export. Live, during the demo, with timestamps and quality codes in the output.
7. Is there a documented API for historical data, and what are its limits?
8. What does full offboarding export cost, in what format, and on what timeline? In the contract, not a future quote.
9. What is the post-termination export window, and does it survive fee disputes?
10. Will you provide written deletion confirmation after offboarding, covering backups?

Frequently Asked Questions

Sources & Further Reading

• 21 CFR Part 11 - Electronic Records; Electronic Signatures (eCFR / FDA)
• America's Water Infrastructure Act Section 2013 - Risk and Resilience Assessments (EPA)
• Surface Transportation Cybersecurity Toolkit (Pipeline Security Directives) (TSA)
• NIST SP 800-88 Rev. 2 - Guidelines for Media Sanitization (NIST)