Just… implemented or merely glossed over?
Receive a package of free GDPR guides and micro-training sessions
Risk Analysis and DPIA
GDPR is always viewed through the lens of the so-called “proactive approach to data protection.” The EU legislator has granted data controllers considerable discretion regarding the methods of processing personal data – as long as they ensure appropriate security for that data. As is well known, the tool that enables the determination of what measures will provide that “appropriate” security is risk analysis – for the resources involved in processing, such as operating systems, office equipment, human resources, paper documents, etc., and for data processing processes, i.e. Data Protection Impact Assessment (DPIA).
Risk Analysis for Resources
According to Article 32(1) of the GDPR, “Taking into account the state of the technical knowledge, the cost of implementation, and the nature, scope, context, and purposes of processing as well as the risk of infringement of the rights or freedoms of natural persons
with varying probabilities of occurrence and severity of the threat, the data controller and the data processor implement appropriate technical and organizational measures to ensure a level of security appropriate to that risk.”
According to our IT experts, a poorly conducted risk assessment for resources is almost an inevitable audit finding if the implementation was not carried out by a specialized company with many years of experience in the field of personal data protection.
Important
We discussed the importance of support from market-verified experts in the article: "In a Safe Direction - Ongoing Support in GDPR Compliance". This solution is gaining popularity as it represents a compromise between a cautious approach to personal data protection and a certain "safeguard" against the consequences of unlawful processing of such data, balanced against a budget and the ability to minimize expenditures while maintaining a sense of security for the organization.
In their opinion, the causes should primarily be sought in the improper approach to risk assessment
and the lack of focus on its most important elements – a poorly executed risk assessment is likely to lead to incorrect identification of threats concerning a given resource, and consequently to inadequate security measures that simply will not fulfill their role.
For example, if the risk assessment did not identify the threat posed by cleaning staff having access to a room that allows free access to personal data in the absence of the data controller's employees, then despite the implementation of security measures in the form of an access control system for the premises – the risk of unauthorized access to data has not been eliminated at all.
Provisional tools for conducting risk assessments that are available to companies engaged in data protection "on the fly," the lack of collaboration with process owners in identifying potential risks present in it, and thus their exclusion, as well as modeling the risk assessment
in a manner convenient for the data controller that does not require too many actions or financial outlays – all of this is the norm, not an exception to the rule. It is unfortunate that such serious shortcomings pertain to an area on which the entire system of personal data protection in the organization is based – a proactive approach allows for the selection of security measures designed to protect all personal data processed in the organization precisely based on a properly conducted risk assessment.
Risk Analysis - We Provide a Form
By using the file included in the article, you will conduct a step-by-step risk analysis: you will identify safeguards, indicate vulnerabilities, as well as threats and their possible consequences. Based on this, you will calculate the level of risk and determine whether the risk exceeds the acceptable threshold. We wrote about this in the article: "Risk Analysis for Resources Processing Personal Data".
However, conducting the risk analysis itself – and documenting it thoroughly, primarily by indicating the methodology, including the adopted criteria – is one thing, while creating a plan for dealing with the identified risk, approved by management/decision-makers and subsequently implemented, is another. The most common structural deficiencies in such a plan relate to incorrect assumptions that, as an organization, we simply cannot meet, e.g., excessively high costs or overestimating the human resources needed to implement the adopted solutions. A data controller may find themselves in an even worse situation if they improperly selected actions aimed at reducing/eliminating risk or simply "overdid it," investing disproportionately high amounts in safeguards that were not necessary to achieve the intended goal. This may all stem from either a lack of awareness on the part of the data controller or the ignorance of external consultants who, having only recently engaged in personal data protection, lack professional and reliable tools as well as the necessary experience, undertake perhaps the most challenging task in light of the GDPR, poorly defining and assessing processes, failing to consider all criteria of the risk analysis (including those expressed in the guidelines of the Article 29 Working Party), which results in erroneous assumptions in the risk management plan and exposes our organization to financial losses greater than the over-invested safeguards that an uninformed "expert" persuaded us to adopt.
A significant portion of the above observations, particularly poorly developed tools and a misunderstanding of the very idea of risk analysis, also applies to Data Protection Impact Assessments (DPIA). From our perspective, one of the main issues related to conducting DPIAs is their… non-conduct. It is worth noting that many condition the necessity of conducting one on the content of Article 35(3) of the GDPR, which states that a DPIA is required particularly
in the case of:
- systematic and comprehensive assessment of personal factors relating to natural persons, which is based on automated processing, including profiling, and serves as the basis for decisions that have legal effects on the individual or similarly significantly affect the individual;
- large-scale processing of special categories of personal data referred to in Article 9(1), or personal data concerning criminal convictions and offenses, as referred to in Article 10; or.
- systematic large-scale monitoring of publicly accessible areas.
A considerable number of data controllers, ignoring the term “particularly” used above, cease further analysis after rejecting the above three conditions. However, attention should be drawn to the principle expressed in the guidelines of the Article 29 Working Party regarding DPIAs, according to which, in most cases, a data controller may determine that processing meeting two of the nine criteria listed below will require a Data Protection Impact Assessment. These criteria are:
|
|
For example, imagine a situation where you run a small manufacturing company employing about 20 people – it would certainly be difficult to find any profiling that produces legal effects concerning an individual, and the sensitive data of employees would certainly not qualify as being on a "large scale," while the issue of systematic monitoring of publicly available places on a large scale would be completely irrelevant from your perspective.
Now consider that as a motivating boss, you have introduced an attractive bonus system for your employees – the implementation of which based on selected criteria may be considered as a evaluation or scoring (evaluation of work performance, personal factors, etc., allowing for the determination of the bonus amount); you use video surveillance, which undoubtedly constitutes systematic monitoring; you process sensitive data, primarily medical certificates of your employees, even though you do not do this on a "large scale"; even the mere fact that you process personal data of your employees fulfills another criterion from the above list of the Working Group! Thus, you have accumulated 4 out of a possible 9 – a DPIA must undoubtedly be conducted. One can only speculate how many processes have not undergone a Data Protection Impact Assessment, even though they undoubtedly should have.
Important
It is all the more surprising that since May 25, 2018, the date when the GDPR came into effect, only one (sic!) entity has approached the supervisory authority after prior consultations as of the date of publication of this article. Let us recall that according to Article 36(1) of the GDPR, "If the Data Protection Impact Assessment referred to in Article 35 indicates that processing would result in a high risk if the data controller does not take measures to mitigate that risk, the data controller shall consult the supervisory authority before commencing processing." How is it possible that practically no organizations consult with the supervisory authority? Is it because they are so good at mitigating risks? Or perhaps they are completely unaware of the need to conduct a DPIA for their processes?
Adjustment of the IT Area
Contrary to the beliefs of many data controllers, actions related to adapting the IT area are not limited solely to the risk analysis discussed above. Another area that directly affects this is Article 32 of the GDPR, which stipulates that organizations processing personal data are required to implement "appropriate" technical and organizational measures.
Undoubtedly, the point concerning the necessity to ensure the ability to continuously maintain the confidentiality, integrity, availability
and resilience of processing systems and services (Article 32(1)(b)) may raise the most doubts in this regard. It turns out that even a thorough familiarization with the regulations, including all the guidelines published by the President of the Polish Data Protection Authority or the Guidelines of the Article 29 Working Party, will not provide us with a clear answer as to what technical and organizational measures will be sufficient in this respect. The obligation specified
in the GDPR, contained in a single sentence, is so broad that we can essentially fit any possible security measure that comes to mind. So what remains for us? The most commonly used practice is to apply guidelines that have been in use in the international market for some time. This refers, of course, to ISO standards, particularly those from the "family" 27000 concerning information security management, which consequently translates into the protection of personal data.
When discussing the adaptation of the IT area to new legal regulations, it is impossible to overlook the appropriate documentation. Although the GDPR does not impose on data controllers a precise scope of internal policies, it clearly emphasizes their presence within the organization. The Polish supervisory authority has addressed the issue related to their required content. Here, once again, we see a strong connection between the relevant legal act and the aforementioned international ISO standards. The President of the Polish DPA, referring to the requirement to have appropriate security policies, strongly suggests – and even explicitly indicates – well-known elements contained in the standard PN-EN ISO/IEC 27002:2017.
Free knowledge about GDPR.
Use it freely!
to non-aggregated, unstructured data, information stored outside databases, such as on local hard drives of company computers or external mobile storage devices. Of course, there are many more such locations. Another challenge is also the implementation of the right to be forgotten concerning backup copies that have not been exempted from this requirement by regulations. Various practices exist. Starting from preparing a test environment where the backup is restored, the record is deleted, and then the copy is created again, to shortening its retention period to 3 months, as stipulated in Article 12 of the GDPR, which allows us to extend the fulfillment of the aforementioned obligation. Touching on the topic of adapting the IT environment,
one should certainly not forget about the functionality of recording objections in the case of using systems for marketing purposes. Additionally, such systems, in accordance with the accountability principle discussed above, should guarantee the ability to verify the exact date and time of consent being given, as well as its withdrawal.
Involvement of external entities in data processing.
Currently, it is difficult for organizations to operate based on a business model that does not require cooperation with external entities. Typically, such cooperation is inextricably linked
to the transfer of personal data to these entities. And this is where the GDPR comes into play. Some data controllers ignore the problem and simply do not recognize (or do not want to recognize?) the relationship between the data controller and the data processor. Others, in the name of what they perceive as a "safe approach," massively enter into data processing agreements with all identified external entities, without deeper analysis and without delving into the details of this relationship, hoping that in the event of a supervisory authority audit, their initiative will be appreciated—even if it is misguided.
When organizing the area related to the entrustment of data to external entities (data processors), attention should be paid to two key issues: first, whether we are indeed dealing with a data processing relationship, and second, whether as a data controller we can demonstrate that the choice of the data processor was made based on an objective and reliable assessment of whether our future processor guarantees the processing of entrusted data in accordance with the GDPR.
Each data processing relationship should be examined separately based on contractual arrangements and actual actions related to the transfer of data "outside," which is why it is not possible to present a golden formula for always correctly identifying a data processing relationship in just a few magical sentences – it often requires hours of analysis, discussions with individuals involved in the process, and reviews of contract records and the process itself. However, we would like to draw attention to the fact that the existence of a data processing relationship is determined by the factual state, not by the conclusion of a data processing agreement by the parties. The data processing agreement is not constitutive – thus, the mere fact of its conclusion does not create a data processing relationship –
but is declaratory, meaning it confirms an already existing relationship between the data controller and the data processor. Often, indications regarding the nature of the relationship connecting us with the other entity can be found in the doctrine
and various guidelines, including interpretations issued by the General Inspector for Personal Data Protection prior to May 25, 2018.
The second issue, equally important, concerns the verification of the external entity in terms of its compliance with the requirements set forth in the GDPR. We entrust data processing to other entities for convenience, their specialized knowledge in a given area, cost savings, and sometimes even to transfer the risks associated with data processing to that external entity – it should therefore be clear that as data controllers, we have an obligation to ensure that the data processor provides an adequate level of implementation of technical and organizational measures ensuring compliance of data processing with the provisions of the GDPR. Article 28 explicitly grants data controllers the right to audit the data processor, while the latter is obliged to provide the data controller with all information demonstrating compliance with the GDPR in the context of data processing entrustment – such an audit is usually a fiction due to staffing shortages and significant financial burdens, especially when we use the services of multiple entities. For this reason, many opt for a convenient alternative in the form of a checklist for the processor, based on which the data controller can decide to entrust data to a specific entity and, in accordance with the principle of accountability, demonstrate due diligence in selecting the processor.
Important
We present a template for such a survey in the article: "Compliance of the processor with the GDPR - methods of verification". Utilizing the provided document will enable the data controller to make a decision regarding the selection of a data processor that will ensure the processing of entrusted data in accordance with the requirements of the GDPR.
Remember that if you rely on one of the above exceptions, your organization, as the data controller, should be able to demonstrate its fulfillment – also in the event of an audit by the President of the Polish DPA.
What is visible "on the outside"
Many shortcomings and underdeveloped solutions on the part of data controllers are evident at first glance. The most common mistakes that may result in a complaint from the data subject, and consequently an audit by the supervisory authority, include:
- making the conclusion of a contract conditional on consent to marketing or providing data other than those necessary to conclude the contract (e.g., a scan of an identity document),
- human errors made by inadequately trained personnel in data protection,
- collecting an excessively broad range of personal data,
- failure to fulfill the information obligation when collecting data from a natural person,
- unauthorized sharing of data with third parties,
- conducting (unwanted) marketing activities without a proper legal basis,
- incorrectly constructing consent clauses and privacy notices,
- inadequate response to requests from individuals related to the exercise of their rights.
So, have you implemented it or just put on a facade?
In light of the new year, in the spirit of accountability, summaries, and the need for continuous improvement, take an objective look at your organization and consider whether the actions taken during the implementation of the GDPR have created a coherent, reliable, and compliant personal data protection system, or merely give the impression that you, as a data controller, are compliant with the new regulations. Implementing the GDPR is not a one-time action, but a process that lasts as long as you have any contact with personal data in your professional activities. Do not settle for merely "putting on a facade" for the most critical elements of the system, hoping that it will allow your organization to survive – it will not – at least for as long as the GDPR is in effect.
