"Where is our data?"
It sounds like a simple question. Depending on the system, the answer may involve a primary database, object storage, backups, logs, email notifications, analytics, support systems and replicas.
That is why we ask it early, while the answer is still a design decision rather than an archaeology project.
Geography is only one part of location
Customers usually ask whether the data is in the EU. That matters for regulatory, contractual and organisational reasons, but the country is only the first layer.
We also want to know which provider holds it, which facility, which system, which backups, and which third parties receive copies. "EU hosted" can describe a surprisingly complicated path.
Applications create copies quietly
A user uploads a document. The application stores it. A backup copies it. A search index reads its text. A log records its filename. An email notification includes an excerpt. A monitoring tool captures an error containing part of the request.
None of those copies is necessarily wrong. They simply need to be known about, because every one of them is a place the data now has to be protected, retained and eventually deleted.
Data maps make architecture better
Knowing where data moves helps with more than compliance. It exposes unnecessary integrations, forgotten stores and single points of failure. It clarifies what actually has to be backed up, and it makes incident response much less speculative.
It also makes deletion requests and retention policies possible to implement correctly, rather than approximately.
Backups count
A system has not forgotten data merely because the production database deleted it. Backups deliberately preserve history, so retention and deletion requirements have to account for them.
The answer is rarely to surgically rewrite every backup. It is usually to design sensible retention and make sure expired backups actually disappear on schedule.
Ask before building
It is far easier to control data flows while designing a system than to reconstruct them years later from the code.
So we ask where the data starts, where it needs to go, who needs access to it and how long it has to exist. Then we try not to create extra copies without a reason.