Cyprus GDPR retention schedule: records, deletion and legal holds

Start with record categories rather than a universal period

List the main records held by each business function and what they are used for. Separate customer account information, invoices, recruitment files, employee records, support tickets and technical logs where their purposes differ. A broad folder called “administration” is unlikely to provide enough detail for a meaningful rule. Begin with categories that staff can recognise in the systems they actually use.

The Commission explains storage limitation by reference to the purpose and any applicable legal obligation. A requirement affecting one category does not automatically justify retaining every associated document for the same period. Equally, closing an account does not automatically remove a duty to preserve a particular required record. Identify the actual reason for continued retention rather than choosing whichever period sounds safest.

Ask each department to name an owner who can explain its records and workflow. Include paper files, exports and shared mailboxes where relevant. The first inventory does not need to reproduce every field in every system, but it should reveal material categories and their locations. Record gaps so an unknown archive does not disappear from the project simply because it has no obvious owner.

Basis and guidance: European Commission: GDPR principles and storage limitation

Verify the legal requirement and the business purpose separately

For a proposed statutory retention rule, identify the actual provision, the records it covers and the event from which the period runs. Check whether a sector-specific obligation applies to the organisation. Avoid copying a period from another business’s policy without verifying its scope. Keep the source or professional assessment with the schedule so the reasoning can be checked when the rule is reviewed.

For records retained for an operational purpose, explain what continuing use requires identifiable information and for how long. “We might need it” is not a useful conclusion by itself. A support history needed for an active issue may have a different justification from an old export retained on a laptop. Consider whether a smaller set of information would meet the continuing need.

Separate a duty to retain records from a possible need to establish or defend a legal claim. The relevant facts and requirements need assessment, rather than a blanket assumption that all material should be held indefinitely. Escalate uncertain categories to an appropriate adviser and record the outcome. Do not invent a Cyprus-specific period where the applicable category or legal basis has not been established.

Define the start event and the action at the end

A period is incomplete without a clear starting event. Identify whether the rule runs from creation, closure of a matter, termination of a relationship, the end of a relevant reporting period or another justified event. Use the event required by the applicable rule and explain it in operational terms. A system cannot apply a policy reliably if staff interpret the start date differently.

Determine where the trigger date is stored and who can change it. If a record lacks that date, establish how the uncertainty will be resolved instead of allowing it to remain outside every deletion run. Consider reopened matters and corrections without assuming that any new activity automatically restarts the whole period. Preserve a reasoned treatment for exceptions and verify it against the underlying requirement.

Specify the end action: delete, securely destroy, genuinely anonymise or review for a defined reason. A recurring review should reach a decision rather than postpone deletion indefinitely. If different components require different treatment, state that explicitly. For example, the organisation may need to preserve a particular transaction record while removing unrelated attachments that no longer have a justified purpose.

Build a schedule that the operating teams can use

Give each row enough information to connect the legal or business decision with implementation. Include category, purpose, responsible owner, location, trigger, period or criterion, end action and the supporting reason. Link detailed advice where necessary. Keep the main schedule readable so staff can find the applicable rule without searching through an unrelated legal memorandum.

The table below describes fields to complete rather than prescribing retention durations. The business must determine those durations for its own records and obligations. A practical schedule can contain different rules for subsets of one system, provided those subsets can be identified reliably. Ask the technical owner whether the proposed distinction can actually be implemented and tested.

Use version control or a dated change record appropriate to the organisation. Show when a rule changed, why and which records are affected. Review the consequences before applying a new rule to an existing archive. A policy update should lead to implementation work where necessary; changing a date in a document does not change the records held in a supplier’s platform.

Translate the rules into system actions and test them

Work with the people who administer each system to identify deletion settings, export locations and integration behaviour. A retention option may affect visible records while leaving attachments or linked objects untouched. Use safe test records to understand the result before running an irreversible action on live information. Confirm how the process handles records that fail or cannot be matched to a rule.

Design an implementation check that verifies more than a successful job status. A completed task can still have selected the wrong category or left additional copies behind. Record the rule version, relevant date and outcome at an appropriate level. Keep enough evidence to demonstrate the action without unnecessarily reproducing the personal data that the process was intended to remove.

Give failures a responsible owner and a route for correction. If a system cannot support the required action, document the limitation and assess a practical solution. Do not silently substitute indefinite retention for a failed automation. Include manual stores such as paper files and downloaded spreadsheets in the operating instructions, with suitable secure disposal steps for the material involved.

Include processors, exports and connected services

Identify which suppliers hold records on the organisation’s behalf and what assistance is needed to apply the schedule. Check the actual return and deletion arrangements in the contract and service documentation. A promise to delete the main account may not explain the treatment of support attachments or backups. Ask specific questions tied to the categories and service configuration in use.

