Every GDPR consultancy will hand you a checklist with forty-seven points on it. The problem is not the points - most of them are real. The problem is that running them in order takes nine months, three full-time hires, and a budget that does not exist outside a Fortune 500. The version that fits inside a real product team's quarter looks different. It is about which steps unblock the others, what can wait, and where the marginal hour of effort buys the most regulator-defensibility.
The One Step Most Teams Try to Skip
You cannot write a privacy notice without knowing what data you have. You cannot pick legal bases without knowing what you process. You cannot run a DPIA on processing you have not mapped. The data inventory - boring, time-consuming, often delegated to whoever has the least leverage to refuse - is the prerequisite for everything else.
Skip it and you will redo the next five steps when you eventually find out about that analytics tool, that legacy database, or that vendor someone added without the privacy team knowing. The teams that get GDPR done in a quarter rather than a year share one thing - they did the inventory first, before anything else got drafted.
Real-World - A Fintech's Four-Month "Sprint" That Reset to Zero
A B2B fintech we audited last year had spent four months on what they called their "GDPR sprint" - three rounds of privacy notice rewrites, a beautifully designed cookie banner, an updated DPA template, and a workflow tool for data subject requests. What they had not done was map their actual data flows.
When the inventory finally got done, it surfaced eleven processing activities that the privacy notice did not mention, three vendors operating without DPAs in place, and one analytics flow sending customer data to a US-based provider with no transfer mechanism on file. Most of the privacy notice had to be rewritten, the DPA template extended to cover the missing vendors, and one vendor relationship terminated because the transfer arrangement could not be retrofitted. Doing the inventory first would have collapsed those four months into about six weeks.
The Six Steps, In Order
Map What You Have
Personal data inventory. Every system, every flow, every vendor that touches it. For each processing activity you are answering four questions: what data, whose data, where it lives, who has access. The output is a Record of Processing Activities (RoPA) under Article 30 - and even if you are under the 250-employee threshold where it is technically optional, you want one. Every later step references it.
Anchor Each Activity to a Legal Basis
For every processing activity in the RoPA, pick one of the six Article 6 bases. We covered the choice in detail in our piece on legal basis for processing. Document the rationale, especially for legitimate interests, where you need a Legitimate Interest Assessment on file.
This step takes longer than people expect - about half the activities in a typical inventory turn out to need basis revision, and a few turn out to need the processing itself restructured. Where consent is the basis, the four-condition test from consent under GDPR applies - and most existing flows fail at least one condition on first audit.
Tell Users What You Do
Privacy notice updates under Articles 13 and 14. Plain language, layered structure (summary at the top, detail underneath), at the point of collection. The bar is not "we technically published it" - it is whether a non-lawyer would understand what is happening to their data.
If your team's privacy lawyer is the only person who can explain the notice, the notice fails the test. A useful sense check is to read the notice aloud to a friend who does not work in tech. If they cannot summarise what data the company collects and why in two sentences, it needs another rewrite.
Wire Up the Rights
Data subject rights under Articles 15–22 - access, erasure, portability, rectification, objection, restriction. We walked through all eight in data subject rights under GDPR. Most teams build the intake form and forget the fulfilment plumbing.
The harder work is being able to actually find a user's data across all systems within 30 days, and to actually delete it from production, backups, and analytics when asked. If your fulfilment plan is "we will figure it out when a request lands," the first request will tell you exactly where the gaps are.
Lock the Perimeter
Article 32 security measures, vendor DPAs, sub-processor due diligence, international transfer mechanisms (Standard Contractual Clauses and Transfer Impact Assessments where data leaves the EEA). Vendor management connects to broader third-party risk management practices.
This is where most programmes silently fail an audit - the security controls exist, but the documentation linking them to GDPR's "appropriate technical and organisational measures" requirement does not. The fix is mostly paperwork. Paperwork that has to actually exist.
Plan for the Worst
Breach response runbook with a 72-hour clock that starts from awareness, not from the incident. Pre-drafted notification templates for the supervisory authority and for affected data subjects. A clear decision tree for what counts as a notifiable breach (most security incidents do not, but the team needs to know how to tell). And - crucially - a tabletop exercise to find out where the runbook breaks before a real incident does. Our tabletop exercise guide covers how to run one.
When You Actually Need a DPO
The Data Protection Officer requirement under Article 37 applies in three specific cases:
- You are a public authority (this rarely surprises anyone)
- Your core activities involve large-scale systematic monitoring - adtech platforms, surveillance technology, large social platforms
- Your core activities involve large-scale processing of special category data - health platforms, large HR systems, biometric identity providers
Most B2B SaaS companies do not meet any of these. Appointing a DPO when you do not legally need one is fine, but it is a commitment to ongoing independence and reporting requirements that smaller teams often regret.
The middle path most pragmatic companies take is a Privacy Lead - an internal accountable owner who runs the programme without the formal DPO designation. Keeps the accountability, skips the structural overhead. If you cross the threshold later, you can elevate the role then. India's DPDP Act has a similar tiered structure - covered in do you need a DPO under DPDP.
90-Day Quick Start vs 12-Month Maturity
There are two credible timelines for getting a GDPR programme to working order, and they answer different questions. The quick start gets you defensible - enough that an enterprise customer's security review passes and a regulator's first question gets a coherent answer. The maturity path gets you efficient - enough that the programme runs on its own without consuming a quarter of someone's calendar every time something changes.
| Workstream | 90-Day Quick Start | 12-Month Maturity Path |
|---|---|---|
| Inventory & RoPA | Top 20% of processing activities mapped | Full RoPA across every system, kept current |
| Legal Basis | Documented per major activity | LIA on file for every legitimate-interest claim |
| Privacy Notices | Updated to match the live RoPA | Layered, plain-language, version-controlled |
| Subject Rights | Intake form + manual fulfilment | Self-serve where possible, automated discovery |
| Vendors & Security | DPAs in place for the top 10 vendors | Continuous vendor risk monitoring, transfer reviews |
| Breach Response | Runbook + one tabletop exercise | Drills, automated detection-to-notification flow |
The mistake is trying to build the maturity column before the quick-start column is working. Gold-plated programmes fall apart the day a regulator asks the basic question, because the basics never got nailed down. Sequence matters at the timeline level too.
The visible work - privacy notices, cookie banners, the DPA template - is the cheap part of GDPR compliance. The expensive parts are the ones that show up after launch. Vendor reviews multiply with every new procurement. Subject-request fulfilment at scale (the 100th request costs more than the first). Inventory and RoPA maintenance as the business changes. Budgeting only for the launch programme leaves you with a snapshot that goes stale within two quarters. The companies that stay compliant treat GDPR work as ongoing process, not a one-time project - and budget the maintenance line accordingly.
Sequencing Beats Comprehensiveness
The single most consistent failure pattern we see - teams trying to do every GDPR thing at once. Nothing reaches operational quality, six months in there is a polished privacy notice attached to a RoPA that is three iterations behind reality, and the team is reworking the same documents for the third time.
The teams that succeed pick the inventory, ship it to working quality, then move to the next step. They accept that the programme will look uneven for a quarter, because uneven-but-real is what scales. Comprehensive-but-fragile does not survive contact with the first audit, the first acquisition, or the first breach.
Final Thought
GDPR is one of the rare regulatory programmes that actually pays for itself if you sequence it right. The inventory gives engineering a useful map of the business. The RoPA makes vendor due diligence faster. The subject-request plumbing forces you to build user-data tooling that turns out to be useful for support, deletion, migration, and eventually for AI training data hygiene.
The maturity path stops feeling like a compliance tax and starts feeling like infrastructure - but only if you start with the right step, and only if you let the rest follow it instead of running them in parallel. The roadmap is not forty-seven points. It is six steps in this order - and the patience to actually run them in this order.
If you are running a programme that has to comply with GDPR alongside India's DPDP Act, the cross-mapping in GDPR vs DPDP - key differences every Indian company must know is the next read.
Frequently Asked Questions
For a focused product team, a defensible GDPR position can be reached in roughly 90 days following a sequenced six-step approach - inventory first, then legal basis, notices, subject rights, security perimeter, and breach response. Full operational maturity (continuous vendor monitoring, automated subject-request fulfilment, ongoing RoPA maintenance) typically takes 12 months. Trying to do everything in parallel rather than in sequence is the most consistent failure pattern.
The personal data inventory - every system, every flow, every vendor that touches personal data. The output is a Record of Processing Activities (RoPA) under Article 30. Without this, the next five steps will all need redoing once the missing data flows surface. Teams that try to draft privacy notices or pick legal bases before completing the inventory consistently rebuild that work later.
Article 37 requires a DPO in three specific cases - public authorities, organisations whose core activities involve large-scale systematic monitoring, and organisations whose core activities involve large-scale processing of special category data. Most B2B SaaS companies do not meet any of these. The pragmatic alternative is a Privacy Lead - an internal accountable owner without the formal DPO designation and its independence requirements.
72 hours from when the controller becomes aware of the breach - not from when the breach occurred. The notification goes to the supervisory authority. Affected data subjects must also be notified without undue delay if the breach is likely to result in a high risk to their rights and freedoms. Pre-drafted templates and a tested runbook are the difference between meeting the deadline and missing it.
For each processing activity: the purposes, the categories of data subjects and personal data, the categories of recipients, transfers to third countries with applicable safeguards, retention periods, and a general description of security measures. Organisations under 250 employees are technically exempt unless processing is regular, likely to risk rights, or involves special category data - but most operational teams maintain a RoPA anyway because every other GDPR step references it.
Operationally, parts of it - vendors can run inventories, draft notices, build subject-request workflows, and stand up DPAs. Legally, no - accountability stays with the controller. The most useful arrangement is a vendor that does the heavy implementation work alongside an internal Privacy Lead who owns the programme, makes the strategic decisions, and answers to the regulator if it ever comes to that.
The supervisory authority must still be notified - late notification with reasoned justification is better than no notification - but you accept additional regulatory risk. Late notification is itself a separate infringement under Article 33 and can compound the fine for the underlying breach. The 72-hour clock makes pre-built templates and a tested runbook genuinely critical, not optional.