Privacy in software projects: the five questions before the start#
27 October 2026 · updated: 27 October 2026
1. Where does the data live — and what does that mean?#
"On our server" is not an answer until you can say: with which provider, in which country, in what legal form. The enumeration sounds bureaucratic and is the heart of the matter: the data location decides access routes, disclosure practice, and what happens when the provider relationship ends. My rule: the data location is decided per project — a blanket claim like "German servers" doesn't work as a brand statement, because it will already be false for the next project.
2. Who has access — and how is it bounded?#
Access lists have a habit of growing: first the developers, then support, then "just quickly" the intern. A serious setup has individual accounts with least privilege — and the honest statement of who can still see everything in an emergency. Ask concretely: "Who can read customer data in plaintext?" If the answer takes longer than one sentence, the concept is missing.
3. How long is what kept — and where is the deletion?#
Every data record needs a deadline and someone who enforces it. On my own website, for example, contact data from enquiries is deleted 12 months after the last contact. In a project, the question re-opens for every data object: what happens to an account after the business relationship ends? Do backups outlive the deadline? The answer belongs in the scope, not in a footnote.
4. Is a data processing agreement needed — and does it exist?#
As soon as a service provider processes personal data for you, a DPA is needed (Art. 28 GDPR). That affects not just the developer but everyone in the chain: hosting, mail delivery, backup storage, analytics tools. Don't ask "is privacy important to you?" — ask "which DPAs exist, and for whom are they missing?" An honest answer contains at least one open point; a perfect answer is usually the dishonest one.
5. What happens at the handover?#
The most common privacy leak at project ends is banal: the developer still has access nobody revoked. A handover therefore includes a literal checklist: repository ownership changes, credentials rotate, access is withdrawn. My handover contains that as a list (process) — the code is yours, and afterwards I should have as much access as any other external party: none.
What that means for your project contract#
These five questions are not legal advice — they are scoping content: they belong in the document that fixes scope and responsibility; with me it is called the scope sheet. A project that answers them in week 1 builds privacy into the architecture; a project that answers them in week 12 builds them into its apology letters.
This matters most where the data is sensitive from the start — practice, firm and client data. For that sector I wrote the dedicated page software for practices and firms; there, what I say about data handling comes first, and what I build comes second.
Soft CTA: if you are about to start a project and unsure whether your questions are covered: free 20-minute intro call — without a sales agenda, with concrete answers.