On this page

Data Disposal

Data disposal permanently removes information from organisational systems when retention periods expire or when deletion is required by regulation, data subject request, or operational need. This task covers identification of disposal candidates, execution of secure deletion across storage types, verification that deletion succeeded, and documentation for compliance purposes.

Disposal differs from archiving in its permanence. Archived data moves to long-term storage for potential future retrieval. Disposed data ceases to exist in any recoverable form. The irreversibility of disposal demands verification at each stage and authorisation before execution.

Prerequisites

Before beginning disposal, confirm the following conditions are met:

Retention period verification requires access to the organisation’s data retention schedule and the ability to query metadata showing when records were created or last modified. The retention schedule specifies minimum retention periods by data category. Disposal before these periods expire violates policy and potentially regulation. Calculate the retention expiry date by adding the retention period to the record creation date or the date of last business activity, whichever is later.

Legal hold status must be checked against the current legal hold register. A legal hold suspends normal retention schedules for data potentially relevant to litigation, investigation, or regulatory inquiry. Data under legal hold cannot be disposed regardless of retention period expiry. Obtain the legal hold register from the legal or compliance team and search for holds affecting the data categories, systems, or date ranges you intend to dispose.

Disposal authorisation requires sign-off from the data owner for the dataset in question. The data owner, as defined in the data governance framework, bears accountability for decisions affecting their data domain. Obtain written authorisation specifying the dataset, disposal rationale, and confirmation that prerequisites have been verified. For high-sensitivity data classified as confidential or restricted, require additional sign-off from the information security team.

System access requirements vary by storage type:

Storage type	Required access	Typical role
Relational database	DELETE permission on target tables, audit log write	Database administrator
Document storage	Delete permission on containers/folders	System administrator
Cloud object storage	s3:DeleteObject or equivalent, versioning management	Cloud administrator
Backup systems	Backup catalogue modification, media management	Backup administrator
SaaS applications	Administrative deletion rights, data export for verification	Application administrator

Verification tooling should be prepared before disposal begins. This includes query access to confirm record absence, log analysis tools to capture deletion events, and checksum utilities if verifying file deletion.

Procedure

Identifying disposal candidates

Extract the current data inventory for the target system from the data catalogue. If no catalogue exists, query system metadata directly. For databases, retrieve table row counts and date ranges:

   SELECT
     table_schema,
     table_name,
     MIN(created_date) as oldest_record,
     MAX(created_date) as newest_record,
     COUNT(*) as record_count
   FROM information_schema.tables t
   JOIN your_schema.audit_dates a ON t.table_name = a.table_name
   GROUP BY table_schema, table_name
   ORDER BY oldest_record;

For file systems, generate an age report:

   find /data/archive -type f -mtime +2555 -printf '%T+ %p\n' | sort > disposal_candidates.txt
   # Files older than 7 years (2555 days)

Cross-reference identified records against the retention schedule. Map each data category to its retention period. Create a disposal candidate list containing only records where:
- Current date minus record date exceeds retention period
- No legal hold applies to the data category or system
- No business exception extends retention
Document each candidate with: unique identifier, data category, creation date, retention period, calculated expiry date, and disposal eligibility confirmation.
Verify legal hold status for each disposal candidate. Query the legal hold register:

   Legal Hold Register Check
   -------------------------
   Hold ID: LH-2024-017
   Affected systems: CRM, Email archive
   Date range: 2019-01-01 to 2022-12-31
   Status: Active

   Disposal candidates in CRM from 2019-2022: EXCLUDED
   Disposal candidates in CRM from 2018 and earlier: ELIGIBLE

Remove any records falling within active hold scope from the disposal candidate list.

Generate the disposal request document containing:
- Requestor name and role
- Dataset description and location
- Record count and date range
- Retention policy reference
- Legal hold verification statement
- Business justification
- Proposed disposal date
- Disposal method
Submit to the data owner for authorisation. Do not proceed until written approval is received and recorded.

Executing disposal by storage type

The disposal method depends on where data resides. Each storage type requires specific techniques to ensure data becomes unrecoverable.

Relational databases

Create a pre-disposal snapshot for verification purposes. This snapshot confirms what existed before deletion and enables validation that the correct records were removed:

   CREATE TABLE disposal_audit.pre_deletion_20250115 AS
   SELECT id, created_date, data_category, checksum(record_content) as content_hash
   FROM target_table
   WHERE created_date < '2018-01-15';

   -- Record count for verification
   SELECT COUNT(*) FROM disposal_audit.pre_deletion_20250115;
   -- Result: 47,832 records

