The Ethics of Erasure: Automating the 'Right to be Forgotten'

02 The Manual Trap: Why SQL DELETE is Insufficient

The traditional engineering response to a data removal request is the execution of a SQL DELETE command. Within the context of compliance engineering, this approach is increasingly viewed as a "manual trap" that addresses only the most visible layer of data persistence while leaving the underlying fragments intact across the storage stack.⁶ A simple DELETE statement changes the logical state of a record but fails to account for the physical and operational realities of modern database engines and distributed systems.¹⁴

03 Physical Persistence and Logical Abstracts

When a record is deleted in a Relational Database Management System (RDBMS) like PostgreSQL or Microsoft SQL Server, the engine typically performs a logical deletion. The space previously occupied by the record is marked as available for reuse, but the bits themselves are not immediately zeroed out on the physical disk.¹³ This behavior is a consequence of performance optimization; physically overwriting data for every deletion would introduce significant I/O overhead. In rowstore indexes, the deletion of rows often causes page fragmentation. For example, a page with 100% density may split into two pages at 50% density after modifications, leaving the "deleted" data fragments residing in the unused space of those pages until they are eventually reclaimed and overwritten by a background process such as VACUUM.¹⁵

The transition from magnetic Hard Disk Drives (HDDs) to Solid State Drives (SSDs) has further complicated the physics of erasure. SSD controllers utilize advanced wear-leveling algorithms and over-provisioning to distribute writes across NAND flash cells, extending the drive's lifespan.¹⁷ When the operating system or database engine signals a deletion, the SSD controller may simply remap the logical address to a new physical cell, leaving the original data in an "inaccessible" but forensically recoverable area of the flash memory.¹⁷ Standard formatting and file-level deletions are insufficient for SSDs; true physical erasure requires specialized commands like ATA Secure Erase or physical destruction of the chips to render the data irretrievable.¹⁷

04 The Transaction Log and WAL Paradox

Beyond the data files themselves, the primary source of PII persistence in modern databases is the Write-Ahead Log (WAL) or transaction log. To maintain ACID (Atomicity, Consistency, Isolation, Durability) properties, every transaction—including a deletion—is first recorded in a sequential log before the changes are applied to the data pages.¹⁹ These logs are critical for crash recovery and Point-in-Time Recovery (PITR).

In active environments, the accumulation of WAL files can be substantial. For instance, in PostgreSQL, mechanisms such as replication slots and long-running backups can prevent the database engine from truncating or recycling old WAL segments.²⁰ If a replication replica becomes disconnected, the primary server may hoard WAL files indefinitely, waiting for the replica to catch up, which inadvertently preserves the "deleted" PII within those logs.²⁰ From a compliance standpoint, a user has not been erased until the WAL logs containing their original INSERT or UPDATE operations have been rotated, truncated, and physically overwritten.²¹ Engineers must therefore synchronize their erasure verification with the log retention and checkpointing cycles of the database.¹³

05 The Backup Re-Introduction Problem

The most significant operational hurdle for Article 17 is the conflict between the Right to Erasure and the "Right to Recover." Backups are by design immutable, providing a safety net for disaster recovery. If an organization erases a user from its production database and subsequently performs a full system restore from a backup taken prior to that request, the user's data is effectively "resurrected".¹¹

Regulatory guidance from European supervisory authorities, such as the UK’s Information Commissioner's Office (ICO), acknowledges that immediate deletion from backup tapes or immutable snapshots is often technically impossible or disproportionately expensive.¹⁴ However, the guidance mandates that organizations put such data "beyond use" and implement a process to re-apply erasure requests immediately upon the restoration of any backup.¹³ This requires a secondary "Forgotten Subjects" database—a persistent list of identifiers that have requested erasure—which must be consulted every time a database is restored or a snapshot is mounted to a production environment.¹¹

06 Crypto-Shredding: The Logical Erasure Paradigm

To overcome the physical persistence issues associated with traditional storage, compliance engineering has adopted "crypto-shredding" as a primary methodology for Article 17 fulfillment.²⁶ Crypto-shredding involves the deliberate deletion or overwriting of the encryption keys associated with specific personal data.⁷ By rendering the data unreadable, the organization achieves a state that regulatory authorities often consider equivalent to physical destruction, provided the encryption is sufficiently robust.²⁶

07 Architectural Foundations: Envelope Encryption

