Data Retention Periods under GDPR — How to Set Storage Periods

One of the most common questions in GDPR practice is: “how long can we keep the data?” The answer is: only as long as necessary — but there is no single, universal “GDPR retention period”. The GDPR sets no specific numbers. It is the controller who must determine the retention period for each purpose, drawing on specific legislation, limitation periods for claims and the genuine need to process the data.

The absence of a considered retention policy is one of the most common problems found during audits and supervisory inspections. Data kept indefinitely “just in case”, customer accounts from ten years ago, marketing databases with no expiry date — these are typical breaches of the storage limitation principle. At the same time, deleting data too early — data that must be kept for tax purposes or to defend against claims — is also a mistake.

This article shows where retention periods come from, discusses the key statutory periods that apply in Poland, and presents a step-by-step method for setting a period. At the end you will find a retention schedule template to use in your own organisation.

The Storage Limitation Principle (Article 5(1)(e) GDPR)

The starting point is the storage limitation principle in Article 5(1)(e) GDPR. Under it, personal data must be kept in a form that permits identification of the data subject for no longer than is necessary for the purposes for which it is processed. In other words: once the purpose of processing ends and there is no other basis for continued storage, the data must be deleted or anonymised.

This principle is closely tied to the accountability principle (Article 5(2)). The controller must not only set retention periods but also be able to demonstrate them — in privacy notices, in the record of processing activities and in an internal policy. A simple statement “we keep data for the period necessary to achieve the purpose” is not enough — supervisory authorities expect specific periods or clear criteria for determining them.

Where Retention Periods Come From — Three Sources

A retention period is set by combining three sources. For a given category of data, the longest applicable period usually governs.

Specific legislation. Many statutes require certain documents to be retained for a fixed time (tax law, accounting law, the Labour Code, social security legislation). This is the hardest source — here the controller has no discretion.

Limitation periods for claims. As long as claims relating to the processing are possible (for example, claims under a contract), the controller has a legitimate interest in keeping the data needed to pursue or defend against them. The retention period therefore often matches the limitation period.

The purpose of processing. If no statute or limitation period sets the boundaries, the genuine need to achieve the purpose decides — for example, data processed on the basis of consent is kept until consent is withdrawn.

Key Statutory Retention Periods in Poland

Below are the most common periods arising from specific Polish legislation. They are a reference point — in a particular situation it is always worth verifying the provision.

Tax and accounting documents — 5 years. Tax books and related documents are kept for 5 years, counted from the end of the calendar year in which the tax payment deadline fell (Tax Ordinance). Approved financial statements and accounting books — 5 years (the Accounting Act). Invoices, including VAT invoices, are also subject to 5-year retention.

Employee records — 10 or 50 years. Following the “e-records” reform (the Act of 10 January 2018, in force from 1 January 2019), employment documentation for employees hired from 1 January 2019 is kept for 10 years, counted from the end of the calendar year in which employment ended (Article 94(9b) of the Labour Code). For those hired before 1 January 1999, the period is 50 years. For those hired between 1 January 1999 and 31 December 2018 — 50 years as a rule, with the option to shorten it to 10 years after filing a declaration (ZUS OSW) and information reports (ZUS RIA) with the social security institution.

Social security data. Linked to employee records and to obligations towards the social security institution — the periods depend on the date of hire and the filing of reports (as above).

CCTV monitoring — as a rule up to 3 months. Workplace CCTV recordings are kept for no longer than 3 months from the date of recording, unless they constitute evidence in proceedings — in which case until the proceedings are finally concluded (Article 22(2) of the Labour Code).

Complaint and warranty documents. Kept for the period needed to handle the complaint and for the limitation period of any related claims (see below).

Limitation Periods as a Basis for Retention

If there is no specific statute for a given category of data, the most commonly used reference point is the limitation periods for claims under the Civil Code. Following the amendment in force from 9 July 2018 (the Act of 13 April 2018), Article 118 of the Civil Code provides:

Six years — the general limitation period for claims (reduced from the previous ten years).

Three years — for claims for periodic payments and claims connected with running a business.

Also important is the rule in the second sentence of Article 118: the end of the limitation period falls on the last day of the calendar year, unless the period is shorter than two years. In practice this means that data kept “until claims become time-barred” is usually best retained until the end of the calendar year in which the period expires. Specific statutes may, however, provide different, shorter periods (for example, one year for certain transport claims), so the limitation period is always determined for the specific type of claim.

Retention of Data Based on Consent and Legitimate Interest

Not all data has a statutory “counter”. For many purposes, the retention period is set by the legal basis of processing itself.

