Every small team I’ve watched build a product does the same thing with two different areas of risk. Uptime gets a dashboard, an alert, and someone who checks it. The privacy policy gets written once, usually by copying a template, and then never looked at again unless a customer asks a question that makes someone go find it.
That’s a strange split, because both are operational commitments. One just doesn’t have a red graph attached to it yet.
The unmonitored surface
If you asked most founders of a five-person company “what’s your uptime this month,” most could tell you, or at least pull up a dashboard and find out in thirty seconds. Ask the same founder “when did you last review your privacy policy against current guidance,” and the honest answer is usually a shrug, followed by “whenever we wrote it.”
That’s not a moral failing. It’s what happens to anything you don’t instrument. Compliance work has the exact shape of the reliability problems we already know how to solve: it degrades silently, the failure mode isn’t visible until someone outside the company notices it, and by the time that happens you’re doing incident response instead of prevention. The difference is we built tooling for one and not the other.
The numbers behind the neglect
It’s worth being specific about what “degrading silently” actually looks like at scale, because the shape of the problem is more mundane, and more fixable, than most people assume.
The ICO received 42,315 data protection complaints in the UK in 2024/25, up 6.5% on the year before, and the regulator’s own trajectory points toward 45,000 to 55,000 a year if that keeps up. The instinct is to picture these as dramatic breaches. Mostly they aren’t. In Q3 2025/26, 43% of completed ICO cases cited Article 15, the right of access, meaning the single largest driver of complaints isn’t a data breach at all. It’s someone asking a company for their data and the company mishandling the request: late, incomplete, or never answered.
That’s an SLA miss, not a security incident. It’s the compliance equivalent of a slow endpoint nobody was watching until a customer complained on Twitter.
And the regulator side isn’t handling its own load particularly well either: 70% of complaints in 2024/25 missed the ICO’s own 90-day response target, with some complainants waiting around 29 weeks just to get a case assigned as of late 2025. I mention that not to let anyone off the hook, but because it’s a useful data point about how these systems behave under load in general. Nobody designed for the actual volume, on either side of the request.
What an SLI for compliance actually looks like
If you’ve spent any time defining SLIs, the translation here is almost mechanical. You’re just picking the handful of signals that tell you whether the system, in this case a legal and operational system rather than a technical one, is doing what it’s supposed to.
A few that map cleanly:
Time to respond to a subject access request. UK GDPR sets this at one calendar month from receipt, extendable by up to two further months for complex or numerous requests, but only if you tell the requester why within the first month. That’s a real SLO with a real deadline, and almost nobody tracks it as a number the way they’d track p99 latency.
Days since the privacy policy was last reviewed. Not rewritten, reviewed. A privacy policy is a claim about what your systems actually do. Every time you add a new analytics tool, a new vendor, a new data flow, that claim can quietly go stale. Treat “days since last review” the way you’d treat “days since last dependency audit.”
Percentage of data flows actually documented. Most small companies can’t answer “what third parties receive user data and why” without someone spending an afternoon reconstructing it from memory and old Slack messages. That’s a coverage gap in exactly the sense a monitoring blind spot is a coverage gap.
None of these need to be measured with anything sophisticated. A spreadsheet with a date column is a monitoring system if someone actually looks at it on a schedule. The failure isn’t a tooling gap first, it’s that nobody assigned these an owner or a cadence the way uptime automatically gets one.
Where this leads
I’ve been building toward this argument for a while now, and it’s part of why I’ve started working on tooling that treats compliance checks (does the current privacy policy still match GDPR and UK DPA 2018 expectations) as something to run on a schedule, next to uptime and performance checks, rather than as a separate exercise someone does once a year if they remember. The two problems have the same shape. They should live in the same place.
But the tooling isn’t really the point of this post. The point is smaller and applies whether or not you ever automate any of it: pick one compliance signal this week, response time to access requests is the highest-leverage one given what the ICO’s own numbers say, and put a number on it. Not a policy. A number, checked on a schedule, by someone who owns it.
That’s the whole move. It’s the same one we already made for servers.
Sources referenced: ICO complaints statistics via gdprcourse.co.uk; UK GDPR Article 15 response timeframes per ICO guidance on the right of access.
Comments 0