If you have read the last few posts, you already know what I am going to ask when someone says a custom app will hold “client data”: what data?
Yes, we are doing this again. I keep asking because nobody can make a sensible security decision while that phrase is doing all the work.
“Client data” could be a work email address. It could be a copy of someone's passport. It could be the code to their front door. It could be a folder of financial records that their competitors would enjoy reading. Putting all of those under one label tells me only that the information belongs to a client.
I still have no idea what would happen if the wrong person saw it.
Someone says the application will hold client data, and suddenly we are discussing compliance requirements before anyone has described a single record. Sometimes even the person ordering the software has not worked out what will go in it.
Let’s use a less imaginary business
Suppose a company sends technicians to customers' homes. It wants a small application for enquiries, appointments and job notes.
At first, the app stores a name, phone number, address and preferred appointment time. That is personal information. The company needs to protect it and decide who should see it. But a scheduler being able to view the address is part of the job.
Now someone adds a field for access instructions. One customer types “side gate is open.” Another types the alarm code. A third says they will be away for two weeks and asks the technician to come while the neighbour has the key.
The field is still called “job notes,” but it now contains information someone could use to get into a customer's house.
Then the owner suggests uploading photos of each property. Some are pictures of the equipment being repaired. Others show the customer's living room, children in the background, or a document sitting on a table. The app did not ask for any of that, but it now holds it.
I would not design those versions of the app the same way. I also would not rule out the project just because a technician needs a customer address.
I would ask what the business actually needs to collect, and what people might put into the fields even if we did not intend them to.
A field name cannot tell you what is inside it
Developers like tidy categories: customer, appointment, note, attachment. Customers are less interested in our database schema. They put useful information wherever the interface lets them.
Give people a blank notes field and it may fill up with whatever helps them finish the job: passwords, medical details, complaints about staff, instructions for getting into a home. Add an upload button and someone might send a passport scan because it seemed useful at the time.
Before building either field, I would ask what the team actually needs. An alarm code might be needed for one visit. It does not have to live in the job history forever. If the business never needs one, the app should not ask for it.
The UK's Information Commissioner's Office calls this data minimisation: collect personal information that is relevant to the purpose, limit it to what you need, then review and delete what you no longer need. Its guidance is refreshingly direct.
In the EU, the GDPR also sets out purpose limitation and data minimisation in Article 5. The specific legal duties depend on where and how a business operates. Wherever the business is, I would still ask: why are we keeping this information at all?
The same detail can matter more in context
A person's email address might already be public on their company website. Put that same address in a leaked list of people who contacted a debt adviser and the list reveals something the person never made public.
An address has the same problem. A technician needs to know where to go. Pair that address with a door code and a schedule saying when nobody is home, and you have created a much more consequential record.
This is why I dislike the idea of choosing a security level from a noun. “Email” is a noun. “Client data” is barely even that. Neither tells us what someone could learn or do if the information reached the wrong person.
A design studio might also keep a client's unreleased product plan in its portal. If that leaks, a competitor could see what the client is making before launch. I would want to know about that folder too.
Work backwards from who needs to do what
For our technician app, the scheduler might need contact details and appointment times. The technician might need the address and repair notes for jobs assigned to them. The accounts person might need invoices without reading every photo uploaded from someone's home.
That is a conversation a business owner can participate in. “Who needs this?” is easier to answer than “What is your preferred access-control architecture?”
Once we know the roles, the developer can turn them into permissions and test them. A technician should not be able to change the address in the browser and pull up another customer's file. A former employee's account should be disabled when they leave. OWASP's guidance on authorisation recommends checking permission for each request and denying access unless it is explicitly allowed.
Some information should not go into a general job note at all. If a customer sends the team a password to another service, I would ask why they need that access and how they are supposed to handle it. Pasting the password beside an appointment is a bad plan.
The information the business does need will not all be useful for the same length of time. An address may be needed for the visit and the invoice. A door code may only be needed until the appointment is over. I would rather settle that before launch than discover years later that every old job record still contains an entry code.
Here is the conversation I would rather have
Before anyone sells the business an expensive answer, I would ask:
- What information does the app need to do its job?
- What could users type or upload that the business did not intend to collect?
- Who needs to see each kind of information, and for how long?
- If one employee account is compromised, what records could it reach?
- What would happen to a person or a client if a particular record were exposed?
- Which information can we avoid storing, shorten the life of, or keep with a specialist service?
If the answers are boring, great: build a boring scheduling tool. If they raise difficult questions, bring in the right specialist or consider another product. At least the decision is about a real application.
Please tell me what is actually in the database before telling me how terrifying it is.