GDPR Pressure Without a Data Map: Where Mid-Market Firms Get Stuck

Ask a 120-person company if they're GDPR compliant and most will say yes, pointing to a privacy policy, a cookie banner, and a data protection statement in the employee handbook. Ask the same company to produce a complete list of where personal data actually lives — every system, every export, every spreadsheet a manager built two years ago — and the confidence usually disappears fast.

That gap is not a legal problem. It's a GDPR data mapping problem, and it is where a large share of mid-market compliance efforts quietly get stuck. You can have every policy document in order and still be unable to answer a subject access request within the statutory window, because policy tells you what should happen and a data map tells you where to actually go looking.

This article is deliberately practical, not legalistic: why the data map is the real bottleneck, what a right-sized one looks like for a company under 200 people, and how to build one without a six-month compliance programme.

Why the data map is the actual bottleneck

Most GDPR obligations sound like legal requirements but are, underneath, data location problems:

• A subject access request requires finding every place a specific person's data exists — across CRM, support tickets, email, marketing platforms, finance systems, and probably at least one spreadsheet nobody remembers building
• A retention policy requires knowing where data older than its retention period is sitting, which is impossible if you don't know everywhere it landed in the first place
• A vendor risk review requires knowing which third parties actually receive personal data from your systems, not just which contracts mention data protection clauses
• A breach notification decision requires knowing, within 72 hours, what data was affected and whose — a question that is unanswerable quickly without an existing map

None of these are solved by writing a better policy. They are solved by knowing, concretely, where personal data lives, where it flows, and who touches it — which is exactly what a data map is for and exactly what most SMEs have never built.

Why "we know roughly where it is" isn't good enough

Most mid-market teams have a mental map — a handful of people who could, between them, describe roughly where customer and employee data sits. This works until it's tested by something with a legal deadline attached to it.

A subject access request gives you one calendar month to respond. If answering "where does this person's data exist" requires asking around, checking with three department heads, and hoping someone remembers a legacy export, that process alone can consume most of the window before any actual work starts. A written data map turns a scramble into a lookup.

The same applies to a regulator inquiry, a customer's procurement due diligence questionnaire, or an internal query from a new DPO trying to understand what they've inherited. Informal knowledge doesn't scale past the one or two people who happen to hold it — the same single point of failure pattern that shows up in data ownership generally.

What a right-sized data map actually contains

Enterprise data mapping exercises can run to hundreds of data flows, multiple software tools, and dedicated headcount. None of that is necessary — or realistic — for a company under 200 people. A right-sized map answers five questions for each category of personal data you hold:

Five columns, populated for your handful of major personal data categories — customers, employees, candidates, suppliers — is enough to answer the vast majority of real compliance demands. This does not need to be, and should not start as, an enterprise data catalogue.

Building it: a practical sequence

1. Start with categories of data, not systems

Don't begin by listing every system and trying to work out what's in each one — start with the categories of person whose data you hold (customers, employees, candidates, suppliers, website visitors) and trace each one outward. This keeps the exercise anchored to what a DSAR or retention question will actually ask.

2. Interview, don't assume

The systems officially used for a data category are rarely the complete picture. A short structured conversation with each department head — "where does customer data end up that isn't the CRM?" — routinely surfaces exports, shared drives, and personal spreadsheets that no policy document ever accounted for.

3. Map flows, not just storage

A data map that only lists where data is stored misses half the compliance picture. Knowing that customer data flows from your CRM into a marketing automation tool, and from there into a data warehouse used for reporting, is what actually lets you answer "who has this and why" — and it's the same lineage thinking behind what a data observability platform monitors, applied to personal data instead of operational data.

4. Assign an owner per category

A data map without an owner decays within months, because nobody's job is to notice when a new tool gets adopted or a new export gets set up. This connects directly to the broader data ownership problem — the map is only as current as the person accountable for keeping it that way.

5. Keep it living, not a one-off project

The map's value comes from being current when you need it, not from having existed once during a compliance push two years ago. A quarterly ten-minute review per domain owner — "has anything changed?" — costs far less than rebuilding the map from scratch when a DSAR arrives and nobody trusts the old version.

How this connects to ownership and the wider framework

A data map is not a standalone compliance artefact — it's one output of having clear data ownership in the first place. If nobody owns customer data as a domain, nobody is naturally positioned to know where it flows or notice when a new tool starts touching it, which is the underlying pattern in data ownership problems.

It also sits inside a company's broader operating model for data. A right-sized data governance framework for companies under 200 people treats the data map as one of a small number of foundational components — alongside named ownership, simple classification, and quality controls tied to that ownership — rather than a separate GDPR-only exercise bolted on afterward.

What tends to trip companies up

Start with exposure, not completeness

You don't need a perfect, universally complete map before it becomes useful. Prioritise:

1. The data category most likely to generate a subject access request (usually customers)
2. The data category with the highest regulatory sensitivity (usually employee and health-adjacent data)
3. Any category already flagged in a customer due diligence questionnaire or vendor review

Mapping these first gets you a defensible position quickly, while the fuller map builds out behind it.

The map is the compliance capability, not the paperwork

GDPR data mapping is not a document you produce once to satisfy an audit — it's the operational capability that makes every other compliance obligation answerable within the time you're actually given. A privacy policy tells a regulator what you intend to do. A data map is what lets you actually do it when a subject access request, a breach, or a due diligence questionnaire lands with a deadline attached.

Most mid-market firms don't get stuck on GDPR because they lack intent to comply. They get stuck because nobody can quickly and confidently say where the data actually is.

Next step: Explore Data Governance as a Service to build a right-sized data map and ownership model together, or read our practical governance framework for companies under 200 people for how mapping fits into the wider operating model.