Super-set feature set for privacy compliance

When it comes to deleting user data, there is an open core issue at #2723323: [META] Clean up references to deleted entities → to clean-up entity references.

However, I wouldn't recommend deleting records, even in this context. Instead, we should obfuscate relevant data fields, not deleting their records. That will keep data consistent, and no business logic will ever break due to deleted records. But, of course, this would also have to address optional revisions.

Added TOMs to default content

My proposition for dividing the feature set in to recipes:

Base (Consent) recipe:

• Privacy: do not track without consent
• Disclose what data you collect and why
• Do not embed remote assets (fonts, videos, images, iframes, etc.) without consent
• Consent management (a.k.a. cookie banner): only ask for consent if really required. Don't forget contact and maybe other forms.
• Default/sample content: imprint, privacy policy, data protection declaration, general terms and conditions, technical organizational measures (TOMs)
• FAQs and recommendations / documentation

Data protection recipe:

• Data protection: only collect data that's really necessary
• Data processing: only process PII with consent and disclose third parties that you share data with
• If you store user data (or otherwise PII), provide easy mechanisms ...
  • to receive a report of what's stored about each user
  • to delete and confirm the deletion of that user data on request
• Sanitized export of data, e.g. for developers (db and files), e.g. with Drush or in the UI
• FAQs and recommendations / documentation

Audit module:

• Avoid dark patterns, e.g. do NOT seduce the user to consent
• Initial and regular internal audits on the website
• External audits, like e.g. Typo3 has done with the German Federal Government
• FAQs and recommendations / documentation

Other (not sure)

• If you provide subscriptions, make it as easy to unsubscribe
• Privacy and compliance API: law firm may hook into those to automatically provide setup, content and updates

Thanks @l_vandamme, this looks great. I've tried with the initial item list myself, but always struggled because there was so much overlap and most items would fit in multiple places. As I also got some additional feedback from interviews with some agencies outside Europe, I now tried to break it down into more feature-like items. They all relate and cover the original list. So, here is what I came up with so far:

Compliance Audit Module

• Should be the supervisor for all the features below
• Provides a dashboard
• Comes with many plugins to scan for issues and to present them for review, e.g.
  • Consent Management
  • Data protection
  • Dark patterns
  • Library analysis
  • JavaScript behaviour
• Execute audit regularly
• Provides documentation, FAQ, links, etc. for site owner

Consent Management Recipe

• Tracking
• Cookies and other locally stored data
• Third party content embedding
• Subscriptions and unsubscription

Compliance Content Pool Recipe

Might be snippets only

Requires multi-lingual support!?

• Data collection disclosure
• Imprint
• Privacy policy
• Data protection declaration
• General terms and conditions
• Technical organizational measures (TOMs)
• API for law firms to hook into

Data Protection Recipe

• Identifying personal data
• Define data storage purpose, duration, relationships
• Encrypting sensitive data
• Limit volume of collected data
• Limit storage duration of collected data
• Limit sharing with third parties
• Provide PII report on request
• Delete (or obfuscate) PII on request
• Sanitizes export for developers

External audit to review this overall solution and that it addresses all legal requirements.

the general direction in both proposals is good. i like the slightly more granular categorization by @jurgenhaas in #5 → a bit more.

two additions. one aspect i am not sure is already explicitly covered, so far i was only able to see the point of sanitized export for developers in both proposals, but both examples (wordpress and joomla) over in #3467980: Competitive analysis → provide the opportunity to either export the entire personal data of a user or export and delete that personal data. that is a feature that would be sort of required imho.

and i still think it might be helpful to introduce as a mid or longterm goal some sort of api similar to the capabilities api in joomla mentioned in #5 → which would help aggregate the necessary information within the various recipes (for example for the generation of the TOM, and components of the compliance as well as the consent recipes)

provide the opportunity to either export the entire personal data of a user or export and delete that personal data. that is a feature that would be sort of required imho.

This is included in the data protection recipe as "Provide PII report on request" and "Delete (or obfuscate) PII on request".

and i still think it might be helpful to introduce as a mid or longterm goal some sort of api similar to the capabilities api in joomla mentioned in #5 which would help aggregate the necessary information within the various recipes (for example for the generation of the TOM, and components of the compliance as well as the consent recipes)

Yes, that should come as part of the Compliance Content Pool Recipe, although I'm not sure yet, if this is even possible to do.

jurgenhaas → credited boromino → .

jurgenhaas → credited grienauer → .

I've updated the issue description and created 5 sub-issues for the 5 topics (added the external audit as a 5th one, just so that we don't forget).

The first 2 are assigned to @l_vandamme and myself, the others are unassigned and postponed for now. Let's focus on the first 2.

Please review the list and make any changes that you feel necessary, or discuss them in comments. Once we all agree about it, lets mark this RTBC so that we can later fix it.

@jurgenhaas I went over the new division again and agree for the most part.

The only unclear item for me would be the "Subscriptions and unsubscription" being within the consent management recipe. I've not had much experience at all with implementing something like subscriptions in Drupal and it seems to me to be an edge-case that might need to be solved by the module supplying the subscription service in the first place. In that case, I would move this to the audit module, because that will make it possible for any subscription module to implement a plugin to have it checked.

Other than that, it looks good to me!

That's a great point, thanks @l_vandamme. I've moved that subscription topic up to the scanner plugins in the audit module.

I'm ok with the list, because I think it's too early to definitely decide to what recipe(s) a feature belongs. E.g. any consent management feature may go into audit, too, because a user may reject or accept every cookie separately, which would imply that any cookie setting module may/should implement a corresponding plugin. Therefore I stumbled about "Comes with many plugins to scan for issues" in the audit recipe. I'm not sure what that implies, but again, for me it's too early to decide on this.

Regarding subscriptions, I see 2 use cases:

1. Subscriptions to on-site features
2. Subscriptions to third party features

They both may require the same information and/or consent or different treatment. As already stated in the meeting, such questions should be handled in the corresponding issues.

Closing this issue, since our action plan is now in individual issues that are mostly in review already.

Automatically closed - issue fixed for 2 weeks with no activity.