Every cloud SCADA evaluation obsesses over uptime, drivers, and dashboards - and then signs a contract that never says who owns the telemetry, where it lives, how long it is kept, or how it comes back out. Those four questions decide whether you are renting a service or mortgaging your operational history to a vendor. This guide walks an operations manager or compliance lead through data ownership language, residency options, retention design, export rights, and the offboarding clauses that prevent vendor lock-in - with the exact questions to put in front of every vendor before you sign.
Explore the full security & certification article series - 60+ practitioner guides.
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 vendor lock-in, and it is 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.
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:
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.
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:
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 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:
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 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.
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:
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.
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.
The one-sentence test: ask the vendor to complete this sentence in writing - "If you leave us, you get all of your data, in an open format, within N days, at a cost of X." A vendor who fills in the blanks without flinching is selling a platform. A vendor who talks around it is selling gravity. Merobix will complete the sentence - see the security architecture, or ask it live in a guided demo.
You should - but only if the contract says so. The operator generates the telemetry, so ownership of raw and historized process data should sit with the customer, with the vendor holding only a limited license to process it in order to deliver the service. Read the agreement for clauses that grant the vendor rights to aggregate, anonymize, or derive products from your data, and for anything that conditions data return on account status. If ownership language is vague or missing, fix it before signing - it is far harder to negotiate after your historian lives on someone else's platform.
Data residency is the question of where your telemetry is physically stored and processed - which country, which cloud regions, and which backup locations. It matters because regulations, customer contracts, and internal policy can all restrict where operational data may live, and because support staff located in other jurisdictions may constitute access from those jurisdictions. Ask vendors which regions hold primary data and backups, whether you can choose the region, and whether a fully on-premise or air-gapped deployment is available when policy rules out the cloud entirely - Merobix offers that deployment option for exactly this case.
It depends on your regulatory environment. Pipeline, water, and pharmaceutical operators commonly face multi-year record-keeping expectations, and many operators keep high-resolution telemetry for one to two years with rolled-up trends kept far longer; audit and security logs often warrant longer retention than raw process data. Exact requirements vary by jurisdiction and industry, so confirm them with your compliance team, then verify the platform lets you configure retention to match - and that deletion at the end of retention is a real, documented workflow rather than an assumption.
Through export mechanisms you should test before you buy: on-demand exports in open formats such as CSV, documented APIs for programmatic extraction, and bulk historian export for full offboarding. A good platform makes customer export a supported workflow, not a support ticket. During your pilot, actually run an export - pull a month of telemetry with timestamps, quality codes, and site context intact, and load it into another tool. If the vendor cannot demonstrate export during a sales cycle, they will not get faster after you have left.
Whatever the contract says - which is why offboarding terms must be negotiated before signing. Look for a defined export window after termination (30 to 90 days is common), export in open formats at no punitive cost, written confirmation of deletion from production and backups after the window closes, and no clause that holds data hostage during billing disputes. Treat portability as a live capability: if you tested export during the pilot and it worked, offboarding becomes a scheduled task instead of a crisis.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Customer-owned data, configurable retention, built-in export workflows, and an air-gapped on-premise option when policy demands it - see how Merobix handles the data layer end to end.