Feature Request: Advanced GDPR tools/functionality

There have been a number of prior community posts around GDPR topics, including:

1. https://support.zendesk.com/hc/en-us/community/posts/360000867987-GDPR-redaction-on-closed-tickets- 
2. https://support.zendesk.com/hc/en-us/community/posts/360001117827-GDPR-Automatically-deleting-old-tickets-via-the-automation-feature
3. https://support.zendesk.com/hc/en-us/community/posts/115008423827-Enable-editing-deleting-comments-and-attachments-in-tickets 
4. https://support.zendesk.com/hc/en-us/community/posts/203439166-Add-ability-to-bulk-delete-closed-tickets 
5. 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:

1. 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).
2. 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.
3. 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.