The Press Release Was in Two Days
We were a stock exchange company. A public announcement was scheduled. And GDPR Article 17 was not optional.
It was 4 AM when my company phone buzzed.
I almost ignored it. Then I saw it wasn’t a mistake.
On the other end, someone said: “There’s something called the ‘right to be forgotten.’ I don’t fully know what it is, but we haven’t implemented it. There’s a press release in two days. They told me you’re the right person to call.”
It was my 3rd day in the new company, and this wasn’t a theoretical compliance discussion.
I’d dealt with GDPR before. Article 17 (the right to erasure, or “right to be forgotten”) wasn’t new to me. I’d architected 14 compliant platforms across telecommunications, digital health, media, and deep-tech imaging. I understood what proper implementation looked like.
But understanding what proper looks like is different from having proper in place.
The press release was going to announce new data processing capabilities for our users and clients. It would describe how we protected personal data. And there was a specific gap: the ability for data subjects to request deletion of their personal data, with that request honored systematically.
Two days.
GDPR Article 17 isn’t complicated in concept. A person requests that you delete their personal data. You delete it. Within 30 days.
In practice, it breaks almost everything.
Personal data exists in production databases. In backups. In logs. In third-party systems. In analytics warehouses. In email threads. In document management systems. In test environments.
The “right to be forgotten” sounds like one button. In reality, it’s a distributed deletion problem across systems that were never designed with deletion as a first-class operation.
A proper implementation would require:
Data discovery across all systems. Lineage mapping to track where data flows. Retention policies formalized and enforced. Deletion workflows with verification. Third-party notification procedures. Backup handling strategies. An audit trail proving deletion occurred.
We had two days.
We did not have two days of engineering capacity. We did not have complete data lineage. We did not have a unified view of where personal data existed.
What we had was a regulatory requirement and a public commitment.
The first decision wasn’t technical.
It was scope.
We didn’t try to “fully implement GDPR.” That would have been dishonest. Full implementation takes months. It involves organizational change, not just code.
Instead, we defined what “right to be forgotten” had to mean for the press release to be accurate.
That meant:
Identifying every place where personal data could realistically exist in the systems covered by the announcement.
Understanding which systems were authoritative (source of truth) versus derived (could be regenerated from authoritative sources).
Defining deletion guarantees that we could actually stand behind. Not aspirational. Operational.
Some data would be deleted immediately. Production databases where we had direct control and clear data models.
Some data would be queued. Systems where deletion required downstream coordination or batch processing.
Some data would be contractually out of scope. Third-party systems where we were processors, not controllers, and where data subject requests were the responsibility of the controller.
Everything was documented. Not as a marketing exercise. As a legal and operational artifact that described exactly what we could promise.
Two things we explicitly did not do:
We did not claim comprehensive coverage. We didn’t say “we delete all your data everywhere.” We said “we delete personal data from the following systems within the following timeframes.” Specific. Auditable. True.
We did not pretend backups were simple. Backup deletion in enterprise environments is a problem with no clean answer. Backups exist for disaster recovery. They’re often immutable. They’re often retained for legal hold purposes. We documented our backup retention windows and the circumstances under which backup restoration would (and would not) trigger re-processing of deletion requests.
Two days later, the press release went out.
The functionality worked. When a data subject submitted a request, it was processed. Personal data was deleted from the systems we controlled. Third-party integrations were handled according to documented procedures. Audit logs captured what happened.
More importantly: the company could explain exactly what “right to be forgotten” meant in practice.
Not in marketing terms. In operational terms.
What systems were covered. What the deletion workflow was. What the SLAs were. What was explicitly out of scope and why.
The system wasn’t perfect. It was defensible.
There’s a difference between “we’ve built the ideal solution” and “we can explain precisely what this does and stand behind it.” Under pressure, the second is what matters.
The Framework: Scope Under Pressure
When you have limited time and a hard commitment, the decision isn’t what to build. It’s what to exclude, and how to document that exclusion.
Here’s the framework I use. Five questions, asked in order.
1. What must be true for the commitment to be honest?
Not complete. Honest.
Strip away aspirations. Ignore what “should” exist. Focus on what the commitment actually says. If the press release says “users can request deletion,” what’s the minimum that makes that statement not a lie?
This question forces specificity. “GDPR compliance” is vague. “Data subjects can submit deletion requests and receive confirmation within 30 days” is testable.
2. What systems are authoritative?
Under pressure, you cannot fix everything. Identify where the source of truth lives.
Authoritative systems get full attention. Derived systems (caches, analytics copies, denormalized views) can often be handled through documented regeneration or time-bound expiration.
The mistake is treating all systems equally. They’re not. Some matter for the commitment. Some don’t.
3. What can we actually verify?
A promise you can’t audit is a liability.
For each system in scope, ask: can we prove the action happened? If you can’t log it, you can’t defend it. If you can’t defend it, don’t promise it.
This is where backup systems usually fall out of scope. You can promise “deleted from production.” You often cannot promise “deleted from all backup tapes.” Be explicit about the difference.
4. What must be explicitly excluded?
Ambiguity is where failures hide.
If something is out of scope, document it. Third-party systems where you’re a processor, not a controller. Legacy systems scheduled for decommission. Data retained for legal hold.
Exclusions aren’t failures. Undocumented exclusions are.
5. What’s the smallest defensible scope?
Not the smallest possible scope. The smallest scope you can defend.
“Defensible” means: if audited, you can explain why this boundary exists. If questioned publicly, you can justify the decision. If it fails, you can describe what was supposed to happen.
Scope down until every remaining item passes that test.
The Decision Matrix
For each system or data category, classify:
The fourth row is where problems live. Every item must move to one of the first three rows before the commitment goes public.
Example: The 48-Hour GDPR Scope Decision
Our architecture was event-driven. Confluent Kafka sat at the center of everything. Every state change, every transaction, every user action flowed through Kafka topics before landing anywhere else. PostgreSQL for persistence. BigQuery for analytics. ELK for logs. Kafka Connect piping data everywhere.
None of it had deletion workflows. None of it was documented for GDPR. That was the starting point.
Here’s how we used the framework to decide what we could realistically commit to in 48 hours:
Nine systems. Two days.
We brought exactly one into scope for immediate deletion capability: PostgreSQL, the authoritative source.
Everything else was either configured to auto-expire within a documented window, or explicitly excluded with documented rationale and (where needed) a remediation timeline.
The press release could honestly say: “Users can request deletion of their personal data. Requests are processed within 30 days.”
What it didn’t say: “We delete from every system immediately.” Because we couldn’t and it is OK by law. And saying we could would have been a lie.
That’s the framework in practice. Not perfect coverage. Explicit boundaries. Defensible commitments.
This is something I’ve learned repeatedly in data leadership.
Under pressure, the job is not to build perfect systems.
It’s to make precise commitments, and then make them true.
The 4 AM phone call wasn’t asking for perfection. It was asking: can we say something publicly that won’t create liability?
The answer to that question isn’t engineering. It’s judgment.
What can we actually deliver in the time available? What can we stand behind? What needs to be scoped out explicitly, rather than left ambiguous?
Most failures in high-stakes data work don’t come from missing features. They come from overpromising under stress.
A system that does exactly what you say it does is more valuable than a system that does more, but with behaviors you can’t explain.
Precision reduces risk faster than completeness.
That’s the lesson. Not just for compliance. For every situation where the question is: what can we promise, and what can we deliver?
The gap between those two things is where reputations break.
Data platforms that survive growth, stress, and reality. - Can Artuc - can [at] dataprincipal.io