It started innocently enough. Sarah Thompson, a former customer of CloudyApp Solutions, sent a straightforward email to support@cloudyapp.com:

“Hi, I closed my account last week and would like to request that all my personal data be deleted from your systems. Thanks!”

Unfortunately, this seemingly simple request opened a pandora’s box of data governance and not only revealed what happens when software has not been designed with data governance in mind from the start, but rather than remove her personal details, cemented Sarah Thomas into the CloudyApp part of the internet for good.

Day 1: The Beginning

Mike from customer support received Sarah’s email. CloudyApp had never actually received this type of request before, despite being in business for three years. Mike did what any reasonable support agent would do - he forwarded the email to his manager with Sarah’s full details still attached:

“Hey Lisa, we got this request. This customer Sarah Thompson wants us to delete all her data. Her account (sarah.thompson.1982@email.com, customer ID CT-445821) has subscription data, payment info, and 2.3GB of uploaded documents. Not sure what our process is here?”

Current copies of Sarah’s data: 2 (original email + forwarded email)

Day 2: Management Chain

Lisa, the support manager, had never dealt with this either. She decided to escalate to the engineering team, helpfully including all the context:

“Hi DevTeam, we need help with a data deletion request. Customer Sarah Thompson (sarah.thompson.1982@email.com, ID: CT-445821) wants everything deleted. Mike says she had payment info and 2.3GB of files. Can someone look into what data we have on her and how to remove it? She was signed up since 2021 with premium features.”

The email went to the entire 12-person engineering team.

Current copies: 14 (original + Mike’s forward + Lisa’s email to 12 engineers)

Day 3: Data Investigation Begins

Senior engineer Tom took ownership and began investigating. To understand what needed deletion, he started documenting everything he found about Sarah’s data across their AWS infrastructure. Being thorough, he shared his findings in Slack:

Found Sarah Thompson's data in:
- RDS users table: email sarah.thompson.1982@email.com, 
  phone +1-555-0123, address: 123 Oak St, Denver CO
- DynamoDB sessions: 847 session records
- S3 bucket user-uploads: 2.3GB in folder /CT-445821/
- EFS shared storage: cached profile images
- CloudWatch logs: IP addresses 192.168.1.x associated with her sessions
- Payment processor: Stripe customer ID cus_J8HH2K4L3M

The Slack channel had 25 members.

Current copies: 39 (previous 14 + Slack message visible to 25 people)

Day 4: Team Consultations

Tom realised he needed help from different team specialists. He messaged the database team:

“Hey DB team, need to delete all data for Sarah Thompson (CT-445821, sarah.thompson.1982@email.com). She has records in users, subscriptions, payments, and audit_logs tables. What’s the safest way to cascade delete without breaking referential integrity?”

He also messaged the DevOps team:

“DevOps - need to purge S3 data for CT-445821 (Sarah Thompson, sarah.thompson.1982@email.com). It’s in user-uploads bucket. Also need to clear her from any EFS caches and CloudWatch retention policies.”

And the security team:

“Security team - data deletion request for Sarah Thompson (sarah.thompson.1982@email.com, CT-445821). Need to ensure we’re not keeping her data in any backup systems, audit logs, or security monitoring tools.”

Each team had 4-6 members.

Current copies: 54 (39 + 3 team messages × 5 average team members)

Day 5: The Backup Discovery

The DevOps team made a concerning discovery. Team lead Jenny posted in the general engineering channel:

*“Bad news on the Sarah Thompson deletion (CT-445821, sarah.thompson.1982@email.com). Found her data in:

  • 30 days of daily RDS snapshots
  • Weekly S3 backups going back 6 months
  • Disaster recovery replica in us-west-2
  • Dev/staging database refreshes (last sync 2 weeks ago)
  • Log aggregation system (Elasticsearch)
  • Our data lake in Snowflake for analytics”*

Current copies: 79 (54 + message to 25 engineering channel members)

Realising this was getting complex, Lisa escalated to the legal team. She forwarded the entire email chain to the company lawyer, who then consulted with the privacy officer. Both began documenting the situation in their own case management system, creating detailed notes about Sarah Thompson’s data and its locations for their GDPR compliance review.

Current copies: 83 (79 + legal team emails + case management entries)

Day 7: Vendor Revelation

