Before anyone touches your client information, ask for a data map. It is one document. Any vendor serious about handling your records can produce one in a day. If they cannot, that is your answer, and you have learned it before signing anything.
This guide explains what a data map is, what it should list, and the questions to ask whoever is about to connect to your systems.
What a data map is
A data map follows one piece of information from the moment it enters a system to the moment it is deleted. It names every step along the way, where each step happens, how long the information stays there, and who can see it.
It is not a privacy policy. A privacy policy is written for the public and says what a company may do. It is not an architecture diagram either. A diagram shows boxes and arrows for engineers. A data map is plainer than both. It is written for the owner of the business, and it describes what will happen to a specific record, such as one call, one invoice or one client file.
If you can read the map and say out loud where a client's phone number goes, the map is good enough.
What it should list
A data map has four parts. Each one answers a question an owner would ask.
Every step
List what happens to the information, in order. A call is recorded. The recording is turned into a transcript. The transcript is summarised. The summary is written to the client's file. The recording is deleted. Each of those is a step, and each one deserves its own line. Steps that are skipped in the map are the ones that go wrong later.
Where it is processed
For every step, name the place. Your own server. A vendor's server. A model provider's service. A laptop. Name the country as well, because the law that applies to the information changes with the border. "In the cloud" is not a place.
How long it is kept
For every place, say how long the information stays. "Until the transcript is confirmed." "Thirty days." "As long as the client file exists." "Never stored, processed in memory and discarded." If a step has no retention answer, the honest answer is probably "indefinitely", and you should know that.
Who can access it
For every place, say who can see the information and under what conditions. Your staff by role. The vendor's engineers, and whether they need your permission first. The model provider, and whether it uses the information to train or improve its models. Automated systems that read it without a person involved.
Here is how the four parts fit together for one recorded call. The rows are an example, not a rule.
| Step | Where | Kept for | Who can see it |
|---|---|---|---|
| Call recorded | Phone system, Canada | Until the transcript is checked | Office staff |
| Transcript made | Model provider, by API | Not stored by the provider | The system only |
| Summary written | Your practice software | As long as the client file | Staff with file access |
| Reviewer approves | Your practice software | Logged with the file | Staff with file access |
| Recording deleted | Phone system | Gone | Nobody |
A real map is longer, because real workflows have more steps. The shape stays the same.
Questions to ask any vendor
Put these to anyone who proposes to connect to your systems or read your files. Ask for the answers in writing.
- Which of our records leave our systems, and where do they go?
- Is any of our information used to train or improve a model? For whom?
- Where are the servers, and in which country?
- Which people at your company can see our data, and when?
- What is deleted, when is it deleted, and how can we check?
- What happens to our data when the contract ends?
- What happens when something goes wrong, and how soon do we hear about it?
- Will you give us this map in writing, and update it when the system changes?
A vendor who answers all eight without hesitation has done this before. A vendor who answers most of them and says "let me confirm" on the rest is being careful, which is fine. A vendor who treats the questions as unusual has not thought about your information as carefully as you have.
Reading the answers
Good answers are specific. "Transcripts are sent to the model provider over an encrypted connection, processed in memory, and not retained. We have the provider's written retention terms and can share them." That answer names a step, a place, a retention period and the evidence.
Weak answers are reassuring and vague. "Your data is fully secure and never shared." That sentence contains no step, no place, no period and no evidence. It may be true. You cannot tell.
If a sentence about your data does not name a place and a time, it is a feeling, not a fact.
Watch for two things in particular. First, any step where information is copied to a second place "for convenience" or "for backup" without its own retention answer. Second, any model provider whose terms allow training on submitted content by default. Both are common, both are fixable, and both are much easier to fix before the system is built.
Who should own the map
The map belongs to you, not to the vendor. Keep a copy with your other records of the business. When a staff member asks where client information goes, the map is the answer. When a client asks, the map is the answer. When a regulator asks, the map is the start of the answer.
It also makes vendors easier to compare. Two proposals that sound alike on a call look different once each one has to write down where every record goes and for how long.
Keep it current
A data map describes a system at one moment. Systems change: a new step is added, a provider is swapped, a retention period is shortened. Each change should produce an updated map, and the updated map should reach you before the change goes live, not after.
We write a data map for every system we build, before the build starts, and we update it with every change. If you are reading this before a first project, the easiest way to begin is to take the workflow you chose and write the four columns yourself for the way the work is done today. You will find the first gaps before any vendor does.
For how we handle client information in our own practice, read Security and trust. For choosing which workflow to map first, read How to choose the first workflow.