Consent. Data processed on the basis of consent (for example, a newsletter or email marketing) is kept until consent is withdrawn. After withdrawal, processing for that purpose must stop and the data must be deleted, unless another basis exists (for example, evidence of the consent previously given, kept for accountability purposes).

Legitimate interest. Where processing is based on legitimate interest, the retention period should follow from the Legitimate Interest Assessment (LIA) and end when the interest is no longer current — for example, direct-marketing data is kept until the individual effectively objects.

Recruitment. Candidate data is kept until the given recruitment ends; if the candidate has consented to future recruitment processes — for a clearly defined, limited period or until consent is withdrawn.

How to Set a Retention Period Step by Step

To set a retention period for a specific activity, it is worth going through six steps:

1. Identify the purpose of processing. Each purpose is analysed separately — the same data may be processed for several purposes with different periods.
2. Establish the legal basis. The basis often determines the retention logic (contract, legal obligation, consent, legitimate interest).
3. Check specific legislation. Is there a statutory retention obligation (tax, accounting, labour law)?
4. Account for limitation periods. How long are claims relating to this processing possible?
5. Set the longest justified period. For a given category, the longest applicable period usually governs; once it expires, further storage loses its basis.
6. Plan deletion or anonymisation. Define when and how the data will be permanently deleted or anonymised.

Retention Policy and Schedule

It is worth recording the results of this analysis in a retention policy and a retention schedule — a document that, for each category of data, sets out the purpose, legal basis, retention period, the moment the period starts to run and the method of deletion. The retention schedule naturally links to the record of processing activities (ROPA), which states, among other things, the envisaged deletion deadlines for each category of data.

Below is a simple retention schedule template. For each entry, complete all columns:

Retention schedule template — columns:

• Data category / process (e.g. order data, employee records, newsletter database)
• Purpose of processing
• Legal basis (Article 6(1)(…))
• Retention period
• When the period starts to run (e.g. end of year, end of employment, withdrawal of consent)
• Method of deletion (permanent deletion / anonymisation)

Sample entries:

Accounting documents and invoices — purpose: tax and accounting obligations; basis: Article 6(1)(c); period: 5 years; start: from the end of the year in which the tax payment deadline fell; deletion: permanent.

Order fulfilment data — purpose: contract performance; basis: Article 6(1)(b); period: duration of performance + limitation period for claims; start: from completion of the contract; deletion: permanent or anonymisation for statistics.

Employee records (hired from 2019) — purpose: employer obligations; basis: Article 6(1)(c); period: 10 years; start: from the end of the year in which employment ended; deletion: permanent.

Newsletter database — purpose: marketing; basis: Article 6(1)(a) (consent); period: until consent is withdrawn; start: from sign-up; deletion: permanent after withdrawal (retaining proof of consent for accountability).

CCTV recordings — purpose: safety of persons and property; basis: Article 6(1)(f); period: up to 3 months; start: from the date of recording; deletion: automatic overwriting.

Deletion and Anonymisation after the Period Ends

Setting a period is only half the task — the data must actually be deleted once it expires. It is best to automate this process (for example, automatic overwriting of recordings, periodic database clean-ups, account deletion procedures). An alternative to deletion is anonymisation: if data is irreversibly stripped of features that allow identification, it ceases to be personal data and can be used further, for example for statistics. Pseudonymisation is not the same as anonymisation — pseudonymised data remains personal data. Deleting data after the retention period ends is also a frequent consequence of exercising the right to be forgotten, where the individual themselves requests erasure.

Common Mistakes

Keeping data indefinitely “just in case”, with no defined period or criteria.

No retention schedule or policy describing the periods for each category.

A vague statement in the privacy notice (“for the period necessary”) without specific periods or criteria.

Failing to delete data after the period ends — the set period exists only on paper.

Confusing pseudonymisation with anonymisation and treating pseudonymised data as deleted.

Premature deletion of data needed for tax purposes or to defend against claims.

Checklist — Data Retention Periods

1. Inventory all purposes and categories of processed data.
2. Establish the legal basis of processing for each purpose.
3. Check the applicable specific legislation (tax, accounting, labour law).
4. Determine the relevant limitation periods for claims.
5. Set the longest justified period for each category.
6. Write down a retention policy and a retention schedule.
7. Link the retention periods to the record of processing activities.
8. State specific periods or criteria in your privacy notices.
9. Automate deletion or anonymisation once the period ends.
10. Schedule a periodic review of the retention policy.

Need Help Setting Your Data Retention Periods?

A retention policy is one of the pillars of GDPR compliance — and one of the most frequently neglected areas. At the Law Office of Dr Joanna Maniszewska-Ejsmont, we help set retention periods for all processes, prepare a retention policy and schedule, and link them to the record of processing activities and privacy notices.