Nobody deletes anything, because deleting needs a decision and keeping does not. So the old customer database, the leavers' files, the recordings nobody remembers switching on: all still there, all still your responsibility, all still in the first sentence of a letter about a breach. A retention schedule turns keeping into the decision instead, once, in writing. This is the schedule, the arithmetic and the list of what is already overdue.
Start from one of these if it helps. They are ordinary categories with ordinary periods, and every one of them needs changing to match what you actually do.
A schedule says how long. This says what is past it. Add the things you hold and the date the clock started for each, and the page works out what is due and what is overdue.
Keeping is the default, which is why it has to be the decision. Nobody has ever been told off at the time for not deleting something. The cost arrives later, all at once, when somebody asks what you hold or when what you hold gets out. A schedule moves the decision to a calm moment and writes it down, which is the only way it survives contact with a busy week.
"For how long" is meaningless without "counted from what". Six years from when? The end of the contract, the last payment, the end of the employment, the decision not to hire, the date of the recording. Nearly every schedule that fails in practice fails here: the period is stated and the starting point is not, so nobody can work out when anything is due and nothing is ever deleted.
A reason you cannot state is a reason you do not have. "In case we need it" is how everything ends up being kept forever. Writing the actual reason, with the period it implies, is what makes the difference between six years because there is a limitation period and six years because six felt safe.
A legal hold beats the schedule, every time. Where material might be relevant to something in prospect, the duty to preserve overrides the schedule, and deleting on schedule during a dispute is considerably worse than keeping too long. HOLD is the other half of this: the schedule says delete, the hold says not yet, and the hold wins.
It stays on this machine. A retention schedule is a map of everything an organisation holds and where it is kept. That is a useful document to an attacker and an awkward one to have lying on somebody else's server. Export it and keep it where the rest of your governance lives.
Whatever your obligations and your risk actually require, which differs by country, sector and record. The starters here are ordinary categories with ordinary periods and every one of them needs changing. A schedule copied unchanged from a template is a schedule nobody will follow, because it does not describe what you do.
Put a short period and a review date rather than no entry. A category with a date attached gets looked at; a category left out of the schedule never does. The worst answer is the one that is missing.
No, and it is important that it does not. It tells you what is past its date; the deleting is done by whoever holds the system, on purpose, with a record that it happened. A tool that reached into your systems and deleted things on a timer is the last thing anybody should want.
They are the hard part and the part most schedules ignore. Deleting from the live system while the backup keeps a copy for another year means you still hold it. Write down how long backups are kept as its own category, and say in the schedule whether a deletion reaches them.
Once a year is the usual answer, and more often where what you do changes. The date is on the page and on each category so that a review is a thing with a date rather than a thing that never happens.