Data retention policy template for EU SMEs: audit-ready

Your data retention policy template is ready to use now. Download the editable Word document (policy body), the Excel retention schedule, a pre-filled example schedule, and an implementation checklist as a single bundle. The template covers GDPR storage limitation under Article 5(1)(e), national data protection laws across EU Member States, and the Article 30 Record of Processing Activities (ROPA) requirement. A generator option is also available via ShieldIQ's platform, which produces a filled retention schedule tailored to your organisation's record categories.

Who should use these files: IT managers, compliance leads, and data protection officers at EU SMEs who need a defensible, auditable retention policy without starting from scratch.

Frameworks covered:

  • GDPR (Regulation (EU) 2016/679)
  • National data protection legislation across EU Member States
  • Article 30 ROPA obligations
  • ISO 27001 information lifecycle controls (where applicable)

Quick-start steps:

  1. Download the bundle and open the Word policy document.
  2. Replace the placeholder organisation name, DPO contact, and effective date.
  3. Open the Excel schedule and populate your record categories (see Section 5 for a sample).
  4. Assign an owner to each row and set a review date.
  5. Share the completed policy with staff and third-party processors.

Pro Tip: Before editing a single cell, save a copy of the blank template as your master. That way you can reset quickly if a column structure breaks during population.

Key takeaways

A defensible data retention policy requires a paired policy document and retention schedule, with specific periods, legal bases, and disposal methods documented for every record category.

Point Details
Pair policy with schedule A policy body without a retention schedule will not satisfy an Article 30 audit; both documents must be in place.
Use trigger events, not creation dates Retention periods run from a defined event (end of employment, contract expiry) to avoid premature or excessive retention.
Document legal bases per category Generic GDPR references are insufficient; each row needs a specific Article 6 or Article 9 ground.
Maintain deletion logs Log every deletion action with a timestamp and record category; retain logs for at least 3 years as audit evidence.
ShieldIQ automates the ongoing work ShieldIQ generates retention policies, maintains a live ROPA, and produces audit-ready evidence reports across GDPR, NIS2, and ISO 27001.

Table of Contents

What is a data retention policy and why does GDPR require one?

A data retention policy is a formal document that states how long your organisation keeps each category of personal data, the legal basis for keeping it, and how it is securely destroyed when the period expires. Under GDPR Article 5(1)(e), personal data must be kept "no longer than is necessary" for the purposes for which it was collected. That single principle creates a direct compliance obligation: you must be able to prove, category by category, that your retention periods are justified.

Hand destroying data storage device securely

The ROPA requirement under Article 30 tightens this further. ICO guidance confirms that documentation must be granular, naming retention periods and legal bases for each data category rather than a single generic statement. A retention policy that simply says "we keep data for as long as needed" will not satisfy an auditor.

Three practical reasons this matters for EU SMEs:

  • Audit evidence: A documented schedule with named owners and disposal methods is the primary evidence a supervisory authority will request during an investigation.
  • Data subject rights: A right-to-erasure request is far easier to handle when you already know where data lives and when it is due for deletion.
  • Breach containment: Holding data longer than necessary increases the volume of records exposed in a breach, which directly affects your GDPR breach response obligations.

Fines for GDPR infringements can reach €20 million or 4% of global annual turnover under Article 83(5), whichever is higher. Retention violations fall squarely within the categories that attract the higher tier of penalties.

Organisations that treat retention as a filing decision rather than a compliance control tend to discover the gap at the worst possible moment: during an audit or after a breach.

What sections must your data retention policy template contain?

A defensible retention policy has two parts: the policy body (governance, principles, responsibilities) and the retention schedule (the actual record-by-record table). Pairing both in one document is standard practice for defensible retention documentation and reduces audit friction considerably.

Essential sections in the policy body:

  • Purpose and scope: States which entities, systems, and data types the policy covers. One sentence per exclusion is enough.
  • Responsibilities: Names the Data Protection Officer (or equivalent), record owners, and IT's role in enforcing deletion. See ShieldIQ's guide on when your business needs a DPO for scoping this section.
  • Retention principles: Summarises the storage-limitation principle, the legal bases your organisation relies on (contract, legal obligation, legitimate interests), and the rule that longer periods require documented justification.
  • Retention schedule: The core table. Mandatory columns: record category, legal basis, retention period, record owner, disposal method, and date last reviewed.
  • Secure destruction: Describes approved destruction methods (cross-cut shredding, certified digital wiping, third-party destruction certificates) and maps each to the record type.
  • Legal holds: Explains how deletion is suspended when litigation, regulatory investigation, or a subject access request is active.
  • Exceptions: Documents any sector-specific or contractual obligations that override the standard periods.
  • Review and version control: States the review cadence (annual minimum), who approves changes, and how version history is maintained.
  • Monitoring and enforcement: Describes how compliance with the schedule is checked and what happens when a breach of the policy is identified.