The security team discovered that Sarah’s data had also been shared with third-party vendors. Security lead Marcus sent out a company-wide email:

*“URGENT: Data deletion request update for Sarah Thompson (CT-445821). Her data was also sent to:

  • SendGrid (email marketing): sarah.thompson.1982@email.com in ‘premium_users’ list
  • Mixpanel (analytics): user events and behavioral data
  • Zendesk (support): 3 support tickets with personal details
  • Stripe (payments): full billing history and payment methods
  • AWS Comprehend: analysed her uploaded documents for content classification”*

The company had 47 employees at this point.

Current copies: 130 (83 + company-wide email to 47 people)

Day 8: Vendor Coordination Nightmare

Now they needed to contact each vendor to request deletion. The customer success manager, David, began reaching out:

“Hi SendGrid support, we need to delete all data for sarah.thompson.1982@email.com from our account. This includes her email address, engagement history, and any cached personal information. Our customer ID is CT-445821 if that helps.”

Similar emails went to Mixpanel, Zendesk, and others. Each vendor’s support team began their own internal discussions about the deletion request.

Current copies: 145 (130 + vendor communications and their internal processes)

Day 12: The Compliance Documentation

Legal required full documentation of the deletion process for compliance purposes. They created a detailed case file including:

  • Original deletion request (with full customer details)
  • Complete inventory of data locations
  • Timeline of deletion activities
  • Correspondence with all vendors
  • Screenshots of data in various systems
  • Verification procedures for confirming deletion

This documentation was stored in multiple systems and backed up according to the company’s 7-year legal retention policy.

Current copies: 160+ (145 + compliance documentation across multiple systems)

Day 15: Verification Script Paradox

To verify the deletion was complete, the QA team needed to check each system. They created test scripts that included Sarah’s personal information as search parameters:

# Verify deletion of customer data
def verify_deletion():
    customer_email = "sarah.thompson.1982@email.com"
    customer_id = "CT-445821"
    
    # Check RDS
    assert not find_user_by_email(customer_email)
    # Check S3
    assert not s3_bucket_contains(f"user-uploads/{customer_id}")
    # Check DynamoDB
    assert not dynamodb_has_sessions(customer_id)

These scripts were committed to version control, code-reviewed, and deployed to multiple environments.

Current copies: 180+ (160 + version control history + deployment logs)

The Final Count: Mission Accomplished?

Three weeks later, CloudyApp successfully deleted Sarah Thompson’s original data from their production systems. However, her personal information now existed in:

  • 47 email inboxes across the company
  • 12 Slack channels with searchable history
  • 8 vendor support systems
  • 6 backup and replica databases
  • 5 legal and compliance documentation systems
  • 4 version control repositories
  • 3 monitoring and logging systems
  • 2 analytics and data warehouse platforms
  • 1 disaster recovery site

Estimated total copies: 200+

The Streisand Effect Strikes Again

What started as a simple request to delete one customer’s data became a company-wide archaeological expedition that created exponentially more copies of that very data. This is a variation of the Streisand Effect*: when trying to suppress or hide information accidentally makes it more public. CloudyApp’s well-intentioned deletion process became the most effective data replication system they’d ever built.

This thought experiment, while exaggerated, illustrates real challenges many software companies face:

1. Privacy by Design is Not Optional

Data deletion processes should be built into systems from day one, not reverse-engineered when the first deletion request arrives.

2. Automate Everything

Manual processes involving personal data create copies, require documentation, and scale poorly. Automated deletion pipelines minimise human handling of sensitive information.

3. Data Minimisation Prevents Data Multiplication

The less personal data you collect and store, the less you need to worry about deleting. Every additional data point multiplies the complexity.

4. Documentation Can Become the Problem

While compliance documentation is necessary, it shouldn’t become a more permanent repository of personal data than the systems you’re trying to purge.

5. Test Your Deletion Processes Before You Need Them

Use synthetic data to verify your deletion workflows work correctly, rather than learning through live customer requests.

Sarah Thompson never learned about the chaos her simple email caused. She received a professional response two days later confirming her data had been deleted, and moved on with her life.

*The Streisand Effect is named after Barbra Streisand, who in 2003 tried to remove photos of her house from an online collection. Her lawsuit drew massive attention to the images, which otherwise few people would have noticed.