WOW what a ride! Some 200 days has passed since I first started reading EU General Data Protection Regulation, finding GDPR friends in the WordPress COmmunity, and seeing the project take form inside WordPress core.
The day has arrived – 25th of May – I’ve said that date quite a few times now, and although it’s an important data as the deadline has kept us focused in our work – the work is not at all “done”.
Our work continues, and updates to the current GDPR hooks and filters you will find in WordPress code as well as backend tools for site administrators, are first versions of the central tools. Many more to come I suspect.
One such tools is a logging feature which we started working on at Peytz when we where still had about 50 days to go before the 25th…
Although you see a logging feature as part of the current GDPR tools in admin, these do not meet the requirements of logging, in terms of the regulation.
Therefore we’ve set out to define an logging feature that can hook into WordPress actions allowing developers log actions performed in code
– separated from the database
Wait – what: re-actionable and separated from the database. That sounds messy!
Well, yes, and it’s not strictly WordPress but let me explain.
To make a log compliant with GDPR, we need to make sure that it does not hold any information that can identify a natural beeing.
We also need to maintain a log that is not part of the data it’s logging.
This makes for an external logging mechanism you can put data into, and also query to fetch previous actions performed on certain data.
A unique but non-personal hashed value will serve as an ID. One that only make sense if a user provides the personal data on which the hashed value has been created.
Stay tuned for more information after today 🙂