Home › Tools

Data Retention Policy Template

Published August 28, 2026 · Updated September 17, 2026

A data retention policy template gives your organization a ready-made framework for documenting how long you keep each category of personal data and when that data must be deleted or anonymized. The table below lists recommended retention periods for 11 common data types across five major privacy frameworks — GDPR, CCPA/CPRA, PIPEDA, LGPD, and India's DPDP Act. Copy it directly into your internal records, or scroll down to the interactive builder to generate a custom retention schedule and a paste-ready clause for your privacy policy.

Retention Schedule Template

The following retention schedule covers the data types most commonly collected by apps and websites. Each period reflects the strictest cross-jurisdictional default drawn from published regulatory guidance. Copy the table and adjust the periods to match your specific data practices.

Custom Retention Schedule Builder

Need a retention schedule tailored to your exact data types, jurisdictions, and business model? Use the interactive builder below. It cross-references regulatory defaults across your selections and outputs a table plus a ready-to-paste retention clause for your privacy policy. Not sure which jurisdictions apply? Run the privacy law applicability checker first.

What Is a Data Retention Policy?

A data retention policy is a formal document that specifies how long an organization stores each category of personal data, the legal basis for that storage period, and the procedure for secure deletion once the period expires. Privacy regulations including the GDPR (Article 5(1)(e)), California's CPRA (Civil Code §1798.100(d)), Brazil's LGPD (Article 16), Canada's PIPEDA (Principle 4.5), and India's DPDP Act (Section 8(7)) all require controllers to define and disclose retention periods rather than keeping data indefinitely.

For app and website developers, the policy typically lives inside your privacy policy's “Data Retention” or “How Long We Keep Your Data” section. It should name each data type you collect — account information, device identifiers, analytics events, payment records — state a specific retention period for each, and cite the legal basis. Vague language like “as long as necessary” does not satisfy GDPR Article 13(2)(a), which requires either a concrete period or the criteria used to determine one. The template table and builder on this page generate both.

How to Use This Tool

Start by checking every data type your app or website collects in the builder above. Next, select the jurisdictions where your users are located. Pick your business type from the dropdown, then click “Generate Retention Schedule.” The builder cross-references a built-in lookup table of regulatory defaults to find the strictest binding ceiling and any statutory minimums across your selected jurisdictions. The output includes a retention table you can reference internally and a ready-to-paste paragraph for your privacy policy's data retention section. Once your retention periods are set, generate your full privacy policy to build a compliant document around them.

GDPR Data Retention Requirements

The GDPR does not prescribe a single retention period for all personal data. Instead, it establishes storage limitation under Article 5(1)(e) and requires controllers to define their own periods based on the purpose of processing. Several articles work together to make this enforceable.

Article 13(2)(a) requires controllers to inform data subjects of the storage period, or the criteria used to determine it, at the time data is collected. Article 17(1)(a) establishes the right to erasure when personal data is no longer necessary for its original purpose. Article 25(1) codifies data protection by design, which the European Data Protection Board interprets to include built-in deletion schedules that execute automatically when periods expire. Article 30(1)(f) requires the record of processing activities to include "envisaged time limits for erasure" for each data category.

Enforcement has confirmed these are not optional disclosures. France's CNIL fined Google €150 million in January 2022 (Deliberation SAN-2021-023) in part because analytics cookies persisted beyond any disclosed retention period; the authority cited the absence of a defined storage duration as a standalone violation. The Irish Data Protection Commission's €225 million fine against WhatsApp in September 2021 included transparency failures around retention disclosures under Articles 12 through 14.

For app and website developers with EU users, the practical requirement is straightforward: every data type in your privacy policy needs a named retention period and a cited legal basis. Use the retention schedule table above as a starting point. If your app or site is directed at children under 13, the amended COPPA Rule adds a written retention policy for children's data that must appear in your online notice, as our COPPA privacy policy guide explains.

Why Every Privacy Policy Needs Retention Periods

Regulators treat vague retention language as a compliance gap. In January 2022, France's CNIL fined Google €150 million (Deliberation SAN-2021-023) in part because Google Analytics cookies persisted far beyond any disclosed retention period; the authority cited the absence of a defined storage duration as a standalone violation of Article 13(2)(a) GDPR. That article requires controllers to state the period for which personal data will be stored, or the criteria used to determine that period — not hedge with “as long as necessary” or “for a reasonable period.” California's CPRA (Civil Code §1798.100(d)) added its own retention-disclosure mandate effective January 2023. Brazil's LGPD Article 16 requires deletion when the processing purpose has been achieved, Canada's PIPEDA Principle 4.5 demands destruction once the purpose is fulfilled, and India's DPDP Act Section 8(7) requires erasure once the purpose is no longer being served.