Execute deletion within a transaction to enable rollback if verification fails:

   BEGIN TRANSACTION;

   DELETE FROM target_table
   WHERE created_date < '2018-01-15'
   AND id IN (SELECT id FROM disposal_audit.pre_deletion_20250115);

   -- Verify deletion count matches expected
   -- Expected: 47,832 rows affected

   -- If count matches:
   COMMIT;

   -- If count does not match:
   ROLLBACK;

For databases with soft-delete patterns where a deleted flag marks records as inactive rather than removing them, execute hard deletion:

   -- First verify soft-deleted records past retention
   SELECT COUNT(*) FROM target_table
   WHERE deleted = true
   AND deleted_date < '2018-01-15';

   -- Execute permanent removal
   DELETE FROM target_table
   WHERE deleted = true
   AND deleted_date < '2018-01-15';

Reclaim storage space after deletion. For PostgreSQL:

   VACUUM FULL target_table;
   ANALYZE target_table;

For MySQL:

   OPTIMIZE TABLE target_table;

For SQL Server:

   ALTER INDEX ALL ON target_table REBUILD;
   DBCC SHRINKDATABASE (database_name, 10);

File systems

Generate a manifest of files to delete, capturing metadata for the audit trail:

   find /data/records -type f -mtime +2555 \
     -printf '%T@ %s %M %p\n' > /var/log/disposal/manifest_20250115.txt

   # Count files
   wc -l /var/log/disposal/manifest_20250115.txt
   # Result: 12,847 files

   # Calculate total size
   awk '{sum += $2} END {print sum/1024/1024/1024 " GB"}' \
     /var/log/disposal/manifest_20250115.txt
   # Result: 847.3 GB

For standard deletion where secure erasure is not required, remove files and directories:

   # Delete files from manifest
   cut -d' ' -f4- /var/log/disposal/manifest_20250115.txt | \
     xargs -d '\n' rm -v >> /var/log/disposal/deletion_log_20250115.txt 2>&1

   # Remove empty directories
   find /data/records -type d -empty -delete

For secure erasure of sensitive data, overwrite file contents before deletion. The shred utility overwrites files multiple times:

   # Secure deletion with 3-pass overwrite
   cut -d' ' -f4- /var/log/disposal/manifest_20250115.txt | \
     xargs -d '\n' -I {} shred -vfz -n 3 {}

   # -v: verbose output
   # -f: force permissions change if needed
   # -z: add final overwrite with zeros
   # -n 3: overwrite 3 times with random data

Secure erasure on SSDs requires different handling because wear-levelling prevents guaranteed overwrite of specific sectors. For SSD storage containing sensitive data, use cryptographic erasure or physical destruction.

Verify deletion by confirming files no longer exist:

   # Check for any remaining files from manifest
   cut -d' ' -f4- /var/log/disposal/manifest_20250115.txt | \
     xargs -d '\n' -I {} test -e {} && echo "EXISTS: {}"

   # No output indicates successful deletion

Cloud object storage

Cloud storage requires attention to versioning, lifecycle policies, and cross-region replication.

Identify objects for disposal. For AWS S3:

   aws s3api list-objects-v2 \
     --bucket organisation-data \
     --prefix records/2017/ \
     --query "Contents[?LastModified<='2018-01-15'].[Key,Size,LastModified]" \
     --output text > s3_disposal_manifest.txt

   wc -l s3_disposal_manifest.txt
   # Result: 8,421 objects

For Azure Blob Storage:

   az storage blob list \
     --container-name records \
     --prefix 2017/ \
     --query "[?properties.lastModified<='2018-01-15T00:00:00Z'].{name:name,size:properties.contentLength}" \
     --output tsv > azure_disposal_manifest.txt

Check versioning status. If versioning is enabled, standard deletion creates delete markers rather than removing data. Previous versions remain accessible:

   aws s3api get-bucket-versioning --bucket organisation-data
   # Output: {"Status": "Enabled"}

For versioned buckets, list all versions of target objects:

   aws s3api list-object-versions \
     --bucket organisation-data \
     --prefix records/2017/ \
     --query "Versions[?LastModified<='2018-01-15'].[Key,VersionId]" \
     --output text > version_manifest.txt

