What the law expects, in the Commission’s words
| Requirement | What the European Commission says |
|---|---|
| Data protection by design | Measures “at the earliest stages of the design of the processing operations”, such as pseudonymisation and encryption |
| Data protection by default | The most privacy-friendly setting from the start — only the data needed, kept for the shortest time, accessible on a need-to-know basis |
| Requests from individuals | Answered without undue delay, in principle within 1 month, free of charge |
| Breaches | Reported to the supervisory authority within 72 hours of becoming aware, if likely to risk people’s rights |
| Fines | Up to €20 million or 4% of total annual worldwide turnover |
Sources: European Commission — Obligations, Dealing with requests from individuals, Enforcement and sanctions. Checked 5 October 2026.
Five examples of GDPR requirements worth writing down
Examples, not a complete list, with illustrative wording — the right set depends on what your app does and whose data it holds.
- What is collected, and why. “At sign-up we collect name and email to create the account. We do not collect date of birth.” A field nobody can justify is a field to remove.
- How long it is kept. “Closed accounts are deleted after 30 days; invoices are kept for the period tax law requires.” Without this, everything is kept forever by default.
- Who can see it. “Support staff see a customer’s orders, not their payment details.” By default means need-to-know.
- How people exercise their rights. “A user can download their data and request deletion from their account page; requests are logged and answered within one month.”
- How a breach is noticed. “Unusual access to customer records raises an alert to a named person.” You cannot report within 72 hours what you never noticed.
Each one is testable. That is the point of putting them in the specification: when the app is delivered, you can check it does what the requirement says.
Why after launch is too late
A privacy policy written after launch describes what the app happens to do. A specification written before build decides what it should do. Retention rules, access limits and data export are cheap as requirements and expensive as retrofits — they reach into screens, data structures and every report already built.
What to ask a vendor about GDPR
- Where in the specification are the GDPR requirements? If the answer is “in the privacy policy”, they are not in the build.
- Which outside services will hold personal data — and where?
- How will a user get or delete their data?
- What evidence will you receive to show the app does what the requirements say?
- Does the vendor claim to make you compliant? Nobody’s vendor can.
How Pricient handles GDPR
You do not have to know which framework applies — the project tells us, and the quote carries it. When a project involves personal data of EU residents, GDPR is spotted, not left to you, and its requirements are written into the specification you receive before you pay anything. The evidence an auditor asks for — a control-mapping binder, data-flow diagrams showing where personal data enters, moves, rests and leaves, and drift checks that fail the build if a later change breaks a control — is produced as the work is done.
Audit-ready by default, never self-certified. We do not make you compliant; we make your auditor’s job faster. This guide is general information, not legal advice.