The effectiveness of crypto-shredding is contingent upon a tiered encryption strategy known as envelope encryption. In this model, data is not protected by a single, monolithic master key. Instead, the architecture employs a hierarchy of keys to manage the encryption lifecycle at scale.²⁹

At the lowest level, a Data Encryption Key (DEK) is generated locally to encrypt the specific dataset or PII fields. This DEK is then "wrapped" or encrypted by a Key Encryption Key (KEK), which is managed by a centralized Key Management Service (KMS) or Hardware Security Module (HSM).²⁹ The encrypted data and the wrapped DEK are stored together in the database or object storage, while the KEK never leaves the secure boundary of the KMS.²⁹

The mathematical workflow can be expressed as:

Encryption: and .

Decryption: and .

When a valid erasure request is received, the organization destroys the specific KEK associated with that data subject.²⁶ Without the KEK, the DEK cannot be unwrapped, and the ciphertext becomes permanent cryptographic noise.⁷ This approach is particularly powerful because it enables the "erasure" of data stored in locations the controller cannot easily access, such as offline backup tapes or distributed cloud nodes.²⁶

08 Scalability and Distributed Systems: The Spotify Case Study

In distributed microservices architectures, user data is often replicated across hundreds of nodes and disparate services like Kafka, ElasticSearch, and S3.7 Manually tracing and physically deleting every instance of a user's data within the one-month GDPR response window is logistically impossible for large-scale platforms.⁷

Spotify addressed this through its "Padlock" system, which leverages crypto-shredding to manage user privacy at scale.²⁶ By assigning a unique, subject-specific KEK to each user at the point of ingestion, Spotify ensures that deleting a single key in one central location immediately invalidates all copies of that user's data throughout the global infrastructure.²⁶ This eliminates the need to coordinate complex deletion jobs across every individual system, as the data is effectively deleted once the key is removed from the central KMS.²⁶

09 Security Constraints and Future Resilience

While crypto-shredding is a robust tool, it is not a panacea. Its security is only as strong as the encryption algorithm and the key management policies in place.²⁶ If the encrypted data is stored in a way that is susceptible to brute-force attacks or if the KEK is compromised prior to its deletion, the "erasure" is invalidated.²⁶

Furthermore, engineers must consider the "future-proof" nature of current encryption. The advent of quantum computing poses a significant threat to asymmetric encryption and some symmetric key lengths.²⁷ For long-term archival data, organizations should implement post-quantum cryptographic (PQC) standards and ensure that KEKs are managed using Hardware Security Modules (HSMs) that provide high-entropy key generation and tamper-proof storage.²⁷

010 Orchestration: Automating Deletion with Apache Airflow

The move from manual scripts to a compliant Article 17 workflow requires a sophisticated orchestration layer capable of managing dependencies, retries, and cross-system communication. Apache Airflow has emerged as the industry-standard platform for these workflows, allowing compliance engineers to define erasure logic as a Directed Acyclic Graph (DAG).²⁵ By treating erasure as a structured pipeline, organizations can ensure that a deletion request propagates correctly through the entire data ecosystem.³²

011 DAG Design Patterns for Distributed Erasure

A resilient erasure DAG must handle the heterogeneous nature of modern infrastructure, where PII resides in relational databases, document stores, object storage, and SaaS applications.¹ The DAG typically follows a staged execution pattern to ensure data integrity and compliance verification.³⁶

Request Ingestion and Verification: The workflow begins by pulling valid erasure requests from a queue or a "Privacy Portal".²⁴ The first task ensures the identity of the requester and validates the legal grounds for the request.²⁴

PII Mapping: The orchestration layer queries a data catalog or metadata engine to identify all datasets and systems containing the subject's PII.¹

Parallel Execution: Using specialized Airflow operators (e.g., PostgresOperator, S3DeleteObjectsOperator, HttpOperator for SaaS APIs), the DAG triggers simultaneous deletion or crypto-shredding tasks across all identified systems.²⁵

Cascade and Propagation: In data lake architectures, deletions must often propagate from "Bronze" (raw) layers to "Silver" (cleaned) and "Gold" (aggregated) layers.³² The DAG manages these dependencies to ensure that sanitized views reflect the erasure of the raw source data.³²

Audit and Closure: The final stage of the DAG involves gathering "success" signals from all sub-tasks and generating a signed Proof of Erasure for the organization's compliance records.⁸

012 Resilience Through Idempotency and Retries

In a distributed environment, failures are common—APIs may timeout, or database connections may drop. Airflow’s task-level retry mechanism is critical for ensuring Article 17 fulfillment within mandated timelines.³⁷ However, for an erasure DAG to be safe, every task must be idempotent.³⁷