Mandatory fields for a defensible retention schedule row:

Pro Tip: The "disposal method" column is where most SME templates fall short. Link each method to a recognised sanitisation standard (such as NIST SP 800-88 or HMG IS5) so the entry is auditable, not just descriptive.

What files does the download bundle include?

The download bundle contains four files, each serving a distinct purpose:

  • Policy document (Word/PDF): The full policy body with all nine sections pre-drafted. Placeholder text in square brackets marks every field you need to customise.
  • Editable retention schedule (Excel/Sheets): A blank schedule with the six mandatory columns, dropdown validation for legal basis and disposal method, and conditional formatting that highlights rows where the review date has passed.
  • Pre-filled example schedule: A completed version covering twelve common record types (employee, customer, financial, and operational categories) with suggested periods and legal bases. Use it as a reference, not a direct copy.
  • Implementation checklist: A one-page tick-list covering data mapping, owner assignment, system configuration, staff communication, and first review date.

Common pitfalls when populating the spreadsheet:

  • Conflating the retention period with the creation date rather than the trigger event (e.g., end of employment, not date of hire).
  • Leaving the "legal basis" column as a generic label ("GDPR") rather than the specific ground (Article 6(1)(c) legal obligation).
  • Failing to update the schedule when a new system or data category is introduced mid-year.

The Word document and Excel schedule are version-controlled with a header row showing document owner, version number, approval date, and next review date. Update these fields every time you make a substantive change.

Pro Tip: Set a calendar reminder in your team's shared calendar for the annual review date the moment you finalise the schedule. Retention schedules go stale faster than almost any other compliance document because systems and business processes change constantly.

Sample retention schedule: common EU record types and suggested periods

The table below shows suggested retention periods for common record categories. These are starting points. Always verify the statutory minimum for your Member State and sector before finalising any period.

A note on sector exceptions: Financial services firms operating under DORA or MiFID II face mandatory retention periods that can extend to 5–10 years for transaction records. Healthcare organisations must follow national clinical records legislation, which often mandates periods of 10 years or more. Where a statutory period is longer than your standard business period, the statutory period always wins. Record the statutory source in the "legal basis" column so the justification is traceable.

GDPR data mapping should capture not just where data is stored but how long it is kept, making the mapping exercise and the retention schedule two sides of the same document.

Pro Tip: For records subject to both a tax obligation and a data protection obligation, apply the longer period and document both legal bases in the same row. Auditors from different authorities may each inspect the same record.

How to set defensible retention periods for each record category

Setting a retention period is not a guess. It is a four-step method that produces a documented, auditable rationale for every row in your schedule.

  1. Identify the purpose and legal obligations. Ask: why do we hold this data, and is there a statutory minimum or maximum? Check national employment, tax, and sector-specific legislation for your Member State. Where a statutory period exists, it sets the floor.

  2. Map where the data lives. You cannot set a deletion date for data you cannot find. Run a focused data inventory covering your primary systems (HR platform, CRM, accounting software, email, shared drives, backups). Note the system name, data format, and who has access.

  3. Assess business needs beyond the legal minimum. Some records have genuine operational value beyond the statutory period. Document the specific business reason (e.g., "retained for 2 years post-contract to handle warranty claims") and confirm it is proportionate. Vague justifications ("might be useful") will not survive scrutiny.

  4. Set the period, trigger event, and disposal method. The period runs from a defined trigger (end of employment, contract expiry, last transaction), not from the date of creation. Assign a disposal method and an owner responsible for executing it.

Handling overlapping periods: A contract may be subject to a 6-year limitation period under civil law and a 7-year tax retention requirement simultaneously. Apply the longer period and record both legal bases. The GDPR compliance cost of getting this wrong, in advisory fees and potential fines, far exceeds the cost of a careful mapping exercise upfront.

