Although the General Data Protection Regulation (GDPR) has been in force for some time now, it seems to be difficult for many government agencies (and companies) to fulfill its requirements correctly. The Standard Data Protection Model (Standard-Datenschutzmodell or SDM) aims to provide a system for deciding whether one acts in a GDPR-compliant manner.

The first two chapters of the SDM explain the background, legal foundation and the goals of the document. In doing so, it also formulates seven guarantee targets which are used to systematically evaluate the legal data protection requirements. The SDM also explains how these targets follow from the GDPR requirements. The SDM then derives generic measures from these targets and provides fitting reference measures. Ultimately, this is to ensure that any data processing is done legally or at least that risks have been sufficiently minimized.

The targets are:

• Data minimization
• Availability
• Integrity
• Confidentiality
• Non-Aggregation
• Transparency
• Ability to intervene

The CIA triad of confidentiality, integrity and availability is well known already, but the four additional points may need further explanation. They are data protection requirements, where data minimization calls for gathering only strictly necessary data; non-aggregation demands that information isn’t gathered in expansive profiles; transparency has to be ensured both towards the subjects of data gathering and any controlling instances and it must be possible to intervene and manually change results of automated decisions based on the processed data.

It’s important to keep in mind that none of these are absolute requirements. Information may be aggregated, for example, if that is necessary for a justified purpose. However if the data was gathered for different purposes, it may not be aggregated. The SDM sensibly points out that large and meaningful data collections can create a demand for uses that go beyond the legally permitted. Having this pointed out here, especially as a reason to avoid such collections, is very positive.

On top of that, there are also qualitative requirements, such as interventions into automated decisions having to happen immediately and effectively. Altogether, this sets very high goals.

Generic measures

The generic measures are very brief, barely more than bullet points like “Creating backups of data, process states, configurations, datastructures, transaction histories et al. according to a tested plan” for availability or “Measures for detailed consent, withdrawal and objection capabilities” for intervention. As food for thought and to encourage planning they are however well suited.

In general, the document also formulates a detailed process for data protection management and risk assessment which both cover reasonable points but do not provide anything new.

Reference measures

These have been released in part, as a sort of public beta. This is to allow testing and improving them in the wild, which is also why they are appendices of the SDM, rather than the core of the document. These appendices should be revised and improved at a more rapid pace than the main document. The measures were grouped into so-called bulding blocks and formulated by various agencies.

The reference measures are plenty generic as well but they do provide the kind of measures one should take to be on the safe side with respect to the GDPR. However, on one hand there are building blocks that depend on each other and on the other, the requirements are occasionally set very high. As an example for the first, the building block on storage explains that data should only be stored as briefly as possible and deleted upon request. This explicitly excludes backups but does not go into what would need to happen if a backup containging already “expired” data needs to be restored. That is explained in the document about deletion, which explains that it is sufficent to delete such data upon restoration of the backup – unless, that is, it is particularly sensitive data, in which case the backup must be subjected to an “unscheduled cleanup”. The deletion building block also provides an example for the second case. Deleting information from a database is not considered sufficent unless a “reorganisation” of the database is done, ensuring that the data is overwritten and cannot be restored.

Conclusion

Ultimately, it seems that an important and ambitious goal, following a strict interpretation of the GDPR and providing clear guidance on fulfilling that interpretation, was set but not reached. The process and requirements are not bad but they are not as clear as they should be on how to implement them. The more specific building blocks are closer yet still too vague and set the bar at a level that only few will be able to clear. Taken together this means that the SDM will likely not improve the situation.

About the Author

Mark Zeman has a Master of Science in Engineering with focus on Information and Communication Technologies at the FHNW. He was able to transform his passion of information security to his focus since 2017. During his bachelor studies he worked for an email security company. (ORCID 0000-0003-0085-2097)