You can implement most of GDPR yourself by working in a fixed order: map the personal data you hold, decide your role and lawful basis for each use, publish clear notices, build a way to handle people's requests, contract your processors, secure the data and rehearse a breach. Bring in counsel for judgement calls. This guide is not legal advice.
Where do you start?
Start with facts, not policies. Article 5 sets out principles including purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability: the controller is responsible for, and must be able to demonstrate, compliance. Demonstrating means records. So step one is building the record of what you do.
The steps, in order
Step 1, map the data. List every system holding personal data. For each activity note what data, whose, why, who receives it, where it goes, how long you keep it and how it is protected. Include analytics, support tools, backups and marketing lists. This becomes your records of processing under Article 30, which carves out organisations under 250 people only if processing is occasional, low risk and avoids special categories.
Step 2, decide your role. For each activity you are a controller, a joint controller or a processor. Software companies are often both: controller for their own customers' account data and processor for the content customers upload.
Step 3, set a lawful basis. For each purpose pick one of the Article 6 bases, such as consent, contract, legal obligation, legitimate interests. Document why. Do not default to consent: it must be freely given and withdrawable, which can be hard to run at scale. Special categories of data need an additional condition under Article 9.
Step 4, write the notices. Tell people who you are, what you do with their data, why, on what basis, who receives it, how long you keep it and how to exercise their rights. Keep wording plain and match it to the map from step 1.
Step 5, build rights handling. People can ask for access, correction, deletion, restriction, portability and to object. You need an intake route, identity checks, a search across systems, a response template and a log. Response is generally due within one month, with limited extension; confirm the current rules with counsel.
Step 6, contract your processors. Article 28 requires a contract with each processor setting out subject matter, duration, types of data and obligations, including security and assistance. List every vendor handling personal data and check each has one. Review international transfers with counsel, since transfer rules need a legal mechanism.
Step 7, secure the data. Article 32 asks for measures appropriate to the risk and gives examples: pseudonymisation and encryption, confidentiality, integrity, availability and resilience, timely restoration, and regular testing of effectiveness. Apply data protection by design and by default under Article 25.
Step 8, assess high risk processing. Article 35 requires a data protection impact assessment where processing is likely to result in a high risk to people, such as large scale profiling or large scale use of sensitive data. Write a short screening checklist and run assessments when it flags.
Step 9, prepare for breaches. Article 33 asks you to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights. Write the runbook and run a tabletop.
Step 10, appoint and train. Check whether you must appoint a data protection officer, and name an accountable person either way. Train staff on handling requests and spotting incidents.
Step 11, review. Re-run the map and the checks yearly and when you launch new products or vendors.
Who does what?
An accountable privacy owner runs the programme. Engineering delivers technical measures and request tooling. Legal reviews bases, transfers and contracts. Marketing and support own the practices that touch most personal data. Leadership approves risk decisions.
What evidence will you want?
The data map, records of processing, lawful basis decisions, notices with version history, request log, processor contracts, security measure exports, impact assessments, breach drill notes and training records.
Where do first timers slip?
- Using consent for everything.
- A beautiful policy that does not match the real data flows.
- Deletion requests that miss backups, logs or analytics.
- Forgetting the processors that sit inside your own tools.
- No log of requests or breaches.
- Setting this up once and never revisiting it.
What to do
- Build the data map and records of processing.
- Classify your role for each activity.
- Record a lawful basis and reason for each purpose.
- Publish accurate notices.
- Create a request procedure with a log and a test.
- Check every processor has an Article 28 contract.
- Apply security measures and test restores.
- Write the breach runbook and rehearse it.
- Review yearly.
Quick check
Is consent always required under GDPR?
No. Article 6 lists several lawful bases, and consent is only one. Pick the basis that fits the purpose and document why.
When must a breach be reported?
Article 33 says to notify the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people's rights and freedoms.
Sources
- Art. 5 GDPR, principles
- Art. 25 GDPR, by design and by default
- Art. 28 GDPR, processor
- Art. 30 GDPR, records of processing
- Art. 32 GDPR, security of processing
- Art. 33 GDPR, breach notification
- Art. 35 GDPR, impact assessment
These are an unofficial reproduction of the regulation text. Articles 6, 9 and 12 to 22 are cited from general knowledge and were not fetched, so confirm them against EUR-Lex.
How Safeguard helps automate this
Several steps in this plan are ongoing evidence work. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than by screenshot, and monitoring runs between reviews. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, which also helps you see which libraries and suppliers handle data. The remediation agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Safeguard helps you prepare and keep evidence ready; it does not make you GDPR compliant, and your counsel and regulator decide that. Book a call.
Last reviewed: 18 October 2026.
