Open source helpdesk for GDPR requests

How an open source helpdesk for GDPR data subject requests meets the one-month rule

Data subject requests rarely arrive through a dedicated form. They come in as ordinary emails to a support address, as web form submissions, or as a short message to an agent who has no idea a clock has started. Under Article 12(3) of the GDPR, the controller must act on the request without undue delay and within one month of receipt. A self-hosted helpdesk such as Zammad can route, time and record these requests so they are not lost in a general queue, but the legal obligations stay with the controller. The platform does not decide whether a request is valid, what data may be disclosed or whether an erasure ground applies.

Two parts of the one-month rule need explicit handling in the design. The first is the extension: the period can be extended by two further months for complex or numerous requests, but only if the data subject is told of the extension and the reasons within the first month. The second is refusal. If the controller does not act, it must explain why within the same month and tell the data subject about the right to complain to a supervisory authority and to seek a judicial remedy (Article 12(4)). Configure a ticket type or tag for data subject requests, set a due date at intake, and create a separate escalation step for the day before the deadline, so an extension notice or a refusal letter is a planned task rather than an emergency.

DeployOpen plans, implements and hardens the helpdesk, including the routing rules, timers, roles and retention settings your process depends on, and prepares the evidence that shows how requests were handled. It does not issue audit reports, attestations or certifications, and certification under Article 42 is voluntary and does not reduce the controller's responsibility. Before scoping, confirm with your data protection officer which request types the helpdesk will handle, who holds the authority to refuse, and which records your supervisory authority would expect to see. Those decisions set the scope of the implementation.

Which GDPR requirements a helpdesk for data subject requests must meet

This table maps each supplied GDPR requirement to what the helpdesk must do and how to configure it in self-hosted Zammad. Read each row as a starting point for design, not as legal advice. The controller must confirm the final mapping with its data protection officer before go-live.

Requirement	What the helpdesk must do	Zammad configuration to consider
Article 12(3): one-month response rule	Act without undue delay and within one month of receipt. An extension of two further months is possible only if the requester is told within the first month, with reasons.	Use a request ticket type with a due date set at creation, a reminder before the deadline, and an escalation to the data protection lead for extension decisions.
Article 12(4): refusals and explanations	If no action is taken, explain why within one month and state the right to complain to a supervisory authority and seek a judicial remedy.	Create a notification template for refusals containing the reasons, complaint and judicial remedy wording approved by legal counsel, and a required closure reason on the ticket.
Article 15(1): right of access	Confirm whether personal data are processed and provide access, purposes, categories, recipients, retention, source and automated decision-making information.	Build a request workflow with a checklist for each information item, linked to the requester's customer record and to the ticket history.
Article 15(3): copy of the data	Provide a copy of the personal data undergoing processing. Answer electronic requests electronically unless the requester asks otherwise.	Export the response as a commonly used electronic format from a controlled storage location, and confirm how attachments are included or referenced.
Article 12(3): electronic delivery	Where the request arrives electronically, provide information electronically where possible, unless the requester asks for another form.	Set the reply channel on the request ticket to match the intake channel, and record any requested alternative format in the ticket.
EDPB Guidelines 01/2022: search all systems	Search all IT and non-IT filing systems using criteria that mirror how the data are structured, such as name and customer number.	Enable Elasticsearch for faster search, including attachment content, and document which mailboxes, groups and external systems are searched manually.
Article 17(1): grounds for erasure	Erase without undue delay where one of six grounds applies, including consent withdrawal, a successful objection or unlawful processing.	Record the erasure ground on the request ticket and link it to the data retention decision before any deletion job runs.
Article 17(2): data made public	Where data were made public, take reasonable steps, including technical measures, to inform other controllers about erasure of links, copies or replications.	Keep a register of public-facing content linked to customers, such as knowledge base articles, and add a task to notify third parties when erasure is approved.

How to run a request from intake to closure in Zammad

This sequence turns an incoming access or erasure request into a documented, time-tracked case that can be answered and defended later. Each step produces a record in Zammad, so the team can show what was verified, searched, released or deleted, and when.

