GDPR has applied since 2018 and touches every organisation that processes personal data. With off-the-shelf software, the supplier has already worked out what that means in practice. Custom software is different: every choice about what data you record, how long you keep it and who can access it gets made inside your own project.
That’s more responsibility, but also more control. Privacy by design, the requirement that data protection is built in from the outset, is something you have to hope for with an off-the-shelf package. With custom software, it’s a series of concrete design decisions you’re involved in yourself. Four subjects determine the difference between software that actually meets GDPR and software that only claims to on paper.
Privacy by design starts with the data model
Data minimisation is the clearest example: don’t collect more than you need for your purpose. In practice, that means looking critically at every field in the data model. Do you need a full date of birth, or just confirmation that someone is an adult? Does a closed file need to be kept in full, or does an anonymised summary do the job for your reporting?
One choice we make as standard in our own projects: never copy production data containing personal data into test and development environments, and have developers work with generated test data instead. That reduces the risk of a leak in a less strictly secured environment, and it forces everyone to work out early on exactly what data the system actually processes.
The data processing agreement sets out who is responsible for what
The moment your development partner can access personal data, for hosting, maintenance or support, that partner becomes a processor and you become the controller. GDPR then requires a data processing agreement. That’s not a formality to file away; the document sets out what happens if something goes wrong. At a minimum, make sure it covers:
- which data the partner processes and for what purpose;
- which sub-processors are involved, such as the hosting provider, and where the data is stored;
- how and within what timeframe a data breach is reported to you;
- what happens to the data once the collaboration ends.
A development partner who raises this before you ask says something about how seriously privacy is taken throughout the rest of the project.
Data subject rights need to be built into the software itself
Everyone whose data you process has the right to see it, have it corrected and, in many cases, have it deleted. If your system can’t do that, every request becomes manual work: someone digging through tables, exports and log files. With custom software, you design those functions in from the start. Think of an export of everything held on one person, and deletion that actually deletes, right down to log files and connected systems. Sometimes that clashes with other legislation that obliges you to retain data; then anonymisation is the answer, and the system needs to be able to handle that too.
The DPIA belongs in preparation, not at delivery
If you process sensitive data on a large scale or systematically track people, a Data Protection Impact Assessment (DPIA) is mandatory: a structured analysis of the privacy risks and the measures against them. Even without that requirement, it pays to answer these questions before you start building, because the outcomes shape the architecture: encryption, access rights, logging, connections with other systems. Adding it in afterwards is usually possible, but costs several times as much. And the risks aren’t theoretical: fines can reach 20 million euros or 4% of global annual turnover, and a data breach caused by an outdated integration can start exactly this way.
The best first step doesn’t require legal expertise: map out what personal data you process, for what purpose and who can access it. With that overview on the table, every conversation about new software becomes concrete straight away, including the conversation with us. When we develop custom applications, we run that inventory as standard at the start of the design phase.