Your SaaS doesn't know how to forget (and that's a problem)

I recently tried out a personal knowledge management tool. It wasn't for me. So when I got a marketing email from the founder, I replied with a formal CCPA data deletion request.

Eleven days and multiple internal handoffs later, support confirmed: "Your account has been closed and deleted."

Then the marketing emails kept coming.

When I pointed out that continuing to send me emails was the opposite of what they claimed, the response was: "I've unsubscribed you from the mailing list."

View full size

That's not what I asked for. I can unsubscribe myself. I can delete my own account. A data deletion request is something fundamentally different, and the fact that they conflated the two tells me they had no idea where my data actually lived in their own systems.

I'm not singling out this company. I'd bet most SaaS startups would handle this identically. They were caught flat-footed by a routine compliance request because they had no process, no tooling, and no infrastructure for actually fulfilling it.

SaaS products are architected in one direction: in.

Append-only event logs, denormalized copies for performance, third-party integrations syncing data outward to analytics platforms, marketing tools, error trackers, data warehouses. Everything is optimized for collecting and retaining. Very little propagates back. Many cloud defaults actively encourage this: AWS CloudWatch Logs, for example, stores logs indefinitely unless you explicitly set a retention policy.

Accumulation isn't just a habit; it's the factory preset.

So when a deletion request arrives, someone has to answer a question the company has never systematically asked: where does this person's data actually live? The honest answer, at most startups, is: we don't fully know. It's in the primary database, sure. But it's also in analytics tools, email platforms, support systems, search indices, backups, exports, and logs.

Deletion isn't a UI toggle. It's a distributed systems problem, and even within a single system, "deleted" may not mean gone.

Database backup retention on services like AWS RDS can keep restore data for up to 35 days after deletion, and snapshots can persist indefinitely. "We deleted it from production" frequently does not mean "it is no longer present anywhere we control."

In my case, the continued marketing emails revealed something specific: the system that managed my account and the system that marketed to me weren't coordinated on basic lifecycle events, let alone deletion. There was no orchestration layer that treated deletion as a cascading event. The account database didn't talk to the marketing automation tool didn't talk to the analytics pipeline.

Here's something even fewer companies think about: what happens when you switch vendors?

When a company migrates from one analytics tool to another, what happens to the years of behavioral data sitting in the former system? Almost universally, nothing. The contract ends, the account downgrades, the data lingers. Under GDPR and CCPA, the company remains the data controller. Responsibility doesn't disappear when the login does. Every vendor transition without a clean data offboarding creates invisible compliance debt, and that debt compounds.

If you're thinking "our Data Processing Agreement covers this": it covers it legally, not operationally. Contracts are not controls. Most DPAs require deletion upon termination, but only if someone triggers the clause and verifies completion.

If you've changed analytics platforms, ESPs, CDPs, or support tools in the last five years, can you produce deletion confirmations from each transition? That silence is instructive.

Building for deletion isn't just about regulatory exposure. It produces real, compounding benefits.

No one can breach data you no longer store. Every record retained past its useful life is pure liability with no corresponding business value. IBM's 2025 Cost of a Data Breach report puts the global average at $4.44 million, with customer PII records costing roughly $160 each. After a breach, regulators ask "why did you still have this?" Companies with automated retention policies and demonstrable deletion infrastructure fare dramatically better.

Deletion readiness is a proxy for operational maturity. If you can reliably delete a single user's data across every system it touches, you understand your data topology. That same understanding supports incident response, vendor migrations, procurement questionnaires, and compliance audits.

It cuts costs you didn't know you had. Storage itself may be cheap, but replication, indexing, backup retention, and warehouse compute accumulate. Data that never expires increases complexity and spend.

It builds trust at exit, not just at entry. Most products reassure you about how securely they store your data. Very few can reassure you about how cleanly they can relinquish it. Imagine receiving a verified deletion receipt showing exactly what was removed, from which systems, and when, not a vague "your account has been deleted" email. Almost nobody does this. That's a differentiator.

And this isn't theoretical risk. Regulators have already acted: a German authority fined a real estate company whose archiving system lacked the ability to delete unnecessary data. FTC settlements have required companies to delete improperly retained data and implement formal retention schedules. The enforcement trajectory is clear.

Data lifecycle deserves the same architectural attention as data ingestion. That means maintaining a living processor inventory, evaluating vendors on deletion capabilities, treating deletion as an event that propagates across systems, enforcing retention policies in code, and distinguishing suppression from erasure.

SaaS companies invest heavily in the first five minutes of a user's experience. The last five minutes — clean exit, verified deletion, architectural symmetry — receive almost none.

If a user who joined five years ago requested deletion today, could you list every system their data touched and prove that it's gone?