Classify the request type on intake
Set up a dedicated group or inbox for data protection requests so they do not sit in general support queues. The agent who first reads the ticket decides whether it is an access request under Article 15, an erasure request under Article 17, or another right such as rectification or objection, and sets a request-type field. Confirm the type with the requester in the ticket if it is unclear. Done means the ticket carries a request type, an owner and a note of the channel it arrived through.
Verify the requester's identity before release
Before any personal data is disclosed or deleted, check that the person asking is the data subject or someone authorized to act for them. Compare the request against the account or customer record, and ask for additional proof only where the risk of a wrong disclosure justifies it. Keep the verification method and outcome as an internal note on the ticket. Done means the ticket records what was checked and who approved it, and no data has left the system yet.
Record the receipt date and start the clock
The controller must act without undue delay and within one month of receipt, so the receipt date is the anchor for the whole case. Zammad stamps each ticket with its creation time, but confirm that your email intake and any forwarded requests keep the original receipt date, and note it in a dedicated field. If the request needs more time, the extension is available for complex or numerous requests only, and the requester must be told of it, with reasons, within the first month. Done means the due date is visible on the ticket and the team knows when an extension notice would have to go out.
Search every system that holds the person's data
Search beyond the helpdesk. Access requests must cover all IT systems and any non-IT filing systems that hold the person's data, using identifiers that match how the data is structured, such as name, email address and customer number. In Zammad, use search and the Elasticsearch index where it is deployed, including attachment content, then query the CRM, billing, product and backup-adjacent sources your organization has confirmed in scope. Log each system searched and the result. Done means a search log exists for every source, including the ones that returned nothing.
Prepare the copy or the erasure action
For an access request, collect the personal data and the information listed in Article 15(1), such as purposes, recipients, retention and source, and prepare a copy of the data undergoing processing. For an erasure request, check the Article 17(1) ground that applies and whether any legal obligation to retain overrides it. If the data was made public, consider the steps required by Article 17(2). Have a second person review the package before release. Done means a reviewed package or a documented erasure plan sits in the ticket, with any exemption reasoning written down.
Send the response electronically where requested
Where the request was made electronically, provide the information electronically where possible, unless the data subject asks for another form. Send the copy through the ticket reply or a secure download link that you control, and avoid unencrypted attachments for large or sensitive sets. For erasure, send confirmation once the deletion is complete. If the controller is not acting on the request, the reply must explain why within one month and name the right to complain to a supervisory authority and seek a judicial remedy. Done means the outgoing message is stored on the ticket with its delivery method.
Close with a record of the decision
Before closing, add a final internal note stating the outcome, the dates of receipt and response, the systems searched, the verification result, any fee or extension decision, and any exemption applied. Confirm that erasure was carried out in the systems listed and that the ticket reflects it. Keep the record under your retention schedule so it can be produced to an auditor or supervisory authority. Done means the ticket is closed with a complete decision record that someone outside the team can follow.

Why identity checks come before any personal data leaves the helpdesk

An access or erasure request sent from an email address is not proof of who sent it. If an agent replies with a customer's ticket history, attachments or account data to a spoofed or compromised mailbox, the disclosure itself is the breach, and the controller remains responsible for it. Identity verification therefore belongs in the ticket workflow before any personal data is searched for, exported or attached. In Zammad, a practical design is a dedicated request category or tag for data subject requests, a state that holds the ticket until verification is recorded, and a verification macro that asks for a defined proof. Typical options include confirming a reference already held on the account, a one-time secure download link to a portal the customer logs into, or a call-back to a number already on file. Each option needs its own handling rule, and the reader should decide which ones are acceptable for their data.

The verification standard itself is a legal and DPO decision, not a helpdesk setting. How much proof is proportionate depends on the sensitivity of the data, the customer base and what the controller already holds, so the reader should confirm the standard with counsel and the data protection officer before configuring anything, and record the decision as a written procedure. On the technical side, confirm which Zammad features apply to the customer base. Zammad supports third-party login through SAML, OpenID Connect and other providers, which can help when requesters are logged-in customers whose identity is already established by the identity provider. That route does not cover people who have no account, so a separate procedure is still needed for them. Check the Zammad third-party applications documentation against the identity provider in use before relying on it.

Keep the verification evidence with the request. Record what was checked, by whom and when, and set the verification outcome as a ticket field or note, so the one-month clock under Article 12(3) can be tracked from receipt and any refusal or extension can be justified. Rejected requests should also be documented, since the controller must explain the reason within one month. Illustrative example: a request arrives from an address that does not match any customer record, the ticket moves to a pending state, the agent sends the verification macro, and the outcome is noted before any search begins. The reader should test this path with a staff-only sandbox ticket before go-live.

Which open-source helpdesk fits a GDPR request queue

A GDPR request queue depends on search across ticket history, attachment handling, identity verification and a clear audit trail. The cards below compare the three open-source helpdesks in the supplied research and explain why this page is built around Zammad, with the checks to run before choosing FreeScout or osTicket.

Zammad as the reference platform

