GDPR-compliant software development: a practical guide

In short: GDPR-compliant software development starts with the architecture, not with the cookie banner. Article 25 GDPR requires data protection by design and by default. In practice that means collecting only the data you really need, limiting access, enforcing retention periods in code, serving data subject rights through features and bringing service providers in under proper contracts. Planning this early saves expensive rework.

What the GDPR actually requires from software

The GDPR is written to be technology neutral. It prescribes principles rather than specific tools: purpose limitation, data minimisation, storage limitation, integrity and confidentiality. For development teams, three places matter most. Article 25 calls for privacy by design and privacy by default. Article 32 requires security of processing appropriate to the state of the art. And the data subject rights in Articles 15 to 21 must be something users can actually exercise in the software.

One note up front: this article covers technical implementation. The legal assessment of a specific case belongs with your data protection officer.

Privacy by design in the architecture

Data minimisation in the data model

Every field in the data model should have a clear purpose. Do you need the date of birth, or is confirmation of legal age enough? Does the customer account need a phone number? Data you don't store can't be lost and never has to be disclosed.

Pseudonymisation and separation

Personal data can often be separated from usage or analytics data. Analyses then run on pseudonymous IDs, and the link to the person sits in a separate, more tightly protected table. For test and development environments, use anonymised or synthetic data instead of copies of the production database.

Access control on a need-to-know basis

Roles and permissions belong in the design from the start. Someone working in support doesn't need access to payment data. Access to sensitive data should be logged, so you can later trace who saw what. The basics of secure login and session handling are covered in our article on authentication with OAuth, JWT and sessions.

Encryption

Encrypted transport via TLS is standard. Add encrypted disks and backups, and application-level encryption for particularly sensitive fields. Passwords are never stored encrypted. They are hashed with a purpose-built algorithm such as Argon2 or bcrypt.

Consent, tracking and cookies

For cookies and similar technologies that are not strictly necessary, German law (Section 25 TDDDG) requires prior consent. This typically affects analytics and marketing tools. Technically, those scripts may only load after consent has been given. Declining must be as easy as accepting, and users must be able to change their decision later.

An alternative is analytics software that works without cookies and without personal data, hosted on your own or EU servers. In many cases that removes the need for a consent dialog for audience measurement. Check this for your case with your data protection adviser.

Data subject rights as features

Access, rectification, erasure and data portability are rights users can invoke at any time. If every request needs a manual database query from the developers, it quickly becomes expensive and error-prone. Built-in features work better:

• an export of all data on a person in a machine-readable format such as JSON or CSV
• a delete function that covers all linked records, including those in connected systems
• a deletion policy with automatic retention periods, for example for inactive accounts or old enquiries
• a documented approach to backups that states when deleted data disappears there too

Statutory retention obligations, such as those for invoices, take precedence over deletion. The software must then be able to restrict that data instead of deleting it.

Service providers, hosting and third countries

Every external service that processes personal data on your behalf needs a data processing agreement under Article 28. That applies equally to hosting, email delivery, error monitoring and AI APIs. Keep a list of all services; it also feeds into your record of processing activities.

For providers outside the EU, check the legal basis for the transfer, for example the EU-US Data Privacy Framework or standard contractual clauses. Hosting in Germany or the EU simplifies these questions considerably. More on that in data hosting in Germany. If you add AI features, also keep the requirements of the EU AI Act in mind.

You also need a process for incidents: personal data breaches generally have to be reported to the supervisory authority within 72 hours. Good logging and monitoring are the precondition for noticing and assessing a breach at all.

Frequently asked questions (FAQ)

Is a cookie banner enough for a GDPR-compliant website?

No. The banner only handles consent for certain technologies. Data minimisation, security, deletion, processor agreements and data subject rights have to be in place regardless.

Can I use US cloud services?

In principle yes, if there is a valid transfer mechanism and a data processing agreement is in place. Many large providers also offer EU data centres. Document the decision and agree it with your data protection adviser.

When should data protection come into a software project?

At the design stage, before the data model is settled. Adding a deletion policy or role separation afterwards is far more work than planning it from the start.

Do I need a data protection impact assessment?

If the processing is likely to result in a high risk to the people affected, for example large-scale processing of health data or systematic monitoring. Whether that applies is best clarified early with your data protection officer.

Conclusion

GDPR compliance is largely a question of good software architecture: little data, well protected, clear responsibilities and features that enforce rights and retention periods automatically. Teams that treat it as a requirement from day one end up building more secure and easier-to-understand systems almost as a side effect.

If you are planning an application that processes personal data, talk to us about web development.