This week, as part of the Serbian open data week, I participated in a panel discussion, talking about international developments and experiences. This is one part of a multi-posting overview of my speaking notes.

The opportunity the GDPR presents

Many European government entities I encounter worry about the GDPR, the personal data protection rules that will start being enforced from next May. They see it as hugely important but also an uncertain factor. Part of that uncertainty is in not really knowing how to implement it well. Also the relationship with things like open data are unclear to most.

Two elements I stressed in the panel discussion: 
First, open data builds on public data, and everything that is restricted because of the GDPR is not public by definition. So in that sense everything you do concerning open data is disconnected from the GDPR. However as I mentioned at the end of the first part of my notes, there is an issue with the privacy implications that may arise from downstream usage and recombination of open data sets. The current legal framework does not solve it, it assumes that the GDPR precedes the PSI Directive, so that only data where the GDPR does not apply will be subject to the PSI Directive. Yet at the same time the GDPR does say things about future usage and effects concerning data that for instance has been released under the PSI Directive, and that currently in turn might invalidate the original conclusion the PSI Directive applies. In short: the GDPR contains non-linear feedback loops, but the sequencing of GDPR and PSI Directive assumes a steady linear path without feedback loops.

Second, I however see the GDPR as a tremendous opportunity for open data to become much more deeply embedded in information processes and systems design inside government. 
The GDPR calls for data protection by design ,as well as for keeping up with the state of the art while doing that. This means personal data protection can no longer be a mere fence around your data, but needs to be designed into your data structures. This means at every stage of your work precisely knowing where in your data structures what types of data reside. It means being able to within a single data set distinguish between fields that need protection and fields that don’t, or only do in specific instances. Any usage restrictions that may apply on the basis of the GDPR basically has to be captured into metadata for the data itself. To me it makes no sense to just do this for the GDPR, for person related data only. It however makes a lot of sense to me to do this for

• openness (what is public, when under which conditions),
• data security (in the sense of the needed guaranteed availability and quality of data, ensuring uptime and making tampering impossible)
• data protection (privacy, third party rights, economic issues and other openness exemptions)
• digital archiving (archiving terms, mandatory destruction of data)

“Everything by design” in short, not just privacy (or openness) by design. The implementation of the GDPR is an opportunity to embed it all in the digital transformation of government and get to much more mature data governance.