GDPR Compliance


#1

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?


#2

You can use the Shredder to really delete objects like attachments, tickets and users from the database: https://docs.bestpractical.com/rt/4.4.2/RT/Shredder.html

Handle with care!

Bye, Daniel


#3

Brilliant!

Thanks for that Daniel, I think it will do just what we need.

cheers

Paul


#4

Well I think GDPR is not a matter of shredding tickets, it’s rather the justification of needs :slight_smile:

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


#5

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.


#6

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


#7

That would be most appreciated Petr.

I look forward to seeing what you decide.

Paul


#8

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 ©
[1] storage limitation, Chapter 2, Article 5.1 (e)

http://eur-lex.europa.eu/eli/reg/2016/679/oj#d1e1797-1-1


#9

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”.


#10

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.


#11

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


#12

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?


#13

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. :slight_smile:


#14

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.


#15

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:

  • deleting attachments (with storing information who deleted and what) from UI
  • anonymization option for tickets (which replaces all data like requestor emails, first/second name from metadata but also from ticket content, too) - and that could be used instead of shredder.

Not sure if that will cover all cases, probably edition of tickets will be needed sometimes, too.


#16

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.