An idempotent erasure task is one where multiple executions of the task result in the same state: the data is gone. For example, a task designed to call a KMS API to delete a key must be written to handle a "404 Key Not Found" error as a success signal on a retry, rather than failing the entire pipeline.²⁵ Engineers also leverage operator-level retries for transient cloud provider errors, which allow the task to recover instantly without generating a "failed" instance in the Airflow metadata database or triggering unnecessary on-call alerts.⁴²

013 Modern Table Formats: Delta Lake and Apache Iceberg

For organizations managing petabytes of data in S3-compatible object storage, physical row-level deletion was historically inefficient, requiring the rewrite of massive Parquet files for even a single record removal.⁴⁴ Modern table formats like Delta Lake and Apache Iceberg have introduced database-like capabilities to the data lake, which are easily orchestrated via Airflow.³⁸

Iceberg, in particular, uses "delete files" in its metadata layer to mark rows as removed without immediately touching the underlying Parquet files.⁴⁴ This allows the erasure request to be "fulfilled" from the perspective of query engines almost instantly. A separate, scheduled maintenance task in the Airflow DAG then performs a physical rewrite (compaction) of the data files to permanently purge the records and satisfy physical erasure requirements.³⁸

014 Audit Trails: Generating Immutable Proof of Erasure

A cornerstone of GDPR compliance is the ability to demonstrate that the organization has acted upon every valid request. Article 5(2) and Article 17 collectively require that organizations maintain a detailed, tamper-proof record of their erasure activities.¹ However, the engineering of an audit trail for erasure presents a paradox: the log must prove that data was deleted without inadvertently re-recording the very PII that was removed.¹¹

015 The Proof of Erasure Certificate Standard

A "Proof of Erasure" or "Certificate of Data Destruction" provides the verifiable evidence required during a regulatory audit.¹⁸ These certificates should align with international standards such as NIST SP 800-88 and the newer IEEE 2883-2022, which define the technical benchmarks for successful data sanitization.⁴⁰

A compliant certificate must document the "who, what, where, when, and how" of the erasure process.⁴⁰ For automated systems, this is typically generated as a JSON object and signed with a digital signature to ensure non-repudiation.³³

016 Implementing Immutable Logs with Cryptographic Chains

To ensure the integrity of audit trails, compliance engineers utilize append-only logging structures that are cryptographically secured.³³ By using hash chains, each log entry is mathematically linked to the previous one, making it impossible for a malicious actor (or a rogue administrator) to delete or modify a past erasure record without breaking the chain.³³

The integrity of a hash-chained log is governed by:

where is the current hash, is the message containing the erasure certificate, and is a secure hash function like SHA-256.33 For even higher security, organizations can anchor these periodic hash roots into a public ledger or a centralized "Ledger Database" like AWS QLDB, which provides a verifiable, immutable history of all data operations.³³

017 Privacy-Preserving Auditing

An audit trail that contains PII is itself a liability. Ethical engineering requires that audit logs are "PII-free" from the moment of inception.¹¹ Instead of logging the user's name or email address, the audit system should use a stable entity key (e.g., Internal_User_ID).²⁵ When the final erasure task in the DAG completes, the mapping between that internal ID and the external PII (e.g., the user’s email) is destroyed.²⁵ This leaves a "Zero-Knowledge" audit trail: the logs prove that the organization performed a compliant erasure for a specific subject, but the log itself does not reveal who that subject was, thus satisfying both the Right to Erasure and the requirement for accountability.³³

018 The Ethics of Erasure: A Multi-Disciplinary Synthesis

Automating Article 17 is not merely a technical exercise in database management or cryptography; it is a fundamental commitment to digital ethics and user autonomy.¹⁰ From a compliance engineering perspective, "The Ethics of Erasure" demands a proactive, "Privacy by Design" approach that prioritizes the user's rights over organizational convenience.⁹

019 Privacy by Design and Data Minimization

The most ethical way to handle Article 17 requests is to minimize the amount of data that needs to be erased in the first place.¹¹ Ethical data engineering emphasizes the principle of data minimization—collecting only the PII strictly necessary for a stated business purpose and implementing automated, time-based retention policies.⁸

For example, using S3 Object Lock with a set retention period ensures that data is automatically and immutably protected for the duration of its legal utility, but is physically purged as soon as the retention window expires, without requiring a manual request.⁵⁵ This reduces the "identity lifespan" of user data and significantly lowers the operational risk associated with Article 17 compliance.⁸

