Aug 23
Security of processing and Risks

Security of processing and Risks

DPOrganizer’s GDPR Requirements Series

#3 – Security of processing and Risks

Welcome back! Today, I am rewinding the series to the accountability principle and adding another layer to it by introducing another requirement. If you do not remember, let me refresh your memory about today’s important aspect of it. It is the controller who is accountable for implementing appropriate and effective measures.

This is evident in another GDPR principle, the principle of integrity and confidentiality, which states that personal data shall be processed in a manner that ensures appropriate security of the data using appropriate technical or organisational measures. This post will elaborate on the requirement found in article 32 in the EU and UK GDPR (the regulations), which is an expression of the principle of integrity and confidentiality. It concerns the implementation of appropriate technical and organisational measures to ensure a level of security appropriate to the risk. You probably see that all of the above share a common theme. It is about appropriate measures, in one way or another.

In this requirement, we talk about technical and organisational measures, called TOMs for short. The technical bit could be more aimed towards cybersecurity, and organisational is aimed towards things like physical security and staff training, as well as governance, policies, and procedures. This post will use part of EDPB’s guidelines on Data Protection by Design and by Default (DPbDD) that is relevant for security, but DPbDD is reserved for a future post.

Any chosen TOMs must be appropriate to the risks posed by processing, meaning that the law does not require absolute security. Both controllers and processors are required to assess risks to know which TOMs are appropriate, and which are not. An assessment of TOMs includes an assessment of the state of the art, the costs of implementation, the nature, scope, context, and purposes of the processing, and the risks to the rights and freedoms of natural persons. That is a lot, so let’s break it down.

The state of the art is a concept that is fleeting and always changing over time. It depends on the circumstances of the latest developments, innovations and what is available to implement from the market. Regarding TOMs, the state of the art isn’t to be conflated with usual tech-lingo connotations. It applies equally to different organisational measures, like access solutions for buildings. Since the state of the art is dynamic, the assessment would have to be a recurring affair.

Nature, scope, context, and purpose mean that you should implement measures that are appropriate to specifically these four factors of your processing operation. According to the EDPB, these factors can be understood as the processing’s inherent characteristics, size and range, circumstances, and aims. Appropriateness differs between a large hospital that processes a large scale of sensitive health-related data and that of a regular neighbourhood grocery store. But say, if that store has CCTV, profiling of persons to give specialised offers, etc, then the appropriate security would clearly be something else.

At last, risks and the GDPR: It’s a huge component of the regulations and a common concept in many requirements. In essence, risks are the likelihood that an event would happen and the severity of that event. The ones that should be protected from these events are people, and their rights and freedoms. The rights are of course the data subject’s rights that the regulations provide for, and also other rights covered by the EU’s Charter of Fundamental Rights.

Taking account of the cost of implementation means considering resources like time and money. It means that you are not required to use a disproportionate amount of resources on measures. If you can implement less resource-demanding measures that are appropriate and effective, then please do. Nonetheless, you can only consider the cost of implementation when actually implementing measures.

You should consider this requirement during the entire data processing life-cycle; before, during, and until the end of the processing. This is especially important when you are about to buy or are using products and services from a third party. It could be thought of generally when you come in contact with other third parties during your processing activities. The appropriateness and effectiveness of any implemented TOMs must be regularly assessed and tested. After that, you will know if they need improvement and updating. If you read the post on the accountability principle, remember that conclusions and rationale behind any decisions should be documented. The documentation, in this case, should at least include the assessment of the appropriateness and effectiveness of the chosen measures and safeguards. It is encouraged to document the measures that were not implemented as well.

Regarding practical challenges, we can mention data-in-transit security issues. You need to think of choosing secure channels for data transmission when personal data will be sent. For example, using firewall and encryption protocols like HTTPS and TLS (SSL is considered obsolete). In addition to that, you should consider that the transmission of personal data through a regular email channel is usually an insecure option and that you should use other methods of communication. As have been stated by so many privacy professionals, password management is such an important part of technical and organisational measures. Not having it can cause a regrettable headache in the future, which in hindsight could have been easily preventable by a bit of planning.

If you are struggling with grasping the security of processing and implementing measures in your organisation then you can reach out to our Professional Services Team (that I am part of). We can help you properly address the challenges in your processing operations regarding security and measures.

One of the reasons to implement appropriate and effective security measures is to counteract potential data breaches. It is precisely what the next blog post will be about. See you around next Tuesday for a post on that requirement!

See more related posts »

Related blog posts