Guide
Privacy and GDPR in software projects
This guide is not legal advice: it is how we handle personal data when we build software, and which technical decisions make a project compliant without surprises.
Last updated:
The GDPR is the European data protection regulation. Much of its obligations are met through engineering decisions taken in time. When they are left to the end, the bill is a redesign. What follows is the technical part; the legal questions (appointing a DPO, running risk assessments, drafting clauses) are for a legal professional.
Minimisation: the data you do not hold cannot leak
Before adding a field, the question is what it will be used for. If there is no concrete answer, it is not collected. Less personal data means less risk surface, fewer obligations and less work to answer an access or erasure request.
Legal basis and purpose
Every processing needs a legal basis (consent, contract, legitimate interest, legal obligation…) and a stated purpose. In practice this shows up in the software: separate data by purpose, do not reuse it for a different purpose without review, and — where consent is the basis — make it granular and as easy to withdraw as it was to give.
Processors and sub-processors
Every external service that touches personal data — hosting, transactional email, analytics, backups, an AI provider — is a processor and needs a contract (DPA) and, if it is outside the European Economic Area, a transfer safeguard. Keep an up-to-date list of sub-processors: it is required and it is also the inventory you need to reason about risk.
- An inventory of where personal data goes and with which provider.
- A signed DPA with each one and the processing location identified.
- Prefer providers processing in the EU when equivalent alternatives exist.
Security (Article 32)
The regulation asks for measures "appropriate to the risk", not a fixed list. In software that means encryption in transit and at rest, role-based access with least privilege, logging of access to sensitive data, tested backups and a plan for what to do in a breach (there are 72 hours to notify).
Privacy by design and rights
Privacy by design and by default (Article 25) means the most protective option is the one enabled out of the box. And from day one the system has to be able to answer data-subject rights: access, rectification, erasure, portability and objection. If deleting a user means a half-hour manual script, the design is not finished. See also the site privacy notice.
FAQ
What people ask us
Does Fona act as a DPO (Data Protection Officer)?
No. We work on the technical side: data architecture, security, minimisation and the ability to answer rights. The DPO role and legal advice are covered by a legal professional we coordinate with.
Does using a US AI provider break the GDPR?
Not automatically, but it is an international transfer that needs a basis (standard contractual clauses, an adequacy framework) and a risk assessment. And it is best not to send more personal data to the provider than strictly necessary.
What does "privacy by design" mean in practice?
Making the privacy decisions at the start, not the end: what is stored, for how long, who has access, how it is deleted. And making the default configuration the most protective for the individual.
How long can data be kept?
As long as needed for the purpose, then anonymised or deleted. In software that means defining a retention policy per data type and automating the deletion, not leaving it to manual judgement.
Related services
Related guides
Keep reading
Next step
Half an hour well spent
Walk us through the problem on a short call. You leave with a first read on how we'd approach it and what it would involve — no commitment, no sales deck.