020 The AI Conflict: Erasure in the Age of Large Models

As organizations increasingly integrate AI and Machine Learning into their operations, Article 17 presents a unique ethical and technical dilemma. Personal data is the "lifeblood" of AI, used to train models that identify patterns and make decisions.⁵³ If a data subject requests erasure, their data must be removed not just from the databases, but also from the training sets.⁵³

This leads to the "Unlearning" problem: removing a specific subject from a trained model often requires retraining the entire model from scratch to ensure that the subject's patterns are not implicitly stored in the model's weights.⁵³ Ethical compliance engineering in this space involves:

Sanitization at Ingest: Using automated pipelines to mask or pseudonymize data before it reaches the training bucket.²⁵

Differential Privacy: Adding mathematical noise to training data so that the presence or absence of an individual data subject cannot be determined from the model’s outputs.⁵⁹

Model Modularization: Designing models that can be retrained in partitions, allowing for the targeted "unlearning" of specific data clusters without a total system reset.⁵³

021 Corporate Responsibility and Trust

Finally, the ethics of erasure is about building and maintaining trust. An organization that can promptly, transparently, and effectively fulfill an Article 17 request demonstrates to its customers and stakeholders that it respects their dignity and digital identity.² Automated compliance is a signal of operational maturity, proving that the organization views privacy not as a regulatory hurdle, but as a core component of its value proposition.²

By moving toward a "Zero-Touch" erasure model—where requests are verified, executed across distributed systems via Airflow, rendered unreadable via crypto-shredding, and documented in immutable ledgers—organizations can achieve the highest standard of GDPR compliance.¹ In the digital era, the right to be forgotten is the ultimate expression of user control, and the ethics of its implementation will define the future of responsible technology.²

Works cited

How to Achieve Compliance with GDPR Article 17 in a Hybrid Cloud Environment - MDPI, accessed January 27, 2026, https://www.mdpi.com/2413-4155/3/1/3

What is "Right to Erasure"? - PrivacyEngine, accessed January 27, 2026, https://www.privacyengine.io/blog/resources/glossary/right-to-erasure/

GDPR Right to Be Forgotten - eSignGlobal, accessed January 27, 2026, https://www.esignglobal.com/blog/handling-gdpr-right-to-be-forgotten-requests

Art. 17 GDPR – Right to erasure ('right to be forgotten') - General Data Protection Regulation (GDPR), accessed January 27, 2026, https://gdpr-info.eu/art-17-gdpr/

Right to be Forgotten: GDPR Erasure Rights Guide - ComplyDog, accessed January 27, 2026, https://complydog.com/blog/right-to-be-forgotten-gdpr-erasure-rights-guide

GDPR and Database Backups | Severalnines, accessed January 27, 2026, https://severalnines.com/blog/gdpr-and-database-backups/

Crypto Shredding in Kafka: A Cost-Effective Way to Ensure Compliance - Conduktor, accessed January 27, 2026, https://conduktor.io/blog/crypto-shredding-in-kafka-a-cost-effective-way-to-ensure-compliance

Data Retention & Automatic Erasure: How to Build a Compliant Workflow - CryptoBind, accessed January 27, 2026, https://www.jisasoftech.com/data-retention-automatic-erasure-how-to-build-a-compliant-workflow/

Privacy by Design GDPR: Complete Implementation Guide for 2025, accessed January 27, 2026, https://secureprivacy.ai/blog/privacy-by-design-gdpr-2025

Data Privacy & AI Ethics Best Practices | Governance Guidance 2025 - TrustCommunity, accessed January 27, 2026, https://community.trustcloud.ai/docs/grc-launchpad/grc-101/governance/data-privacy-and-ai-ethical-considerations-and-best-practices/

GDPR for Operations - InfoQ, accessed January 27, 2026, https://www.infoq.com/articles/gdpr-for-operations/

GDPR and the “Right to Be Forgotten”: The Role of Certified Data Destruction, accessed January 27, 2026, https://datadestruction.com/gdpr-and-the-right-to-be-forgotten-the-role-of-certified-data-destruction/

Does GDPR require deleted backups to be rendered unrecoverable?, accessed January 27, 2026, https://dba.stackexchange.com/questions/305978/does-gdpr-require-deleted-backups-to-be-rendered-unrecoverable

