Preparing for GDPR Compliance

Preparing for GDPR Compliance

Most checklists list GDPR prep steps in a flat order, like they're all equally urgent. They're not. Almost everything else on the list depends on getting one step right first: knowing exactly what personal data you actually have. Skip that, and every later step is built on guesswork.

Step 1: Map Your Data Before You Do Anything Else

Here's a distinction worth knowing: GDPR doesn't technically require a "data inventory" by name. What it requires is a Record of Processing Activities (Article 30). But you can't realistically build an accurate RoPA without first doing the inventory and mapping work — so in practice, this is the non-negotiable first step everyone ends up doing anyway.

A real data inventory tracks, for each piece of personal data you hold:

• Where it came from

• Why you collected it

• Where it flows internally (which teams, which systems)

• Who outside your organization gets access to it

• How long you keep it, and when it gets deleted

A simple example: someone applies for a job through your website. The source is the application form. The reason for collecting it is "submitted by the applicant." It flows to HR, maybe to a hiring manager, maybe into a recruiting tool. The disposal plan might be "keep the email for future opportunities, delete everything else after six months." That's one row in your inventory — and a real organization usually has hundreds of these.

This is also the step where you find things you didn't know existed. The marketing team's spreadsheet with lead contact info nobody told legal about. The support team pasting customer emails into a shared doc. The HR tool that's quietly storing health insurance data right next to salary data. You won't find these by reading a privacy policy — you find them by actually asking each team what they collect and where it goes.

A good way to test whether your inventory is actually accurate: run a mock breach drill. Pick a piece of data and ask your team to trace it — where does it live, who has access, which vendors touched it. If they can't answer fast, your inventory has a gap, and you just found it before a regulator did.

Step 2: Identify Your Lawful Basis for Each Processing Activity

Once you know what you're collecting and why, match each activity to an actual legal basis — consent, contract, legal obligation, legitimate interest, and a few others. Don't default to consent for everything; it's often not the right basis, and it comes with its own withdrawal mechanics you have to support.

Step 3: Update Privacy Notices to Match Reality

Your privacy notice should describe what you're actually doing, based on the inventory you just built — not a generic template that was accurate three reorganizations ago. If the inventory surfaced data flows you didn't know about, your notice probably needs updating to reflect them.

Step 4: Build a Real Process for Rights Requests

Once you know where data lives, you can actually build a working process for access, deletion, and correction requests. GDPR Data Subject Rights: All 8, Explained covers all eight rights and their deadlines — useful to read before building this process, not after.

Step 5: Put Real Safeguards in Place

Technical and organizational measures, based on what the inventory showed you actually needs protecting. This is also where privacy by design comes in — building safeguards into new systems from the start, instead of retrofitting them later.

Step 6: Review Every Vendor Contract

Any vendor touching personal data on your behalf needs a real Data Processing Agreement. Controller vs. Processor Responsibilities covers exactly what has to be in that agreement, including the part about sub-processors that catches people off guard.

Step 7: Sort Out Cross-Border Transfers, If They Apply

If your data inventory shows personal data moving outside the EU, you need a real mechanism backing that up — adequacy decisions, Standard Contractual Clauses, or Binding Corporate Rules. This isn't a step to handle informally; enforcement here has gotten serious.

Why the Order Actually Matters

Doing these out of order is the most common way GDPR prep stalls. You can't write an accurate privacy notice before you know what you collect. You can't build a working rights-request process before you know where data lives. You can't review vendor contracts properly before you know which vendors are actually touching personal data in the first place. The data inventory isn't just step one because it's easiest — it's step one because everything else depends on it being right.

Keeping the Inventory Current

A data inventory built once and never revisited goes stale fast — new vendors get added, systems change, teams start collecting things nobody flagged. Treat it as a living document with a named owner, not a one-time project you check off and forget.

Pairing This With Other Frameworks

If you're also working toward ISO 27001 or SOC 2, the data mapping work above does double duty — both frameworks expect you to know exactly what sensitive data you hold and where, before you can build the right controls around it.

FAQs

What is the first step in preparing for GDPR compliance? The first step is building a complete data inventory — mapping what personal data you hold, where it came from, why you collected it, where it flows internally, who outside the organization accesses it, and how long you retain it. Nearly every other GDPR requirement depends on this being accurate first.

Does GDPR technically require a "data inventory"? Not by that name. GDPR requires a Record of Processing Activities (RoPA) under Article 30, but building an accurate RoPA is practically impossible without first doing the inventory and mapping work — so in practice, the inventory becomes the non-negotiable first step.

How do you know if a data inventory is actually accurate? A useful test is running a mock breach drill: pick a specific piece of data and ask your team to trace where it lives, who has access, and which vendors have touched it. If they can't answer quickly, that's a gap in the inventory worth finding before a regulator does.

What's a common example of data organizations don't realize they're collecting? Frequently uncovered examples include a marketing team's spreadsheet of lead contact info that legal was never told about, support staff pasting customer emails into shared documents, or an HR tool storing health insurance data alongside salary data. These typically surface only by asking each team directly, not by reviewing the privacy policy.

What comes after building a data inventory in GDPR preparation? After the inventory, the sequence is: identify a lawful basis for each processing activity, update privacy notices to reflect actual practices, build a working process for data subject rights requests, implement technical and organizational safeguards, review vendor contracts and DPAs, and address cross-border transfer mechanisms if applicable.

Why shouldn't a company default to "consent" as the lawful basis for all data processing? Consent is often not the most appropriate lawful basis, and it comes with specific withdrawal mechanics an organization has to support ongoing. Other bases — contract, legal obligation, legitimate interest — are frequently more accurate and less operationally burdensome depending on the processing activity.

Why does the order of GDPR compliance steps matter? Each step depends on the one before it: you can't write an accurate privacy notice without knowing what data you collect, can't build a working rights-request process without knowing where data lives, and can't properly review vendor contracts without knowing which vendors touch personal data. Skipping the data inventory undermines everything that follows.

Is a data inventory a one-time project or ongoing work? Ongoing. An inventory built once and never revisited goes stale as new vendors are added, systems change, and teams start collecting new types of data. It should be treated as a living document with a named owner, not a completed checklist item.

What needs to be included in a vendor Data Processing Agreement (DPA)? Any vendor touching personal data on an organization's behalf needs a DPA covering specific contractual obligations, including provisions for sub-processors — a detail that often catches organizations off guard if overlooked. See Controller vs. Processor Responsibilities for full requirements.

Does GDPR data mapping work overlap with ISO 27001 or SOC 2 preparation? Yes. Both frameworks require organizations to know exactly what sensitive data they hold and where it's located before building appropriate controls, so the data mapping and inventory work done for GDPR typically satisfies a foundational requirement for ISO 27001 and SOC 2 as well.