Data Retention Policy & Schedule

What's in the pair

• The policy (DOCX) — retention principles (storage limitation, schedule-as-source-of-truth, disposal-by-default), legal hold procedure with FRCP teeth, four disposal standards mapped to classification tiers, roles, exceptions, and an approval page.
• The schedule (XLSX) — 23 record categories banded across Financial, HR & Payroll, Customer & CRM, Marketing, Legal, IT & Security, and Healthcare, each with retention period, trigger event, regulatory basis (SOX, IRS, FLSA, ERISA, HIPAA, GDPR, CCPA, PCI), disposal method, and owner. Cover sheet with usage rules; raw CSV if you'd rather import it.

The two rules that make schedules work

Periods run from the trigger event, not creation. "7 years" for personnel files means seven years from termination, not from hire. Every row names its trigger.

Brackets are choices, not laws. Values like [26] months for analytics or [90] days for backups are defensible defaults you must consciously adopt — while the SOX/IRS/HIPAA rows are regulatory floors to validate with counsel for your jurisdictions. This template is a practitioner starting point, not legal advice.

How to adapt it (about 4 hours)

1. Set every bracketed period in the schedule and record why.
2. Validate regulatory rows with legal counsel — especially if you operate in multiple jurisdictions or a regulated industry.
3. Name an owner per row. Unowned schedule rows never get disposed.
4. Wire the automatable categories (logs, analytics, backups, email) to system-enforced expiry, then document the mapping in the policy.
5. Approve both artifacts together — the policy references the schedule as its operative appendix.

What this doesn't replace

Retention assumes you know how sensitive each record is — that's the classification policy — and disposal standards reference those tiers. For the reasoning behind retention design, defensible deletion, and legal holds, read the companion article: Data Retention Policy: How to Build One That Holds Up.