The statement "the data is owned by the client" is not enough. The contract should define separately the scope of datasets, usage rights, storage location, current access, format, quality, retention, security, audit, and the handover and deletion of data after the cooperation ends. Each of these issues needs a deadline, an owner, and evidence, not just a declaration.
In short
- Ownership, possession, access, portability, and retention are five different matters.
- The contract must separate measurements, calculated results, configuration, audit, and raw transmission logs.
- An open format without metadata does not provide usable migration.
- A trial export before signing the contract says more than a general data handover clause.
- This text is informational material; a lawyer who knows the project should assess the final wording.
"The data belongs to the client" - why this sentence does not solve the problem
The asset owner may have an economic interest in the full measurement history, yet still not have a file that can be opened without the supplier's platform. They may see a chart but have no right to share the data with a designer. They may receive CSV, but without units, configuration, and formula versions. In each of these cases, the promise "the data is yours" sounds good, but it does not allow analysis or a change of service provider.
Monitoring data portability is the ability to receive measurements together with metadata and context in an agreed format and use them in another tool without disproportionate cost and without dependence on the current supplier.
In the EU, additional context comes from the Data Act - Regulation 2023/2854. It regulates access to data from connected products and related services, including pre-contract information on type, format, frequency, storage, and method of access. However, do not assume automatically that every element of a specific monitoring system falls under the same rules. The scope of application requires legal review, and a well-written contract still removes operational uncertainty.
Twelve clauses: control question and minimum evidence
The table below is not a ready legal template. It is an instruction for the business and technical team: what must be resolved before a lawyer adapts the language to the jurisdiction, cooperation model, and procurement.
| # | Clause | Control question | Minimum evidence |
|---|---|---|---|
| 1 | Data scope | Which datasets are created and who creates them? | Data dictionary and a sample of each dataset |
| 2 | Usage rights | Who may analyze, copy, and share? | Rights and recipients matrix |
| 3 | Possession | Where is the primary copy located? | Architecture and location description |
| 4 | Current access | Who downloads data and how during the contract? | Export performed with the client's account |
| 5 | Format | Does the file include units, time, and metadata? | Open file and schema |
| 6 | Quality | How are completeness and freshness measured? | Report from the agreed window |
| 7 | Retention | What disappears, when, and on what basis? | Retention table per dataset |
| 8 | Copies and continuity | How is the service and the data restored? | Restoration test result |
| 9 | Security | How are transmission and accounts protected? | Agreed security package |
| 10 | Personal data | Who is the controller and who is the processor? | Data processing agreement, if needed |
| 11 | Audit and versions | Can the decision be reconstructed after a change? | Entry with values before and after |
| 12 | Exit | When, how, and to whom is the whole dataset issued? | Trial migration and protocol |
Each row should have an owner on both sides, an execution deadline, an acceptance criterion, a defect reporting method, and the consequence of non-performance. Only then does the table become a contractual annex, not a list of good intentions.
Clauses 1-4: scope, rights, possession, and day-to-day access
1. Scope and classification of data
Start with a closed catalogue of datasets: source measurements, calculated results, configuration, references, thresholds, alarm history, change audit, user data, and raw communication logs. For each dataset, indicate the author or source, business meaning, unit, expected volume, and retention period.
It is especially important to separate the measurement from the result. A value after calibration or compensation is not the same as the input reading. Without the formula, coefficients, and configuration version, the result may be impossible to reproduce.
2. Ownership and usage rights
The lawyer will choose the structure appropriate for the legal system: ownership, license, database rights, confidentiality, or a combination of these. The technical team, in turn, should answer what is allowed in practice. May the client copy the data, analyze it with another provider, share it with a regulator, insurer, or expert, publish results, and combine the history with other datasets?
Regulate the supplier's use separately: service delivery, support, security, aggregated statistics, and any further purposes. Do not leave a broad consent "for service development" if it is not clear which data, in what form, and for how long it covers.
3. Possession and copy location
Ownership does not say where the only operational copy is located. The contract should define the environment, storage region, backups, subcontractors, and whether the client has its own current copy. For installations in the client's infrastructure, administration of the database, updates, and backup creation must also be clearly assigned. A server on the client's side does not automatically mean full control.
4. Access during the contract
Do not postpone export until the contract termination date. An authorized user should know how to download data, the range limits, the format, and any costs. If only support can perform the full export, set the delivery time and price. The minimum test is an independent download of the agreed period during acceptance.
Clauses 5-8: usable format, quality, retention, and restoration
5. Format, schema, and metadata
"CSV" does not mean portability. The file needs persistent identifiers, UTC time, units, marking of raw and calculated values, missing-data encoding, and schema version. Complex data, for example dynamic traces or geometry-dependent profiles, may require more than one table and a separate manifest.
Attach a sample export and a data dictionary to the contract. This prevents a column layout change from becoming a small interface change that silently breaks the client's integration. The technical structure of such an annex is developed further in the specification of data for the technical requirements document.
6. Quality and responsibility for gaps
Separate application availability from stream quality. The contract should define completeness, freshness, maximum gap, latency, and the method of classifying an invalid frame. Then assign responsibility boundaries: device, connectivity, integration, platform, and incorrect configuration.
Not every gap is the fault of the platform provider, and not every correct number proves a healthy sensor. The purpose of the clause is to quickly identify the layer to diagnose and preserve evidence, not to shift all risk to one side.
7. Retention, deletion, and suspension of deletion
The retention table should cover each dataset separately. Define the start of the period, rules for extension, the notice method before deletion, and the treatment after the contract ends. If the project may enter a dispute, ask a lawyer about the procedure for preserving data and suspending standard deletion.
Do not declare a WORM mechanism, legal hold, or immutability if the solution does not provide it. A normal application audit and a backup are not the same as an evidence repository with special guarantees.
If the data may later be used in a dispute, ownership wording alone is not enough. The chain from measurement and time through configuration to the operator's decision must be preserved. The key elements of this chain are described in the guide monitoring data as evidence in a dispute.
8. Backups and continuity
The clause should define the backup scope, frequency, encryption, retention, and restoration test. RTO defines the target service recovery time, and RPO defines the acceptable data loss point. Both values must match the measurement cadence and alarm procedure; the sentence "we perform backups" does not say how much history may be lost or when the panel will return.
Clauses 9-12: security, privacy, audit, and exit
9. Security and incident handling
Require an access control model, a process for granting and revoking accounts, transmission protection, updates, incident monitoring, and notification deadlines. NIST IR 8259A provides a useful starting point for IoT device capabilities: identification, configuration, data protection, interface control, updates, and security state awareness.
Do not insert the name of an algorithm or certificate automatically without linking it to risk. What matters more is the scope: which connections, data, and copies are protected, and who responds if the safeguard fails.
10. Personal data and subcontractors
Structural readings alone usually do not identify a person, but the platform stores accounts, email addresses, phone numbers of alarm recipients, and activity logs. If the supplier processes personal data on behalf of the client, Article 28 of the GDPR requires an appropriate contractual basis, a description of processing, confidentiality, security measures, rules for sub-processing, assistance to the controller, and the return or deletion of data after termination.
Scope and roles must be assessed for the specific implementation. Not every technical field is anonymous just because it comes from a device.
11. Configuration audit and versions
The contract should require recording the person, time, type of operation, and the before-and-after values for changes affecting interpretation: threshold, coefficient, reference, equation, role, and profile configuration. Define how long the audit is available and whether it is included in the final delivery.
An audit does not have to mean automatic rollback of changes. If you need restoration, result versioning, or immutable records, name this as a separate requirement and test it.
12. Exit, handover, and confirmation of deletion
The exit plan must indicate the trigger event, deadline, data scope, format, transfer channel, receiving party, period of transitional access, cost, and migration support. After confirmed receipt, define deletion from active environments and the fate of backups in line with the agreed retention.
The best evidence is a trial migration performed at the start of the cooperation. If a small project can be reproduced by the recipient, both sides know the format and effort. If not, the problem appears before years of history accumulate.
Illustrative example: the file exists, but the history cannot be transferred
Illustrative example. After three years, the asset owner changes supplier. They receive a file with time and values. However, there are no persistent channel identifiers, units, formulas, or dates of coefficient changes. Some names were edited in the meantime, so the new team does not know whether two series refer to the same point.
The old supplier formally "released the data." The new one can draw a chart, but cannot reliably reproduce the results or confirm continuity. The migration cost moves from export to manual investigation.
A contract based on twelve clauses would also require a schema, a dictionary, configuration versions, and a trial import. The problem would be detected during the acceptance of the first month, not after three years. This is an illustrative example; its purpose is to show the difference between possessing a file and having portable information.
How this looks in Inclify
In Inclify, measurements in the time-series database are not deleted automatically; older data are compressed. Tabular data can be exported to CSV, the chart image as a graphic file, and dynamic analysis results to XLSX. The platform does not offer PDF export. History from a previous solution can be sent through the same HTTP/JSON interface with the original UTC times, but there is no series import from a file or manual form.
Raw device requests and responses are a separate diagnostic dataset. They are compressed and stored for a configurable period, by default seven days; administrators have access to them. The audit log records configuration changes with before-and-after values, but it is not an automatic restoration mechanism or a declaration of WORM or legal hold.
These facts should be translated into a specific contract: the required retention period for measurements and logs, the scope of export, the delivery deadline, and the rules after termination. The platform functions are described on the online monitoring page, but the binding scope should always come from the offer and the contract.
Checklist before signing the contract
- [ ] We have a list of all datasets, not only "measurement data".
- [ ] We separated source measurement, result, configuration, audit, and transmission log.
- [ ] Rights to copy, analyze, share, and publish are explicit.
- [ ] We know the location of the primary copy and backups.
- [ ] An authorized user can download data without a support ticket.
- [ ] The format includes identifiers, UTC, units, missing values, and schema version.
- [ ] Stream quality has metrics, windows, and a division of responsibility.
- [ ] Retention is separate for each dataset.
- [ ] RTO, RPO, and the restoration test are agreed.
- [ ] Accounts, transmission, updates, and incidents have owners.
- [ ] We assessed personal data and the need for a processing agreement.
- [ ] The audit shows before-and-after values, but does not pretend to be a WORM mechanism.
- [ ] The exit plan includes deadline, format, cost, recipient, and secure transfer.
- [ ] We performed a trial export and import before production start.
The exit cost is worth including from the start in the five-year monitoring TCO. A "free export" does not mean a cost-free migration if the data require weeks of manual cleanup.
Limitations and legal notice
This article is informational and does not constitute legal advice or a contract template. The concepts of ownership, database rights, license, trade secret, personal data, and obligations under the Data Act may work differently depending on the parties, jurisdiction, financing, and system architecture. Final clauses should be prepared or approved by a lawyer after reviewing the specific data flow.
A contract alone will not fix an untested export. Even the best obligation can lead to a dispute if the format and sample are not attached. On the other hand, a technical test without clear usage rights is also not enough. Both elements are needed: a precise contractual basis and a working acceptance process.
Inclify does not declare a built-in WORM mechanism, legal hold, or automatic reconstruction of an old configuration. If the project requires them, an additional repository or procedure should be provided and responsibility described outside the standard platform scope.
FAQ
Does the owner of the sensors automatically own the data?
You should not assume that. Equipment ownership, rights to the data, access to the platform, and the ability to share further are separate matters. They may depend on the contract, regulations, the role of the parties, and how the data were created. The safest approach is to describe each dataset and permitted actions explicitly, and submit the wording for legal review for the specific project.
Does the Data Act solve the IoT data access problem?
The Data Act establishes important rights and obligations regarding data from connected products and related services, but its application depends on the facts. It does not replace the description of format, metadata, retention, migration support, and responsibility. In a tender, it is worth treating it as a minimum legal context, not as a ready exit plan for the entire monitoring history.
What should be included in the final export?
At minimum, source measurements, contractually required results, persistent identifiers, UTC timestamps, units, missing-value markers, data dictionary, and schema version. If interpretation depends on thresholds, equations, calibration, references, or geometry, their versions and validity periods are also needed. The scope should be confirmed by a trial import in an independent environment.
How long should raw communication logs be kept?
There is no single universal number. Logs are useful for diagnostics and for reconstructing what the device sent, but they may be large and may contain information that requires protection. The period should result from incident detection time, service needs, legal obligations, and cost. In the contract, separate it from measurement retention.
Is a backup proof of data immutability?
No. A backup serves primarily for recovery after failure. By itself, it does not prove that a record was not changed, who made the change, or that the required chain of evidence was preserved. If you need an immutable archive, signatures, WORM, or legal hold, name these mechanisms separately and accept their operation.
When is the best time to test exit from the service?
Before production start or, at the latest, when the first full data period is accepted. The dataset is then small, both sides remember the assumptions, and correcting the schema costs little. The test is worth repeating after any major change in format or scope. Waiting until termination turns a technical error into time pressure and business risk.
Sources and further reading
- Traffic Monitoring Guide 2022, Chapter 6: Third-Party Traffic Data, Federal Highway Administration.
- Facilities Management Standard 002: Asset Data, UK Government Property Function.
- Regulation (EU) 2023/2854 on data - Data Act, EUR-Lex.
- Regulation (EU) 2016/679 - GDPR, EUR-Lex.
- NIST IR 8259A - IoT Device Cybersecurity Capability Core Baseline, NIST.
- ISO 19650-1:2018 - Information management using BIM, ISO.
What next: run an exit test before you need one
If you have a draft contract or a sample export, we can go through the technical part of the twelve clauses together and run a portability test on a small sample. Schedule a conversation about data and the exit plan. A lawyer will approve the contract language, and you will first see whether the promised process really works.