Document retention and access rules should connect a content class to its business owner, access purpose, retention trigger, period, hold behavior, disposition decision and evidence. “Keep seven years” is incomplete without knowing which record, when the clock starts and who may suspend disposal.
Begin from approved policy and specialist advice. This checklist helps translate policy into testable system and operating controls; it is not a substitute for jurisdiction-specific legal review.
Identify content classes
Group documents by business purpose and obligation, not folder alone. Examples can include contracts, invoices, employee records, policies, project deliverables and support evidence. Name the accountable owner.
A class should be understandable enough for consistent assignment and narrow enough for a meaningful rule.
Write the rule card
| Field | Required decision |
|---|---|
| Class/scope | which documents and versions qualify |
| Trigger | event that starts retention |
| Period | minimum/maximum or reviewed duration |
| Access | roles, purpose and restrictions |
| Hold | who applies/releases and affected content |
| Disposition | automatic proposal, review and evidence |
Define the trigger
Use contract expiry, employee exit, case closure, supersession, financial period or another observable event. Decide how the system receives and validates it.
Creation date is often a poor proxy. Missing triggers can retain forever or delete too early, so monitor them as exceptions.
Control classification
Use source system, content type, metadata or workflow to assign rules. Give users safe defaults and a correction route. Record reclassification and its effect on retention.
Test mixed-content containers and copies. One folder may contain several classes with different obligations.
Apply least-purpose access
Define who needs to create, read, change, approve, administer and export. Use groups and attributes where maintainable. Review broad links, inherited access and privileged support.
Test transfer, leave, termination and external collaboration. Retention does not justify indefinite access.
Protect versions and records
Decide which versions form the record and when alteration stops. Drafts may have different retention from approved outputs. Preserve metadata and evidence needed to understand the decision.
Do not assume version history equals a declared record or that every autosave must be retained.
Design legal or investigation hold
Define authorised requester, scope, search, notification, preservation, access, monitoring and release. Test overlapping holds and content added after the hold begins.
Disposal must fail closed when an applicable hold exists. Keep hold detail appropriately restricted.
Review disposition
Decide which classes can be disposed automatically after tested rules and which require owner review. Present content, rule, trigger, hold status and decision evidence.
Avoid review queues so large that owners approve blindly. Improve classification and risk segmentation.
Retain disposal evidence
Record class, volume, rule version, approval, date, method, failures and exceptions without retaining the disposed content unnecessarily. Reconcile completion across replicas and integrations.
Define what “deleted” means for active storage, backup, archive and supplier systems and document limitations.
Test the rules
Use a current document, superseded policy, expired contract, held record, misclassified file, changed owner and failed trigger. Verify access, clock, hold and disposition outcome.
Repeat after system or policy change. A configuration that once passed can drift.
Map copies and downstream systems
Identify exports, synced devices, email attachments, backups, data warehouses and business-system copies. Decide which retention rule and deletion capability applies to each. The primary repository cannot guarantee disposal elsewhere.
Reduce unnecessary replication and document technical limits. Use contract and supplier evidence for hosted services.
Control exceptions
Every exception needs content scope, reason, approving authority, compensating control, expiry and review. Avoid permanent “do not delete” labels with no owner. Monitor expired exceptions.
When a rule cannot be technically enforced, define a manual control and evidence. Keep the gap visible until fixed or accepted.
Review access periodically
Choose review frequency by sensitivity and change rate. Give owners meaningful groups, recent use and unusual access, not a raw list of thousands of names. Record retain, remove and investigate decisions.
Trigger review after reorganisation, supplier exit, project close or incident. Automate obvious removals where authority is reliable.
Prepare supplier exit
Verify export of content, metadata, versions, audit, holds and retention state; secure deletion process; timelines; formats; and responsibilities. Test a representative export before contract end.
A retention obligation can outlast a software relationship. Plan the repository and ownership that will carry it.
Use a governance pack
Keep approved policy source, class dictionary, rule cards, access roles, hold procedure, exception register, test evidence, disposition logs and owner review. Version changes and map affected systems.
This pack lets an auditor or future administrator explain why content exists, who can use it and how its lifecycle ends.
Operate governance
Maintain class owners, policy source, system implementation, exceptions, last review and next trigger. Monitor unclassified content, missing triggers, expired holds, overdue disposition and access anomalies.
The checklist succeeds when each retained document has a reason, each user has a purpose, and eventual disposition is controlled and explainable.
Report unresolved rule gaps and manual controls to the accountable governance forum. A policy is not implemented merely because a schedule exists; the organisation must show that triggers, holds, access reviews and dispositions actually operate.