What a manual data map really costs

Manual data maps rarely show up as a budget line. The cost is spread across dozens of people's calendars as interviews, follow-ups and spreadsheet edits, which is exactly why it gets underestimated. Here is how to put a number on it.

This article explains the two ways teams approach a first map, breaks down where the time actually goes, and walks through a worked example using a simple cost model (see also the data map cost estimate page). If you need the background on what a data map, inventory and ROPA are, start with the data mapping and discovery guide.

Top-down versus bottom-up

There are two starting points, and most projects end up doing some of both.

The model covers both: interview time scales with business units (top-down), documentation time scales with systems (bottom-up). In most realistic inputs, documentation dominates, because companies have many more systems than departments.

Where the hours actually go

Interviews

An interview costs everyone in the room. A one-hour session between a privacy lead and a head of marketing is two person-hours, plus prep and write-up. Group sessions with three or four people from a department multiply quickly. That is why the model has a "people per interview" input instead of treating interviews as the privacy team's time alone.

Per-system documentation

For each system, someone has to find the owner, establish which personal data it holds, find the hosting region and access locations, read the vendor's DPA and sub-processor list, check the retention settings, and write it all up. For a simple SaaS tool with good documentation this can be quick. For an in-house system with years of schema changes, it can take days and an engineer's attention. The average hides a long tail, so it is worth separating your handful of complex systems and estimating them individually.

Coordination

Scheduling, chasing late responses, reconciling contradictory answers ("marketing says the CRM keeps leads for two years, sales ops says forever") and assembling the result into a ROPA. This is invisible in project plans and modeled here as a percentage overhead on everything else.

Upkeep

A map starts going stale the day it is finished. Every review cycle, a share of systems will have been added, retired or changed, and each business unit needs a shorter check-in to catch new processes. Upkeep is cheaper per cycle than the first build, but it repeats. Over a few years it usually adds up to more than the build.

What is not in the estimate

Fixing what the map reveals (missing DPAs, data stored in the wrong region, retention rules nobody enforces) is separate work and often bigger than the mapping. So is the ongoing cost of answering data subject requests, which a good map reduces but does not eliminate.

The formula

This is the model. Every input is yours to change.

• Systems in scope S = SaaS vendors + internal systems
• Build hours = (business units × hours per interview × people per interview + S × hours per system) × (1 + overhead%)
• Hours per review = S × change% × hours per system + business units × (hours per interview ÷ 2) × people per interview
• Annual upkeep hours = hours per review × reviews per year × (1 + overhead%)
• Cost = hours × blended hourly rate

It is deliberately simple: linear, transparent and easy to rebuild in a spreadsheet. It does not pretend to know your numbers.

A worked example

Take a hypothetical company with eight business units, 120 SaaS tools that touch personal data and 25 internal databases and systems. These are made-up inputs for illustration, not benchmarks.

First build

1. Systems in scope: 120 + 25 = 145.
2. Interview hours: 8 × 1.5 × 3 = 36.
3. Documentation hours: 145 × 3 = 435.
4. Subtotal 471 hours, plus 20% overhead = 565 hours.
5. At $95 an hour: about $53,700.

Notice the split: interviews are under 8% of the subtotal. The bulk of the work is documenting systems, which is why system count is the input to get right.

Annual upkeep

1. Changed systems per review: 145 × 15% = 21.75, × 3 hours = 65.25 hours.
2. Check-ins per review: 8 × 0.75 × 3 = 18 hours.
3. Per review: 83.25 hours.
4. Four reviews a year with 20% overhead: 83.25 × 4 × 1.2 = about 400 hours.
5. At $95: about $38,000 a year.

Over three years (the build plus two years of upkeep) this hypothetical company spends roughly $129,600 of people's time on the map, and about 59% of it on upkeep.

Sensitivity

Switching to twice-yearly reviews but assuming more change per review (25%, because more drift builds up between reviews) gives 126.75 hours per review and about 304 hours, or roughly $28,900, a year. Less frequent reviews are cheaper, but the map is less accurate for longer stretches. That trade-off, cost against staleness, is the real decision the model helps you frame.

The inputs that move the result most are the system count and hours per system. If you are unsure about either, work the formula with a low and a high value and present the range.

Using the number

• Budgeting. Convert hours into a staffing ask. Hundreds of hours a year of upkeep is a meaningful fraction of a full-time role, spread across people who also have other jobs.
• Build versus buy. Compare the annual upkeep figure with quotes for discovery and mapping tools. Be fair to both sides: tools have setup and tuning costs, and they still need humans for purpose and legal basis. See the privacy tech stack and the buyer's checklist.
• Reducing the manual cost. The cheapest reduction is to make the map update itself through existing processes: a privacy step in vendor procurement, data tagging in engineering design reviews, and a pre-filled system list from SSO and expenses before each interview. The discovery guide covers these.
• Scoping. If the number is too high, prioritize. Map systems with special-category data, large customer datasets and international transfers first. The ROPA template lists the fields you must capture for each.

FAQ