How to evaluate data ownership when buying agency software
Data ownership means asking five questions before you buy: where does active data live, who holds the keys, which jurisdiction applies, what happens on exit, and can the vendor access it silently? Most vendors answer with policy, not architecture. Use these as pass/fail criteria — so you know whether your client data is yours or on loan.
Before you sign a contract for agency software, ask where your data lives, who can access it, and what you get if the vendor disappears. Most evaluations cover features, price and integrations. Few cover ownership — because vendors are good at saying “your data is yours” while architecturally keeping it in a central database only they control.
This post gives you a five-question checklist that turns marketing copy into pass/fail criteria, so you know what you are actually buying.
Why ownership matters more for agencies
A retailer losing access to inventory data is painful. An agency losing access to client data is existential — because the data is not just operational, it is the relationship history your clients trust you to maintain.
Agencies hold:
- Client contact details and communication history
- Contracts, briefs and approved deliverables
- Financial records — invoices, rates, payment history
- Project timelines, decisions and approvals
- Sometimes credentials, brand assets and unreleased work
If any of that is locked inside a vendor’s infrastructure with no independent access path, you do not own it in any practical sense. You rent it.
The five-question checklist
1. Where does the active database live?
This is the most important question, and the one vendors are least eager to answer precisely.
| Answer you hear | What it actually means | Pass? |
|---|---|---|
| “We host on AWS in eu-west-1” | Their database, their account, their servers | ⚠️ Residency only |
| “Your data is stored securely in our cloud” | Central multi-tenant database, shared infrastructure | ❌ |
| “We use SOC 2 certified hosting” | Compliance about the host, not about your access | ⚠️ |
| “A dedicated database is provisioned on your cloud account” | Your database, your account, your region | ✅ |
What to ask: “Is the production database in your cloud account or mine?”
If the answer is theirs, you have residency at best — not ownership. Your data is a tenant in their building. They hold the keys to the front door.
sSystm provisions a dedicated D1 database on your Cloudflare account at signup. The answer to question one is verifiable: you can see the database in your own Cloudflare dashboard.
2. Who holds the encryption keys?
Encryption is meaningless if only the vendor can decrypt.
What to ask: “Can I access the database directly with my own credentials, independent of your platform?”
- If yes: you can verify, back up and query your data without asking permission
- If no: the vendor can read everything, and so can anyone who compromises them
This is the difference between “encrypted at rest” as a checkbox and encryption that actually protects you.
3. Which jurisdiction governs the data?
For EU agencies and agencies with EU clients, this is not optional.
What to ask: “Can I choose the region where the database is created, and is that choice enforced at the infrastructure level?”
| Answer | Risk |
|---|---|
| “We are GDPR compliant” | A policy claim — ask what enforces it |
| “We process data in the EU” | Processing ≠ storage; sub-processors may be elsewhere |
| “You select your region at signup; the database is created there” | Architectural guarantee |
“We are GDPR compliant” is not an answer to “where is the data.” GDPR compliance and data residency are related but not the same thing. Residency enforced by architecture — the database is created in the region you chose — is stronger than residency promised in a DPA.
4. What happens on exit?
This is the question nobody asks until they need to.
What to ask: “If we terminate the contract tomorrow, what do we have access to, for how long, and in what format?”
| Answer | What to expect |
|---|---|
| “You can export your data at any time” | CSV/JSON files; relationships may not survive |
| “We provide 30 days to export after termination” | A countdown clock; hope the export is complete |
| “Your database remains on your cloud account” | No export needed; switch software, keep data |
The third answer only applies to BYOC or self-hosted architectures. Every other answer means you are planning a migration under pressure.
If the vendor is shutting down entirely, the exit question becomes urgent — and the quality of the export window determines whether you rebuild or continue.
5. Can the vendor access your data without your knowledge?
What to ask: “Under what circumstances does your team access customer data, and is that access logged and auditable?”
Reasonable answers include: support requests you initiate, security incidents with notification, legal requirements with notice. Unreasonable answers include: “we may access data to improve our product” without specifying anonymisation, or no audit trail at all.
For agencies handling client data, this question extends to your own clients: if a client asks “who can see our files,” you need an answer that is better than “our SaaS vendor’s employees, under their policy.”
Red flags in the sales conversation
Walk away or escalate to legal review if you hear:
- “You own your data” without specifying where it lives or how you access it
- “We can migrate you later” — migration is always harder than promised
- “Export is available via our API” — APIs change, deprecate and shut down
- “Trust us, we are SOC 2 certified” — certification is about process, not your access rights
- “All our customers are on the same infrastructure” — multi-tenant by definition
Green flags
- Database provisioned on your cloud account
- Region selection at signup, enforced at infrastructure level
- Direct database access with your credentials
- DPA that names you as controller and lists sub-processors
- Exit that does not require an export scramble
How to use this checklist in practice
Before your next demo, send the five questions in writing. Vendors who can answer concretely will. Vendors who respond with marketing PDFs are telling you the architecture does not support ownership.
Score each candidate:
| Question | Vendor A | Vendor B | sSystm (BYOC) |
|---|---|---|---|
| Where is the database? | Their AWS | Their AWS | Your Cloudflare account |
| Who holds keys? | Vendor | Vendor | You |
| Jurisdiction? | “EU processing” | EU region selectable | Region chosen at signup |
| Exit? | 30-day CSV export | API export | Database stays on your account |
| Vendor access? | “As needed” | Logged, on request | Your infrastructure |
You are not looking for perfection. You are looking for whether the vendor’s architecture matches their ownership claims — or whether “your data is yours” is a legal fiction.
Ownership is an architectural decision
Features can be added. Prices can be negotiated. Integrations can be built. Data architecture cannot be retrofitted. The choice of whether your agency’s client data lives on your cloud account or a vendor’s central database is made at signup and rarely changes without a full migration.
sSystm is built on BYOC because agencies should not have to parse marketing language to find out whether their client data is actually theirs. The checklist above should take five minutes to complete — and the answers should be verifiable in your cloud dashboard, not in a footnote.
Related: What is a BYOC agency OS? · Data residency and GDPR for agencies · SaaS vendor lock-in
Frequently asked questions
Who owns the data in a SaaS application?
Legally, you often retain ownership of the content you upload — but the vendor controls where it is stored, how it is accessed, and whether you can export it. 'You own your data' in a terms-of-service document does not mean you can reach it independently. True ownership means you hold the database, the keys, and the ability to access your records without the vendor's permission.
What questions should I ask about data ownership before buying agency software?
Five essentials: (1) Where does the active database physically reside? (2) Who holds the encryption keys? (3) Which jurisdiction governs the data? (4) What happens to your data if you leave or the vendor shuts down? (5) Can the vendor access your data without your knowledge? If any answer is vague, assume the vendor controls the data.
What is the difference between data residency and data ownership?
Data residency is about geography — where the servers are located. Data ownership is about control — who holds the database, the backups and the keys. A vendor can host in the EU (residency) while still keeping your data in their central multi-tenant database that you cannot access directly (no ownership). Residency without ownership is a policy promise; ownership is an architectural fact.
What does a good data processing agreement look like for agencies?
It should specify the data controller (you), the processor (the vendor), the sub-processors involved, the jurisdiction, breach notification timelines, and your right to audit or export. For agencies handling client data, it should also clarify what happens to client records when your agency relationship with the vendor ends — not just your agency's own account data.
How does BYOC affect data ownership evaluation?
BYOC (Bring Your Own Cloud) changes the answer to every question on the checklist. The database is provisioned on your cloud account, you choose the region, you hold the access credentials, and leaving the vendor does not require an export — the data is already on your infrastructure. Evaluation becomes verifying the architecture, not parsing marketing language.
sSystm is the first BYOC agency OS — your clients, your code and your cloud on your own Cloudflare account, with your AI working the whole workspace over MCP.
Join the waitlist