Start free
Published: Last updated:

Help desk software and GDPR: a privacy checklist

Six questions to put to a supplier before signing: roles, data collected, where it is processed, retention, data subject rights and access logging.

Published by Oglut Srl, publisher of OglutTicket.

From a privacy point of view, a ticketing system is an archive of personal data that grows on its own: names, email addresses, phone numbers, and inside the conversations whatever a customer decided to write to you — including, now and then, information you would rather not have received.

That is why “is it compliant?” has no useful answer. The GDPR does not provide a badge a supplier can hold up on your behalf. It assigns responsibilities that stay yours, and the supplier either gives you the tools to exercise them or does not. The six questions below separate the two before you sign anything.

1. Who is the controller and who is the processor

Everything else follows from this. Towards your customers, you are the controller: you decide why and how their data is processed. The software supplier is a processor and acts on your instructions.

The practical consequence: there must be a data processing agreement between you and the supplier, and the privacy notice your customers read on the request form must be yours, not theirs. If a product shows your customers the notice of the company that built it, you are declaring that somebody else is the controller.

Ask for the list of sub-processors too: who hosts the infrastructure, who sends the email, and — an increasingly relevant question — whether an artificial intelligence provider receives the text.

2. What personal data a ticket collects

Write the list out, because it is longer than it looks: what the customer types into the form, the content of the messages, attachments, the addresses of anyone copied in, and technical metadata such as timestamps and access records.

Then ask the minimisation question, which almost nobody asks: does the public form require fields you do not need? A mandatory phone number on a request you answer by email is personal data collected for no reason, and it is the easiest part of compliance to fix.

3. Where the data is hosted and who can reach it

Three separate questions that suppliers tend to answer as if they were one:

  • Which region holds the database, the attachments and the mail service. Not “the cloud”: the name of the region.
  • Which sub-processors, and in which countries, because a transfer outside the European Economic Area needs a legal basis you must know and be able to cite.
  • Which of the supplier's staff can reach the data for maintenance, under what conditions, and whether that access is logged.

Ask for the answers in writing, or backed by public documentation: a verbal reassurance cannot be cited in a record of processing activities.

No supplier can be compliant on your behalf. It can give you the tools with which you are.

4. How long the data is kept

You set the retention period, based on the purpose, and you write it in your own privacy notice. There are two questions for the supplier: what happens to the data when the contract ends, and with how much notice; and whether data can be deleted selectively, without emptying the whole archive.

Be wary of “we keep everything forever”, which turns a support archive into a risk that grows every year. But be equally wary of automatic deletion nobody let you configure: a conversation that vanished while it was needed for a dispute is a different problem, and not a smaller one.

5. Answering a data subject request

Sooner or later a customer will ask for a copy of their data, or for deletion. The test to run during evaluation is very concrete: try it, during the free trial, on a fake but real requester.

  • Can one person's data be exported, or only the entire archive?
  • Is deletion permanent, or does it hide a row from a list?
  • Does it need a dedicated permission, or can anyone answering tickets do it?
  • Does it need them? If so, your answer to the data subject depends on the supplier's response time, and a month goes quickly.

6. Access, logging and attachments

Three technical checks worth more than several declarations. First: how people sign in. Passwords shared between colleagues are the most common weak link in a small company, and they outlive the resignation of the people who knew them.

Second: is there an unmodifiable record of who did what? Without one, “only the people who needed to read that conversation did” is not verifiable — it is a hope.

Third, the one almost nobody tries: are attachments reachable from a public address? Copy an attachment's address, open it in a window with no session and see what happens. If the file downloads, every link forwarded by mistake is a disclosure of data.

What no software can do for you

No product writes your privacy notice, keeps your record of processing activities, decides whether you need an impact assessment or sets your retention periods. No product stops an agent pasting into a ticket data they should never have collected, and no feature replaces the instructions you give the people who answer.

If you are offered a “GDPR certified” product, ask who issues the certificate and what its scope is: in most cases the answer is that no such badge exists. A supplier who is clear about what it does not do is a better signal than one declaring a compliance that is not theirs to declare.

What you can verify in OglutTicket

The answers, in the order of the questions. Towards your customers you are the controller, and each company puts its own privacy notice on its own public form. The infrastructure runs on Amazon Web Services in the European region of Frankfurt: database, attachments and the mail service are there.

Exporting and permanently deleting one customer's data are product features, behind a dedicated permission: they are not a request you send us and wait on. Every operation is recorded and cannot be modified — messages, assignments and status changes are dated and attributed. Attachments are not readable from a public address: every file passes through the application, which checks who is asking before delivering it. There are no passwords to choose or to share: you sign in with an email address and a code. Artificial intelligence starts switched off, and while it is off no model receives your messages.

Two things you will not find, said here rather than in a footnote: OglutTicket claims no certifications, and there is no automatic deletion on expiry — you decide retention and enforce it with selective deletion. The full picture, naming the feature behind each statement, is on security and privacy.

On why there are no passwords there is a dedicated guide; on letting customers write without collecting an account, support without customer accounts.