Execute deletion. For non-versioned buckets:

   # Delete objects in batches of 1000 (S3 limit)
   split -l 1000 s3_disposal_manifest.txt batch_

   for batch in batch_*; do
     aws s3api delete-objects \
       --bucket organisation-data \
       --delete "$(cat $batch | awk '{print "{\"Key\":\"" $1 "\"}"}' | \
         jq -s '{Objects: .}')"
   done

For versioned buckets, delete all versions:

   while read key version; do
     aws s3api delete-object \
       --bucket organisation-data \
       --key "$key" \
       --version-id "$version"
   done < version_manifest.txt

Verify deletion and confirm no versions remain:

   aws s3api list-object-versions \
     --bucket organisation-data \
     --prefix records/2017/ \
     --query "length(Versions[?LastModified<='2018-01-15'])"
   # Result: 0

Backup media

Backup systems present particular challenges because data may exist across multiple backup generations, tape media, and offsite copies.

Identify backup media containing disposal candidate data. Query the backup catalogue:

   Backup Catalogue Query
   ----------------------
   Data source: /data/records
   Date range: 2017-01-01 to 2017-12-31

   Results:
   - Full backup 2017-01-07, Media ID: TAPE-2017-001, Location: Onsite vault
   - Full backup 2017-02-04, Media ID: TAPE-2017-005, Location: Offsite (Iron Mountain)
   - Full backup 2017-03-04, Media ID: TAPE-2017-009, Location: Recycled 2020-03
   [... additional entries ...]

   Active media containing target data: 47 tapes

For disk-based backup systems, expire backup jobs containing target data. In Veeam:

   # Find backup jobs containing target path
   Get-VBRBackup | Where-Object {$_.GetObjects().Path -like "*records/2017*"}

   # Remove restore points older than retention
   $backup = Get-VBRBackup -Name "Records Backup"
   $restorePoints = Get-VBRRestorePoint -Backup $backup |
     Where-Object {$_.CreationTime -lt "2018-01-15"}

   foreach ($rp in $restorePoints) {
     Remove-VBRRestorePoint -RestorePoint $rp -Confirm:$false
   }

For tape media requiring physical destruction, generate a destruction request:

   Media Destruction Request
   -------------------------
   Request ID: MDR-2025-003
   Date: 2025-01-15

   Media for destruction:
   - TAPE-2017-001 through TAPE-2017-047 (47 tapes)
   - Location: 12 onsite vault, 35 offsite (Iron Mountain)

   Data classification: Internal
   Destruction method: Degaussing followed by physical shredding

   Authorised by: [Data Owner]
   Destruction vendor: [Certified vendor name]
   Certificate of destruction required: Yes

Coordinate destruction with offsite storage vendor. Request return of media for onsite destruction or vendor destruction with certificate:

   Iron Mountain Work Order
   ------------------------
   Account: ORG-12345
   Request type: Secure destruction
   Media IDs: TAPE-2017-005, TAPE-2017-008, [... 33 additional]

   Service level: Witnessed destruction
   Certificate required: Yes, with serial numbers
   Destruction method: Shredding to DIN 66399 Level H-5

Cryptographic erasure

Cryptographic erasure destroys data by deleting the encryption keys rather than the data itself. When data is encrypted with a key that no longer exists, the ciphertext becomes unrecoverable even though it remains on storage media. This approach proves particularly valuable for SSDs where physical overwriting cannot guarantee data destruction, and for cloud storage where the organisation does not control the underlying media.

Verify target data is encrypted and identify the encryption key:

   # For LUKS-encrypted volumes
   cryptsetup luksDump /dev/sdb1
   # Note the key slots in use

   # For application-level encryption, query key management system
   vault kv get secret/encryption-keys/records-2017
   # Returns key ID and metadata

Confirm all copies of the data use the same key or keys under your control. Data encrypted with the key must not exist in any location where it should be retained. Map key usage:

   Key Usage Audit: KEY-RECORDS-2017
   ----------------------------------
   Primary storage: /data/encrypted/records-2017 [DISPOSAL APPROVED]
   Backup copy 1: Veeam backup repository [DISPOSAL APPROVED]
   Backup copy 2: Azure cold storage [DISPOSAL APPROVED]
   Replica: DR site [DISPOSAL APPROVED]

   All copies approved for disposal: YES
   Safe to destroy key: YES

