.svg){kind=logo}
An auditor asks for your data retention policy. You pull up a document titled “Data Retention v1 - Draft” with a date from three years ago and no approval signature. That document is not a policy. It’s a liability.
A data retention policy is a formal, approved document that tells your organisation what data it keeps, how long it keeps each type, how that data is protected during the retention period, and how it is securely destroyed when the period ends. It applies to everyone: employees, contractors, and any system that creates, stores, or processes company data.
The policy typically has two co-owners: the CISO or Head of Security (for the technical and infosec requirements) and Legal (for the regulatory minimums). Data owners in each department, such as the Head of HR or VP of Engineering, are responsible for applying the retention schedule to the data in their domain.
Without a written, approved data retention policy, you face two risks pulling in opposite directions. Keep data too long and you amplify your breach exposure, create legal liability, and potentially violate privacy laws. Delete too soon and you destroy audit evidence, break minimum-retention rules, and leave yourself unable to respond to legal hold requests.
These frameworks require or strongly expect a data retention policy:
- SOC 2 (criteria CC6.5 and CC7.2)
- ISO 27001 (controls A.18.1.3, A.11.2.7, A.12.4.1)
- HIPAA (§164.530(j))
- GDPR (Article 5(1)(e) storage limitation)
- CCPA / CPRA (retention disclosure requirements)
By the end of this guide, you will know exactly what to put in a data retention policy, how to set defensible retention periods for each data type, and how to get it audit-ready.
Here is what I will cover:
- What a data retention policy is and how it differs from a document retention policy
- Which companies need one and why
- What to include, with a full retention periods table
- A free inline template you can use today
- How it maps to SOC 2, ISO 27001, HIPAA, GDPR, and CCPA
- The seven most common mistakes that get companies caught in audits
Free Template
Download the Data Retention Policy Template (PDF)
Pre-filled with retention periods aligned to SOC 2, ISO 27001, HIPAA, and GDPR. Ready to approve and distribute.
What Counts as a Data Retention Policy?
A data retention policy can sound like something only large enterprises with dedicated legal teams need to worry about. It is not. If you hold customer data, log security events, or keep employee records, you already have a retention obligation. The policy is just the part that makes it official, consistent, and auditable.
Key insight
If your policy only covers ‘documents,’ your security logs and database backups are not covered, and auditors will notice.
A data retention policy is a documented set of rules that defines: which data categories your organisation holds, how long each category is retained, how data is stored and protected during that period, and how it is securely destroyed when the retention period ends.
It covers structured data (databases, CRM records, user accounts), unstructured data (emails, documents, spreadsheets), security and audit logs, backups, and any copies held in third-party systems.
What it is not: a backup policy covers how data is copied and recovered, not how long it is kept. An archive policy governs long-term cold storage. A data classification policy labels data by sensitivity. The retention policy answers one question: how long does each type of data live?
Data Retention Policy vs. Document Retention Policy
You will see “document retention policy” used as a synonym, particularly in legal and HR departments. Strictly speaking, a document retention policy refers to formal records: contracts, invoices, HR files, board minutes. A data retention policy is broader. It covers all digital data, not just formal documents.
In practice, many companies merge them into one policy. That is fine, provided all data categories are explicitly listed. If your policy only covers “documents,” your security logs and database backups are not covered, and auditors will notice.
Who Owns the Data Retention Policy?
The CISO or Head of Security typically owns the policy. Legal is the co-owner, because most retention minimums are set by regulation, not by technical preference.
Individual data owners, such as the Head of HR or VP of Engineering, are responsible for applying the schedule to the data in their area. IT or Engineering implements and maintains the technical controls: the automated deletion rules, archival workflows, and purge schedules that actually enforce the policy.
The Real Cost of Keeping the Wrong Data
Most companies treat data retention as a box-ticking exercise: have a policy, write some numbers down, move on. The companies I have spoken to who got caught in audits or received regulatory attention thought the same thing, until they didn’t.
Free Demo
ComplyJet builds defensible retention periods, mapped to every framework
Covers SOC 2 CC7.2, ISO 27001 A.18.1.3, HIPAA §164.530(j), and GDPR Article 5(1)(e).
The risk runs in two directions.
Keep data too long and you amplify your blast radius in a breach. More data held means more data exposed. You also create eDiscovery liability if litigation arises. And under GDPR Article 5(1)(e), retaining personal data beyond its stated purpose is itself a violation, even if nothing else goes wrong.
Delete too soon and you eliminate the audit trail you need. SOC 2 expects security event logs to be available for at least 12 months. HIPAA requires policies and procedures to be retained for six years. If an incident occurs and you cannot produce logs because they were purged on a 30-day cycle, that becomes a finding.
Have no written policy at all and you fail on both counts simultaneously. It does not matter what you are doing operationally. In a SOC 2 or ISO 27001 audit, the absence of a documented, approved policy is a gap regardless of practice. The documentation is the control.
I have seen SOC 2 audits stall specifically because a company’s security logs were being retained, but nobody had written down that they were being retained and why. A one-page policy would have closed that finding in ten minutes.
Who Actually Needs a Data Retention Policy?
The short answer: any organisation that stores personal data, pursues a security certification, or operates in a regulated industry. That covers most companies reading this.
Why it matters
If you are a startup pursuing your first compliance certification, your data retention policy is one of the first documents your auditor will ask for. It is foundational.
GDPR applies to any company processing personal data of EU or UK residents, regardless of where the company is based. Article 5(1)(e) requires data to be kept no longer than necessary, and Articles 13/14 require you to disclose retention periods in your privacy notices. No written policy means no defensible answer when a regulator asks.
HIPAA applies to covered entities and business associates handling protected health information. Section 164.530(j) requires policies and procedures to be retained for six years from the date of creation or the date they were last in effect.
SOC 2 is not a regulation but a standard. Its criteria, particularly CC6.5 (removal of access rights) and CC7.2 (system monitoring), expect evidence of defined retention and disposal practices. A missing or undocumented retention policy is almost always a finding in a SOC 2 Type II audit.
ISO 27001 requires it explicitly. Control A.18.1.3 mandates that retention periods be defined and documented. Controls A.11.2.7 and A.12.4.1 add requirements around secure disposal and log retention.
CCPA / CPRA requires California-regulated businesses to disclose retention periods for each category of personal information in their privacy policies.
If you are a startup pursuing your first compliance certification, your data retention policy is one of the first documents your auditor will ask for. It is foundational. Everything else, including access logs, audit trails, and incident records, only makes sense if someone has defined how long those things should be kept.
What Your Data Retention Policy Should Cover
A well-structured data retention policy has eight core sections. Here is what each one needs:
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists: the compliance frameworks it supports, the risks it addresses |
| Scope | All employees, contractors, third parties, systems, and data categories covered |
| Roles and responsibilities | Policy owner, Legal co-owner, data owners by department, IT enforcement role |
| Retention schedule | Data category, minimum retention period, recommended period, regulatory or operational basis |
| Storage requirements | How data is protected during retention: encryption, access controls, backup requirements |
| Legal holds and exceptions | How holds override the schedule, who issues them, how exceptions are approved |
| Data destruction | Approved destruction methods, logging requirements, vendor destruction obligations |
| Review cadence | Annual review minimum, plus triggers for out-of-cycle review |
Retention Periods by Data Type
This is the core of the policy. Every data category needs a retention period and a stated reason. “We keep it for two years” is not a reason. “We keep it for two years per GDPR Article 5(1)(e) and our contract terms” is.
| Data category | Minimum retention | Recommended retention | Regulatory basis |
|---|---|---|---|
| Customer PII | Relationship duration + 1 year | Relationship + 2 years | GDPR Art. 5(1)(e) |
| Employee records (HR) | Employment + 7 years | Employment + 7 years | Local employment law |
| Financial records | 7 years | 7 years | SOX / local tax law |
| Security and audit logs | 12 months | 12-24 months | SOC 2 CC7.2, ISO A.12.4.1 |
| Access logs | 90 days | 12 months | SOC 2 best practice |
| Backup data | Per backup policy | 30-90 days rolling | Operational |
| Health records (PHI) | 6 years from creation or last use | 6 years | HIPAA §164.530(j) |
| Contracts and legal documents | Contract term + 7 years | Contract term + 10 years | Legal / contractual |
Data Retention and Destruction Policy: Secure Deletion
Reaching the end of a retention period is not the same as pressing delete. Secure deletion means the data cannot be recovered, not just that it is no longer visible in the application.
Accepted destruction methods include cryptographic erasure (for encrypted volumes), secure wipe following NIST 800-88 guidelines, and physical destruction for decommissioned hardware. Your policy should specify which methods are approved for which data types.
Every destruction event must be logged. The log should capture the date, the method used, the data category destroyed, and the name of the person responsible. That log becomes evidence in an audit.
Vendors and processors holding copies of your data must follow equivalent destruction procedures. Write this into your data processing agreements.
Legal Holds and Exceptions
A legal hold suspends the normal retention schedule when litigation, a regulatory investigation, or an internal review is in progress. Data subject to a legal hold cannot be deleted, even if its retention period has expired.
Your policy needs to define how holds are issued (by Legal, in writing), how IT and data owners are notified and expected to respond, and how a hold is lifted (again by Legal, in writing). Without this process defined, you have no consistent way to respond to legal hold requests, and courts notice.
Free Data Retention Policy Template
The template below is based on the structure used in ComplyJet’s compliance template library. Customise the bracketed placeholders for your organisation: company name, data owner names, and any retention periods that differ from the defaults.
Free Template
Download the Data Retention Policy Template (PDF)
Pre-filled with retention periods aligned to SOC 2, ISO 27001, HIPAA, and GDPR. Ready to approve and distribute.
[Company Name] Data Retention Policy
Version 1.0 | Effective date: [Date] | Owner: [CISO / Head of Security]
1. Purpose
[Company Name] retains data as long as it has a legitimate business need, or to meet regulatory or contractual requirements. Once data is no longer needed, it is securely disposed of or archived. This policy defines the retention periods for each data category, the responsibilities for enforcing them, and the procedures for secure destruction and legal holds.
2. Scope
This policy applies to all employees, contractors, and third parties who create, access, or process data on behalf of [Company Name], across all systems and storage environments.
| Data / system type | In scope |
|---|---|
| Customer application data | Yes |
| Employee HR data | Yes |
| Security and audit logs | Yes |
| Financial records | Yes |
| Contracts and legal documents | Yes |
| Backup data | Yes |
| Temporary / ephemeral files | Yes (subject to operational retention) |
| Third-party processor copies | Yes (governed by DPA) |
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| CISO / Head of Security | Policy owner; annual review; exception approval |
| Legal | Co-owner; advises on regulatory minimums; issues and lifts legal holds |
| Data owners (department heads) | Define and apply retention requirements for their data sets |
| IT / Engineering | Implement and maintain technical controls: automated deletion, archival workflows, purge schedules |
| All staff | Comply with retention requirements; report concerns to the CISO or Legal |
4. Data Retention
[Company Name] retains data for as long as it has a business use, or to meet regulatory or contractual requirements. Data owners, in consultation with Legal, determine retention periods for their data sets.
Personally identifiable information (PII) is deleted or de-identified as soon as it no longer has a business use.
Retention periods are documented in the Data Retention Matrix in Appendix B.
5. Legal Holds
Under certain circumstances, [Company Name] may be subject to legal proceedings requiring retention of data associated with legal holds, lawsuits, or other matters as stipulated by [Company Name]’s legal counsel. Such records are exempt from the standard retention schedule and must be retained per Legal’s written instructions. All holds are subject to annual review with legal counsel.
6. Data Destruction
At the end of the applicable retention period, data must be destroyed using an approved method.
| Data type | Approved destruction method |
|---|---|
| Digital files on encrypted storage | Cryptographic erasure |
| Digital files on unencrypted storage | Secure wipe (NIST 800-88) |
| Decommissioned hardware | Physical destruction or certified E-Waste service with destruction certificate |
| Cloud-hosted data | Provider-certified deletion; retain deletion confirmation record |
Each destruction event is logged with: date, method, data category, and responsible person. Certificates of destruction for hardware are retained for one year.
7. Exceptions
Exceptions to this schedule require written approval from Legal and the CISO. The exception record must document: the reason for the exception, the alternative control in place, the expiry date of the exception, and the name of the risk owner.
8. Review
This policy is reviewed annually. Out-of-cycle review is triggered by: a material change to applicable regulations, a data breach, entry into a new market or jurisdiction, or the addition of a new major data category.
Appendix A: Retention and Disposal Procedures
[Company Name]’s [Responsible Party] is responsible for enforcing data retention and disposal procedures across all systems and storage environments.
Customer accounts: Customer data is deleted within [Deletion Days] days of contract termination through manual or automated deletion processes.
Employee devices: Devices are collected upon employee termination and securely erased before reprovisioning. Remote employees are sent a return shipping label; return is tracked. Devices that cannot be wiped in-house are processed through a certified E-Waste service. Destruction certificates are retained for one year.
Appendix B: Data Retention Matrix
| Data source | Data description | Retention period |
|---|---|---|
| [Company Name] product / SaaS platform | Customer application data | [e.g., 60 days after contract termination] |
| [Support system, e.g., Intercom] | Support tickets and cases | [e.g., Indefinite, or 3 years] |
| [Security logging platform] | Security and system event logs | 12 months minimum (24 months recommended) |
| [HRIS, e.g., BambooHR] | Employee records, payroll, performance data | 7 years after termination |
| [CRM / marketing platform] | Sales and marketing data | 3 years after last activity |
| Policy documents | Security policies and procedures | 6 years (HIPAA minimum) or 1 year post-archive |
| Financial records | Invoices, contracts, financial statements | 7 years |
| Temporary files | Ephemeral processing data | Deleted at end of processing session |
Data Retention Policy Examples and Samples
Here is a data retention policy example for each of two very different company types: a startup and a healthtech company.
Example A: 20-person SaaS startup. Five categories in the retention schedule: customer PII, employee records, security logs, financial records, contracts. Security log retention is enforced via an S3 lifecycle policy set to 12 months. Everything else is reviewed manually each quarter. The policy is two pages long. It passes SOC 2.
Example B: 80-person healthtech company. Two separate retention tracks: PHI (six-year HIPAA minimum, in a HIPAA-compliant environment) and non-PHI (standard schedule). Destruction is logged in a shared spreadsheet signed off by the Head of Security each quarter. Legal holds are issued via email with a ticket reference tracked in Jira.
Neither is complicated. The difference between a company that passes its audit and one that doesn’t is not the sophistication of the policy. It’s whether the policy exists, is approved, and is actually followed.
Sample Data Retention Policy
The template above is the sample. Download the PDF version for a pre-filled copy with placeholder values already populated, ready to adapt for your organisation.
How to Build and Roll Out a Retention Schedule
Getting from “we should have a policy” to “we have an approved, implemented policy” takes about ten steps. None of them are hard. The hard part is actually doing them.
Free Demo
ComplyJet handles your retention schedule, approval workflow, and audit evidence
Pre-mapped to SOC 2, ISO 27001, HIPAA, and GDPR. Automated deletion evidence included.
Inventory your data. Map every data type you hold, where it lives, and who owns it. Customer records in your CRM, security logs in your SIEM, HR data in your HRIS, financial records in your accounting system. You cannot write a retention schedule for data you haven’t catalogued.
Identify regulatory minimums. Check GDPR, HIPAA, SOC 2, ISO 27001, and any industry-specific rules that apply to you. These set the floor for each data category.
Set retention periods. Use the regulatory minimum as the floor and operational need as the ceiling. If GDPR says “no longer than necessary” and your contracts run for two years, your customer PII period might be two years plus one.
Assign data owners. Each data category needs one accountable person. Without this, the retention schedule is a document nobody enforces.
Document and get sign-off. Write the policy, get approval from Legal and the CISO. Both need to sign. Legal owns the regulatory accuracy; the CISO owns the technical implementation.
Communicate and train. Every employee who handles data needs to know what to keep and what to delete. Putting the policy in an email attachment is not sufficient. Put it in onboarding and collect acknowledgements.
Implement technical controls. Wherever possible, automate: S3 lifecycle policies, database TTL settings, log rotation rules. Manual processes fail at scale and in emergencies.
Collect acknowledgements. All staff should confirm they have read and understood the policy. This is also evidence for your audit.
Map to compliance controls. For each retention period, note which SOC 2 criterion, ISO 27001 control, or regulatory clause it satisfies. This saves significant time when preparing audit evidence.
Review annually. Schedule it. When regulations change or you add a new data type, update the schedule.
Data Retention Policy Best Practices
A few things that trip up even well-prepared teams.
Automate deletion wherever you can. Humans forget, priorities shift, and the person who owned the quarterly deletion review eventually leaves. An S3 lifecycle policy does not forget.
Maintain a destruction log. Not just for the auditor. If an incident occurs and you need to prove what data existed at a given time, the destruction log is part of that answer.
Align the retention schedule with your backup and recovery policy. A 30-day rolling backup does not satisfy a seven-year financial records requirement. These are separate controls serving different purposes.
Check your vendor agreements. Any data you have shared with a processor is covered by your retention obligations. Your DPAs need to include explicit deletion and destruction terms.
Do not conflate retention with archiving. Archiving extends where data lives, not the retention clock. Data moved to cold storage is still subject to your retention schedule.
Framework Requirements for Data Retention
| Framework | Key requirement | Relevant control or clause |
|---|---|---|
| SOC 2 | Define retention and disposal for data; retain security logs for investigation | CC6.5, CC7.2, A1.2 |
| ISO 27001 | Document retention periods; define secure disposal for assets and media; enforce log retention | A.18.1.3, A.11.2.7, A.12.4.1 |
| HIPAA | Retain policies and procedures for 6 years; sanitise media before reuse | §164.530(j), §164.310(d)(2)(i) |
| GDPR | Storage limitation; disclose retention periods in privacy notices; honour right to erasure | Art. 5(1)(e), Art. 13/14, Art. 17 |
| CCPA / CPRA | Disclose retention periods per data category in privacy policy | CPRA §1798.100(a)(3) |
SOC 2
SOC 2 does not prescribe specific retention periods, but the criteria require you to have them documented and enforced. CC7.2 covers ongoing system monitoring: without 12 or more months of security log retention, you cannot demonstrate continuous monitoring over the audit period. CC6.5 requires removal of access rights when no longer needed, and access logs substantiate that controls were applied consistently.
ISO 27001
Control A.18.1.3 requires protection of records with documented retention periods. A.11.2.7 extends this to physical and virtual assets: when you decommission a server or wipe a laptop, the data destruction must be deliberate and logged. A.12.4.1 covers event logging: log retention periods must be set and technically enforced, not just stated in a document.
HIPAA
The six-year minimum under §164.530(j) applies to policies and procedures, not to clinical records (where state law governs and is often longer). The key operational requirement is §164.310(d)(2)(i): any media being reused must be sanitised before that reuse. PHI cannot just be “deleted” and the device handed to someone new.
GDPR
GDPR does not set specific retention periods in most cases. What it requires is that you document your retention basis, keep data no longer than necessary for the stated purpose (Article 5(1)(e)), and honour deletion requests within the right-to-erasure framework (Article 17). Your retention policy is also what feeds your privacy notices under Articles 13 and 14. If you have not written it down, you cannot accurately disclose it to your users.
CCPA / CPRA
The CPRA (the 2023 update to CCPA) added an explicit requirement to disclose, in your privacy policy, the retention period for each category of personal information, or the criteria used to determine it. There is no regulatory minimum period. The requirement is transparency, not a specific number.
What Auditors Actually Look for in Data Retention
When an auditor reviews your data retention policy, they are not just checking that the document exists. They are checking that it is current, approved, followed, and evidenced.
| Evidence type | What auditors expect to see |
|---|---|
| Retention policy document | Approved, version-controlled, named owner, current effective date |
| Retention schedule | Per-category periods each with a documented regulatory or operational basis |
| Destruction log | Date, method, data category, responsible person for each deletion event |
| Legal hold log | Active holds listed with issuing party, date range, and current status |
| Employee acknowledgements | Confirmed by all staff within the last 12 months |
| Annual review record | Meeting notes or approval sign-off with the date of last review |
| Technical controls evidence | Screenshots of automated deletion rules, S3 lifecycle policies, purge schedules |
| Third-party processor evidence | DPAs or data processing agreements with retention and destruction clauses |
The most common gap I see is the destruction log. Teams delete security and audit logs and other data on schedule but never record that they did it. The policy says data will be deleted after 12 months. The data has been deleted. But there is no log showing when, by whom, and for which categories. In a SOC 2 audit, that is a finding.
Retention Mistakes That Get Startups Caught in Audits
No written policy. Even if your team is deleting data on the right schedule, undocumented practices do not count as controls. The auditor needs to see the policy, not hear that you have a process.
Watch outSaying you delete data is not evidence that you deleted it. The destruction log is the evidence.Retention periods with no stated basis. “We keep things for two years” is not a retention policy. Every period needs a source: a regulatory requirement, a contractual obligation, or a documented operational reason. Without that, auditors treat it as arbitrary.
Forgetting security logs. This is the most common gap in early SOC 2 audits. Security and audit logs are not a category most companies think about consciously. SOC 2 expects at least 12 months of retention and evidence that the logs were actually kept for that full period.
No destruction log. Saying you delete data is not evidence that you deleted it. The destruction log is the evidence. Without it, you have an assertion, not a control.
Confusing backup with retention. A 30-day rolling backup does not satisfy a seven-year financial records requirement. These serve different purposes: backups are for recovery, retention is for compliance and legal obligations.
Leaving out third parties. Any data you have shared with vendors or processors is still your data for compliance purposes. If your DPAs do not include retention and deletion terms, your policy does not cover your full data footprint.
The annual review never happens. A policy with a “last reviewed: never” record is a red flag in every audit. The document exists; the governance does not.
Right-Sizing Your Data Retention Policy by Stage
Startups (1-25 Employees)
Keep it simple. A one-page policy with five or six data categories covers most of what you need. Focus on the categories auditors care about first: customer PII, employee records, security logs, financial records, and contracts.
Quick tip
Before you finalise HIPAA or GDPR-driven retention periods, have your lawyer confirm the numbers. Getting this wrong creates compliance exposure, not just audit risk.
Use cloud-native controls wherever you can: S3 lifecycle policies, Google Workspace retention labels, Slack message retention settings. These do not require engineering resources and they give you documented, automated evidence.
Before you finalise HIPAA or GDPR-driven retention periods, have your lawyer confirm the numbers. Getting this wrong creates compliance exposure, not just audit risk.
Growing Companies (25-200 Employees)
As you add data types, expand the schedule: marketing analytics, product telemetry, CRM data, partner integrations. Each new category needs a documented retention period and an owner before it goes into production.
At this stage, manual deletion processes start to break down. If your retention policy depends on someone remembering to run a script every quarter, you will eventually have a gap. Automate what you can, and build the destruction log into the automated workflow, not as a manual step afterwards.
Add retention and deletion terms to all new vendor agreements before signing. Adding them after the fact is significantly harder.
Larger Enterprises (200+ Employees)
At this scale, data retention becomes part of a broader data governance programme. You likely hold dozens of data categories across multiple systems, regions, and legal jurisdictions. A single retention schedule may need region-specific tracks for GDPR (EU), CCPA (California), and local employment law.
Consider a data catalogue to track what you hold, where it lives, and who is accountable. Move from annual to quarterly retention reviews. For M&A activity, litigation, or regulatory investigations, a legal holds management system is worth the investment.
Keeping Retention Audit-Ready with ComplyJet
The friction in data retention is not writing the policy. It is keeping it current, getting sign-offs, tracking acknowledgements, and proving to an auditor that the policy is actually implemented, not just filed in a folder.
ComplyJet ships a pre-built data retention policy template already mapped to SOC 2, ISO 27001, HIPAA, and GDPR controls. You can customise the retention schedule, assign data owners, collect staff acknowledgements, and set the annual review reminder, all from the same place.
Each retention period is linked directly to the framework control it satisfies. When an auditor asks for evidence that your log retention supports CC7.2, you point to the mapped control, not a spreadsheet assembled the night before.
Destruction logs, legal hold tracking, and review history are maintained automatically as part of your compliance record.
Frequently Asked Questions (FAQ)
What is a data retention policy?
A data retention policy is a documented set of rules that defines how long different types of data are kept, how they are stored during the retention period, and how they are securely destroyed when that period ends. It applies to all data an organisation holds: customer records, employee data, security logs, financial records, and backups.
What is data retention policy and why does it matter?
Retention obligations exist in almost every compliance framework. GDPR requires you to disclose retention periods and not keep data longer than necessary. HIPAA sets a six-year minimum for policies and procedures. SOC 2 expects 12 or more months of security log retention. A missing or undocumented retention policy is a gap in all of them. Beyond audits: retaining data you no longer need increases your breach exposure, and deleting it too early destroys your audit trail.
What should a data retention policy include?
At minimum: a purpose statement, a scope definition, roles and responsibilities, a retention schedule with one row per data category and a stated regulatory or operational basis for each period, data destruction procedures, a legal hold process, an exceptions process, and a review cadence. The retention schedule is the core. Without it, everything else is preamble.
How long should data be retained?
It depends on the data type and which regulations apply to you. Financial records: seven years in most jurisdictions. PHI under HIPAA: six years. Security and audit logs under SOC 2: at least 12 months. Customer PII under GDPR: no longer than necessary for the stated purpose, with the actual period documented in the policy. Always cite the source, not just the number.
Does a data retention policy need to cover all data?
Yes. It should cover every category of data your organisation holds: customer records, employee data, security logs, financial records, contracts, backups, marketing data, product telemetry, and any data held by vendors on your behalf. If a data type is not in the schedule, there is no defined retention obligation for it, which creates both compliance and operational risk.
Who is responsible for the data retention policy?
The CISO or Head of Security typically owns the policy. Legal is the co-owner, because most retention periods derive from regulatory requirements. Individual data owners (Head of HR for employee records, VP of Engineering for security logs) are responsible for applying the schedule to the data in their domain. IT or Engineering enforces the technical controls.
How often should a data retention policy be reviewed?
At minimum annually. Also review it after a significant regulatory change, after a data breach, when entering a new market or jurisdiction, and when you add a new major data type not yet covered by the schedule. The review should be documented and signed off. That sign-off is audit evidence.
What is a good data retention policy?
One that covers all data categories, gives a documented basis for each retention period, includes clear destruction procedures, assigns ownership, is reviewed annually, and is actually implemented. The practical test: if an auditor asked for your retention policy and your destruction log today, could you produce both within five minutes?
Related Policies
A data retention policy does not operate in isolation. These four policies work alongside it and are worth having in place at the same time.
Data Classification Policy: defines how data is labelled by sensitivity. Retention periods often align with classification tiers. Highly sensitive data may warrant shorter retention to reduce exposure, while business records may need longer periods for compliance.
Information Security Policy: the parent policy governing your overall data handling and security controls. The retention policy is a supporting document that flows from it.
