Besides all possible extra tools and loops, like encryption or generic archives, there is one main concept, which is summarized perfectly by Rachel
the site owner must make a list of the personal datas he has stored in the platform, why, and for how long (no longer than necessary).
When the duration of a personal data storing is over, it is necessary to:
- remove it
- or archive it (i. e. outside the website)
- or anonymize it
We therefore should start by showing integrators where TYPO3 stores data. This is not obvious at the moment. For example: When I install TYPO3 I just don’t know where TYPO3 stores IP addresses. The »sys_log« table may be obvious, but where else? Without this information I can’t provide a proper privacy statement.
Next step: Create tools to remove/anonymize the data. It is for example okay to temporarily store session data, such as the IP address of frontend users, which is stored in the database subsequently. When the session ends, all session data should be destroyed and removed from the database. This is already the case, but not documented in some privacy note.
Third step: Create a guideline on how to handle user data and urge developers to follow this guideline. It should be part of the coding guidelines, that extension developers instruct integrators whether an extension stores personal data, why and for how long.
The core could support this with tools as well, for example by providing a core method to retrieve and store an IP-address. Example: Extension »acme-news« uses a core method to retrieve and store an IP-address, by using this method the TYPO3 core automatically knows about this data usage & processing and could list this extension in an overview. We could also extend the »Table garbage collection« scheduler task, and provide an easy but required method to set an expiry date for records or fields with personal data.
In general I propose that the CMS itself faces all challenges of the GDPR and provides solutions and best practices for developers and agencies, instead of the other way around. I support Fedir’s proposal to create a working group and organize a dedicated TYPO3 Code Sprint related to the preparation to GDPR (and I would like to join this group).