Hi,
I use RT for tracking bugs in our software reported by users. Sometimes we have attachments and sometimes they fall under the GDPR and we will need to show that we can remove the files.
How can I do that in RT? As I understand it, a major feature of RT is that it keeps a permanent and immutable record.
How does RT handle this?
You can use the Shredder to really delete objects like attachments, tickets and users from the database: RT::Shredder - RT 4.4.2 Documentation - Best Practical
Handle with care!
Bye, Daniel
Brilliant!
Thanks for that Daniel, I think it will do just what we need.
cheers
Paul
Well I think GDPR is not a matter of shredding tickets, itâs rather the justification of needs 
So my first mind concept is: somebody wants to solve an issue with
your Service Desk so he needs to accept that you (Service Desk and all
subsequent solvers) will process his personal data which he provides for
issue clarification. No acceptance forms or such things needed here.
The second concept is: we have legitimate interest in keeping communication
(with itâs data) integral, available and confidential for various future
events. When you start to delete tickets, you have no integrity and
availability anymore. No shredding is needed then.
Petr
Hi Petr,
Iâm not sure I follow. Perhaps it is my lack of understanding of the details of the GDPR. You are suggesting that the storage of personal information is in these cases is a legitimate cause to keep the data?
Thanks for the comment. I donât think this is an RT issue but one of understanding the GDPR.
Paul
It looks like I have some more reading to do.
Yes, exactly. So far this is my opinion and colleagues from our company. We will discuss this shortly also on some meeting of HelpDesk managers, Iâll post here some conclusions.
Petr
That would be most appreciated Petr.
I look forward to seeing what you decide.
Paul
All RT request from individuals where the requestor, owners, or cc:s can be identified by f.x name or email adress or the context of the request, are Personal Data (PI) per the definition in the GDPR.
I agree that RT system owners can use legitimate interest as an argument to not require initial consent, and for the continued use of personal information for the duration while an issue is active, and if relevant also for a limited period after that for say billing, usage analysis, or process improvement.
But the GDPR also clearly require that the processor does not require or collect more PI than necessary [0]. The GDPR also requires that collected PI isnât stored longer than necessary[1].
Because of that I do not agree that one can blindly store all requests in an RT system indefinitely and claim that it falls within the scope of legitimate interest. It is reasonable in general that old requests are deleted when no longer absolutely relevant to the business relationship with the persons involved in the request.
Perhaps RT already has a date based auto-purge option? Otherwise it would be neat to have. Basically that RT by default purged all non-active (resolved/rejected/deleted?) requests after say 3 month. That would make GDPR compliance with RT a breeze.
[0] data minimisation, Chapter 2, Article 5.1 (c)
[1] storage limitation, Chapter 2, Article 5.1 (e)
The company that I work for has almost exclusively US clientele, so be forewarned that this is an academic exercise on my part. I may be overthinking this, and equally, overlooking some aspect of GDPR.
I suspect that thereâs not a one size fits all answer here. RT could plausibly be used by organizations whose tickets are entirely tactical and have a life span of days, or whose tickets tend to last for years and contain business logic that is refered to indefinitely.
Rather than using a blanket âdelete after 3 monthsâ I would suggest a statistical approach â measure how long tickets stay in an âACTIVEâ status, and find some proxy for whether the contents are referred to again⌠perhaps if and when a link is created to that ticket, or the âlast updatedâ date, then create thresholds based on the mean âtime to last referralâ.
Once youâve measured those thresholds, then you can set rt-crontool to shred accordingly, and you have a solid justification for keeping the data that you donât delete â âwe have an x% chance that this data will be used again to resolve ticketsâ is a stronger argument than âweâre pretty sure that we wonât use data that hasnât been touched in 3 monthsâ.
Perhaps RT already has a date based auto-purge option? Otherwise it would be neat to have. Basically that RT by default purged all non-active (resolved/rejected/deleted?) requests after say 3 month. That would make GDPR compliance with RT a breeze.
The rt-shredder tool has the Tickets plugin that allows you to specify a query to match the tickets you want to get rid of. Thus if you can produce a Query Builder SQL query that matches the tickets you feel you should get rid of, you can use the same query with rt-shredder. For example if you want to nuke all tickets that were last updated over 60 days ago and are rejected, resolved or delete you could use something like:
rt-shredder --plugin âTickets=query,LastUpdated < â60 days agoâ AND ( Status = ârejectedâ OR Status = âresolvedâ OR Status = âdeletedâ )â
Thereâs info on rt-shredder in the RT documentation and the wiki contains information on TicketSQL, including the date formats accepted.
I think we also need a Data Processing Agreement (a.k.a. DPA or Data Processing Addendum) which is an agreement between us and RT and outlines commitments on: acting on written instructions, confidentiality agreements for staff, security, access rights to data, actions upon termination, right to audit, amongst other things. How are other people handling this with RT? Thanks
We are lucky in that we do not allow user access to RT, it is for internal use only.
As such clients information is limited to the information we put in there ourselves. Users when added to a ticket as Requester are created with only an email address. Real Name and other fields are intentionally left blank.
Also - the content userâs supply is added manually to a ticket by a staff member so we can ensure no personal information is in the body of a ticket, it is only the occasional attachment that may have identifying information. I havenât looked into it, but if the shredder can be invoked on an SQL query result to shred only the attachments then we can keep our historical data for future reference.
I believe the key is managing what you put into RT in the first place. As I said, itâs easy for us, clients are at armâs length from RT and so it comes down to practices and procedures internally to ensure as little sensitive data as possible is in there in the first place. Like so many other things I believe this is a management issue not a technical one.
Not sure what you mean here Stewart, âRTâ is Best Practical and âusâ is companies using it?
Using rt-shredder as @GreenJimll suggests solves my immediate GDPR requirements for RT. In my case we basically donât need to refer to issues that have been resolved ever again, so wiping/shredding resolved, deleted, or rejected issues in RT after some duration is perfectly fine. So, thanks for the example and documentation links!
I agree with @Barton_Chittenden that there probably isnât a single one size fits all solution. My suggested 3 month was just an example. On the other handâŚ
I believe that defaults have a powerful impact on actual usage. I suggest that there could be some reasonable default setting in RT that encourages admins to consider what data rentention policy they really need for their use case. And if the default is to limit retention - and then shred, say after a year - then most installations would probably never change that configuration value and the ones that do probably have good reason for it.
Just consider the new slogan: RT - the request tracker that is GDPR compliant by default.
We have requirements in some queues that we keep the requests around until 2 years after a student graduates (mark contention and such). Turning on any defaults that would result in data deletion would be very bad.
While an upgrade can provide all the hooks it canât change the existing behaviour.
Any new install basically needs to do the same thing. You can add a âmake enable-GDPRâ action which installs a set of defaults and tells you where to update them. Preferably it installs a set of fully functional commented out defaults and says âcustomize thisâ.
âWeâre running with the vendor defaultsâ doesnât buy you much when the-powers-that-be notice stuff has disappeared unexpectly.
Weâre currently starting a review of data governance within RT. Tools and suggestions would be nice.
rt-shredder doesnât help here at all.
We canât delete anything just by date because tickets contains various information unrelated to GDPR and that data needs to be kept.
Also GRPD require you to delete personal data immediately after you no longer need these, so for example if user provides his ID card for verification in ticket you need to delete such attachment from the system after performing verification while you can keep ticket itself.
Here I miss things like:
Not sure if that will cover all cases, probably edition of tickets will be needed sometimes, too.
This requirement more or less mean youâll be having to handcraft a solution for your particular situation, as the RT developers arenât going to be able to handle all the odd cases of personal data embedded in email bodies such as whatever ID card data youâre capturing, odd names (is âMayâ or âAprilâ part of a date or a personâs name for example?) or personal vs corporate email addresses.
Luckily with RT we all have access to the database and Perl APIs so we can make these home grown, site specific additions and tools when we need them.