This is not legal advice. It is the practical checklist we built for ourselves while working with clients in Germany, Italy and the UK, and repeat on every new project. It does not replace your lawyer, but it makes the meeting with your lawyer far shorter.
The basic frame: your client is the controller, you are almost certainly the processor, and every cloud service you use is a sub-processor. Once you place those three words correctly, the rest of the list falls into order by itself.
GDPR is not paperwork; it is an architectural decision. The documents describe the architecture — they do not replace it.
01The contract layer: a DPA and standard contractual clauses
You need a signed data processing agreement with every EU client. Because Türkiye has no adequacy decision, if data will be processed in Türkiye that DPA is accompanied by standard contractual clauses and a short transfer impact assessment. In practice these three documents travel together, and once prepared well they are reused on every project.
Step two is the sub-processor list. Every service you use — hosting, transactional email, error tracking, analytics, backups — is listed with its name, purpose and region, and that list is shared with the client. Adding a line to it is a notifiable event under the contract, which is why keeping it as a page and linking to it is the most practical approach.
02The architecture layer: region, retention, deletion
For EU clients our default is unambiguous: database and object storage in an EU region (Vienna or Ireland), with backups staying in the same region. That one decision simplifies the answers to the hundred questions that follow. If the development team accesses it from Türkiye, that is remote access and is described as such in the DPA.
Retention periods are written per data type: contract and invoice records for the years the law requires, marketing consents until withdrawn, server access logs ninety days, candidate CVs six months. Encoding those periods in the software — a deletion-due field and a nightly job — is more reliable than writing them in a document.
Treat deletion and export requests as a feature from day one. If you can export and erase one user's data in a single operation, the statutory thirty-day window stops being a source of stress. Bolting it on later is always hard, because by then the data has spread across five tables.
03Daily practice: cookies, forms, breach plan
The cookie banner is not a design element but a technical promise: analytics and marketing scripts must not load before consent, and "reject" must be as visible as "accept". A site that gets those two right has already cleared the first two items on any audit list.
On forms, separate the purposes: a project enquiry and a newsletter subscription are two different consents, and no box arrives pre-ticked. Every form links to a privacy notice, and that notice actually describes the fields on that form.
The last item is the one nobody wants to prepare: the breach plan. One page stating who gets notified, where the logs are read from, what you write to the client, and who owns the seventy-two-hour clock. Writing that page on a calm day is far cheaper than writing it on a bad one.
Written by
The Paradigma7 team
Product, engineering and operations
We are an Ankara-based team building software for Europe. Nothing here is theory: these are the processes we actually run on client projects.
About us