GDPR by Design: What It Actually Means in a Software Specification

"Can you confirm this is GDPR compliant?" One of the most common questions on a spec review — and one of the least answerable as asked. GDPR compliance is not a binary property. It is an architectural posture.

Data minimisation: you must specify what you don't collect, not just what you do. A compliant system collects the minimum personal data necessary for each processing purpose — and documents those purposes before build begins.

Cookie consent architecture: how it should work versus how it usually works. The consent mechanism must be presented before any non-essential scripts load, with genuine parity between accept and refuse options — not a dark pattern with a large accept button and a buried refuse link.

Server-side versus client-side processing: sensitive operations — authentication, payment, personal data retrieval — should run server-side. Executing these in the browser exposes them to third-party scripts that may be loaded without consent.

EU data residency: the hosting decision determines your legal exposure. Storing personal data of EU residents on servers in the US creates a transfer obligation under Chapter V of GDPR. EU-region infrastructure eliminates this by default.

The data-flow map as a project deliverable: every Prime Digital Labs project specification includes a data-flow map that documents: what personal data is collected, where it is stored, who has access, how long it is retained, and the legal basis for each processing activity.