GDPR and Custom Software: What to Watch Out For

The GDPR regulates how organizations within the EU must handle personal data: from names and email addresses to IP addresses and behavioral data. Almost every application that registers users, customers or employees processes personal data in some way. Think of a customer portal, a CRM integration, a registration form or a dashboard with user statistics.

With off-the-shelf software, part of the responsibility lies with the supplier. With custom software, you design the data processing yourself, together with your development partner. That means more freedom, but also more responsibility: you can't hide behind the settings of a standard package. Errors in the data model or architecture can directly lead to a GDPR violation.

Two core concepts from the GDPR that directly affect software development are privacy by design and privacy by default. Privacy by design means that privacy protection is considered from the very first design stage, not added afterwards as a separate component. Privacy by default means that a system defaults to the most privacy-friendly setting, for example by only collecting strictly necessary data.

In practice, this translates into concrete architectural choices: which fields are mandatory, which data is logged and which isn't, who has access to which data, and how long data is retained. Ideally, these choices are made before a single line of code is written, not afterwards.

The GDPR requires that you only collect data that is necessary for a clearly defined purpose (purpose limitation), and no more than that (data minimization). In custom software, this is an important point of attention during the functional analysis: every field in a form or database should be justifiable.

In our experience, clients are often inclined to add extra fields or tracking options "just in case," because it might come in handy later. From a GDPR perspective, that's a risk: data you don't need is better left uncollected. Our approach is usually to critically examine at the start of a project which data is actually functionally necessary, and deliberately leave out the rest.

The GDPR requires organizations to take appropriate technical and organizational measures to protect personal data. For custom software, this includes encryption of sensitive data, a well-thought-out permission system (who can view or edit which data), secure connections, and logging access to personal data.

Security and privacy are closely related but not the same: a well-secured system can still violate the GDPR if, for example, it collects or retains too much data. You can read more about the technical side of security in our article on securing custom software.

The GDPR gives people a number of rights over their own data: the right to access, rectification, erasure ("the right to be forgotten"), data portability, and objection to certain types of processing. With custom software, you need to think about how these rights are facilitated technically.

Can a user request or delete their data without a developer having to manually dig through the database? Is there an export function for data portability? It's best to add this functionality during development, since building it in afterwards is often more complex and costly, especially in systems with integrations to other platforms, such as a web portal or intranet or an e-learning platform with an LMS integration.

When you engage an external agency to build or host custom software, and that agency comes into contact with personal data in the process, a data processing agreement is legally required. This sets out who is responsible for which processing activities, which security measures apply, and how data breaches are handled.

It's important to clarify who is the data controller in your situation (usually the client) and who is the processor (often the development agency or hosting provider). This division also determines who needs to take which steps in the event of, for example, a data breach.

To structurally incorporate GDPR compliance into a software project, we generally follow these steps:

1. Map out which personal data you actually need and why (purpose limitation).
2. Determine who should have access to each type of data and record this in a permission system.
3. Deliberately choose privacy-friendly default settings (privacy by default).
4. Build in functionality for viewing, correcting and deleting data.
5. Ensure appropriate security measures such as encryption and logging.
6. Record agreements with external parties in a data processing agreement.
7. Consider a Data Protection Impact Assessment (DPIA) for high-risk processing activities.

This roadmap is no guarantee of full compliance — legal advice is often needed as well — but it does ensure privacy becomes a built-in part of the development process rather than a separate checklist afterwards. This applies not only to complex platforms, but also, for example, when you have a custom website built with a contact form or customer account.