The question "where is my customer data" usually gets answered at the vendor level. In our CRM, in email, in accounting. That's an inventory of tools, not an answer to the question.

The useful answer follows the customer journey, because that's what generates the data. At each moment something is created, it lands somewhere, and someone is formally the owner. Those three rarely line up with what you'd expect.

01 / the journeyWhat data is created where?

Five moments, from first contact to completion. At each one, the question is where it lands.

There's also a shadow copy at every step, and it's almost always forgotten in this kind of inventory. An export in someone's downloads folder. A shared folder with old quotes. A mailbox going back twelve years with every file still sitting in it. Those copies fall under the same rules as the original, and in a data breach they're usually the source.

Look at steps 2 and 5. Those are the two where the most value is created and where it's least structurally recorded. That's no coincidence: they're also the two steps without a required form.

02 / ownershipWhat does "in your own hands" actually mean?

Not that you host everything yourself. But that the accounts are in your name and that you can leave.

That distinction matters more than it sounds, because it's where a lot of service arrangements get sticky. There's a difference between data sitting with a vendor on your contract, and data sitting in an environment that an intermediary manages for you. In the first case, nothing changes when the collaboration ends. In the second case, something has to be arranged, and that's exactly the moment you have the least negotiating position.

The test isn't where it's located. The test is what happens on the day you leave.

We therefore apply a separation that's worth asking any provider about: the client owns the accounts and the data, the builder owns the build layer they deliver. Anyone who notices in that conversation that no clear answer comes has already got their answer. The full breakdown of that question is in who owns it when it works.

03 / locationWhy Europe matters

Because it determines which court has jurisdiction and which government can get access.

Additional requirements apply to personal data leaving the EU, and those requirements have gotten stricter in recent years. In practice it comes down to two questions: which country are the servers in, and which jurisdiction does the parent company fall under. Those two are not the same, and the second is almost never asked.

What this means for you depends on what you process. If you work with ordinary business contact details, it's a point of attention. If you work with health data, records of vulnerable people, or personnel data, it's a design requirement, not a preference. Explored further in keeping data in Europe and in how safe is customer data in an AI system.

04 / open sourceWhat it solves and doesn't

Open source solves the exit problem. It doesn't solve the privacy question.

That distinction gets structurally blurred in sales conversations, so to be sharp about it. Open software means the source code is public and that you can, in principle, run it yourself. That lets you switch vendors without losing your data, and it lets you have what happens checked. That's real value, and it's why we build in that direction.

But: where you run it determines the privacy, not the license. Open software on a US server is still data on a US server. And open source says nothing about the quality of your own setup, your passwords, or your access rights. That remains work someone has to do.

Which parts of our own stack are open and which aren't is listed on the stack page. We think a provider should be able to answer that question without first having to consult internally.

05 / the testSix questions to ask

Ask every party that's going to do something with your customer data, preferably before anything is signed.

• Whose name are the accounts in? Not who manages them, but who is contractually the customer with that vendor.
• What happens on the day I stop? Concretely: which file do I get, in what format, and how long does that take.
• Which country are the servers in, and where is the parent company based? Two questions, not one.
• Who can access my data and how is that logged? Ask about the logging, not the promise.
• Is there a data processing agreement? If personal data flows through it, that's a legal requirement, not a formality.
• How long is what retained? Unlimited retention isn't a luxury, it conflicts with the principle that you don't keep data longer than necessary.

Ask them in writing. Not because a conversation is unreliable, but because an answer on paper still exists later, even after the account manager who gave it has moved on somewhere else.

We publish our own answers to those questions in the privacy statement. Not because it's required, but because it's the only way to keep ourselves sharp about them.

A provider that finds these six difficult hasn't thought about it. That, by itself, is the answer.

This text was produced with AI assistance and reviewed and approved by a human before publication.