Zammad is licensed under AGPL-3.0 and is the platform this page is built around. Its search, ticket history and third-party login options cover the core needs of a request queue. Confirm the current release and security update status before any deployment, since security releases were published on both the 6.5 and 7.x lines in October 2026.

Zammad infrastructure requirements

Zammad stores its content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime websocket communication. Elasticsearch is optional but strongly recommended, because it powers faster search and searching of email attachment content. Memcached is needed for multi-instance deployments such as containers or cluster nodes. Plan these components together, because search completeness for access requests depends on them.

Elasticsearch for access request search

Access requests must be searched across all systems using the identifiers the organization uses, such as name and customer number. Elasticsearch in Zammad supports faster search and attachment content search, which matters when a data subject's details sit inside email attachments. Confirm with your own tests that searches on these identifiers return complete results before relying on them for a response.

FreeScout as a lighter option

FreeScout is licensed under AGPL-3.0 and its current version is 1.8.248. It is a shared inbox style helpdesk that may suit a small team with low request volume. Confirm whether it offers the structured request handling, bulk export and deletion tooling your volume needs, and whether it can track response deadlines against the one-month rule.

osTicket as a ticket-first option

osTicket is licensed under GPL-2.0 and its current version is 1.18.4. It focuses on ticket tracking for support teams and may fit simple intake from web forms. Confirm whether it supports identity verification workflows, full ticket history export for access requests and secure erasure of attachments before you select it for regulated personal data.

Testing the request queue before choosing

Whichever platform you evaluate, run a test queue with sample access and erasure requests. Check whether all related tickets, comments, attachments and customer records can be found and exported in a commonly used electronic form, and whether deletion removes copies, not just the visible ticket. Ask the vendor or partner to document each result so the evidence supports your choice.

What auditors and supervisory authorities ask for from a GDPR request helpdesk

This table lists the records an assessor or supervisory authority is likely to ask for when reviewing how a self-hosted Zammad helpdesk handled data subject requests. Each row names the component that produces the evidence and where it usually sits, so you can check coverage before an inspection. The controller decides what to retain, how long, and who may access it, so treat the table as a starting inventory rather than a fixed list.

Evidence item	Producing component	What the reader should confirm
Request register with receipt dates	Zammad ticket history, with the created and first-response timestamps on each request ticket	Receipt dates are recorded from the day the request arrives, and the one-month clock is tracked per ticket
Identity verification records	Zammad ticket notes and attachments, with agent actions in audit or admin logs	What checks were made, by whom, and that the verification record does not copy more data than needed
Search logs showing the systems searched	Ticket notes listing each system queried, plus Zammad audit logs for agent searches	Search criteria match how the data is structured, such as name and customer number, as the EDPB guidelines describe
Copies of responses sent	Outbound emails stored in Zammad ticket history, backed up in PostgreSQL backups	Responses are retrievable as sent, and electronic answers follow the requester's chosen form
Extension notices	Ticket notes and sent emails showing the extension and its reasons, sent within the first month	The notice was sent within the first month of receipt and states the reasons for the two-month extension
Refusal letters with complaint and judicial remedy information	Sent emails in Zammad ticket history, with a reference to the ticket number	Each refusal explains why, within one month, and gives the complaint and judicial remedy information
Erasure confirmations and third-party notices	Ticket notes and sent emails, plus change records for deletion or anonymization jobs in the database	Deletion covers backups and copies where required, and any notices to other controllers are logged
Patch records for Zammad releases	Change records and upgrade logs, including Zammad 7.2.2 (October 8, 2026) and parallel security release 6.5.5 (October 15, 2026)	Each security release applied on your running line is dated, approved, and tested against your environment

How to handle access and erasure requests in a helpdesk

An access request under Article 15 has two parts. The first is confirmation of whether personal data are processed. The second is a copy of the data and the information listed in Article 15(1), including purposes, categories, recipients (especially in third countries), retention periods, the source of the data and any automated decision-making. In a helpdesk, the personal data sit in more places than the ticket body: customer records, previous tickets, attachments, notes, merged tickets and any linked systems. EDPB Guidelines 01/2022 expect the search to cover all systems using criteria that match how the data are structured, such as name and customer number.

Request tag and due date: Tag the ticket with a dedicated access tag (for example, dsar-access) and record the receipt date so the one-month clock under Article 12(3) is visible in every view.
Macro for confirmation and copy: Build a macro that acknowledges receipt, asks for identity verification and states that the copy will be provided electronically unless the requester asks otherwise.
Saved searches by identifier: Create saved searches on the email address, customer number and name variants so an agent can find every ticket, user record and article tied to the person.
Attachments and exports: Export the ticket history and attachments into a secured folder on your own storage, and note in the ticket where each part was delivered. Any further copy may carry a reasonable fee under Article 15(3).
Retained record: Keep a note of the search criteria, the systems searched and the date the response was sent.

