How does custom software relate to GDPR and data in the EU? (residency, processors, subprocessors)

Not legal advice, but sound agreements

This section is not legal advice: for definitive interpretation, rely on legal counsel and, where necessary, a data protection officer (DPO). We can, however, outline what typically comes up in software projects.

Roles and responsibility

Usually the client is the data controller for the personal data that ends up in the application; the studio acts as a processor during design, build and maintenance, unless contractually agreed otherwise. This requires a Data Processing Agreement (DPA) covering purposes, subprocessors, retention periods, data export and deletion, and incident notification.

Subprocessors and the chain

A custom product almost always uses cloud, email, monitoring, analytics; these can be subprocessors. You want transparency about which parties do what, where data can physically land, and which safeguards (such as SCCs for relevant transfers outside the EEA) apply.

Residency and "data in the EU"

Residency is not a magic fix: it is about which provider, which regions, which encryption and which contractual guarantees. "Everything in the EU" can be a requirement; in practice you align hosting regions, logging and backup accordingly. This belongs early in Imagine, not at the point of going to production.

Data minimisation and privacy by design

In the application itself: minimise personal data, separate roles and permissions, avoid unnecessary logging of PII (personally identifiable information), offer export and deletion where needed, and define retention periods. Privacy by design is cheaper than retrofitting.