Destroy the encryption key in the key management system:

   # HashiCorp Vault
   vault kv destroy secret/encryption-keys/records-2017
   vault kv metadata delete secret/encryption-keys/records-2017

   # AWS KMS (schedule deletion with minimum 7-day waiting period)
   aws kms schedule-key-deletion \
     --key-id arn:aws:kms:eu-west-1:123456789:key/abc-123 \
     --pending-window-in-days 7

Document key destruction with timestamp and method. The encrypted data may remain on storage but is now cryptographically inaccessible. Optionally delete the ciphertext to reclaim storage:

   # After key destruction, remove encrypted files
   rm -rf /data/encrypted/records-2017/

Physical media destruction

Physical destruction applies to storage media being decommissioned where cryptographic erasure is not possible or additional assurance is required.

Remove media from active systems and document chain of custody:

   Media Chain of Custody
   ----------------------
   Media ID: SSD-WS-0847
   Serial: SAMSUNG-MZ7LH480-XYZ123
   Capacity: 480GB
   Source system: Workstation WS-0847
   Removed by: [Technician name]
   Removal date: 2025-01-15
   Storage location: Secure disposal cage, Building A

Select destruction method based on media type and data classification:

Media type	Standard data	Confidential data	Method
HDD	Degauss	Degauss + shred	NSA/CSS EPL-listed degausser, DIN 66399 H-5 shredder
SSD	Shred	Shred to dust	DIN 66399 E-5 or higher
Tape	Degauss	Degauss + shred	Degausser rated for media coercivity
Optical	Shred	Shred	DIN 66399 O-5
USB/Flash	Shred	Shred	DIN 66399 E-4 minimum

Execute destruction using certified equipment or contracted service. For onsite destruction:

   Destruction Log
   ---------------
   Date: 2025-01-15
   Equipment: Garner HD-3WXL Degausser, SEM Model 0101 Shredder
   Operator: [Name]
   Witness: [Name]

   Media destroyed:
   - SSD-WS-0847: Shredded, particle size < 2mm
   - HDD-SRV-1204: Degaussed (field strength 20,000 Oe), then shredded
   - TAPE-2017-001: Degaussed, shredded

   Destruction verified by visual inspection: Yes

Obtain certificate of destruction. For vendor destruction, require:
- Vendor name and certification credentials
- Destruction date and location
- Media serial numbers or asset tags
- Destruction method used
- Witness attestation
- Vendor signature and company seal

Third-party data deletion

Data held by SaaS vendors, cloud providers, and partners requires coordination because you cannot directly access or delete from their systems.

Identify third-party systems holding disposal candidate data:

   Third-Party Data Inventory
   --------------------------
   System: Salesforce CRM
   Data type: Contact records pre-2018
   Record count: 3,847
   Vendor contact: support@salesforce.com
   Deletion capability: Self-service via Data Loader

   System: MailChimp
   Data type: Subscriber lists archived 2017
   Record count: 24,000
   Vendor contact: compliance@mailchimp.com
   Deletion capability: Admin portal bulk delete

   System: Former payment processor (terminated 2019)
   Data type: Transaction records 2015-2017
   Record count: Unknown
   Vendor contact: compliance@oldpayments.example
   Deletion capability: Formal request required

For systems with self-service deletion, execute deletion using vendor tools. Export records before deletion for the audit trail:

   # Salesforce: Export contacts before deletion
   sfdx force:data:soql:query \
     -q "SELECT Id, Name, Email, CreatedDate FROM Contact WHERE CreatedDate < 2018-01-01" \
     -r csv > sf_contacts_disposal_20250115.csv

   # Generate deletion batch
   awk -F',' 'NR>1 {print $1}' sf_contacts_disposal_20250115.csv > sf_delete_ids.csv

   # Execute deletion via Data Loader or API
   sfdx force:data:bulk:delete -s Contact -f sf_delete_ids.csv

For systems requiring formal deletion requests, submit written request to the vendor:

   Data Deletion Request
   ---------------------
   To: compliance@vendor.example
   From: dataprotection@organisation.example
   Date: 2025-01-15
   Subject: Data deletion request under service agreement

   Pursuant to Section 8.3 of our service agreement dated 2019-03-15,
   we request deletion of all data associated with our account
   ORG-12345 meeting the following criteria:

   - Record type: Transaction records
   - Date range: 2015-01-01 to 2017-12-31
   - Data categories: Payment details, customer identifiers

   Please confirm:
   1. Estimated completion date
   2. Confirmation that backup copies will also be deleted
   3. Written certification of deletion upon completion

   Contact: [Name, email, phone]

