Six weeks, one GDPR request, and why we automated it

The moment we realised we weren't ready

The request itself was reasonable. A user wanted to know what data we held about them. On paper, ARK is privacy-first by design. On-device scans wherever possible. No analytics on free-tier use. But the moment legal landed that request on my desk, I realised how different 'privacy-first architecture' feels from 'proving privacy compliance on demand'.

We had to trace every touchpoint. The device UUID we use for Shield and Fortress sync. The breach monitoring database queries against Have I Been Pwned (HIBP). The dark-web monitor logs. The phishing URL checks. The password health assessments. Each one involved either our own infrastructure or third-party APIs, and each one needed documentation, audit trails, and verification that we could actually retrieve and delete the user's data on request.

By week three, I was sitting in a spreadsheet with our DevOps lead, mapping data flows that I'd never fully visualised before. We'd built ARK to keep user data off the cloud where possible, but the moment someone asked 'what do you have on me', we needed to answer with certainty. That certainty was missing.

Why automation became essential, not optional

The process took six weeks because it was manual. Each step required human intervention: searching databases, cross-referencing logs, composing responses, verifying deletions. If we'd had two such requests in parallel, we'd have failed our legal obligations. By request five, we'd fail on time alone.

That's when it became clear that GDPR compliance at scale isn't a legal checkbox. It's a technical problem. And if we were building a security app for privacy-conscious users, we couldn't ask them to trust us while we ourselves treated their data-subject rights as an afterthought.

So we built GDPR Autopilot, a Fortress feature that automates data-subject requests from inside the app. A user submits a request directly, and the system traces what we hold, composes the verified response, and handles the deletion workflow. No spreadsheet. No six weeks. No grey areas.

The irony isn't lost on me. An app designed to audit other companies' data practices needed to audit itself. And once we did, we made the audit permanent.

What we learned about privacy at the product level

That manual six-week process taught us something uncomfortable. Privacy compliance and privacy-forward product design are not the same thing. You can have great intentions and still leak user data through poor tracking, unclear deletion logic, or third-party integrations that sit in a legal grey zone.

Building GDPR Autopilot forced us to think like a data processor. Not 'what data do we want', but 'what data do we actually need, and what happens when someone asks us to prove it or delete it'. For each feature in ARK, we had to answer: where does this data live, who can access it, and can we delete it on demand?

That filter changed decisions. The stalkerware detector, for instance. It runs on-device and stores no match history on our servers. That design choice was made before GDPR Autopilot, but now it's documented and auditable. The dark-web monitor scans against our own proprietary breach database; we don't hand user credentials to third parties and trust them to delete on request. The password health check runs locally; we don't upload your passwords to score them.

Each choice compounds. A user running a security audit on their own privacy posture shouldn't have to wonder if they're being audited in return.

The feature no one asked for, until we understood why they needed it

When we soft-launched GDPR Autopilot with the Fortress tier, the response surprised us. Users weren't asking for it. Privacy-conscious people don't necessarily expect their security app to make data-subject requests easy. But the moment it was there, people used it. Not always as a full data request; often as a verification. 'Show me what you have on me' became a regular flow.

Parents checking family devices started using it to audit what we collect about their kids. Small business owners running it across multiple team phones to understand their BYOD risk. One user told us they ran it as a trust test. Not because they expected us to be negligent, but because they'd never been given a transparent way to verify.

That phrase stuck with me: 'a transparent way to verify'. That's what GDPR Autopilot is. It's not a privacy feature in the sense that dark-web monitoring or phishing detection is. It's a transparency feature. It proves that the privacy we claim is actual privacy.

What comes after proving you're serious

The six-week request also exposed deeper things. We discovered that some of our third-party integrations, while reputable, didn't have SLAs for user data deletion. We found legacy API endpoints that were still logging information we no longer needed. We realised that 'privacy-first' can't be a design philosophy if the backend doesn't enforce it.

GDPR Autopilot became a forcing function. If we're going to let users request their data on-demand, we have to be certain about what we hold and how long we hold it. That certainty extends upstream. We've since tightened retention policies across the board. We've shifted more logic on-device, reducing what touches our infrastructure at all. We've documented data flows that used to live in institutional knowledge.

None of that work makes headlines. But it's the work that separates apps that claim privacy from apps that practice it.