Feature Request: Advanced GDPR tools/functionality
There have been a number of prior community posts around GDPR topics, including:
- https://support.zendesk.com/hc/en-us/community/posts/360000867987-GDPR-redaction-on-closed-tickets-
- https://support.zendesk.com/hc/en-us/community/posts/360001117827-GDPR-Automatically-deleting-old-tickets-via-the-automation-feature
- https://support.zendesk.com/hc/en-us/community/posts/115008423827-Enable-editing-deleting-comments-and-attachments-in-tickets
- https://support.zendesk.com/hc/en-us/community/posts/203439166-Add-ability-to-bulk-delete-closed-tickets
- https://support.zendesk.com/hc/en-us/community/posts/245247207-General-Data-Protection-Regulation-2018-the-right-to-be-forgotten
@Joel Hellman posted a solid list that captures a variety of concerns, many of which I share and believe are worthy of a larger discussion about GDPR tools/features that Zendesk customers need to support their own compliance needs. The current methods of handling GDPR responsibilities are technically compliant, but simply aren't nuanced enough for us to balance legal compliance with our own teams' needs for efficiency, reporting, and consistency and our own customers' ability to control their data. Below are some features I believe would address those issues without requiring Zendesk customers to have a developer-level of competence with the API. (Warning: long read ahead)
--------------------------
Similar to how SLA policies exist independently of other Zendesk features, I believe a robust feature for capturing all Data Management policies under a single umbrella is a potential solution. Attempting to align the various aspects across different configurations and features would offer a fractured, confusing experience for admins attempting to create clear, manageable data polices that align with their business needs. As with SLAs, attributes can be added from other sources (e.g. triggers, automations) to determine which policy applies to any given ticket. However, a single feature should serve as the source of truth for data policies, system-wide. Components of such a policy might include:
-----------------------------
Data Retention
Admins should be able to configure global retention policies that are attached to each ticket, same as SLAs. These policies can apply to fields for consistent data handling processes across tickets. They also allow admins to designate which fields' data can be retained (e.g. non-PII data that's used for analytics), allowing teams to maintain valuable data in their reports/dashboards. Flexible policies can also be defined for tickets or users that meet specific GDPR challenges, such as data that must be retained for ongoing litigation.
Configuration options:
Tickets
- Delete [ticket fields] when [conditions] are met (configure like SLAs/triggers)
- Multi-select list of fields to delete when [conditions] are met. This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want deleted.
Users
- Delete [user fields] when [conditions] are met.
- Multi-select list of fields to delete when [conditions] are met. This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want deleted
Attachments
Attachments pose a particular problem, as they are not always subject to the same policies as other ticket data. Sometimes a ticket can be closed, anonymized, and deleted, but the attachment must be retained for a much longer time due to other legal compliance reasons. Thus, attachments may require separate policy controls than tickets themselves.
Configuration options:
Tickets
- Delete [attachments] when [conditions] are met (configure like SLAs/triggers)
Ephemeral upload channels
Ephemeral upload channels would solve the problem of handling extra sensitive information. The reason for separating this from general retention policies above is this: sometimes attachments and other ticket data don't have the same level of sensitivity. These could be handled by the attachment policies above, but a new feature to manage upload channels (similar to email forwarding) would be helpful, as it could be a used in the criteria of those policies (e.g. attachments coming through a 'burner' channel would be treated differently than a 'standard' one that has a longer retention period). From a liability perspective, there is some information (e.g. passports, ID cards, and other identity documents) that is best handled in a "Snapchat" manner - once it's served its purpose, it can (and should be) discarded as soon as an issue has been resolved.
Data Anonymization
Deleting tickets to maintain compliance will cause irreversible loss of data. Instead, the original ticket should be retained but with any potential PII information scrubbed/anonymized as necessary. Admins should have simple ability to select which fields should/shouldn't be anonymized for each policy. This policy would need the ability to modify tickets in the 'closed' state to be fully effective.
Configuration options:
Tickets
- Anonymize [ticket fields] when [conditions] are met (configure like SLAs/triggers)
- Multi-select list of fields to anonymize when [conditions] are met. This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want scrubbed.
- Advanced > Regex matching - support automated data anonymization when custom patterns are met (same as credit card redaction works now). A 'tester' regex wizard that allows admins to see which ticket data would be affected prior to enabling them (same as automation previews) would make this more accessible to admins who don't have development resources. A more complex version would display a list of ticket data prior to anonymization that would require manual approval
Customer Control
Data Export
Users should be able to easily download & export their Zendesk data in a portable format (i.e. .zip archive of .csv or .json files) with optional encryption password.
Data Deletion/Right to be Forgotten
Users should be able to submit deletion requests into an admin tool/interface. Manual requests of this nature are cumbersome to manage if they can't be initiated by the data subject directly.
- Allow users to manage their own data
- Multi-select list of user fields users can delete
- Allow users to manage their ticket history
- This relies on the ticket policy attached to each ticket in their history. Users can choose to delete their tickets, triggering the deletion policy attached to each on if it hasn't already run.
- A bulk delete option should be prominently displayed in the customer's ticket history for customers to initiate ticket deletion (subject to overriding retention policies enumerated on the individual tickets in the section above).
Auditing
The ticket event log is fairly robust as is, but 3 general additions would greatly enhance Zendesk auditing for compliance purposes:
- Full details in the audit log: (e.g. https://domain.zendesk.com/settings/account/audits?filter[source_id]=1234567&[source_type]=rule). Currently, it shows that changes were made when you hover over an entry, but you can't see what the full differential in the configuration changes (this is somewhat addressed in other places by trigger revision history).
- Ticket viewer history: A record of any event where a ticket was viewed - there's no current access log that I'm aware of. In case of a privacy event or data breach, knowing who has accessed a ticket is critical information.
- System config differentials: Understanding the day-to-day changes in a complex system of triggers, automations, macros, 3rd party apps, and more is nearly impossible. This is exacerbated when attempting to test new features & deploy them to production. Zendesk would benefit greatly from a robust change log & versioning process that's commonly used in code deployment. Enabling complex rule sets can be tricky and this functionality would allow for both better auditing and simpler reversion if errors are introduced during a big change. Manual rollback is extremely painful and can lead to cascading issues system-wide if not executed properly.
-
Commentaire officiel
Hi Matt -- thanks so much for the detailed post here. This is really great feedback, and it definitely resonates with what we are hearing as we roll this out to customers. You are indeed doing our Product Management job for us :).
Frankly, we've been consumed with the heavy lifting over the past 6 months to meet the basic (and essential) data deletion requirements across all of our systems and infrastructure (a VERY heavy lift as you can imagine), but we understand that there are ways in which we can make the basic Admin experience easier for our customers and your customers. Threads like this and the others you reference are really helpful as we build this roadmap beyond the basics. Thanks for taking the time to provide the feedback.
I'll also echo some of Graham's points that there is a lot you can do via our developer tools and APIs in the mean time. We have seen some customers build some interesting Apps and background jobs of their own to make this easier. Of course I know how hard can be to find engineers and / or budget to do this, but it is an option.
-
Can Zendesk hire this guy as a producer? ;) These recommendations are exactly what we need, very well thought out and would address many of our concerns. For our business, the most important one is being able to automatically anonymize data (specific fields containing PII) from certain tickets based on criteria. Deleting the ticket is not a desired solution as we lose important data for historical volume/trends reports.
-
This guy gets it.
Thank you Matt, you've put into words many of the concerns and ideas we have but haven't been able to express nearly as well. Zendesk's current compliance option to 'just delete the ticket' isn't acceptable.
All tickets (including Closed) need to be able to have specific data redacted in bulk and/or via a rules-based system in order to comply with GDPR and not damage our own business. If they're positioning themselves as an Enterprise grade solution, these data management features are needed!!
-
Haha, thanks for the compliments Stephen & Dan. I posted this because I expected many other Zendesk customers were experiencing similar limitations with managing data effectively. Maintaining balance between your own business needs and your own customers is tricky business, as well all know well. There are lots of opportunities to automate the policies to reduce potential errors in their application.
WRT closed tickets: I had also asked about this initially and failed to include it above. I also want to know what can be done to handle those more tactically. I have no issue with immutability at a certain state but it'd be nice to have control over exactly when that transition occurs. Currently, there's an artificial 28-day maximum on the transition from solved --> closed that can't be overridden. That's another aspect that would be great to specify directly in data retention/anonymization policies.
-
Hey Matt,
A solid piece of work here, although it appears to come from a suggested solution orientation.
However, it does highlight the GDPR pain points, and what might work best from a Zendesk admin perspective i.e. define policies and have them enacted.
At a recent public GDPR and Zendesk Webinar, Zendesk did allude to Zendesk doing and planning much at the product level to more deeply support admins with GDPR management tasks beyond the basics. My understanding is that tickets won't be deleted since that would cause distortion of reporting statistics, rather they would semi-deleted/modified to remove GDPR sensitive data.
As you highlighted, closed tickets are currently in a lock-down scenario, so we do really need some Zendesk enablement here, hopefully at the API level too.
Here at CloudSET, a commercial Zendesk App Development Partner, we are prototyping the use of Zendesk new Custom Resources API, which allows the addition of different object types and relationships between them and core Zendesk objects. This offers up some mouth-watering possibilities to model GDPR policies, and enact them using existing and new Zendesk Services. This includes the whole world of Zendesk Apps Framework and the Apps you can build yourself, or obtain from partners like CloudSET.
As such, there are some fundamental capabilities that only Zendesk can provide, with either Zendesk fleshing out the full solution at the product level and/or allowing other parties to provide a full solution set.
If anybody is interested in partnering with CloudSET 's Early Adoption Program for Customer Data, please reach out to us at info@cloudset.net.
Graham Robson - CloudSET (Coherence Design)
-
(edit: 2018-05-18 13:44 - post is pending approval still- check later if you don't see it yet)
Since it's relevant to the points above, I'm cross-posting my best attempt at enacting a deletion/retention process with the current API endpoints. I hope this provides more depth into just how under-equipped the current features are to comply with the necessary data policies imposed by GDPR. -
I was going to create a new thread but this post captures part of my requirement exactly and I would like to add my thoughts to it.
If a customer terminates their contract with us, yes I can retain their data for a reasonable amount of time to protect the company against claims of negligence for example. However eventually this data will need to be removed from Zendesk. My issue, as confirmed by your Support team, is that by hard deleting tickets you're opening yourself up to inaccurate reporting through Insights.
If I want to report on all of the tickets created 6 months ago but I've had to delete a bulk of them, then the only way to include them in the report is to add the filter that states to include deleted tickets. However, this includes all of the tickets that should never have been a ticket in the first place i.e. the ones that made it through your spam filters etc.
So now I'm stuck between a rock and a hard place, either way my reporting is now inaccurate. I'm missing tickets, or adding in ones that shouldn't be included, and this is just one example of the many frustrations that I have with GDPR and Zendesk's lack of support for it.
There has to be a way to obfuscate data! Our company is a supplier of case management software and we now scrub our DB of all information, but leave a marker behind for our reporting so that we can still accurately account for what cases went through our software.
I'm seriously surprised given the period of notice that everyone had that GDPR was coming, that a company as big as Zendesk has not adequately produced a set of tools available to it's user base to support the introduction of this law.
-
@matt this is an amazing summary of needs around GDPR!
We have built a GDPR Redaction app that helps remove all PII and customer data based on a ticket, a user, or an entire organization. We built this custom for a few clients then made it available as a general app. It doesn't accomplish all of the above, but it DOES solve the problem in the mean time.
Find it in the Marketplace here: https://www.zendesk.com/apps/support/gdpr-redaction-app/
We have a couple of major international clients using the app and have also worked with Zendesk Services team on one of those implementations.
Please reach out to me with any questions. gdpr@thoughtexhaust.com.
-
I work for a smaller company and have been tasked with developing the data retention policy for my group. The current lack of tools to set a data retention policy without additional spend is appalling. Our engineering team already runs extremely lean and doesn't have the resources to help me with an API; there are not enough details in any of the API articles to help me do this myself. My higher-ups won't approve additional spend on any of the apps geared towards this. ZenDesk needs to integrate data retention into its program sooner rather than later.
-
@... My organization would be interested in joining this EAP. Thanks!
-
Hi,
Thanks for these information.
But what about the servers physical locations? If I am not mistaken they must be located in the EU territory and must not be replicated outside isn't?
Thx
-
Nicholas - No, they don't physically need to be located in EU territory, they can be outside of the EEA (European Economic Area). However, safeguards need to be in place to transfer data outside of the EEA such as Privacy Shield (which is now not valid), EU standard contractual clauses or consent from the end user.
Can someone from Zendesk please update us with what progress is being made? The GDPR text has been out in its final form since March 2016 - over four years ago.
-
I would like to add something to the list: https://support.zendesk.com/hc/en-us/community/posts/360050955773-Urgent-feature-request-GDPR-compliant-cookie-consent-management-at-Zendesk-HelpCenter
-
This is definitely on our list of priorities as it is typically on anyones minds when taking on a platform as there are laws we abide by
-
Any Updates on Zendesk creating native apps to cleanse users and organizations? The manual import and export of the data is incredibly tedious and time consuming. I realize there are third party solutions, however, our business does not have the budget and are conscious of system security...
-
Hi Bradley Lowes,
Thanks for your comment!
Automation for deletion is currently in development with an estimated delivery of early H2. Ticket deletion will be released first then users to follow shortly afterwards.
We'll be posting an official announcement in the coming weeks with more info on confirmed dates and scope.
Thanks,
Mary -
Mary O'Neill Thank you for the update
Vous devez vous connecter pour laisser un commentaire.
17 Commentaires