Subject access requests in Zoho Desk: the short answer
Subject access requests handled in Zoho Desk work best as a dedicated ticket process. Requests arrive through one intake channel. An authorised person checks identity. The ticket moves through fixed stages with a due date. The person's data is exported as a CSV file and the reply goes out before the legal deadline, which the ICO guidance explains.
A subject access request is a request from an individual to see the personal data you hold about them. The ICO notes that it is also known as a SAR or the right of access. Zoho Desk calls the wider category a data subject request (DSR). Zoho defines a DSR as a request from an individual to a data controller about the personal data held on them.
Zoho Desk has built-in handling for two types of request, according to Zoho's help article on addressing data subject requests:
- Right to Access, which gives the person a copy of their data.
- Right to Erasure, which deletes it.
The built-in tool does the extraction. It does not decide whether a request is valid, who may see it or when it is due. It also does not write the reply that goes with the export. Those parts are your process, and this guide sets them out step by step.
Controller, processor and data subject: who is responsible for a SAR
Your organisation, not Zoho, is responsible for answering a subject access request. You decide why and how the customer data in Desk is used, which makes you the data controller. Zoho's privacy FAQ also confirms that you own the service data you store in Zoho. Zoho acts as the data processor.
Three terms recur throughout this guide, so here they are in Zoho's own definitions:
- Data controller: the party that decides the purpose and means of processing personal data, meaning why and how the data is used.
- Data processor: an organisation that processes personal data on the controller's behalf and cannot change the purpose it was collected for.
- Data subject: the person whose personal information you collect, typically customers and employees.
The practical consequence is simple. Zoho supplies the tools to find and export a data subject's records in Desk. Your team owns the judgement calls: whether the request is genuine, what can be withheld and when the reply goes out. Zoho's help article also notes that GDPR applies to professional or commercial activity, not to personal or household activity.
The UK GDPR draws the same line. Any business running a support desk falls on the professional side of it.
A dedicated intake channel keeps SARs out of the shared support inbox
A dedicated intake channel is the single most useful control for subject access requests in Zoho Desk. A SAR that lands in a general support queue looks like any other email. An agent may answer it as a routine query, or it may sit unassigned while the deadline runs.
Set up one route for privacy requests and send everything there. In Desk, that usually means a separate department, for example "Privacy requests", with its own support address. Zoho's DSR tool is not department-specific, so a separate department does not stop authorised staff from processing the request. It simply keeps SAR tickets out of the everyday queue and away from agents who do not need to read them.
Email suits this channel. A Zoho Desk community tip makes the point that email is most useful when the customer wants to put things on record, which is exactly what a requester is doing. Publish the address in your privacy notice. You can also add a clear "how to request your data" route to your customer-facing site; our post on planning a help centre in Zoho Desk covers where such guidance fits.
Requests will still arrive elsewhere, by phone, in chat or in a reply to an old ticket. Train every agent to recognise them and move them into the privacy department the same day.
Identity checks before any personal data leaves Zoho Desk
An identity check confirms that the person asking for data is the person the data is about. Without one, a SAR process becomes a way for anyone to obtain someone else's records. Sending one customer's ticket history to an impostor is a data breach of its own.
Build the check into the ticket, not into an agent's memory. A workable sequence looks like this:
- Compare the requester's email address with the contact record in Desk.
- If the addresses differ, or the request comes from a third party such as a solicitor, ask for confirmation of identity or authority before you search.
- Record what you asked for, what you received and who approved it, as a private note on the ticket.
- Only then move the ticket to the search stage.
Ask only for what you need to be confident. Requesting excessive documents can look like obstruction. The ICO's brief guidance on SARs covers how to recognise and respond to a request, and its self-service tool answers specific questions. Check both before you fix your identity rules, rather than inventing a standard of your own. Write the agreed rule into a short internal procedure so every handler applies the same test.
Permissions: who may process data subject requests in Zoho Desk
By default, only the administrator can process data subject requests in Zoho Desk. Support agents with the Agent profile must ask the administrator for access. This default is sensible, because the DSR screen exposes everything Desk holds about a person.
To give named people access, the administrator edits their profile. Under the profile's Administrative Permissions column, the Manage Privacy Settings option can be enabled or disabled. Zoho's help article describes this switch as the control for DSR access.
Because DSR requests are not department-specific, anyone with that permission can process a request from any department. Choose the holders accordingly. A good pattern is a small, named group: a privacy lead and one deputy, so the process does not stop when one person is on leave.
Keep the permission off general agent profiles. The person who triages the ticket does not need to be the person who extracts the data. Separating the two roles means a mistake at intake cannot turn straight into a disclosure.
When Svennis sets this up for a client, we create a separate profile carrying Manage Privacy Settings and assign it only to the named privacy handlers. The failure we see most often is the opposite: the permission added to a shared agent profile during setup and never removed.
Tracking each subject access request as a ticket through fixed stages
A tracked SAR process gives every request the same stages, an owner at each stage and a record of when it moved. You can build the stages with a Blueprint in Desk or with ticket statuses. The tool matters less than the discipline of using the same stages every time.
The table below is a checklist you can map onto your own Desk setup.
| Stage | Owner | Done when |
|---|---|---|
| Logged | Any agent | Ticket sits in the privacy department with the date the request arrived |
| Identity confirmed | Privacy lead | Private note records the evidence and who approved it |
| Search | Holder of Manage Privacy Settings | Right to Access request run and CSV exported |
| Review | Privacy lead | Other people's data checked; any withholding decision recorded with reasons |
| Sent | Privacy lead | Reply sent securely with the CSV, a note on field names and the supplementary information; date noted on the ticket |
| Closed | Privacy lead | Ticket closed; DSR history in Desk shows the completed request |
The Sent stage of a SAR covers more than the CSV export. The reply also carries a short note explaining any field names. It includes the supplementary information the law requires: purposes, categories of data, recipients, retention, whether you use automated decision-making, and the safeguards for any transfer outside the UK. It also covers the person's rights, including how to complain to you and to the ICO, and the source of the data. A link to your privacy notice can cover most of it.
To make sure nobody misses a new request, use automation. Zoho Desk supports webhooks, which deliver information on help desk events such as a ticket being created or updated. A webhook on new tickets in the privacy department can alert the privacy lead wherever they work.
The SAR response deadline: take it from the ICO guidance and put it on the ticket
The response deadline for a subject access request is set in law, and the ICO's guidance is the place to read it. This guide deliberately does not restate the time limit. Take it from the ICO's subject access request guidance, together with the circumstances in which it can change.
Once you know the limit, turn it into a hard date on every ticket at the Logged stage. Count from the starting point the ICO guidance specifies, then write the due date into the ticket. A date on the ticket can be reported on and escalated. A date in someone's head cannot.
An SLA policy in Desk, scoped to the privacy department, can then do the chasing. Set reminders well before the due date, not on it, because review and secure sending take time after the export. Escalate to a manager automatically if the ticket has not reached the Review stage by the halfway point.
Two habits protect the deadline in practice:
- Never let a SAR wait in the Logged stage while identity is chased without a note of when you asked.
- Recheck the ICO guidance when it changes, and update the SLA to match.
Finding and exporting a person's data from Zoho Desk as a CSV
Zoho Desk extracts a data subject's records through its built-in privacy screen. The path is Setup > Privacy and Security > Data Subject Requests. From there, an administrator or an agent with Manage Privacy Settings raises a Right to Access request for the person.
When the request has run, the data appears as a request entry, and you export it as a CSV file. Zoho Desk also keeps a history of all data access requests executed in your organisation, with their status. Administrators and authorised agents can view that history at any time, which gives you an audit trail alongside the ticket.
Desk is rarely the only place a customer's data sits. If Desk is integrated with Zoho CRM, tickets a customer raises in different departments are linked to their CRM records. Zoho's integration settings let admins choose between showing CRM users tickets from all departments, which is the default, or only tickets from their own departments. Search CRM as part of the same SAR, and review that visibility setting while you are there. Firms running Desk alongside CRM, for example inside Zoho One, should list every app in scope on the ticket.
Keep the Delete Data option well away from access requests. Zoho states that deletion is permanent and the data cannot be recovered.
Worked example: one subject access request through Zoho Desk
This worked example follows a single, hypothetical subject access request from arrival to closure. A customer, here called Jane, emails your privacy address asking for all the personal data you hold about her.
- Logged. The email creates a ticket in the "Privacy requests" department. The webhook alerts your privacy lead. The agent on duty writes the arrival date and the due date, taken from the ICO guidance, onto the ticket.
- Identity confirmed. Jane wrote from the address on her contact record, and the privacy lead is satisfied. A private note records this and who approved it.
- Search. Your deputy, whose profile has Manage Privacy Settings enabled, opens Setup > Privacy and Security > Data Subject Requests. She raises a Right to Access request for Jane and exports the CSV. Because Desk is linked to Zoho CRM, she also notes Jane's CRM record on the ticket for the CRM search.
- Review. The privacy lead reads the export. One ticket names another customer. The lead checks the ICO guidance on withholding information and records the decision with reasons.
- Sent. The reply goes to Jane securely, with the CSV, a short note on field names and the supplementary information. The sent date is noted.
- Closed. The ticket closes. The DSR history in Desk shows the completed request.
Every decision sits on one ticket. If Jane complains later, you can show what you did and when.
What the ICO guidance means for a UK business using Zoho Desk
For a UK business, the ICO is the authority on subject access requests, and its guidance should shape your Desk process. The ICO states that the guidance on its SAR page is suitable for large businesses in the public, private and third sectors. Small businesses are directed to the resources on the ICO's small business web hub instead. Start from the one that fits your size.
Three ICO resources are worth building into your setup:
- Brief guidance, covering how to recognise and respond to a request, find and provide the information, and when you can withhold information or refuse a request.
- Detailed guidance, which covers health, social work and education information. Clinics, care providers and schools should read this before they finalise the Review stage.
- Staff training recordings on individual rights, including subject access, which the ICO makes available for you to reuse with your agents.
Know where your Desk data lives. Zoho's privacy FAQ says the data centre is chosen automatically from your IP address at sign-up, and you can identify it from the URL domain you use. Zoho has also appointed a Data Protection Officer, based at Zoho Corporation BV in Utrecht, which helps if you need to raise a processor question.
Next steps for setting up SAR handling in Zoho Desk
Setting up subject access request handling in Zoho Desk takes a few deliberate changes, most of them in settings you already have. Work through them in this order:
- Read the ICO's brief guidance, or its small business hub, and write down the deadline and your identity rule.
- Create a privacy department with its own address, and publish that address in your privacy notice.
- Create a profile with Manage Privacy Settings enabled and assign it to two named people.
- Build the six stages from the checklist table as a Blueprint or ticket statuses.
- Add an SLA scoped to the privacy department, with reminders well ahead of the due date.
- Run a test request on a staff member's own record, export the CSV and check what it contains.
- Prepare a reply template that carries the supplementary information alongside the export.
- Review the Desk and CRM ticket visibility setting.
The test request in step 6 is the one most firms skip, and it shows you what a real requester will receive. If you want a second pair of eyes on the configuration, our Zoho Desk implementation page explains how we set up departments, profiles and workflows. If you are still deciding who should help, read what a Zoho partner does first.
Sources
- ICO: Subject access requests (also known as SARs or right of access)
- Zoho Desk Knowledgebase: Addressing Data Subject Requests
- Zoho: Frequently Asked Questions on Privacy
- Zoho Desk API Documentation
- Zoho: Regulate Support Tickets' Visibility In Zoho Desk Integration
- Zoho Desk Community: Customer Feature Requests


