Records retention schedule: the table that makes the policy real

A records retention schedule is the operational half of a retention policy: a table listing every category of record the organisation holds, how long it is kept, why, where it lives, who owns it and when it is next reviewed for disposal. The policy explains the principles; the schedule is what someone opens on the day they are deciding whether to delete a folder.

The difference matters because policies without schedules do nothing. "Personal data is retained no longer than necessary" is a true sentence that has never caused a single file to be deleted.

The columns a schedule needs

• Record category, named as your people would name it — "signed customer contracts", not "commercial documentation".
• Description, one line, so classification is possible without asking.
• Retention period, as a number and a unit.
• The trigger the period runs from: creation, end of contract, end of financial year, end of employment. This is the column most often missing, and without it the period cannot be applied.
• Basis: the statute, regulation, contract or business reason, named specifically enough to check.
• Location or system where the category lives.
• Owner, by role.
• Disposal method: delete, anonymise, securely destroy, or transfer to archive.
• Next review or disposal date, which is what turns the table into a task list.
• A notes column for exceptions, and a flag for anything currently under legal hold.

The trigger column is what makes a schedule usable. "Seven years" means nothing without knowing seven years from what — an employment record kept seven years from creation and one kept seven years from the end of employment can differ by decades. Every row needs an explicit trigger, and rows whose trigger is an event rather than a date need a way to record that the event happened.

Building the schedule

1. Start from where records actually are: the document store, email, the accounting system, the CRM, shared drives, and physical files. Walk the office if you have one.
2. Write the categories before the periods. Getting the list of what you hold right is most of the work.
3. For each category, find the governing obligation and record it with its source. Where several apply, take the longest and note the others.
4. Add the trigger explicitly for every row, without exception.
5. Assign an owner per row, by role, and check each named role agrees they own it.
6. Add the disposal method, and verify it is technically possible in the system named — several will not be, which is useful to discover now.
7. Calculate the next disposal date and sort by it. The schedule is now a work queue rather than a reference document.
8. Run a disposal round annually against that queue, and record what was destroyed and when — the record of destruction is itself evidence you complied.
9. Review the whole schedule yearly, and whenever a system is added or retired.

Why it belongs in a table, not a document

A schedule is asked questions a document cannot answer: what is due for disposal this quarter, what does this role own, which categories live in the system we are decommissioning, what is under hold. Those are filters and sorts, which means the schedule wants to be structured data — a table with typed fields — rather than a list inside a policy document. The policy stays prose; the schedule becomes something you can query.

Ettex Records fits that shape: custom tables with typed fields and no code, so category, period, trigger, basis, location, owner and next disposal date are real fields; relations between tables so owners and systems are references rather than retyped strings; grid, kanban and gallery views with saved filters — due this quarter, by owner, under hold; formulas and rollups across related rows; revision history where every cell change is tracked and restorable, which matters when someone asks who changed a retention period; row comments for queries; and CSV import to bring an existing spreadsheet in as a starting point. The policy behind it lives in Ettex Docs, deletion requests arrive through Ettex Forms, and the disposal rounds go in Ettex Calendar.

Said plainly: Ettex does not enforce the schedule. There is no automatic expiry of documents, no scan that finds records of a given category, no legal-hold mechanism that blocks deletion, and no report of what is overdue beyond the view you build yourself. Records gives you a well-structured, auditable table; the deletion is performed by people. Enforcement across systems is what dedicated records-management software does.

Common problems

• No trigger column, which makes every period ambiguous.
• Categories that nobody can map their actual files to.
• Periods without a stated source, so nobody can check or defend them.
• Systems omitted — usually email, personal drives and paper, which is where a lot of it actually sits.
• Owners assigned to people who left, rather than to roles.
• No next-disposal date, so the schedule is never a task and nothing is ever destroyed.
• Disposal performed but never recorded, losing the evidence that you did it.
• Legal holds tracked in someone's head.

A records retention schedule works when every row has a trigger, an owner and a next disposal date. That turns retention from a statement into a quarterly task — and a record of destruction you can point at.