A records retention schedule is the approved table that tells everyone in an organisation how long each kind of record is kept and what happens to it when that time is up. ISO 15489-1:2016 calls this instrument a disposition authority and covers it in clause 8.5, one of the four records controls in clause 8. The name differs but the job is the same: turn appraisal decisions into rules that people and systems can apply without guessing.
Any retention period below illustrates format only; it is not legal advice.
What this guide covers
- What a records retention schedule is in ISO 15489-1 terms
- Build the records retention schedule on functions, not departments
- The five fields every class in a records retention schedule needs
- Where records retention schedule periods come from
- Trigger events: when the records retention schedule clock starts
- Disposition actions in a records retention schedule
- Big-bucket or granular?
- Approving and reviewing the records retention schedule
- Applying the records retention schedule in systems
- Why a copied records retention schedule is dangerous
- Frequently asked questions

What a records retention schedule is in ISO 15489-1 terms
ISO 15489-1 is guidance: it recommends rather than requires, and nobody can be certified against it. In paraphrase, clause 8.5 recommends that:
- the organisation knows, from law, regulation or its own policy, who is responsible for developing the authority;
- the authority is built from appraisal (clause 7) and put to work through system design and the records processes in clause 9;
- records are grouped into classes that share a period and an action, each tied to the business context it documents;
- the authority is formally approved, dated, put into use and revisited as requirements change, with sign-off from an outside body where a jurisdiction demands it.
In practice a records retention schedule is a table. Each row is a retention class, and each column holds one piece of information about that class. Disposition itself, destroying or handing over records once their period ends, sits in clause 9.9 and runs under the schedule, never around it.
Build the records retention schedule on functions, not departments
Clause 8.5 allows classes to come out of a functional or sequential analysis. The reason to work this way is durability. Departments merge, split and rename themselves; the work they do changes far more slowly. A class for “paying suppliers” survives a reorganisation that would orphan a class named after the accounts payable team.
Start from your business classification scheme. Each activity maps to one retention class, and several activities can share a class where their records need identical treatment. Once every classification class maps to a retention class, classifying a record tells the system how long to keep it.
The five fields every class in a records retention schedule needs
Clause 8.5 lists what a disposition class should contain. As column headings:
- Identifier. A stable code, such as RC-FIN-012, never reused, so an old destruction certificate still points to exactly one rule.
- Description. What the class covers, in terms of the function or activity, with examples staff will recognise.
- Disposition action. What happens when the period runs out.
- Retention period. How long the records are kept, counted from the trigger.
- Trigger event. The event that starts the count.
Add a sixth column, the justification: the requirement and mandate references behind the period. ISO 15489-1 does not name it as a field, but without it nobody can defend a period to an auditor or update it when a mandate changes.
Where records retention schedule periods come from
A retention period is a decision, and clause 8.5 says it should rest on appraisal. Clause 7.4 names three sources of records requirements: business needs, legal and regulatory demands, and the expectations of the community or wider society. For each class, collect requirements from all three, for every jurisdiction you operate in, then settle the period:
- List each mandate that sets a minimum keeping time, and any that sets a maximum. Data protection rules can cap how long personal data may be held.
- Add the business need, such as the window in which a dispute could realistically arise, and write down the reasoning.
- Set the period at the longest minimum unless a maximum applies. Where the two collide, refer it to legal counsel and record the outcome.
Our guide to records appraisal covers the analysis that feeds this step. Where appraisal concludes a requirement will not be met, clause 7.5 expects a senior manager to authorise that decision.
Trigger events: when the records retention schedule clock starts
Seven years from what? The trigger answers that, and choosing it well separates a records retention schedule that systems can run automatically from one that needs a person to rule on every case. Good triggers are events your systems already capture, and they happen once, at a moment you can pin down. “When no longer needed” fails both tests.
The periods below are illustrative examples of format, not recommendations; confirm every period against your own mandates.
| Trigger type | Example trigger | Period (illustrative only) | Can a system detect it? |
|---|---|---|---|
| Calendar | End of the financial year in which an invoice is paid | For example, 7 years | Yes, from the payment date |
| Closure | Complaint case closed | For example, 3 years | Yes, if closure is recorded |
| Relationship end | Employee leaves; contract expires | For example, 6 years | Yes, from the HR or contract system |
| Asset life | Asset decommissioned | For example, 2 years | Only if the asset register is linked |
| Supersession | Policy replaced by a new version | For example, 10 years | Yes, with version control |
| Creation | Date a routine record was made | For example, 1 year | Yes, but check it fits the requirement |
Where a trigger lives in a different system from the records, such as leaving dates held in the HR system, plan the integration or the manual step before you approve the class.
Disposition actions in a records retention schedule
Clause 9.9 recognises three outcomes: destruction; passing control to another organisation that has taken over the activity, for example after a restructure; and transfer to an archive for permanent keeping. A schedule can also use “review” for classes whose long-term value is uncertain, provided someone owns the review date.
For destruction, clause 9.9 sets principles to build in. Paraphrased: nothing is destroyed without authorisation; nothing tied to litigation or an investigation is destroyed while that matter is live or expected; destruction is complete and respects security limits; and it is recorded. Each action should also be checked shortly before it happens, in case requirements have changed.
Two traps follow. “Permanent” should be a deliberate appraisal outcome, not a default for classes nobody wanted to think about. And a passed date never makes destruction automatic: a legal hold overrides the schedule for records relevant to a dispute, investigation or regulator’s inquiry.
Big-bucket or granular?
Decide how fine-grained the records retention schedule will be. A big-bucket records retention schedule has a few broad classes per function: easy for staff to apply and cheap to maintain, but the longest requirement in each bucket applies to everything in it, so some records are kept longer than needed. A granular schedule gives each record type its own period, at the cost of more rows to configure, test and revisit. A practical pattern is broad classes by default, split only where a mandate or a privacy limit forces different treatment.
Approving and reviewing the records retention schedule
An unapproved schedule is an opinion. A workable route: the records manager drafts; business owners confirm the need behind each class; legal counsel confirms periods and triggers per jurisdiction; the data protection officer checks periods for personal data; a senior officer approves and dates the version. Some public bodies also need approval from an external archives authority, which clause 8.5 anticipates.
As one example of a published schedule for a single sector, the US National Archives issues General Records Schedules that give disposition authority for records common to US federal agencies. They bind those agencies only.
Review the records retention schedule on a fixed cycle, and out of cycle whenever a mandate changes, a function starts or stops, or monitoring shows a class cannot be applied. Keep every superseded version: last year’s destruction was authorised by last year’s version.
Applying the records retention schedule in systems
Clause 8.5 expects the rules to take effect through system design, and clause 9.9 asks for systems that can carry out disposition. That means configuring each approved class in every system that holds its records, testing that calculated disposal dates are right, stopping ordinary users from deleting records, letting a hold flag block disposition, and logging every action. Where a system cannot do this, record the gap and run disposition there manually.
Migrations need their own check. Map each record’s class into the new system before cut-over, or records arrive with no rule and quietly become permanent.
Why a copied records retention schedule is dangerous
A copied records retention schedule carries someone else’s jurisdictions, functions and risk decisions. Three things go wrong:
- The periods are wrong for you. Too short destroys evidence you still need; too long may breach a data protection limit.
- The triggers do not match your systems. A trigger nobody records cannot start a clock.
- There is no justification trail. “Another organisation used it” does not answer an auditor.
Use a published schedule as a format reference and a prompt for missed record types, never as a source of periods.
Frequently asked questions
Is a records retention schedule the same as a disposition authority?
In substance, yes. ISO 15489-1 uses “disposition authority” for the approved instrument setting periods and actions for classes of records; “retention schedule” is the everyday name.
How often should a records retention schedule be reviewed?
ISO 15489-1 sets no interval, only that review is regular. Pick a cycle, for example every two years, plus out-of-cycle triggers such as a new mandate.
Who approves a retention schedule?
A senior officer, after legal counsel and business owners have confirmed it. Where a public archives authority must approve, that comes first.
Can one schedule cover several countries?
One structure can. Periods need checking per jurisdiction; where they differ, the class takes the longest minimum or splits by country.
Our ISO 15489 Toolkit provides 92 editable templates aligned with ISO 15489-1. For this topic it includes the Records Retention and Disposition Schedule, a workbook seeded with 44 function-based classes whose periods are illustrative and flagged for you to confirm, plus the Disposition Authority Development and Approval Procedure, the Disposition Authority Review and Implementation Log, the Records Mandates Register, the Records Requirements Register, the Disposition and Destruction Procedure and the Disposition Register. It is $99.