GDPR does not list technology to install. Article 32 asks for security measures appropriate to the risk, and Article 25 asks for data protection by design and by default. For engineers that translates into a data inventory, minimisation, encryption, access control, logging, tested restores, deletion that works and a breach process that can meet a 72 hour clock.
What does the regulation actually require from engineering?
Four articles do most of the work.
Article 25 says controllers should implement measures so that, by default, only personal data necessary for each specific purpose is processed. It applies to how much data you collect, how far you process it, how long you keep it and who can reach it.
Article 32 names examples of measures: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore access to personal data after an incident, and a process to regularly test and evaluate the effectiveness of your measures. It also says the level of security should reflect state of the art, cost and risk.
Article 30 requires records of processing activities, with a carve out for organisations under 250 people unless processing is not occasional, risky, or involves special category data.
Article 33 requires notifying the supervisory authority of a breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to risk people's rights and freedoms.
This is not legal advice. Your data protection officer or counsel decides what applies to you.
The checklist, grouped by what engineers touch
Know where personal data lives. Build a data map from real systems: databases, object stores, logs, analytics tools, backups, support tools, third party processors. For each, record the data categories, purpose, owner, retention and location. This map feeds Article 30 records.
Collect less. Review every form, API field and event payload. If no purpose needs a field, remove it. Default new fields to off. Strip personal data from logs and analytics at the source.
Protect it. Encrypt in transit and at rest, manage keys separately from data, and pseudonymise where a use case allows. Enforce least privilege and multi factor authentication on anything that can read production personal data. Separate production data from development environments.
Keep it available. Back up, and test a restore on a schedule. Article 32 speaks of timely restoration, so a backup you have never restored does not count for much.
Log and review. Record who accessed personal data and what admin actions were taken. Keep logs long enough to investigate, but treat the logs themselves as personal data with a retention limit.
Delete properly. Build deletion and export as features: a user request should reach the primary database, caches, search indexes, analytics and backups (by documented expiry). Test it with a synthetic user.
Control processors. Each vendor handling personal data needs a contract under Article 28 and an entry in your records. Include software suppliers whose components process data on your behalf.
Prepare for a breach. Have a runbook, an on call owner, a template for the authority notification and a decision log that records when you became aware.
Who does what?
Engineering owns the technical measures and evidence. A privacy lead or DPO owns the records, lawful basis and assessments. Security owns incident handling. Legal owns contracts. One named person should hold the master checklist, or items will sit in the gaps.
What evidence should you keep?
Screenshots age badly. Prefer exports and artefacts a reviewer can re-check: the data map with a review date, encryption settings from configuration, access reviews with approver names, restore test results, deletion test results, vendor contracts, breach drill notes and the change history of your privacy notice.
Mistakes that show up again and again
- A data map made once in a spreadsheet and never updated.
- Personal data leaking into logs and error trackers.
- Deletion implemented only in the main database.
- Backups with no stated retention.
- Treating a certification or code of conduct as proof of compliance. Article 32 only says adherence may be used as an element to demonstrate it.
- No record of when the company became aware of an incident.
What to do
- Build the data map from systems, not from memory, and assign an owner per system.
- Cut collection fields and default new ones off.
- Turn on encryption, least privilege and multi factor authentication for every store holding personal data.
- Schedule restore tests and deletion tests, and keep the results.
- List every processor and check each has an Article 28 contract.
- Write the breach runbook and rehearse the first 24 hours.
- Review the whole list at least yearly and after major changes.
Quick check
Is encryption mandatory under GDPR?
Article 32 lists encryption as an example of an appropriate measure, not a blanket mandate. The test is what is appropriate to the risk. In practice, not encrypting personal data in transit or at rest is hard to defend.
Does a small team need records of processing?
Article 30 has an exemption for organisations under 250 people, but it does not apply if processing is not occasional, is likely to risk people's rights, or includes special category data. Most software companies keep records anyway.
Sources
- Art. 25 GDPR, data protection by design and by default
- Art. 32 GDPR, security of processing
- Art. 30 GDPR, records of processing activities
- Art. 33 GDPR, notification of a breach to the authority
- Art. 28 GDPR, processor
The links point to an unofficial reproduction of the regulation text; the authoritative version is on EUR-Lex.
How Safeguard helps automate this
Several items on this list are evidence problems, and that is where automation pays. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems instead of screenshots, and monitoring continues between reviews. For Article 32 style questions about software, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, so you can show which vulnerable components are actually exercised. The remediation agent can open tested fix pull requests for vulnerable dependencies, but it is off by default, every category starts on Manual, and you pick which categories run automatically. Safeguard helps you prepare and keep evidence ready; your regulator and counsel decide compliance.
See the framework mapping demo or book a call.
Last reviewed: 18 October 2026.