Pro Tip: Practitioners recommend starting with a small set of high-value categories (payroll, contracts, customer billing) rather than cataloguing every data type at once. Get those rows right first, then expand the schedule incrementally.

How to enforce retention rules across your systems and processes

A policy document sitting in a shared folder enforces nothing. The controls below turn written rules into operational reality.

Essential technical controls:

  • Data mapping integration: Your retention schedule must align with your GDPR data mapping exercise. Every system that holds personal data should appear in both documents.
  • Automated lifecycle rules: Where your platform supports it, configure retention labels or policies that trigger deletion or archival automatically. Microsoft Purview, for example, allows administrators to create retention policies and assign labels that map directly into deletion workflows, removing the reliance on manual intervention.
  • Access controls: Restrict who can override or delay a scheduled deletion. Changes to retention periods in live systems should require dual authorisation.
  • Secure deletion standards: Digital deletion must go beyond moving files to a recycle bin. Certified overwriting (NIST SP 800-88) or physical destruction with a certificate of destruction are the accepted standards for sensitive personal data.
  • Logging: Every deletion event, legal hold activation, and schedule change should be logged with a timestamp, the user who performed the action, and the record category affected.

Legal hold process (numbered checklist):

  1. The DPO or legal counsel declares a hold in writing, naming the record categories and the reason (litigation, regulatory enquiry, subject access request).
  2. IT suspends automated deletion for the affected categories in all relevant systems.
  3. The hold is recorded in the retention schedule with the declaration date and the name of the declaring officer.
  4. The hold is reviewed at least every 90 days and lifted in writing when the triggering event resolves.
  5. Deletion resumes according to the original schedule from the date the hold is lifted.

Pro Tip: Legal holds are the most common reason a retention schedule fails an audit. Build a simple hold register (a separate tab in your schedule spreadsheet) that logs active holds, their scope, and their review dates. Auditors will ask for it.

Review cycles, version control, and audit evidence

Auditors do not just check whether a policy exists. They check whether it was applied, reviewed, and updated when circumstances changed. A policy with a 2019 review date signals neglect, regardless of how well it was written.

Recommended review cadence:

  • Annual review as a minimum, triggered by the review date in the policy header.
  • Triggered review when a new system is introduced, a new data category is processed, a regulatory change occurs, or a data breach exposes a retention gap.

Mandatory version control fields (policy header):

  • Document owner (name and role)
  • Approver (name and role)
  • Version number (e.g., v2.1)
  • Effective date
  • Next review date
  • Summary of changes from previous version

Sample version history entry:

Audit evidence trail: Every deletion action executed under the schedule should generate a log entry. Store deletion logs separately from the records they relate to, and retain the logs themselves for at least 3 years. When a supervisory authority asks "how do you know this data was deleted?", the log is your answer. The ICO's documentation guidance is explicit that accountability requires evidence of action, not just evidence of intent.

Hand pointing at deletion log document

Copy-ready policy clauses and a filled short example

The clauses below are ready to paste into your policy document. Adjust the bracketed fields for your organisation's name, DPO, and applicable law.

Clause 1: Purpose and scope

This Data Retention Policy sets out the periods for which [Organisation Name] retains personal data and the procedures for its secure disposal. It applies to all personal data processed by [Organisation Name] in any format, across all systems and locations, and to all staff, contractors, and third-party processors acting on our behalf.

Clause 2: Retention principle

Personal data will be kept only for as long as necessary to fulfil the purpose for which it was collected, or as required by applicable law. Retention periods are documented in the Retention Schedule, which forms part of this policy. Any extension beyond the standard period requires written approval from the Data Protection Officer and a documented legal or business justification.

Clause 3: Secure destruction

When the retention period expires and no legal hold is active, personal data must be destroyed using an approved method as specified in the Retention Schedule. Digital data must be deleted using a certified overwriting process or equivalent secure deletion tool. Physical records must be cross-cut shredded or destroyed by a certified third party. A destruction certificate or log entry must be retained for a minimum of 3 years.

Clause 4: Legal hold

Where personal data is subject to actual or anticipated litigation, regulatory investigation, or a data subject rights request, deletion is suspended for the affected categories until the hold is formally lifted by the Data Protection Officer or legal counsel. All active holds are recorded in the Legal Hold Register.

Filled short example (employee and customer records):