Before relying on this workflow, confirm with your privacy team which systems outside Zammad, such as the CRM or billing platform, hold the same person's data and how they will be searched.

Article 12(3) allows the one-month period to be extended by two further months for complex or numerous requests, but only if the data subject is told of the extension and the reasons within the first month. Article 12(4) requires the controller that does not act on a request to explain why within one month and to inform the data subject of the right to complain to a supervisory authority and to seek a judicial remedy. In a helpdesk, the risk is that a refusal or extension is sent as a casual reply by an agent, with no record of the reasoning or the deadline.

Extension status field: Use a ticket state or tag such as dsar-extended and a dated internal note stating the reasons, so the extension is visible to the whole team.
Refusal macro: Create a reviewed macro that gives the reason for not acting and includes the complaint and judicial remedy information required by Article 12(4).
Escalation rule: Route complex or disputed requests to a privacy queue with restricted agent access, using a trigger on the request tag.
Overview search: Build a saved search that lists open requests by deadline, so the team sees any request approaching the one-month point.
Decision log: Retain the internal decision, the approver and the date, separate from the customer conversation.

Ask your privacy counsel to approve the wording of extension and refusal macros before go-live, and confirm how your Zammad roles and permissions limit who can see these tickets.

Questions buyers ask before hiring help for GDPR requests in Zammad

How much does it cost to run Zammad for GDPR requests?

Self-hosted Zammad has no license fee, so the cost is the infrastructure you run it on, the implementation work and any support you buy. Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Those subscriptions are paid to Zammad, not to DeployOpen. Implementation is quoted separately from a written scope, and hosting, storage and staff time recur every year. Ask any partner for a quote that separates one-time setup from recurring hosting and support.

What drives the effort of a GDPR request setup in Zammad?

The main drivers are the number of systems that hold personal data and must be searched, the volume of requests, how identity is confirmed, and whether you are migrating existing tickets. Each system outside Zammad that holds customer data adds search criteria, access rules and testing. Identity integration through SAML or OpenID Connect adds configuration and review. Migrating from Freshdesk, Kayako, OTRS or Zendesk, which Zammad has migrators for, adds mapping and validation of history. Ask for the scope to list each system, each channel and each migration source explicitly.

How long does it take to set up GDPR request handling in Zammad?

The timeline depends on the scope, and DeployOpen agrees it in writing before work starts. The scope sets the number of systems to connect, the identity and channel configuration, any migration, the testing of search and erasure steps, and the procedure documents your team needs. Confirm with a prospective partner which deliverables are in the fixed scope, which dates depend on your input, and what happens if your reviews take longer than planned. Do not accept a duration that is not tied to a written list of deliverables.

Can our team set up GDPR request handling in Zammad alone?

A capable administrator team can install Zammad using the documented package, Docker Compose or Helm chart options, but the GDPR part is more than installation. It requires a documented procedure for the one-month response period, a search plan that covers every system holding personal data, a way to confirm identity, and tested erasure steps. Zammad documents PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, and Elasticsearch is optional but strongly recommended for search. Teams without spare platform and privacy capacity usually bring in a partner for the build and keep the process ownership in house.

What do we need to provide for a GDPR helpdesk implementation?

You need named process owners who decide how requests are classified and answered, input from your data protection officer on lawful handling and exemptions, and administrative access to the systems that hold personal data so they can be searched and corrected. You also need a list of data sources, existing ticket exports, the identity provider settings and staff who will work the queue. Without these inputs the search criteria, retention rules and erasure steps cannot be finalized. Ask the partner to name each input and the person who provides it in the written scope.

Does DeployOpen issue GDPR certification or audit reports?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. The GDPR itself requires no audit or certificate. Article 42 certification is voluntary and is issued by accredited certification bodies or supervisory authorities, and it does not reduce your responsibility for compliance. Ask your data protection officer which evidence your supervisory authority or auditor will expect, and treat any partner who offers a certificate as a warning sign.

What does DeployOpen cover in a GDPR request engagement?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For this use case, that can include the Zammad installation, identity and channel integration, search configuration, the request procedure and its documentation, and evidence preparation for your assessments. Engagements are usually fixed-scope, and ongoing support or upgrades can be added as a retainer. Your legal and privacy decisions remain with your organization.

What the helpdesk cannot settle on its own

Zammad can hold the request, the identity check and the reply, but several decisions sit outside the ticketing tool. The cards below cover the legal judgment, the search across other systems, backups and logs, the request register, staff access and the processor relationship with any host.

