Somewhere in the agreement you signed with your cloud provider, SaaS vendor, CRM, analytics platform, or whatever service you hired is holding your company's information, there's probably language saying that you own your data. I mean, there should be.
That’s awesome. Keep reading. We’re not done yet.
Because having a relationship with your data means you’re in one that’s high maintenance and complicated. It’s a lot more than just ownership. Where does it live? Who can access it? What can the company storing it do with it? What happens to backups when you delete something? What information is being created from your data? And when you decide to leave, exactly what does "your data" include?
Those questions have become even more important as companies connect AI models and agents to enterprise data. Now we're not just talking about storing customer records or running reports. We're deciding what information AI systems can access, what can be used to improve those systems, and what records exist showing what they did.
Your contract may give you a very simple answer to who owns your data. What that ownership actually means can be a hell of a lot more complicated.
What did you give the vendor permission to do with it? A company doesn't need to own your data to have considerable control over what happens to it.
That's not necessarily sinister. If you're paying someone to host and process information for you, they need permission to actually host and process the damned stuff. Depending on the service, that can mean storing it, copying it, transmitting it, analyzing it, backing it up, and making it available to the people and systems you've authorized to use it.
The important question isn't whether your vendor can do things with your data. Of course they can. I mean they are working for you. The question really is more focused on what did you agree they could do?
AWS provides a good example of why it's worth reading beyond the sentence that says you own your data. AWS explicitly says customers own their "Customer Content" and control which AWS services process, store, and host it.
But AWS also defines what Customer Content means. The definition does not include information in resource identifiers, metadata tags, access controls, rules, usage policies, permissions, and similar information used to manage AWS resources. AWS uses that information to provide and improve its services.
There's nothing hidden about that. AWS explains it on its own data privacy page.
But it demonstrates something important: before asking who owns your data, make sure you understand what the agreement actually defines as your data.
That gets particularly interesting when the information surrounding the original data starts becoming valuable itself. And here’s where we find out what the shark really ate.
Your data creates more data. Take a customer record, for example. The customer's name, account number, address, purchases, and support history are fairly easy to recognize as data.
Now build a functioning enterprise system around those records. You have schemas describing how information relates. There are classifications identifying sensitive information. You create calculated fields and transformations. There are access policies, workflow configurations, search indexes, lineage, audit records, and metadata describing the data itself.
And then we get to dump a bottle of AI into the stew.
There may be prompts, responses, embeddings, model interactions, agent activity, and other information derived from how people and systems use the original data. Which of those things are included when the contract says, "You own your data?" And the biggie, what is the provider allowed to do with them?
Atlassian gave us a useful real-world example in 2026. On August 17, updated terms went into effect expanding how eligible customer metadata and in-app data can be used to improve Atlassian apps and AI experiences for customers. Atlassian says contributed information receives privacy protections including de-identification and aggregation (aggregation is pretty much taking away your data’s ID and tossing into a massive pool party to swim with all the other data).
The interesting part is how much control customers have over that contribution.
|
Atlassian plan |
Metadata contribution |
In-app data default |
|
Free |
On, cannot opt out |
On |
|
Standard |
On, cannot opt out |
On |
|
Premium |
On, cannot opt out |
Off |
|
Enterprise |
On by default, can opt out |
Off |
Those are Atlassian's current published settings. Certain government, regulated, and specially configured organizations are excluded.
Notice what didn't happen. Atlassian didn't need to take ownership of everyone's Jira tickets. Customers still own their underlying data. The terms governing how certain information can be used changed.
And different vendors make different choices. Notion's AI terms, for example, say it does not use Customer Data, or allow others to use it, to train the machine-learning models used to provide Notion AI. It also defines AI inputs and outputs as Customer Data.
Neither example gives us a universal rule for how SaaS companies treat customer data. And that’s my point. There isn't one. You have to know what your provider's agreement says.
Now onto the next bailiwick, data deletion. You’ve deleted your data, is it actually gone? Deletion sounds like another one of those questions that should have a simple answer. Delete means delete, right? Press the button and whack! No more data.
Well...
Hosted systems don't normally contain one magical copy of your data sitting on one server somewhere. There may be production databases, replicas, backups, disaster recovery systems, logs, archives, and other copies maintained for perfectly legitimate reasons.
Backups aren't the enemy here. When something goes horribly wrong, they're what saves your bacon. The problem is assuming that deleting something from the production system means every other copy immediately disappears with it.
Blackbaud provides a particularly ugly example of why retention matters. In 2020, an attacker remained inside Blackbaud's environment for approximately three months and removed large amounts of unencrypted sensitive information belonging to Blackbaud customers. According to the Federal Trade Commission, Blackbaud had retained some customer information far longer than necessary, including information belonging to former customers.
When Blackbaud discovered the attack, it paid the attacker 24 Bitcoin (worth about $250K at the time) after being told the stolen data would be destroyed. According to the FTC, Blackbaud never verified that it actually was.
The FTC eventually required Blackbaud to establish a data-retention schedule and delete information it no longer had a legitimate business or legal reason to retain.
There's an important distinction here. The lesson isn't "backups are bad." It's "know what happens to your data after you don't need the vendor anymore."
How long do backup copies remain? Current industry standard works on a 3-2-1-1-0 backup strategy paired with a grandfather-father-son (GFS) retention rotation. Under this standard, daily backups are generally kept 7 to 14 days, weekly 4 to 5 weeks, monthly 12 months, and yearly backups are kept for 7 years.
That’s industry standard, the average. The big unknowns, and what you should know when you sign up with your vendor, are whether they’re still accessible for normal processing. When are they overwritten or destroyed? What happens to logs? What happens to de-identified information? What happens after your contract ends?
You may own the data and still discover that copies of it will exist in someone else's environment long after you thought you were finished with them. Case in point, FTC's Blackbaud case and retention findings4. "You can export your data" doesn't answer the question
Things have happened and you've decided to leave. Your vendor says there's no problem because you own your data and can export it whenever you want. Great. What do you get? A collection of CSV files containing all your customer records might technically satisfy an export requirement while leaving behind much of what made those records useful. But what happens to the schemas? Metadata? Relationships? Classifications? Transformation logic? Governance policies? Audit history?
The biggie, and super important to you, is can another system actually use what you receive? That distinction has become important enough that governments have started regulating it. The European Union's Data Act became applicable in September 2025 and specifically addresses switching between data-processing services.
The European Commission identifies high data-egress charges, lengthy switching procedures, lack of interoperability, and potential loss of data and applications as barriers customers have faced when moving between providers. The Act's switching provisions cover input and output data, including metadata generated through use of the service, with certain exclusions for provider intellectual property and trade secrets.
In other words, "you can download your data" and "you can take your working data environment somewhere else" are not the same thing. Before signing or renewing a data-service agreement, I'd want answers to a few questions:
|
The agreement says... |
What I'd want to know |
|
You own your data |
What exactly does "your data" include? |
|
We can process your data |
For what purposes, and what information can be derived from it? |
|
You can delete your data |
What happens to backups, logs, archives, and derived information? |
|
You can export your data |
Do I also get metadata, schemas, relationships, and relevant history? |
|
Your data is portable |
Can another compatible system actually use what I receive? |
|
You can terminate the service |
How long do I have to retrieve everything, and what happens afterward? |
|
We support AI |
Which models and agents can access which data, and is that access recorded? |
And I'd want the important answers documented in the agreement governing the relationship, rather than discovering them during an exit project three years later.
Ownership should still mean something after the vendor is gone. None of this means companies should stop using managed services and haul their servers back into the building. We've already tried that. The goal isn't necessarily to control every piece of technology yourself. It's to make sure that hiring someone else to operate the technology doesn't require giving up practical control of the data running through it.
That's the distinction behind Spitfyre's approach to data independence. Its architecture is designed to avoid dependence on proprietary data formats or closed technology layers. Its portability promise covers the data itself, metadata, agreed governance artifacts and transformation logic, and structured audit history. It also calls for an exit plan everyone agrees with before production use.
Spitfyre applies the same idea to AI. Approved models and agents connect through governed access, while approvals, access, queries, exports, and policy actions are all recorded. The organization decides which AI systems can access which data rather than tying the data architecture permanently to one AI provider.
That doesn't mean every application, report, integration, or piece of business logic you've ever created will magically work somewhere else. Changing technology will always involve some work.
But there's a substantial difference between work required to change providers and being unable to change providers without rebuilding the environment that makes your data useful.
We’ve answered who actually owns your data. We’ve also explored what you're allowed to do with it, what your vendor is allowed to do with it, what happens to it when you delete it, what gets created from it, and whether you can still use it when the vendor is gone.
Spitfyre makes the last one a lot simpler. Would your data still work without the vendor? If the answer is no, I'd want to know why before I signed the contract.
Sources: