Questions to ask a vendor before you sign
The questions that make a supplier prove data sovereignty, and what a real answer versus an evasive one sounds like. Copy them into an RFP, or read them down a vendor call.
Sovereignty is a claim to be tested, and a vendor’s answers are where you test it. Ask these before you sign, when you still have leverage, and read the answers for what you could enforce rather than what sounds reassuring. Where an answer is a mechanism, a named term, or a plain yes or no, it is worth something. Where it is a soft word doing heavy lifting, it is a follow-up question waiting to happen.
These questions are equally fair to point at us. That is the intent. The sharpest tool for interrogating any supplier should work on all of them.
Where is our data physically stored, and can you name every region and data-centre operator that holds a copy?
Why it matters
Physical location decides which state can compel access and whether you can be cut off. But location is necessary, not sufficient, a Dutch data centre operated by a US-headquartered provider is still reachable under foreign law. You need the operator's jurisdiction, not only the postcode.
A good answer
A specific list of regions and the legal operator of each facility, distinguishing primary storage from replicas and CDN tiers, plus clarity on whether that operator is EU-controlled or, if a hyperscaler, which one.
Warning signs
"In the EU" with no region named, "we use AWS or Azure so it is secure", or treating an ISO 27001 certificate as an answer to a location question.
Where are backups, snapshots and disaster-recovery replicas stored, and under whose control?
Why it matters
Backups routinely leak across jurisdictions the primary store never touches, and they are the copy that survives a contract dispute or an insolvency. Custody of the backups is custody of your continuity.
A good answer
Backups pinned to the same jurisdiction and operator as primary storage, a stated retention policy, keys you control, and a way for you to hold your own independent copy.
Warning signs
"Backups are handled automatically", replicas kept in a different region "for resilience", or backup keys held solely by the vendor.
Which legal jurisdictions can compel access to our data, given your corporate ownership and that of every infrastructure provider you rely on?
Why it matters
Jurisdiction follows the corporate control chain, not the map. An EU-incorporated vendor owned by a US parent, or hosting on a US hyperscaler, exposes your data to extraterritorial law wherever the bytes sit.
A good answer
A clear statement of the ultimate parent and its jurisdiction, the jurisdiction of each infrastructure provider, and an honest acknowledgement of any extraterritorial exposure, with a process for challenging government requests.
Warning signs
"We are GDPR compliant" offered as a jurisdiction answer, no mention of parent-company ownership, or the claim that an EU region removes foreign legal reach.
Who holds the encryption keys for our data at rest, and can we hold them ourselves so you cannot decrypt without us?
Why it matters
Whoever holds the keys holds the data. Encryption with vendor-held keys protects against a stolen disk, not against the vendor, an insider, or a legal order served on the vendor.
A good answer
Support for a genuine external key store the vendor cannot bypass, with revocation that renders the data unreadable to them, and a clear distinction between bring-your-own-key and hold-your-own-key.
Warning signs
"AES-256 at rest" offered as the whole answer, BYOK described as if it were HYOK, or keys stored in the same tenant as the data they protect.
Can we export all of our data, including metadata, audit logs and attachments, in open documented formats, and how?
Why it matters
Export is the precondition of leaving, and "all your data" is usually narrower than it sounds. If the rows export but the relationships, history and audit trail do not, the export is not restorable.
A good answer
A self-service, complete export in open documented formats, available via API so it can be automated and tested, with no punitive egress fee.
Warning signs
Export limited to PDF or CSV reports, attachments or history excluded, export only on a support request, or a proprietary format only their tooling reads.
Can an export be restored into a working system elsewhere, and will you support a test restore before we sign?
Why it matters
An export you cannot restore is backup theatre. Portability is the round trip, and the only honest proof is a restore you have actually performed.
A good answer
A documented import path into at least one alternative, a schema and data dictionary so relationships survive, and willingness to support a proof-of-concept restore during evaluation.
Warning signs
"The data is yours, you can export it" with no restore story, no schema documentation, or treating a successful export as a successful restore.
Can we run this software ourselves, self-hosted or in our own tenancy, now or as a contractual fallback?
Why it matters
The strongest form of software sovereignty is the option to run the software where you choose. Even unused, it changes the balance of power and gives you a continuity path.
A good answer
A real self-hostable artefact or single-tenant deployment, clear licensing, or, where unavailable today, a contractual right to a self-host build or source escrow triggered by defined events.
Warning signs
"We are SaaS only" with no fallback, or a "self-hosted" option that still phones home to the vendor for core function.
Which subprocessors process our data, what does each one do, and where are they?
Why it matters
Your real exposure is the union of every subprocessor's jurisdiction and posture, not the vendor's alone. A vendor pinned to the EU that routes analytics or AI inference through a US subprocessor has re-exported your data without you noticing.
A good answer
A current, public, itemised list naming each entity, its function and its jurisdiction, including the less obvious ones like analytics, error tracking and AI inference, and referenced in the DPA.
Warning signs
No list, a vague "trusted third parties", or a list that omits analytics, support and AI vendors.
How and how far in advance will you notify us of new or changed subprocessors, and can we object?
Why it matters
A subprocessor list is a snapshot. Sovereignty survives over time only if changes are governed, with notice, a right to object, and a no-penalty exit when you cannot accept a change.
A good answer
A defined notification mechanism with meaningful advance notice, a contractual right to object, and a right to terminate without penalty if you cannot be accommodated, all in the DPA.
Warning signs
"We may update our list from time to time" with no notice period, notice only after the change, or an objection that only entitles you to keep paying while you leave.
What exactly happens to our data, and our access, on termination: expiry, breach, non-payment, or your insolvency?
Why it matters
The exit clause is where ownership is proven or lost. The dangerous cases are the involuntary ones, a dispute or an insolvency is exactly when you most need your data and most risk being locked out.
A good answer
A defined retrieval window with export preserved even during a payment dispute, a deletion timeline after retrieval, a specified insolvency outcome, and a commitment that access is never used as leverage.
Warning signs
Immediate cut-off, access suspended during disputes, silence on insolvency, or "deleted within 90 days" with no way to retrieve it first.
How do you prove that data has actually been deleted, across primary storage, backups and subprocessors?
Why it matters
Deletion is the least verifiable claim a vendor makes and the easiest to fake. Data deleted from the application often persists in backups, logs and subprocessor systems for months.
A good answer
A concrete deletion process covering primary storage, backups, logs and subprocessors, with a timeline for each and a certificate or audit-log artefact you can verify, and crypto-shredding where physical deletion lags.
Warning signs
"Data is deleted immediately" with no mention of backups, no certificate or evidence, or deletion that covers the application but not backups and subprocessors.
Can we control our own identity provider and authentication, and does the integration follow open standards?
Why it matters
Identity is the control plane for everything else. If the vendor owns your identity layer you cannot cleanly revoke access at exit, enforce your own policy, or cut off a compromised account on your schedule.
A good answer
Support for bringing your own identity provider over SAML or OIDC with SCIM provisioning, you control MFA and session policy, and de-provisioning through your IdP immediately revokes access.
Warning signs
Vendor-proprietary accounts only, SSO gated behind a premium tier, no SCIM, or recovery paths that bypass your IdP.
Put this to work
Assess yourself
Take the self-check
Ten questions, answered in your browser. Nothing is stored.
Related concept
Data residency
Where your data physically sits. It is a necessary question and a long way from a sufficient one, because location is a weak proxy for control.
Related concept
Encryption key custody
Who controls key material, key policy, decryption requests and revocation, and which technical or operational paths can still reach plaintext.
Where we can help
Talk to the team
Once you have the answers, working out which gaps are dealbreakers and how to close them in your own tender is where a second pair of eyes helps most.