I’ve had a number of questions recently about how long help desks should keep personal data about the queries they receive. The correct answer is “as long as you need, and no longer”. But I hope the following examples of why you might need to keep helpdesk tickets are more helpful than that bare statement:
- To resolve the question. Obviously, until both the requester and the helpdesk are satisfied that the question has been satisfactorily resolved, the helpdesk needs to keep personal data such as email address and phone number that’s needed to contact them. Once the problem has been resolved, this purpose doesn’t require you to keep information. So we should be looking at days or weeks before personal data is deleted or anonymised.
- To identify users with persistent problems. Some helpdesks look for patterns of requests that might indicate a user with long-term problems. This might be resolved by training, new equipment/software, etc. This requires that requesters remain identifiable for longer, but we should still be aiming to resolve the problem as soon as possible. So perhaps a few months’ retention. The same approach, though with an even more urgent need to address problems, applies to monitoring of helpdesk staff.
- Statistical reporting. This is normally done by department, type of software, or some other categorisation. There’s no need to keep personal data about which individual reported the problem for this purpose, just the categories into which the report fell.
- To collate frequently-asked questions and answers. Again, there’s no need for personal data: just a description of the problem and a model answer.
- To monitor system performance over the long-term. A history of reports about a particular piece of equipment may provide an early indication of a fault or imminent failure. For this purpose reports should be grouped by piece of equipment, not by the person reporting the problem. If remedial action is needed, the current responsible person can be identified from an asset register or similar – there’s no need to contact everyone who has reported the problem in the past.
These and other reasons for keeping information only apply if you actually have those processes, of course. But I hope they give examples of how to think about the “how long should we keep…?” questions.
In any database, it should be possible to delete/anonymise a single field if the rest of the data are still required for another purpose. For example – a common combination of the bullets above – if you are resolving questions but also want to keep a resource to identify frequently asked questions, it should be possible to remove the requester’s details from the database once their query has been resolved but keep the question and answers for later use in a FAQ.
One further challenge arises when the database contains a large quantity of unstructured text that may contain personal data. That’s a more general issue, so I’ve covered it in a separate post.