Beyond compliance, clear retention periods reduce your data footprint. Holding data longer than necessary increases your exposure in a breach, raises storage costs, and makes subject-access requests harder to fulfill. A well-defined retention schedule turns an open-ended liability into a manageable, auditable process.

Statutory Floors: When You Cannot Delete Early

Some data types have legally mandated minimum retention periods that override purpose limitation. Payment and tax records are the most common example, and the specific floor varies by country. Germany's Handelsgesetzbuch (HGB) §257 requires commercial and tax records to be retained for ten years from the end of the calendar year in which the last entry was made. France's Code de commerce Article L123-22 mandates the same ten-year period. The UK requires six years under the Companies Act 2006 §388. In the United States, IRC §6501(a) sets a three-year statute of limitations on most federal tax assessments, but §6501(e) extends it to six years when gross income is understated by more than 25 percent, and the IRS recommends keeping supporting records for seven years to cover both windows. Canada's Income Tax Act §230(4) requires six years from the end of the last tax year the records relate to. Brazil's Código Tributário Nacional (CTN) Article 173 sets a five-year decadential period for tax authority assessments. India's Income Tax Act §149(1)(b) allows reassessment up to ten years in cases involving escaped income above ₹50 lakh, making eight years the practical floor for most businesses.

When a statutory floor applies, it acts as a hard minimum — you must retain the data for at least that long even if your general retention policy would delete it sooner. This tool checks for statutory floors across all your selected jurisdictions and surfaces the longest applicable minimum so your retention schedule stays compliant everywhere you operate.

Worked Example: SaaS App With EU and US Users

A SaaS platform collects account emails, IP addresses, analytics events, and payment records from users in the EU and the United States. Here is how the retention periods resolve:

• Account email: No statutory floor in either jurisdiction. GDPR Article 5(1)(e) and CPRA §1798.100(d) both default to purpose limitation. Recommendation: delete within 30 days of account closure.
• IP addresses: No statutory floor. The EDPB's guidelines on data processing for server logs recommend a maximum of six months; CPRA allows up to 12 months for security and fraud prevention. The tool picks six months — the stricter ceiling — so the schedule is compliant in both markets.
• Analytics events: No statutory floor. CNIL's Deliberation 2020-091 recommends a 25-month maximum for analytics data linked to identifiers, with 14 months for raw event data. CPRA allows 12 months. The tool picks 12 months.
• Payment records: Statutory floor applies in both jurisdictions. The EU default in this tool is seven years (84 months), reflecting the requirement in most member states. The US floor under IRC §6501 covers up to seven years. The tool surfaces seven years as the cross-jurisdiction minimum.

The result: the SaaS platform retains emails for account duration plus 30 days, IP addresses for six months, analytics for 12 months, and payment records for seven years. Each period has a named legal basis the platform can cite in its privacy policy and defend in an audit.

Purpose Limitation: The Default Rule

Where no statutory floor exists, every major privacy law defaults to the same principle: retain personal data only for as long as it is needed to fulfill the purpose for which it was collected, then delete or anonymize it. The GDPR calls this “storage limitation” under Article 5(1)(e). The CPRA codifies it in Civil Code §1798.100(d) as a requirement that retention be “reasonably necessary and proportionate” to the disclosed purpose. PIPEDA's Principle 4.5 states that personal information shall be retained only as long as necessary for the fulfillment of the stated purposes, and the Office of the Privacy Commissioner of Canada has enforced deletion timelines against companies that kept data indefinitely (e.g., PIPEDA Report of Findings #2015-001).

In practice, purpose limitation means you need to define a concrete period for each data type rather than relying on open-ended language. The six-month ceiling for IP addresses in server logs comes from the EDPB's repeated recommendations in opinions on ISP and web-server data processing, adopted by most EU data protection authorities. The thirteen-month cookie lifetime traces to CNIL's Deliberation 2020-091 (updated in 2022), which caps analytics identifiers at 25 months and recommends 13 months for most first-party tracking cookies. The thirty-day limit for precise location data reflects the CPRA's classification of geolocation as “sensitive personal information” under §1798.140(ae)(3), which triggers the consumer's right to limit use and demands tighter retention. Your actual retention periods may be shorter depending on how you use the data. For a step-by-step guide to translating these periods into policy language, see our guide on how to write a privacy policy for your app.

Frequently Asked Questions