The legal decision on each request

Zammad records what was asked and when, but it does not decide whether an access or erasure request must be refused in whole or part. Erasure has to be checked against the grounds in Article 17(1) and any legal retention duty, and refusals must explain the reasons and the complaint routes. Document who made each decision and on what basis, and have counsel review the template replies.

Search across non-helpdesk systems

The EDPB's Guidelines 01/2022 require the controller to search all IT systems and non-IT filing systems, using criteria such as name and customer number. A ticket history is only one source, so ERP, HR, billing and marketing tools also need a documented search procedure. Check each system's search keys and record which were searched for every request.

Deletion from backups and logs

Erasing a record in Zammad does not remove copies held in database backups, search indexes, attachment stores or application logs. Define how long backups persist, whether erased data is restored from them, and how erasure is applied after a restore. Ask your partner to document this so the controller can explain the position to the data subject.

Retention of the request register

The record of each request, including the identity check and the decision, is itself personal data. Set a retention period for that register that is shorter than the ticket history it refers to, and state the justification. Confirm that the Zammad deletion job or a manual process removes the register entries on schedule.

Agent training and access controls

Agents see customer data across tickets, so access must follow the need to know. Restrict the group and role that can view identity documents or erasure queues, and log their actions. Train agents on verifying identity before disclosure. The EDPB's February 18, 2026 findings on erasure and January 20, 2025 findings on access both point to staff handling as a recurring gap, so review them with your team.

Processor contract with the host

If a hosting provider, managed service or support partner can reach the Zammad database, attachments or logs, a processor agreement under Article 28 is needed, and it should set security measures, sub-processors and deletion at contract end. Confirm the data location and the audit rights the contract gives you. Self-hosting in your own infrastructure reduces, but does not remove, these questions.

What changes for cross-border enforcement and pending GDPR amendments

The GDPR text is unchanged as of October 2026, so plan your request handling against the current articles. Regulation (EU) 2025/2518 adds procedural rules for complaints and investigations in cross-border enforcement cases, and it applies from 2 April 2027. It does not change the one-month response rule in Article 12(3), the access content in Article 15 or the erasure grounds in Article 17. Two proposals are still in progress: Omnibus IV (procedure 2025/0130(COD)), with a text agreed in negotiations on 26 June 2026 that still awaits Parliament's first-reading vote, and the Digital Omnibus (procedure 2025/0360(COD)), which is awaiting a committee decision. Neither should delay the design of your ticket workflows. Confirm the current status of both procedures on the European Parliament's Legislative Observatory before each quarterly review of your data protection program.

Build the helpdesk so that any request record can be produced to a supervisory authority in any Member State where you operate. Under the GDPR, the supervisory authority is national, so a request that reaches one of your mailboxes in Spain may be examined by a different authority if your main establishment is elsewhere. In Zammad, this means each request is a ticket with a stable number, the original message and attachments, timestamps for receipt, extension notices and the response, plus a log of who viewed or changed the record. Ask your implementation partner to show how a full case export is produced, how it is labeled by group and country, and how it is kept in a read-only archive. Also confirm which legal counsel will review the process when the Regulation (EU) 2025/2518 procedures begin to apply.

How DeployOpen scopes, delivers and supports GDPR request handling in self-hosted Zammad

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so GDPR request handling in Zammad runs on systems you control. We start from the written scope of your request types, channels and systems, then build, test and hand over the workflow with the evidence your compliance team needs.

How we scope

Engagements are fixed-scope, with the request types, channels, systems and deliverables agreed in writing before work starts.
We map which systems hold personal data for access and erasure searches, including attachments, linked records and non-ticket sources.
We confirm with you who owns identity verification, the one-month clock, extension decisions and sign-off on erasure exceptions.

How we build

We configure Zammad ticket states, groups, macros and SLA triggers so data subject requests are separated from routine support tickets.
We set up identity check steps, secure intake for requests and attachment storage on your own infrastructure.
We test access exports and erasure runs against sample tickets, including how attachments and history are handled, before go-live.

How we hand over

You receive written documentation of the configured workflow, roles, search criteria and the steps each request follows.
We prepare the control and evidence records your compliance team and independent assessors would review, without issuing any attestation ourselves.
We walk your agents and privacy staff through the runbook and the escalation path for requests that need legal review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
We apply Zammad security and minor releases to your environment and retest the request workflow after each upgrade.
We review the search and erasure procedures when guidance or your data landscape changes, and agree any change in writing.

Open source helpdesk for GDPR data subject requests