Track vendor response and obtain deletion confirmation:

   Vendor Deletion Tracker
   -----------------------
   Vendor: Former Payment Processor
   Request date: 2025-01-15
   Request ID: REQ-2025-001
   Vendor acknowledgement: 2025-01-17
   Estimated completion: 2025-02-15
   Actual completion: 2025-02-12
   Certificate received: 2025-02-14
   Certificate filed: /compliance/disposal/2025/vendorcert_oldpayments.pdf

Data subject request disposal

Data subject requests under GDPR Article 17 or similar regulations require deletion within specific timeframes. The standard 30-day response period allows limited time for the full disposal process.

Receive and log the erasure request:

   Data Subject Request Log
   ------------------------
   Request ID: DSR-2025-0042
   Received: 2025-01-15 09:30 UTC
   Channel: Email to privacy@organisation.example
   Request type: Erasure (Right to be forgotten)
   Data subject: jane.smith@email.example
   Identifiers provided: Email, phone +44 7700 900123
   Response deadline: 2025-02-14

Search all systems for data subject records using provided identifiers:

   Data Subject Search Results
   ---------------------------
   CRM (Salesforce): 1 contact record, 47 activity records
   Email archive: 156 messages (sender or recipient)
   Marketing platform: 1 subscriber record, 12 campaign interactions
   Finance system: 3 donation records (retention: 7 years - EXEMPT)
   Case management: 1 closed case (retention: 6 years - EXEMPT)
   Backup systems: Present in backups dated 2024-01-15 to present

Determine exemptions. Certain data may be retained despite the erasure request:
- Legal obligation to retain (financial records, tax documents)
- Public interest (archiving, research, statistics)
- Legal claims (litigation hold equivalent)
- Contractual necessity (active service delivery)
Document each exemption with legal basis.
Execute deletion of non-exempt data following storage-specific procedures from earlier sections. For backup data, note that immediate deletion from all backups is often impractical. Document the backup retention approach:

   Backup Handling for DSR-2025-0042
   ----------------------------------
   Approach: Suppress from restore

   Data subject identifiers added to suppression list.
   If backup restore required, suppression list applied
   post-restore to delete data subject records before
   system returns to production.

   Backups naturally expire per retention schedule (90 days).
   Full deletion from all media: 2025-04-15 (estimated)

Respond to data subject within deadline:

   Data Subject Response
   ---------------------
   To: jane.smith@email.example
   Date: 2025-01-25
   Subject: Response to your erasure request (DSR-2025-0042)

   We have processed your request to delete your personal data.

   Deleted:
   - Contact record and interaction history from our CRM
   - Email correspondence from our archive
   - Marketing preferences and campaign data

   Retained (legal basis):
   - Donation records (legal obligation: financial record keeping)
   - Complaint case record (legal obligation: regulatory requirement)

   Backup systems:
   Your data will be naturally removed from backup systems as they
   expire over the next 90 days. Measures prevent restoration of
   your data from backups in the interim.

   Questions: privacy@organisation.example

Verification

Verification confirms disposal completed successfully and creates the audit trail required for compliance.

Execute verification queries immediately after disposal:

-- Database verification: confirm zero records remain
SELECT COUNT(*) FROM target_table
WHERE created_date < '2018-01-15';
-- Expected: 0

-- Verify against pre-disposal snapshot
SELECT COUNT(*) FROM disposal_audit.pre_deletion_20250115 p
WHERE EXISTS (SELECT 1 FROM target_table t WHERE t.id = p.id);
-- Expected: 0

# File system verification
find /data/records -type f -mtime +2555 | wc -l
# Expected: 0

# Verify specific files from manifest no longer exist
head -100 /var/log/disposal/manifest_20250115.txt | \
  cut -d' ' -f4- | xargs -I {} test -e {} && echo "FAIL: {}"
# Expected: no output

# Cloud storage verification
aws s3api list-objects-v2 \
  --bucket organisation-data \
  --prefix records/2017/ \
  --query "length(Contents)"
# Expected: 0 or null

Generate the disposal certificate documenting completion:

Certificate of Data Disposal
============================
Certificate ID: DISP-2025-0015
Date issued: 2025-01-15

Disposal summary
----------------
Dataset: Customer records 2017 and earlier
Systems: PostgreSQL CRM database, S3 archive bucket, Veeam backups
Record count: 47,832 database records, 8,421 S3 objects, 47 backup jobs
Disposal method: Database deletion, S3 object deletion, backup expiry
Verification: All counts confirmed zero post-disposal

Authorisation
-------------
Disposal requested by: [Name, role]
Data owner approval: [Name, date]
Information security review: [Name, date] (for confidential data)

Verification performed by: [Name, role]
Verification date: 2025-01-15
Verification method: SQL count queries, S3 list operations, backup catalogue review

Attestation
-----------
I certify that the data described above has been disposed of in
accordance with organisational policy and applicable regulations.

Signed: _______________________
Name: [Disposal executor name]
Role: [Role]
Date: 2025-01-15

Store the disposal certificate with supporting evidence:

/compliance/disposal/2025/
├── DISP-2025-0015/
│   ├── certificate.pdf
│   ├── authorisation_email.eml
│   ├── pre_disposal_snapshot.sql
│   ├── deletion_log.txt
│   ├── verification_queries.sql
│   └── verification_results.txt

Troubleshooting

Symptom	Cause	Resolution
DELETE statement affects zero rows	WHERE clause does not match any records; data already deleted; incorrect date format	Verify filter criteria against actual data values with SELECT before DELETE; check date format matches column type
DELETE statement affects more rows than expected	WHERE clause too broad; missing filter conditions	ROLLBACK transaction immediately; review and correct WHERE clause; verify against pre-disposal snapshot
Foreign key constraint prevents deletion	Child records reference parent records being deleted	Delete child records first or use CASCADE; verify referential integrity requirements
Permission denied on deletion	User lacks DELETE privilege; row-level security blocks access	Request appropriate permissions from database administrator; verify user context
File deletion permission denied	File owned by different user; file system mounted read-only; file in use	Check ownership with `ls -la`; verify mount status; identify process holding file with `lsof`
S3 deletion returns AccessDenied	IAM policy missing s3:DeleteObject; bucket policy restricts deletion; MFA Delete enabled	Review IAM permissions; check bucket policy; provide MFA token if required
S3 objects remain after deletion	Versioning enabled creating delete markers; replication copying objects back	Delete all versions explicitly; disable replication or delete from all regions
Backup catalogue shows media still contains data	Deletion job incomplete; catalogue not refreshed; offsite media not processed	Re-run deletion job; force catalogue rebuild; follow up with offsite vendor
Vendor does not respond to deletion request	Wrong contact; request not received; vendor disputes obligation	Escalate to account manager; send registered letter; review contract for dispute resolution
Data subject request deadline approaching	Complex data landscape; multiple systems; exemption analysis incomplete	Communicate delay if justified; prioritise high-risk systems; document partial completion
Verification query returns non-zero count	Deletion incomplete; new data arrived during disposal; wrong verification scope	Re-execute deletion; implement isolation during disposal window; align verification criteria with disposal criteria
Cryptographic key deletion blocked	Key has dependent resources; key deletion scheduled but not completed	Remove dependent resources; wait for scheduled deletion; verify key management system status

Recovery from incorrect disposal

If data is disposed incorrectly, recovery options depend on the disposal method and available backups:

Incident: Incorrect Disposal Recovery
-------------------------------------
Discovery: 2025-01-16 14:30
Issue: Disposal DISP-2025-0015 deleted 2018 records that were under
       legal hold LH-2024-017 (hold scope was 2018-2022, not 2017-2022)

Impact assessment:
- Records deleted: 12,847 (2018 calendar year)
- Legal hold scope: Active litigation requiring 2018-2022 data
- Classification: Confidential

Recovery actions:
1. Identified most recent backup containing 2018 data: 2025-01-14 23:00
2. Restored target_table to temporary database from backup
3. Extracted 2018 records meeting legal hold criteria
4. Re-inserted records into production with audit annotation
5. Documented incident and recovery in legal hold file

Records recovered: 12,847
Recovery verified: 2025-01-16 18:45
Legal counsel notified: 2025-01-16 19:00

Preventive measures:
- Enhanced legal hold verification procedure
- Two-person verification for disposal affecting held data