Data Retention & Disposal Policy

1. Purpose

Specifies how long Rex Black keeps every class of data and how it is destroyed at end-of-life.

2. Policy statements

1. Every data class listed below has an owner, a retention period, and a disposal method. Nightly automation enforces the schedule where technically possible.
2. Data beyond its retention period is disposed of by the next scheduled purge cycle unless a legal hold is in place.
3. A legal hold suspends disposal for the subject data until the Privacy Officer lifts the hold in writing.
4. Disposal of Confidential or Restricted data is recorded in the audit log with the data class, volume, and method.

3. Retention schedule

Data class	Retention (hot)	Archive	Total	Disposal method
Executed SOWs and signed contracts	7 years	Glacier Deep Archive (Object Lock)	7 years	Immutable; automatic after window
E-signature envelopes and audit events	7 years	same	7 years	Immutable
Billing records, invoices, Stripe events	7 years	S3 + Glacier	7 years	Crypto-erase after window
Application audit log	1 year (hot)	S3 (IA → Glacier)	6 years	Crypto-erase
Access review records	3 years	S3	3 years	Crypto-erase
Client project data (in-flight)	Life of engagement	,	+ 90 days grace	Soft delete, then purge at +90 days
Client project data (completed)	7 years	S3 + Glacier	7 years	Crypto-erase
Prospect / CRM records	2 years idle	,	2 years	Crypto-erase
Chat / support transcripts	90 days	S3	1 year	Crypto-erase
Email (Google Workspace)	3 years	Vault	3 years	Workspace retention
Authentication sessions	30 days	,	30 days	Soft delete
MFA secrets / API tokens	Until rotation	(	)	KMS schedule delete
Backups (DynamoDB PITR)	35 days	,	35 days	Automatic
Security event / incident records	7 years	S3	7 years	Crypto-erase
Security training records	3 years	S3	3 years	Crypto-erase
HR employee records (post-termination)	7 years	S3	7 years	Crypto-erase
Vendor / subprocessor contracts	Life + 7 years	S3	,	Crypto-erase

4. Disposal methods

• Soft delete: DynamoDB attribute deletedAt set; hidden from application; purged on schedule.
• Crypto-erase: the KMS data key wrapping the payload is scheduled for deletion; ciphertext becomes unrecoverable.
• Object Lock expiration: applies only to WORM buckets; the configured retention window elapses and lifecycle rules purge.
• Physical wipe: end-of-life devices are wiped per NIST 800-88.

5. Legal holds

1. A legal hold is initiated by the CEO, the Privacy Officer, or legal counsel, and is recorded with the scope, reason, and expected duration.
2. A legal hold pauses all disposal affecting its scope, including Object Lock expiration where extension is possible.
3. A hold is not released without written authorization.

6. Roles & responsibilities

Role	Responsibility
Privacy Officer	Owns the schedule; approves exceptions; holds.
Engineering	Implements and runs the nightly purge jobs.
All personnel	Do not store data past its purpose.

7. Enforcement & exceptions

Data found outside its retention window is reported as an incident. Exceptions require Privacy Officer approval.

8. References

• 009-data-classification-and-handling-policy.md
• 028-data-subject-rights-policy.md
• 005-backup-and-recovery-policy.md

9. Revision history

Version	Date	Author	Approver	Change
1.0	2026-04-17	P.O.	CEO	Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.

Approved by	Myles Bai
Title	Chief Executive Officer, Rex Black LLC
Email	myles@rexblack.com
Approval date	2026-04-17
Effective date	2026-04-17
Next review due	2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.