GDPR Right To Erasure: Should You Delete Backups As Well? - Hall Booth Smith, accessed January 27, 2026, https://hallboothsmith.com/we-all-know-about-gdprs-right-to-erasure-does-this-mean-you-have-to-delete-data-from-backups-as-well/

Optimize index maintenance to improve query performance and reduce resource consumption - Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver17

Whitepaper : SQL Server Fragmentation Explained - IDERA, accessed January 27, 2026, https://www.idera.com/resource-center/whitepapers/sql-server-fragmentation-explained/

New IT Systems Require SSD Shredding for Data Security, accessed January 27, 2026, https://veritysystems.com/new-it-systems-require-ssd-shredding-for-data-security/

Understanding the BSI Guidelines for Permanently Erasing Data - BitRaser, accessed January 27, 2026, https://www.bitraser.com/article/bsi-guidelines-permanently-erasing-data.php

Troubleshoot a full transaction log (SQL Server Error 9002) - Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002?view=sql-server-ver17

How to Clean Up WAL Files and Replication Slots in PostgreSQL (Complete Guide for DBAs) | by Jeyaram Ayyalusamy | Medium, accessed January 27, 2026, https://medium.com/@jramcloud1/how-to-clean-up-wal-files-and-replication-slots-in-postgresql-complete-guide-for-dbas-2ca33b3fdb3b

How can I solve postgresql problem after deleting wal files?, accessed January 27, 2026, https://dba.stackexchange.com/questions/80317/how-can-i-solve-postgresql-problem-after-deleting-wal-files

Amazon RDS PostgreSQL WAL Logs Not Clearing, High Storage Consumption, accessed January 27, 2026, https://repost.aws/questions/QUBOrsgylZS2GdChkiOtsEiQ/amazon-rds-postgresql-wal-logs-not-clearing-high-storage-consumption

Defragmentation Based on Page Density - SQL Server Administration, accessed January 27, 2026, https://forums.sqlteam.com/t/defragmentation-based-on-page-density/24534

Right to Erasure: GDPR Compliance Steps - Reform.app, accessed January 27, 2026, https://www.reform.app/blog/right-to-erasure-gdpr-compliance-steps

Building a Secure GenAI Architecture in HealthTech: Avoiding HIPAA & GDPR Pitfalls, accessed January 27, 2026, https://www.sekurno.com/post/building-a-secure-genai-architecture-in-healthtech-avoiding-hipaa-gdpr-pitfalls

Crypto-shredding the best solution for cloud system data erasure ..., accessed January 27, 2026, https://www.verdict.co.uk/crypto-shredding-gdpr-cloud-systems/

Crypto-shredding - Wikipedia, accessed January 27, 2026, https://en.wikipedia.org/wiki/Crypto-shredding

Privacy Policy - Agrilinkage, accessed January 27, 2026, https://www.agrilinkage.com/privacy-policy

Envelope encryption | Cloud Key Management Service - Google Cloud Documentation, accessed January 27, 2026, https://docs.cloud.google.com/kms/docs/envelope-encryption

Protecting Sensitive Data Using Envelope Encryption - DEV Community, accessed January 27, 2026, https://dev.to/ibrahimgunduz34/protecting-sensitive-data-using-envelope-encryption-4o3c

Understanding Envelope Encryption with AWS KMS | willdady.com, accessed January 27, 2026, https://willdady.com/understanding-envelope-encryption-with-aws-kms

GDPR for Data Engineers: A Practical Guide to Privacy-Compliant Data Architecture, accessed January 27, 2026, https://blog.pmunhoz.com/data-engineering/gdpr_data_engineers_guide

Immutable Audit Log Architecture - Emergent Mind, accessed January 27, 2026, https://www.emergentmind.com/topics/immutable-audit-log

Dags — Airflow 3.1.⁶ Documentation, accessed January 27, 2026, https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html

Architecture Overview — Airflow 3.1.⁶ Documentation, accessed January 27, 2026, https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html

DAGs — Airflow Documentation, accessed January 27, 2026, https://airflow.apache.org/docs/apache-airflow/2.5.2/core-concepts/dags.html

DAG writing best practices in Apache Airflow | Astronomer Docs, accessed January 27, 2026, https://www.astronomer.io/docs/learn/dag-best-practices

Prepare your data for GDPR compliance | Databricks on Google Cloud, accessed January 27, 2026, https://docs.databricks.com/gcp/en/security/privacy/gdpr-delta

