A data retention policy sets how long you keep each category of data, why, and what happens to it at the end of that period. Keep what laws, regulations, contracts and genuine business needs require, and delete everything else on a schedule you can prove you follow. Legal drivers pull in two directions: some set minimum periods, while others, such as the GDPR's storage limitation principle, forbid keeping personal data longer than necessary.
Why does data retention matter for security?
Every record you keep has to be protected, can be exposed and has to be searched when someone makes an access request or a lawyer asks for documents. Data kept "just in case" carries all of that cost and usually none of the benefit. Less data also means a smaller incident: an exposed file share holding three years of customer records is a very different problem from one holding ten.
What legal and regulatory requirements drive data retention?
Most organizations face several retention requirements at once. Three come up often.
GDPR's storage limitation principle
Article 5(1)(e) of the GDPR requires personal data to be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Longer storage is allowed only for archiving in the public interest, scientific or historical research, or statistical purposes, with appropriate safeguards.
The GDPR doesn't set specific periods. You decide them and must be able to justify them. Two other provisions make those decisions visible: Article 13(2)(a) requires privacy notices to state the retention period or the criteria used to set it, and Article 30 records of processing should include the envisaged time limits for erasure where possible.
PCI DSS Requirement 3.2.1
PCI DSS v4.0.1, published in June 2024, addresses retention in Requirement 3.2.1. It requires account data storage to be kept to a minimum through retention and disposal policies, procedures and processes that include:
- Coverage for all locations of stored account data
- Coverage for any sensitive authentication data stored prior to completion of authorization
- Limiting storage amount and retention time to what legal, regulatory or business requirements need
- Specific retention periods for stored account data, with a documented business justification
- Processes for securely deleting or rendering account data unrecoverable when no longer needed
- A process for verifying, at least once every three months, that stored account data beyond its retention period has been securely deleted or rendered unrecoverable
The bullet covering sensitive authentication data stored before authorization was a best practice until 31 March 2025 and is now required. Separately, Requirement 3.3.1 prohibits retaining sensitive authentication data after authorization, even if it's encrypted.
HIPAA's six-year documentation rule
Under 45 CFR 164.316(b)(2)(i), covered entities and business associates must retain the documentation required by the Security Rule "for 6 years from the date of its creation or the date when it last was in effect, whichever is later." The Privacy Rule has a parallel requirement at 164.530(j).
The rule applies to policies, procedures and records of required actions and assessments, such as risk analyses. It does not set a retention period for medical records. HHS states plainly that the Privacy Rule does not include medical record retention requirements and that state laws generally govern how long medical records are kept.
Other common drivers
Tax and accounting rules, employment law, industry regulation and customer contracts all set their own periods, which vary by jurisdiction. Get legal advice for the categories that matter most, and record the source of each period in the schedule.
How do you build a data retention schedule?
The retention schedule is the core of the policy: each data category with its retention period, the event that starts the clock, the reason and what happens at the end.
Work through it in this order:
- Inventory data by category, not by system. "Customer contracts" and "job applications" are categories. A CRM or file share is where they live.
- Assign an owner to each category. Usually the business function that creates or relies on the data.
- Identify the drivers. Note any legal minimum, any legal maximum and the genuine business need.
- Set the period and its trigger. "Six years" means nothing without a start point, such as the end of the contract or the date a record was superseded.
- Choose the disposition. Delete, anonymize or move to a restricted archive.
- Map each category to the systems that hold it. This is where deletion will actually happen.
- Approve and publish the schedule, then review it at least annually.
Here's what a few entries might look like:
| Record category | Trigger | Retention | Driver | Disposition |
|---|---|---|---|---|
| HIPAA security policies and risk analyses | Date last in effect | 6 years | 45 CFR 164.316 | Secure deletion |
| Stored cardholder data | Transaction date | Per documented business justification | PCI DSS 3.2.1 | Secure deletion, verified quarterly |
| Security audit logs (card data environment) | Log creation | At least 12 months, 3 months immediately available | PCI DSS 10.5.1 | Automated deletion |
| Unsuccessful job applications | Hiring decision | Set by local employment law and policy | GDPR storage limitation | Deletion |
Resist creating hundreds of categories. A manageable number of broad categories is easier to follow and far easier to automate.
How should legal holds work?
A legal hold suspends normal deletion for data that may be relevant to litigation, an investigation or a regulatory inquiry. Once a hold applies, it overrides the retention schedule for the data it covers.
A workable process includes:
- A clear trigger, usually when legal counsel decides litigation or an investigation is reasonably anticipated
- A written hold notice defining the custodians, systems, data types and date ranges in scope
- Technical steps to suspend automated deletion for exactly that scope
- Acknowledgment from each custodian, with periodic reminders
- A formal release when the matter ends, after which the normal schedule resumes
The technical piece is where things go wrong. If deletion automation can't exclude data under hold, you're left choosing between destroying potential evidence and switching off deletion everywhere. Build hold exceptions in from the start.
Which data deletion methods should you use?
The right method depends on where the data lives and how sensitive it is.
In applications and databases, confirm that "delete" really removes the record. Many systems soft-delete by default, flagging a record while keeping it. Configure a hard purge after any recovery window you need.
For storage media, NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, published in September 2025, replaced Rev. 1 as the main reference. It keeps the three familiar methods: Clear, which uses logical techniques on user-addressable storage; Purge, which makes recovery infeasible with state-of-the-art laboratory techniques; and Destroy, which also leaves the media unusable. Cryptographic erase, which destroys the encryption keys rather than overwriting the data, is covered as a purge technique and is often the most practical option for encrypted storage.
Anonymization is a valid alternative to deletion, but only if individuals genuinely can't be re-identified. Pseudonymized data remains personal data for an organization that can re-identify it, so storage limitation still applies.
What about backups and archives?
Backups are where retention schedules quietly fail. If you delete a record from production but your backups are kept for years, your real retention period is the backup retention period.
Align backup retention with the schedule. Short-term operational backups for recovery, plus a deliberate archive for records that genuinely need long retention, is usually cleaner than long-term backups of everything.
Individual records usually can't be removed from backup media, so plan around that:
- Document that deleted data persists in backups until they expire on their normal cycle.
- Keep a record of deletions so they can be re-applied if a backup is restored.
- Restrict access to backups so they are used only for recovery.
- Set immutability or retention locks to match the schedule, since locked data can't be removed early.
Archives are subject to the schedule too. They're often the forgotten tier, holding data long past any need because nobody owns the clean-up.
How long should you keep logs?
Security logs have to be kept long enough to investigate incidents, which can be discovered months after they begin. PCI DSS Requirement 10.5.1 sets a useful reference point for the card data environment: retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
Logs also contain personal data such as usernames and IP addresses, so storage limitation applies. Set a justified period for each log type rather than keeping everything indefinitely. Debug and application logs usually need far shorter retention than security audit logs.
The better fix is upstream: don't log sensitive data in the first place. Card numbers, passwords, health information and session tokens have no place in routine logs.
How can you automate data deletion?
Manual deletion doesn't scale and rarely survives a busy quarter. Most platforms now include retention features you can configure against your schedule:
- Retention policies in email, file storage and collaboration platforms
- Lifecycle rules in cloud object storage
- Time-to-live settings and scheduled purge jobs in databases
- Retention settings in log management and monitoring tools
Roll automation out carefully. Start with high-volume, high-risk stores, run first jobs in report-only mode, and have data owners approve before enabling deletion. Unstructured data such as file shares, mailboxes and exported spreadsheets is hardest to automate and usually needs periodic owner reviews as well.
How do you prove data was deleted?
A policy that says data is deleted isn't evidence that it was. Auditors, customers and regulators may ask to see the proof. Useful evidence includes:
- Logs from deletion jobs showing what was deleted, when and how many records
- Screenshots or exports of retention policy configurations
- Records of the quarterly PCI DSS 3.2.1 verification
- Certificates of sanitization for media, which NIST SP 800-88 recommends for each item sanitized, and destruction certificates from disposal providers
- Confirmation from processors that personal data was deleted or returned at contract end, as GDPR Article 28(3)(g) requires
- Results of periodic spot checks that search for records past their retention date
Spot checks are the most convincing. Pick a category, search for records older than the retention period, and document what you found and fixed.
Frequently asked questions
Does HIPAA require us to keep medical records for six years?
No. The six-year rule in 45 CFR 164.316 covers Security Rule documentation such as policies, procedures and risk analyses. Medical record retention is generally set by state law.
Do we have to delete data from backups when someone asks for erasure?
Removing a single record from backup media is usually impractical. A common approach is to delete it from live systems, make sure it can't be restored into production without the deletion being re-applied, and let the backup expire on its normal cycle. Explain this in your privacy notice and your response.
How often should we review the retention schedule?
At least once a year, and whenever you add a significant system, enter a new market or become subject to a new regulation.
Key takeaways
- Build a schedule by data category, with an owner, a trigger, a period, a documented driver and a disposition.
- Treat GDPR storage limitation as a ceiling, and remember HIPAA's six-year rule covers documentation, not medical records.
- Build legal hold exceptions into deletion automation from the start.
- Align backup, archive and log retention with the schedule.
- Keep evidence that deletion happened, and test it with periodic spot checks.