Zammad for GDPR erasure and retention

Deletion tasks and retention schedules solve different problems, and a compliant setup needs both. A Data Privacy deletion task answers one request about a specific person or record. The scheduler applies a time limit to a class of tickets. Erasure requests under Article 17(1) arrive case by case, while storage limitation under Article 5(1)(e) applies to whole categories of data. Plan both mechanisms before any ticket data goes live.

Treat each deletion task as a scoped operation with a known result. Before running one, confirm in the installed release which objects it removes, such as ticket content, customer profile fields, articles and attachments. Then record what remains: ticket numbers referenced from other tickets, audit entries that show who ran the deletion and when, attachment text in Elasticsearch indexes if it is enabled, and copies in backups that are not yet rotated. Your records of processing should state these residual locations and how long each one persists.

The scheduler handles retention by ticket type, and each period should follow from the purpose of processing, as Article 5(1)(e) requires. A billing dispute, a product question and a support chat do not share a purpose, so they should not share a period. Write one retention register that lists each ticket type, its purpose, its period and its trigger date, such as closure or last update. Keep that register outside Zammad so auditors can read it without access to the helpdesk.

Article 17(3) exceptions, including a legal obligation and the establishment, exercise or defence of legal claims, need a documented hold rule. Zammad cannot decide alone whether a dispute is live or a tax rule applies. Define who may place or lift a hold, which evidence starts it, how it is reviewed and how the scheduler and any pending deletion task respect it. Test that a held ticket is skipped by both mechanisms. Article 5(2) expects you to demonstrate this decision trail, so the hold register matters as much as the setting.

Verify the design on a copy before relying on it. Restore a recent backup to a separate instance, run one deletion task and one scheduled retention job against known test tickets, then search for the content, the attachments and the audit trail. Record each object that survived and decide whether the residue is acceptable. Repeat the test after each upgrade, since the set of objects a deletion covers can change between releases. Confirm the exact behavior with the vendor documentation for your release before going live.

Hosting a self-managed Zammad stack in the EU, in infrastructure your organization controls, removes one question: where the vendor's hosted service stores your data. It does not remove the Chapter V transfer question for the application data you hold. A transfer under Chapter V can still arise from several paths, and each one needs its own answer before you rely on EU hosting.

The most common paths are remote access from a third country, storage in a cloud region outside the EEA, backups replicated abroad, and identity providers outside the EEA. EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer even when the person only views data on a screen for support or administration, and that storage in a cloud outside the EEA is a transfer. For Zammad, that means checking whether an administrator, a support engineer or a managed service provider in another country can open tickets, customer records, or the database. It also means checking whether SAML or OpenID Connect sign-in sends user identity data to an identity provider outside the EEA, and whether Elasticsearch, Redis or PostgreSQL backups leave the region.

Zammad's hosted plans are run in a data center in Germany, according to the vendor's pricing page. That fact describes one processor relationship. The self-managed route creates a different one: your organization is the controller, and any hosting provider, backup service, managed database operator or consultant becomes a processor or sub-processor that you must assess. Ask the vendor and each provider for written statements on location, sub-processors and support access, and keep them in the processing record for the Zammad stack.

Two legal exposures need plain treatment. Article 48 of the GDPR says a third-country court order or administrative decision requiring disclosure of personal data is recognized or enforced only if it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. The US CLOUD Act, at 18 U.S.C. 2713, requires US-based providers to preserve or disclose data in their possession, custody or control wherever it is located. A provider with US control over your data can therefore be compelled, regardless of the server location. EDPB Recommendations 01/2020 (version 2.0) state that where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Encryption at rest does not solve that case if the provider holds the keys or operates the service.

Before deciding, map every component and every access path for the stack: the application servers, PostgreSQL, Redis, Elasticsearch, Memcached, file storage, backups and snapshots, mail servers and connectors, SSO providers, monitoring and logging, and each person or vendor with administrative or support access. For each path, record the location, the entity with control, and whether a third-country party can reach the data in clear text. Only then decide which paths are transfers, which need Chapter V safeguards or a transfer impact assessment, and which can be removed by changing the architecture.