Everything you need to know about the "Right to be forgotten" - GDPR.eu, accessed January 27, 2026, https://gdpr.eu/right-to-be-forgotten/

Must Have Elements of a Data Destruction Certificate - Blancco, accessed January 27, 2026, https://blancco.com/resources/blog-must-have-elements-of-a-data-destruction-certificate/

50 IT Director Interview Questions & Answers [2025 - DigitalDefynd, accessed January 27, 2026, https://digitaldefynd.com/IQ/it-director-interview-questions/

Building Resilient Airflow Operators | by Dusan Zamurovic | Jan, 2026 | Medium, accessed January 27, 2026, https://medium.com/@ezamur/building-resilient-airflow-operators-the-retry-pattern-for-aws-emr-fc264c792cdd

Best Practices — Airflow 3.1.⁶ Documentation, accessed January 27, 2026, https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html

Apache Iceberg on AWS: The Key to GDPR Compliant Data Lakes - Data Engineer Things, accessed January 27, 2026, https://blog.dataengineerthings.org/apache-iceberg-on-aws-the-key-to-gdpr-compliant-data-lakes-d86b4ad07478

How do you enforce immutability and append‑only audit trails? - Design Gurus, accessed January 27, 2026, https://www.designgurus.io/answers/detail/how-do-you-enforce-immutability-and-appendonly-audit-trails

A Comprehensive List of Data Wiping & Erasure Standards - Blancco, accessed January 27, 2026, https://blancco.com/resources/blog-comprehensive-list-data-wiping-erasure-standards/

What Are Immutable Logs? A Complete Guide - HubiFi, accessed January 27, 2026, https://www.hubifi.com/blog/immutable-audit-log-guide

The AIGN Data Act AI Governance Framework - Shift8 Web, accessed January 27, 2026, https://cycejbtdfgao.cdn.shift8web.com/wp-content/uploads/2025/07/AIGN-EU-Data-Act-AI-Governance-Framework.pdf

The Ultimate Guide to Immutable Audit Trails - HubiFi, accessed January 27, 2026, https://www.hubifi.com/blog/immutable-audit-log-basics

Soft delete vs hard delete in multitenancy with GDPR and audit trail - Reddit, accessed January 27, 2026, https://www.reddit.com/r/softwarearchitecture/comments/1mfsrht/soft_delete_vs_hard_delete_in_multitenancy_with/

Ask HN: How are you implementing GDPR-compliant soft deletes? - Hacker News, accessed January 27, 2026, https://news.ycombinator.com/item?id=16366050

Data Ethics: Frameworks, Principles & Challenges (2025) - Atlan, accessed January 27, 2026, https://atlan.com/data-ethics-101/

AI and GDPR: A Road Map to Compliance by Design - Episode 3: The Development Phase, accessed January 27, 2026, https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20250730-ai-and-gdpr-a-road-map-to-compliance-by-design-episode-3-the-design-phase

Data retention and deletion | Digital Ethics and Privacy in Business Class Notes - Fiveable, accessed January 27, 2026, https://fiveable.me/digital-ethics-and-privacy-in-business/unit-2/data-retention-deletion/study-guide/prHu5LUl38XrfnXK

Applying Amazon S3 Object Lock at scale for petabytes of existing data | AWS Storage Blog, accessed January 27, 2026, https://aws.amazon.com/blogs/storage/applying-amazon-s3-object-lock-at-scale-for-petabytes-of-existing-data/

S3 Object Lock for Ransomware Protection, accessed January 27, 2026, https://objectfirst.com/guides/immutability/s3-object-lock-for-ransomware-protection/

Setting Up S3 Object Locking (Immutable Storage) for Rapid Recovery Archives (4376845), accessed January 27, 2026, https://support.quest.com/rapid-recovery/kb/4376845/setting-up-s3-object-locking-immutable-storage-for-rapid-recovery-archives

Navigating Regulatory and Ethical Challenges in Data Lake Governance: A Comprehensive Review, accessed January 27, 2026, https://norislab.com/index.php/IJITAI/article/download/93/86/216

(PDF) ETHICAL DATA ENGINEERING: NAVIGATING PRIVACY CHALLENGES AND ALGORITHMIC BIAS IN THE AI ERA - ResearchGate, accessed January 27, 2026, https://www.researchgate.net/publication/390756201_ETHICAL_DATA_ENGINEERING_NAVIGATING_PRIVACY_CHALLENGES_AND_ALGORITHMIC_BIAS_IN_THE_AI_ERA