Record category Period Legal basis Owner Disposal
Employee contracts 7 years post-employment Legal obligation HR Manager Certified deletion
Payroll records 7 years post-employment Legal obligation Finance Manager Certified deletion
Unsuccessful job applications 1 year from decision Legitimate interests HR Manager Secure deletion
Customer invoices 7 years from transaction Legal obligation (tax) Finance Manager Certified deletion
Customer marketing preferences 2 years post-relationship Consent Marketing Lead Secure deletion

Where your organisation operates in a regulated sector (financial services, healthcare, critical infrastructure), review the sector-specific legislation for your Member State before finalising these periods. The clauses above use plain language deliberately; adapt them to your corporate style but preserve the substantive obligations.

EU compliance checklist and practical tips for audit readiness

Use this checklist before any GDPR audit or supervisory authority engagement. Each item maps to a specific accountability obligation.

EU audit checklist:

  • ROPA is complete, current, and includes retention periods and legal bases for every data category (Article 30 requirement).
  • Retention schedule is version-controlled and was reviewed within the last 12 months.
  • Legal bases for each category are specific (Article 6(1)(a)–(f), Article 9 for special categories) and documented.
  • Secure deletion procedures are documented and deletion logs exist for the past 3 years.
  • Legal hold register is maintained and all active holds have a review date.
  • Staff with data handling responsibilities have received retention policy training in the last 12 months.
  • Third-party processors (cloud providers, payroll bureaux, marketing platforms) have contractual retention obligations in their data processing agreements.
  • Special categories of data (health, biometric, criminal records) are identified in the schedule with enhanced controls and, where required, a Data Protection Impact Assessment (DPIA).

ShieldIQ's platform automates several of these steps: it generates tailored retention policies, maintains a live ROPA, and produces audit-ready evidence reports across GDPR, NIS2, and ISO 27001 simultaneously. The ShieldIQ trust page explains how the platform handles its own data protection obligations, which is useful context when assessing a GRC tool for sensitive compliance work.

Pro Tip: Senior management sign-off on the retention policy is not a formality. It is accountability evidence. The DPO can draft the policy, but the board or CEO approval signature is what demonstrates organisational commitment under Article 5(2).

Pro Tip: Data silos are the single biggest obstacle to a complete retention schedule. HR, finance, IT, and marketing often hold overlapping copies of the same personal data in separate systems. A focused mapping exercise that asks each department head "what personal data do you hold and where?" surfaces these duplicates before an auditor does.

Why the template problem is harder than it looks

Most SMEs do not lack a retention policy because they ignored the requirement. They lack one because the first attempt produced a generic document that nobody could actually use: a policy body with no schedule, or a schedule with no legal bases, or a schedule that covered three record types when the organisation processes thirty.

The real trap is treating the policy and the schedule as separate projects. They are not. A policy without a schedule is an aspiration. A schedule without a policy has no governance wrapper. Pairing them in a single document, as templates that combine policy text and a retention schedule demonstrate, forces the organisation to name owners, legal bases, and disposal methods in the same place. That act alone closes most of the audit gap.

The other underestimated problem is the trigger event. Organisations routinely set a retention period correctly (seven years for payroll) but start the clock from the wrong date (date of hire rather than end of employment). The data is then deleted too early or held too long, and neither outcome is defensible. Getting the trigger event right is more important than getting the period right.

*— Matthew Lemon

ShieldIQ makes audit-ready retention policies faster to build and maintain

Drafting a retention policy manually is a one-time effort. Keeping it current as systems change, staff turn over, and regulations evolve is the harder, ongoing problem. ShieldIQ's GRC platform generates tailored retention policies and retention schedules using AI, maps them to your live ROPA, and flags gaps before an auditor does.

Three concrete benefits for EU SMEs:

  • Time saved: Policy generation that typically takes days of drafting and legal review is reduced to a guided workflow, with outputs aligned to GDPR, NIS2, and ISO 27001 simultaneously.
  • Centralised evidence: Deletion logs, legal hold records, version history, and ROPA entries are stored in one place, ready to export for any supervisory authority request.
  • Built-in compliance checks: The platform flags when a retention period lacks a legal basis, when a review date has passed, or when a new data category has no schedule entry.

For organisations that need hands-on support, ShieldIQ's consulting services include policy tailoring, data mapping workshops, and audit preparation. Book a consultation to see how quickly your retention documentation can reach audit-ready status.

Sources

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Recommended