Ownership

What customers should own when buying a managed workflow

A practical ownership model for source data, structured records, schemas, operating history, access, exports, retention, and exit.

7 min read · 20 August 2026 · StructuredLayer

Managed operation should not turn customer information into avoidable dependency. The customer needs a clear right to its inputs, resulting records, agreed schema, operating history, and usable exit exports.

Separate customer assets from operating components

The customer normally owns or controls its source materials, authorized accounts, business rules, contacts, conversations, and resulting business dataset. Source licences and third-party rights can still limit reuse.

The operator may retain reusable methods, connectors, monitoring components, and general know-how. The agreement should distinguish those components from customer-specific records and configuration.

Customer inputs and authorized source data
Normalized and calculated records
Customer-specific schema and rules
Reusable operating components

Ownership needs portability

A contractual ownership sentence has little value if the customer cannot receive the data in a documented format. Export fields, identifiers, timestamps, source references, attachments, classifications, and history should be defined before launch.

The managed copy, backups, logs, and provider data need retention and deletion rules. Access should be revocable without destroying the customer’s ability to continue its work.

Documented export format
Stable identifiers and field definitions
Retention and deletion schedule
Revocation and exit handover

Preserve evidence and transformations

Raw source values should remain distinguishable from normalized, calculated, classified, or inferred values. Timestamped observations should not be silently overwritten when history matters.

Decision framework

Assets to identify before signing

01	Customer data	Inputs, contacts, records, conversations	Customer ownership or documented rights
02	Derived records	Normalized values, calculations, classifications	Define ownership, evidence, and reuse
03	Operating components	Connectors, monitoring, reusable methods	Usually operator components; licence needed
04	Operating history	Runs, errors, overrides, exports	Define access, retention, and handover

What good looks like

A data inventory that distinguishes controller data, source-licensed data, derived records, and reusable components
Machine-readable exports with schemas, identifiers, timestamps, attachments, and history
Return-or-delete instructions for personal data at contract end
A transition window, named contacts, migration assistance, backup treatment, and deletion confirmation
Subprocessor transparency and equivalent obligations flowing down the delivery chain

Buyer red flags

The contract says “customer owns data” but defines no export
Only a PDF report is available when structured records are needed
Backups and provider copies have no deletion timeline
Cancellation removes access before the customer can migrate
Configuration, schema, history, and attachments are omitted from exit scope

Put it in writing

Requirements to resolve in the proposal or contract.

01Controller and processor roles where applicable
02Data categories, purposes, duration, and documented instructions
03Export scope, format, timing, transfer method, support, and cost
04Production, replica, backup, archive, and legal-retention treatment
05Subprocessors, locations, audit rights, incidents, and exit assistance

Buyer checklist

Questions to resolve before approval.

Who owns the resulting records?
Which source licences constrain use?
Is the schema documented and exportable?
Are raw and transformed values distinguishable?
What operating history is retained?
What happens at cancellation or provider change?

Research reviewed

Primary guidance behind this article.

These sources support the operating framework; they do not endorse Aineed Data or replace legal, regulatory, security, or sector-specific advice.

01ICO processor contract clausesReturn or deletion, instructions, security, subprocessors, rights, and audit terms.02ICO IT supplier relationshipsExit strategy, data and configuration return, security, backup, and supplier controls.03ICO contracts and data sharingAccountability expectations for contracts and third-party processing.