Map regular exports and integrations. A report copied from the CRM into a shared drive can outlive the source record unless the process accounts for it. Establish whether the copy remains necessary, who owns it and how the applicable rule will be enforced. Avoid treating every export as a new record with a fresh retention period merely because it was downloaded later.

When replacing a supplier, include retention and deletion in the exit plan. Verify what has been returned, what must remain for a justified reason and what should be removed. Preserve appropriate confirmation and unresolved issues. Keep responsibility assigned during the transition so the old service does not become a forgotten archive after the new system starts operating.

For the related process, see the processor-agreement guide.

Address backups and restoration explicitly

Understand how backups work before making promises about deletion. Identify their purpose, access restrictions, lifecycle and restoration process. A backup used for recovery differs from an archive routinely searched by staff. Document that distinction and check it in practice. Keeping a second active copy under a “backup” label does not answer the question of why the information remains necessary.

The EDPB’s 2026 report highlights difficulties with erasure in backups and the importance of appropriate procedures, including after restoration. Technical integrity concerns can affect the approach to modifying backups. They do not justify ignoring the issue. Work with technical and privacy advisers on an arrangement appropriate to the system and obligations, and avoid promising a universal deletion method or deadline.

Test the restoration scenario with safe sample records. If information removed from the active system reappears after recovery, establish how the relevant action will be reapplied before ordinary use resumes where appropriate. Keep the process understandable to the recovery team. The people restoring service should not have to discover the retention requirements during an urgent incident.

For the related process, see the breach-response guide.

Basis and guidance: EDPB 2025 coordinated enforcement report on erasure, adopted February 2026

Assess erasure requests and specific preservation needs

An individual’s erasure request needs its own assessment; do not simply respond that the standard schedule has not expired. Identify the applicable grounds and exceptions and explain the outcome as required. Conversely, a request does not automatically require destruction of a record that must lawfully remain. Separate the information and purposes so a justified exception does not become a refusal covering everything.

Where a specific preservation need affects normal deletion, define the material, reason, responsible person and review arrangements. Obtain suitable advice for a legal hold and limit it to what the circumstances require. Communicate the instruction to relevant system owners and suppliers. A hold should be discoverable by the deletion process rather than buried in an email to one employee.

Review whether the hold remains necessary and document its release. Reassess the normal rule at that point rather than automatically starting a new full retention period. Keep the record of the decision proportionate and separate from unnecessary copies of the underlying material. Coordinate related access or restriction requests so different teams do not give contradictory instructions about the same records.

For the related process, see the access-request handling guide.

Basis and guidance: EDPB: respecting individuals’ rights

Example: separating an account from its transaction records

Consider a hypothetical customer closing an online service account. The platform holds profile fields, invoices, support attachments and marketing preferences. The business first identifies which records have distinct continuing purposes or obligations. It does not assume that the account closure permits deletion of every transaction record, or that retaining invoices requires keeping the entire profile and every attachment.

The schedule maps the relevant categories to their rules and locations. The team discovers that monthly customer exports sit in a shared reporting folder with no deletion process. It checks whether those identifiable exports are still necessary and assigns the appropriate action. This step addresses a real implementation gap that would remain even if the primary account deletion button worked correctly.

The response to the customer describes the relevant outcome accurately, including any justified retained categories where required. The organisation avoids saying “everything deleted” if information remains under an applicable obligation. It also avoids a vague statement that all records must be kept for the longest period found anywhere in the business. The record of the decision explains the distinctions.

Keep notices, reviews and evidence aligned with practice

Explain retention periods or the criteria used to determine them in the relevant information provided to individuals. Match that explanation to the actual categories and process. A statement that information is held only as long as necessary is unlikely to help if the organisation itself has never determined what that means. Review notices when a material rule or processing purpose changes.

Check the schedule when introducing a new system, data category or purpose. Confirm that a supplier change or migration has not disabled an existing deletion process. Where a significant new activity requires a DPIA, include retention and deletion in the design review. Reuse verified facts from the schedule while assessing whether the proposed processing creates a different need or risk.

Keep a manageable review process that identifies overdue actions, failed jobs and unresolved categories. Follow each finding through to a verified outcome instead of treating the policy’s annual review date as completion. Zeno can coordinate independent professional and operational support to establish an appropriate schedule and implementation plan. The business should retain clear responsibility for applying and maintaining the resulting rules.

For the related process, see the DPIA planning guide.

Primary sources and scope

Sources checked: September 27, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• European Commission: GDPR principles and storage limitation
• EDPB: respecting individuals’ rights
• EDPB 2025 coordinated enforcement report on erasure, adopted February 2026