Make Data Retention Deadlines Enforceable for Compliance Teams
Make Data Retention Deadlines Enforceable for Compliance Teams
A data retention deadline is the date a category of records must be deleted, anonymised or moved to archive. The clock starts at a trigger event (a contract ending, an employee leaving, a tax return being filed) and runs for a period set by law or by your own written policy. To make those deadlines enforceable, you need three things: a schedule that names the trigger and period for each record type, a check for legal holds before anything is destroyed, and a log proving what was deleted and when.
This guide covers the periods that matter most in the US and UK context, how to build the schedule, and where retention programmes usually break.
ExpiryEdge tracks deadlines like these, reminds the owner before each one, and escalates anything that's overdue. You can try it free for 14 days without a credit card.
Common retention periods, and where each number comes from
The right number depends on who sets it. Here are the record types that catch compliance teams out most often, with the rule behind each one.
| Record type | Minimum retention | Where the rule comes from |
|---|---|---|
| Federal income tax records | 3 years in most cases; 6 or 7 years in specific situations | IRS, How long should I keep records? |
| Employment tax records | At least 4 years after the tax was due or paid | IRS, same page |
| HIPAA policies and procedures documentation | 6 years from creation or the date last in effect, whichever is later | 45 CFR 164.316(b)(2) |
| Employee exposure records | At least 30 years | OSHA, 29 CFR 1910.1020(d) |
| Employee medical records | Length of employment plus 30 years | OSHA, 29 CFR 1910.1020(d) |
| Signed contracts | Usually contract end plus your state limitation period | State law; varies by state |
The IRS figures are worth reading in full, because they don't say what most people think. The IRS page sets three years as the default. Six years applies if you left out income worth more than 25% of the gross income on your return, seven years if you claimed a loss from worthless securities or a bad debt deduction, and there's no limit at all if you never filed or filed a fraudulent return.
HIPAA's six years applies to your policies, procedures and required documentation, counted from creation or the date it was last in effect. It isn't a rule about patient charts. Medical record retention for providers comes from state law, and it differs from state to state.
OSHA's numbers are the long ones. Section 1910.1020 requires exposure records to be kept for at least 30 years and employee medical records for the length of employment plus 30 years. A metal shop that measured solvent exposure in 2026 still owes that record to an inspector in 2056.
Security logs don't have one federal number. Your SOC 2 auditor will test against whatever period your own policy promises, and some frameworks and contracts set a fixed minimum. Pick a period you can defend, write it down, and make sure your logging system actually keeps that much history.
Every one of these deadlines pauses once a legal hold applies. If a record is relevant to a lawsuit, a subpoena or an investigation you can reasonably expect, it stays put regardless of what the schedule says.
Build the schedule one record type at a time
A retention schedule turns "how long do we keep this?" from a guess into a policy you can defend. Auditors look for the same handful of fields on every entry, whatever your industry. A missing field is usually where a routine review turns into a finding.
Each line of the schedule needs:
- The record type, described the way staff would recognise it: supplier invoice, personnel file, firewall log, signed customer agreement.
- The trigger event that starts the clock, such as contract termination, employee separation, transaction date or ticket closure.
- The retention period counted from that trigger, plus the law or business reason that justifies it.
- The disposal method (secure deletion, shredding, or transfer to permanent archive) and the role that owns the entry.
- A review date for the entry itself.
When no law sets a period, choose the shortest one that still covers a real business need, and record why. A vendor contract might be destroyed seven years after it ends. A rejected job applicant's CV might go after a year. Some records never get a destruction date at all: incorporation papers, cap tables and patent filings normally move to a permanent archive.
Get the trigger right before you worry about the period. If your system stores "date created" when the schedule counts from "date employment ended", every deletion date downstream is wrong, and nobody notices until an audit.
A legal hold stops the clock, so check for one before anything is deleted
A legal hold suspends normal retention the moment litigation or an investigation becomes reasonably foreseeable. In US federal courts, Rule 37(e) lets a judge act when electronically stored information that should have been preserved is lost because a party didn't take reasonable steps. Where the court finds intent to deprive the other side, it can tell the jury to presume the lost material was unfavourable, or even end the case.
A memo from the legal team isn't enough. Running a hold properly means:
- Tagging every affected record in the system that stores it, so automated deletion skips it.
- Naming a hold owner who tracks the scope and the eventual release date.
- Keeping a record of when the hold started, who issued it and what it covers.
- Writing to each custodian directly, by name, and keeping proof they received it.
Holds are where auditors and opposing counsel look first. A schedule that says "seven years" but shows no hold ever being applied looks incomplete, even if every deletion was technically correct.
Automate the deletion, but put a human check in front of it
A spreadsheet of what to delete and when works for a few dozen records. It stops working once you have thousands spread across several systems. Then deadlines slip both ways: data kept too long sits there as breach exposure, and data deleted too early leaves a gap in your audit evidence.
The technical side has four parts. Attach retention metadata (record type, trigger date, owner) when the record is created. Use lifecycle rules in your storage and backup tools to delete or archive on schedule. Keep a deletion log that can't be edited after the fact. And restrict who can change a retention entry.
For physical media and decommissioned hardware, get a destruction certificate showing the date, method and who did it. That's the evidence an auditor asks for when they want proof a deletion really happened.
The risky bit is automation without a hold check. A lifecycle rule will delete on time whether or not legal has frozen the data. Put a sign off step before any deletion of records that could be relevant to a dispute, and send the reminder early enough for someone to act. ExpiryEdge can sit on top of your storage rules here: it reminds the owner ahead of each disposal date, escalates if nobody signs off, and keeps a record of who approved what.
Review high-risk categories every quarter, not just once a year
Schedules go stale quietly. A cadence that holds up looks like this:
- Now: list your ten biggest record categories, give each an owner, and write down the trigger that starts each clock.
- Quarterly: spot check the risky ones, especially security logs, health data and biometric data, where state laws change faster than policies do.
- Annually: run a full review with compliance, legal and IT signing off that every entry still matches the law.
- Straight away after a breach, a new privacy law taking effect, or an audit finding.
The quarterly check is the one teams skip. An annual review catches structural problems, but a biometric rule that changed six months ago won't wait for it.
Keeping too much is as risky as deleting too early
Most organisations prepare for only one side of the problem. The obvious risk is deleting something a regulator or court later asks for. If records disappear before the required period ends, you're explaining a gap, and "we didn't have a written schedule" won't help.
The less obvious risk is keeping data you had no reason to keep. Old records are discoverable in litigation they would otherwise never have touched, and they add to the damage if you're breached. Privacy law treats over-retention as a breach in itself: under [GDPR Article 5(1)(e)]({GDPR}), personal data can be kept in identifiable form for no longer than is necessary for its purpose.
So the target is the shortest period that meets every legal and business obligation, written down with the reasoning attached. Keeping everything forever fails an audit. So does deleting aggressively with no paper trail.
Tell each team only the rules that apply to them
A retention schedule that lives in a compliance binder protects nobody, because employees are the ones who create, store and sometimes delete the records.
Break the policy down by role. HR needs the personnel file rules. Finance needs the tax and invoice periods. IT needs the lifecycle settings. A one page summary tied to someone's actual job gets used. An all-hands email about "our data retention policy" gets skimmed.
Cover it at onboarding and again whenever the schedule changes materially. Put the trigger and disposal method inside the tools people already use, not in a policy portal nobody opens. When a hold starts, write to each custodian by name and record that you did.
When jurisdictions disagree, keep for the longest legitimate period and say why
If you operate in more than one place, one record can have several clocks running at once. A customer file touching California, the EU and US federal tax rules can be subject to three different minimums and maximums.
The working rule: keep it for the longest mandatory period that genuinely applies, and document which law requires it. That documentation is your answer if the shorter-period jurisdiction asks why you still hold the data.
Watch for ceilings as well as floors. GDPR's storage limitation can clash with a tax rule that needs the same data for years. The usual fix is to trim the record: keep only the fields the tax obligation needs and delete the rest, rather than picking one law over the other.
US state laws add their own documentation rules. California's regulations require a business's notice at collection to state how long it intends to keep each category of personal information, or the criteria it uses to decide. Illinois's Biometric Information Privacy Act requires a public written retention schedule for biometric data, with destruction once the original purpose is met or within three years of the person's last interaction, whichever comes first.
Your backups are part of the retention schedule too
Retention and backup are different jobs. Retention decides how long a record may exist in usable form. Backup protects against losing data. Teams that treat them as the same thing end up with a gap.
Here's how it happens. A record is deleted from the live system on schedule, but a copy sits in a backup snapshot from six months ago. If a regulator or a plaintiff's lawyer finds it, the fact that production was cleaned up doesn't help you.
Extend the schedule to backups and archives explicitly. Backup rotation should be no longer than the retention period it serves, and any backup kept beyond that needs its own written reason.
Less data means less to protect and less to disclose
Every record you hold past its purpose adds to your breach exposure and gives you nothing back. A smaller, well-defined dataset is quicker to secure and encrypt, and cheaper to deal with if it leaks, because breach notification work grows with the number of people and records affected.
Privacy rules are moving the same way. More laws now expect you to say, in plain terms, how long you keep personal data and why. "As long as we need it" isn't an answer a regulator or a customer will accept.
Where retention programmes usually fail
Most organisations have a retention policy. The failure is that the systems holding the data have no way to enforce it, so deletion becomes a manual job someone forgets.
The next failure is the trigger date, covered above. The third is automation that ignores holds and deletes on time regardless. That's arguably worse than a slow manual process, which at least gives someone a chance to notice.
All three have the same fix: tag records when they're created, check hold status before any automated deletion, and log every disposal so you have evidence rather than a policy claim.
Put the schedule on a system that checks it for you
A written schedule says what should happen. Making it happen on time, across hundreds of record types and several departments, is the part most policies quietly fail at.
ExpiryEdge handles that reminder and escalation layer. You load each retention deadline with its owner, it reminds them by email, SMS, WhatsApp, Slack or Teams before the date, escalates to a manager if nothing happens, and keeps an exportable audit trail of who did what. It doesn't decide how long you must keep a record (that's for your legal team) and it doesn't delete files itself. It makes sure the decisions you've documented actually get acted on.
A sensible first step this week: pick your three riskiest record types, write down the trigger and period for each, and set a reminder 30 days before the next disposal date. If you'd like to run that in ExpiryEdge, the 14-day trial needs no credit card.
Where to check the rules for your organisation
Start with the IRS recordkeeping page for federal tax records, your state archives for public-sector schedules, and the text of any privacy law that applies to you, such as California's regulations or Illinois's BIPA. Have counsel confirm the final schedule before you adopt it.
Sources
- IRS: How long should I keep records?
- eCFR: 45 CFR 164.316, HIPAA documentation requirements
- OSHA: 29 CFR 1910.1020, access to employee exposure and medical records
- Illinois General Assembly: 740 ILCS 14/15, BIPA retention and destruction
- Cornell LII: Cal. Code Regs. tit. 11, 7012, notice at collection
- GDPR Article 5: principles relating to processing of personal data
- Cornell LII: Federal Rule of Civil Procedure 37
FAQ
What Is the 7 Year Retention Policy?
It's a common internal rule of thumb, not a single law. The IRS says most tax records need keeping for three years, six if you underreported income by more than 25%, and seven only if you claimed a loss from worthless securities or a bad debt deduction. Many companies pick seven years for all financial records because it covers every one of those cases.
What Records Need to Be Kept for 7 Years?
Under IRS guidance, the records behind a claimed loss from worthless securities or a bad debt deduction need seven years. Beyond that, seven years is usually a company choice for invoices, ledgers and signed contracts, often counted from the contract's end date rather than its signing. Check your state's limitation period for written contracts before you settle on a number.
What Is the Standard Retention Period for Data?
There isn't one. Each record type has its own clock: three years for most tax records, six years for HIPAA policy documentation, 30 years for OSHA exposure records. Where no law sets a minimum, GDPR and similar privacy laws push the other way, so you keep personal data only as long as its purpose needs and write down why.
What Records Should Be Kept for 3 Years?
Most federal income tax records, according to the IRS, as long as you reported all your income and didn't claim a bad debt or worthless securities loss. Grant-funded research records often carry a three year minimum too, but the sponsor's terms decide, so read the award letter rather than assuming.
Recommended
- Contract Expiry and Renewal Management for Legal Ops
- Deadline Escalation Workflow Guide for Ops and Compliance
- Inspection Deadline Automation: A 2026 Ops Guide
- Fixed Deadline Workflow Best Practices for Ops Teams
Frequently asked questions
Under IRS guidance, the records behind a claimed loss from worthless securities or a bad debt deduction need seven years. Beyond that, seven years is usually a company choice for invoices, ledgers and signed contracts, often counted from the contract's end date rather than its signing. Check your state's limitation period for written contracts before you settle on a number.
There isn't one. Each record type has its own clock: three years for most tax records, six years for HIPAA policy documentation, 30 years for OSHA exposure records. Where no law sets a minimum, GDPR and similar privacy laws push the other way, so you keep personal data only as long as its purpose needs and write down why.
Most federal income tax records, according to the IRS, as long as you reported all your income and didn't claim a bad debt or worthless securities loss. Grant-funded research records often carry a three year minimum too, but the sponsor's terms decide, so read the award letter rather than assuming.
Not medical, clinical, or HIPAA compliance advice
This article is for general informational purposes and does not constitute clinical or HIPAA compliance advice. ExpiryEdge is not currently a HIPAA Business Associate. Healthcare organisations handling Protected Health Information should review the specifics of their compliance programme with a qualified privacy officer or HIPAA consultant.
