What do you actually own in your analytics stack?

Turn a broad promise into specific questions

“You own your data” sounds clear until the team needs to change a provider, administer a cloud account, repair a model, or recreate a report.

Data ownership, account control, access, portability, and software rights are related but separate ideas. A useful engagement describes each of them in terms that both the business owner and technical team can understand.

This checklist helps prepare that conversation. It is a practical reporting worksheet; the final rights and obligations need to be recorded in the actual agreement.

Start by drawing the reporting path: source systems, ingestion, storage, models, reporting application, and exports. Then apply the questions below to every part.

1. Who controls the source accounts?

List the systems where the original business activity is recorded. For each, identify the account owner, billing owner, administrators, and the permissions used by the reporting connection.

Ask who can grant, revoke, rotate, and recover access. Identify whether the connection uses a customer-controlled identity, a provider-managed credential, or another arrangement.

An important operational distinction is whether the customer can continue to administer the source independently of the analytics provider. The documentation should make that clear without requiring the team to inspect a script.

Record any vendor approval, subscription, or access limitation that affects the reporting path.

2. Where does the data foundation run?

Identify the cloud, warehouse, storage, or other data-platform accounts involved. Ask which organization controls those accounts and which party pays the infrastructure charges.

A customer-owned warehouse is one possible part of an ownership model. It does not, on its own, describe every data flow or service involved in the engagement.

Ask where processing occurs, whether an intermediary is used, which copies or caches are maintained, and how those arrangements change during support or troubleshooting.

The answer should be a readable architecture and responsibility description, not only a vendor logo on a slide.

3. Which data assets remain available?

List the raw or ingested data, cleaned data, reporting models, published aggregates, and historical versions that the engagement creates or maintains.

For each asset, ask whether it is accessible to the customer, how long it is retained, what format it uses, and what happens if the engagement ends.

Do not assume that a dashboard export is equivalent to the underlying foundation. A CSV of the current chart may not contain historical source records, model logic, or the information needed to reproduce a metric.

Also distinguish a contractual right to receive data from a practical, tested method of obtaining it.

4. What happens to the transformations and definitions?

The value of a reporting foundation often lives in its business logic: source mappings, calculation rules, exclusions, period conventions, and reconciliation.

Ask which of those assets are documented and delivered. Identify which are customer-owned, licensed, provider-maintained, or dependent on a third-party service.

The team should be able to answer:

• What does each important metric mean?
• Where do the supporting facts come from?
• How are records mapped across systems or locations?
• What assumptions and exceptions affect the calculation?
• Who can approve a change?
• What would a new operator need to maintain the model?

A model that technically exists in the customer’s account can still be difficult to use if its meaning is undocumented.

5. What software rights are included?

Separate the customer’s data and reporting assets from the application software used to present them.

The agreement may grant access to a hosted application, a software license, rights to configuration, or another arrangement. It should explain the relevant limits and what continues if the service relationship changes.

Owning the source data does not automatically transfer the provider’s application code or third-party software. The reverse is also true: licensing an application does not answer who owns the customer’s business data.

Ask for an asset-by-asset explanation where the broad language could be misunderstood.

6. Who operates the system?

Ownership and operational responsibility do not have to be identical. A customer may control the data foundation while a managed partner maintains the reporting.

The practical question is who does what when something changes or fails.

The answer should also distinguish included maintenance from additional implementation work.

7. Where do the costs sit?

Ask which costs are included in the provider’s quote and which remain with the customer.

Possible categories include source subscriptions, cloud infrastructure, ingestion services, reporting software, implementation, ongoing management, support, and transition work.

The useful question is not simply whether the price is “all in.” It is which conditions could change the amount, who controls those conditions, and how the customer will know before additional work is performed.

A new source, major vendor change, additional operating unit, or more demanding access model can change the work required. The agreement should describe how that is handled.

8. What does the exit path look like?

Ask the provider to describe offboarding as a sequence of concrete steps.

Which data and documentation are handed over? How are source credentials and access changed? Which application rights end? Is transition support included or separately scoped? What remains dependent on a paid service?

Identify the expected formats and responsible people. Where an export is important, ask how it can be tested before it becomes urgent.

An exit path does not need to promise that every hosted feature continues unchanged. It needs to explain what is transferable, what is not, and the work required to make the transition.

9. Can the internal team verify the arrangement?

The business owner, IT or data owner, and procurement or legal reviewer may each see different parts of the engagement.

Bring them together around the same asset and responsibility inventory. Confirm that the proposal, architecture, access model, and agreement describe the same arrangement.

Record unresolved questions rather than allowing each team to fill in a different assumption. “We thought that was included” often begins as an undefined asset, cost, or responsibility.

The inventory should be updated when the scope changes, not only at the beginning of the relationship.

A one-page review worksheet

For each part of the reporting path, record:

1. The asset or account.
2. Its owner and administrator.
3. Where it runs or is stored.
4. The customer’s access and usage rights.
5. The party maintaining it.
6. Its direct and indirect costs.
7. The documentation provided.
8. The export or transition method.
9. Any limitation or dependency.
10. The agreement section that establishes the arrangement.

The final column matters: a marketing statement should point to a clear commercial understanding, not replace it.

Use ownership to make the relationship better

Clear ownership does not mean doing the work alone. A managed service can build and maintain a useful reporting system while leaving the customer with a meaningful foundation.

The best starting point is an explicit conversation about the independence, visibility, and support your organization needs. That makes it easier to choose an architecture and engagement model that fit the business.

Read ChartSplice’s ownership approach for how these questions shape a reporting engagement.