How to Conduct a Risk Analysis in Compliance with GDPR – Practical Guidelines

18 listopada 2024

Personal data protection is a topic that is widely discussed. However, we often focus only on one side of the coin – the formal aspects of compliance. Consent clauses, user information, and regulations – all of these have already been thoroughly analyzed and described. But what about the other side, namely the security of the processed data? This pillar often remains in the shadows, even though it is equally important and it is precisely this that protects us from real threats.

In this article, we aim to shed light on the security of processed data. We will show you why risk analysis is key to effective data protection and how to conduct it in practice. As a result, your company will not only comply with regulations but will also gain a true advantage in a world full of data security challenges.

What is risk

Risk accompanies every aspect of our lives – from daily decisions to more complex professional actions. In the context of personal data protection, risk refers to the chance of a situation occurring that could negatively impact data security and the rights and freedoms of individuals whose data is being processed. Risk analysis, therefore, means carefully examining potential threats and their consequences – from accidental data breaches to deliberate actions that could lead to the disclosure or loss of information.

The definition of risk in personal data protection, as in organizational management, encompasses two fundamental elements: the likelihood of a threat occurring and its potential impact. Risk analysis allows organizations to assess which situations require special attention and what protective measures should be implemented to effectively minimize these risks and ensure compliance with GDPR.

What is the purpose of risk analysis

The purpose of risk analysis is not (as many may think) merely to satisfy the requirements of the legislator. Risk analysis is a powerful tool in the hands of management and decision-makers that allows them to answer a fundamental question: Are our safeguards actually effective? Simply put, risk analysis provides objective information on which organizations can make informed, rational decisions.

Until now, many of us have become accustomed to a reactive approach to risk management. Actions were primarily taken to meet legal requirements. However, the philosophy of GDPR changes this dynamic. Instead of merely meeting the expectations of the legislator, each organization must develop effective data protection methods on its own. GDPR, unlike the Personal Data Protection Act of 1997, does not provide a list of specific safeguards. What it offers is a technology-neutral provision that everyone must fulfill with their own solutions. Risk analysis thus becomes a tool that helps organizations independently determine how best to protect data, rather than relying solely on ready-made schemes.

Let us take a moment to consider this: over 25% of fines imposed in Poland for RODO violations result from improper application of security measures. This is not a coincidence. In most cases, these sanctions stem from a lack of risk analysis, its improper execution, or, equally importantly, a failure to act based on the conclusions drawn from that analysis. And if we add to this the fact that over 20% of fines relate to errors in managing breaches, we uncover something concerning – nearly half of all fines are directly related to broadly understood risk management.

But what does this actually mean? It means that organizations not only do not understand how critical risk management is, but also do not take actions that could prevent serious consequences. The problem lies not only in theory but in the practical daily decisions that are often made without full awareness of the consequences.

What is the essence of risk analysis under the GDPR

Imagine that conducting a risk analysis in the context of the GDPR is like driving a car. You play the role of the driver – the data controller. While driving, you do not think only about yourself, but about other road users – the individuals whose data you process. You consider what risks you may pose to them. It is like asking: Is there a risk that I might hit someone? Could I cause an accident? These risks concern others, but they arise directly from your actions.

Webinar - how to conduct a risk analysis under the GDPR

This is what distinguishes risk analysis under the GDPR from other analyses, such as those based on the ISO 27001 standard. In the latter case, you are still the driver, but your perspective is entirely different. You then consider what risks might affect you personally: a fine, a photo from a speed camera, an accident, or perhaps vehicle theft. In other words, you focus on protecting your own interests.

Risk analysis under the GDPR always prioritizes the individual and their personal data. It is not just a technical procedure – it is a responsibility for others. It is a view of the world from the perspective of privacy protection and the safety of the people who have trusted you. Therefore, every data controller must learn to look at the road from this very perspective – not only through the lens of their own needs but, above all, in a way that protects those who are within their sphere of influence.

How Many Risk Analyses Function Under GDPR

We often encounter the belief that there is only one risk analysis under GDPR. This is a common but incorrect view. Why? Not only do the provisions of GDPR state otherwise, but this is also confirmed by the practice of the President of the Polish Data Protection Authority. The excerpt of the article you see before you comes from the website of the Polish Data Protection Authority. It clearly shows that risk analysis under GDPR is not a single assessment, but several significant assessments.

The first of these is the so-called general risk analysis mentioned in Article 32 of GDPR. This is the basic assessment of safeguards aimed at ensuring an appropriate level of data protection. But that is not all. Article 35 of GDPR also introduces the obligation to conduct a Data Protection Impact Assessment (DPIA) – particularly when processing may involve a high risk of infringing the rights and freedoms of individuals whose data is being processed.

Documentation of Personal Data Processing in Accordance with GDPR

In summary, the new documentation of personal data processing compliant with GDPR, which will also serve as an instrument demonstrating compliance of the processing activities with legal provisions, should additionally include elements such as:

  • Records of processing activities and the scope of the register of categories of processing activities
    Art. 30 GDPR
  • Guidelines for classifying breaches and the procedure for reporting data breaches to the supervisory authority (Polish DPA)
    Art. 33(3) GDPR
  • Procedure in the event of breaches that may cause a high risk of infringing the rights and freedoms of individuals, regarding informing them of the actions they should take to mitigate this risk
    Art. 34 GDPR
  • Procedure for maintaining internal documentation constituting a register of data breaches
    Art. 33(5) GDPR
  • Report from the Conducted General Risk Analysis
    Art. 32 GDPR
  • Report on Data Protection Impact Assessments – if applicable
    Art. 35 sec. 7 GDPR
  • Procedures related to pseudonymization and encryption – if applicable
  • Business continuity plan
    Art. 32 sec. 1 point b GDPR
  • Disaster recovery procedures and their testing
    Art. 32 sec. 1 points c and d GDPR
Source: Polish DPA

What are the differences between these two analyses? Let us start with the general risk analysis referred to in Article 32 of the GDPR. First and foremost, this is an analysis that concerns both the data controller and the data processor. It forms the foundation in the process of establishing technical and organizational measures that are intended to ensure the protection of personal data. In other words, this analysis indicates what security measures we should implement to effectively protect the relevant categories of personal data processed in a given operation. Through it, we can identify threats and adjust technical and organizational safeguards to the specifics of the data being processed, ensuring compliance with the requirements of the GDPR.

Essentially, this analysis should be conducted before the commencement of data processing or the implementation of a new resource involved in processing operations. This constitutes an element of so-called data protection by design. The frequency of updates to this analysis depends on the adopted cycles, for example, once a year. Additionally, it should be reviewed again after each personal data breach to assess whether the measures taken were sufficient.

On the other hand, the Data Protection Impact Assessment (DPIA), referred to in Article 35 of the GDPR, is more detailed and applies only when we act as the data controller. Importantly, a DPIA is not required for every processing operation. We apply it only when the processing operation is associated with a high risk of infringing the rights and freedoms of the data subjects.

Similarly to the general risk analysis, we also conduct the DPIA before the processing begins. Although there is no direct legal obligation to review the DPIA periodically, it is recommended to regularly update this assessment in the event of significant changes in the processing conditions, such as changes in purposes, data recipients, or categories of processed information.

Requirements
Risk Analysis (Article 32 GDPR)
DPIA (Article 35 GDPR)
Who?
Data controller and data processor
Data controller
What?
Processing operation (individual resources involved)
Processing operation
How?
Identify the resources involved in the processing operations and assess them
Identify processing operations that generate high risk and assess them
When?
Before processing begins
Before processing begins
How often?
In accepted cycles (e.g., once a year)
-
When additionally?
As needed (e.g., after a breach)
As needed (e.g., when risk changes)

How to Manage Risk

Cezary Lutyński

PROMOTIONAL OFFER

Time to Manage
Risk in GDPR

Are you wondering how to secure personal data in your organization? During a brief conversation, you will learn about our offer and receive a discount

CHOOSE A CALL DATE

According to experts from the UK National Cyber Security Centre (NCSC), cybersecurity risk is most often assessed in the context of individual components of the system, such as hardware (for example, computers, servers) and software. This approach is referred to as bottom-up or component risk assessment. It involves analyzing risk as a combination of the value of individual system components and the likelihood of their breach.

In practice, this means the necessity to assess the level of threats faced by these components, their vulnerabilities, and the potential consequences for business operations in the event of a breach. The component approach allows analysts to precisely identify specific risks associated with individual elements of the system. As a result, they can prioritize risks based on their potential impact. Prioritizing risks in this manner enables a focus on minimizing the most serious threats first, if possible.

Another approach, known as the complementary approach to risk management, primarily focuses on the goals or tasks of the system rather than its individual components. This type of strategy is called a top-down or system-driven approach, as it analyzes the entire system as a whole, taking into account all its elements and their interactions, rather than just individual components.

In the system-driven approach, interactions between various aspects of the system are considered, including between people, business processes, and technology. Risk analysts, when applying this approach, start by defining the overall goal of the system, then add further details. In this way, they create a design that allows achieving that goal. Understanding the interdependencies between the individual elements of the system is key here.

How does risk management fit into a systemic approach? In addition to analyzing the objectives that the system is intended to achieve, top-down risk management also considers the objectives that the system should exclude. Here, we are talking about potential losses or threats that may arise during the operation of the system. For example, in the case of a system controlling automatic safety doors, the objective is to enable safe passage for individuals. However, a loss that needs to be identified could be, for instance, the accidental admission of unauthorized persons or the risk of injury to users from the door mechanism.

Loss analysis may seem obvious; however, experience shows that these negative scenarios are rarely taken into account at the early stages of system design. Typically, we focus on the system's objective, and we begin to consider losses only in more advanced phases of the project when we already have a clear picture of the system's operation. As a result, it often leads to situations where security issues are "tacked on" at a later stage, rather than being integrally considered from the outset of the project lifecycle.

To better understand the connections between bottom-up and top-down techniques, it is worthwhile to refer to the hierarchy of abstraction created by Jens Rasmussen, presented in the diagram below.

Systemic Management
Application
Methodologies / Techniques
Resource-based Risk Management
  • risk analysis for resources involved in processing operations
  • deconstruction of less complex systems with well-understood connections between individual components
  • analysis of systems whose functions (objectives) have already been agreed upon by stakeholders
  • ISO/IEC 27005
  • NIST
  • COBIT 5
Systemic Risk Management
  • investigation of security breaches resulting from the complex interaction of multiple system components
  • determination of system security requirements at the design stage
  • gathering feedback from various stakeholders regarding what the system should and should not achieve
  • analysis of security breaches that cannot be traced back to a single cause of the breach
  • STAMP
  • TOGAF
  • SABSA

This model introduces the idea that systems can be viewed through different levels of abstraction. By analyzing only the top three layers of this hierarchy, we focus on the conceptual aspects of the system. This means that our analysis concentrates on what the system is intended to achieve, rather than on the details of its operation.

The bottom-up, component-based approach refers to the analysis of potential errors at the two lower levels of this hierarchy. This includes physically existing elements of the system or their representations, such as detailed architecture diagrams that describe specific technological decisions.

In contrast, the top-down or system-driven approach refers to the overall purpose of the system and potential losses. The goal is to identify scenarios in which losses could occur as a result of implementing the conceptual design of the system. At this level of abstraction, the concepts of threats and vulnerabilities, typical of component-based methods, lose significance. Instead, we seek ways in which the system may lead to losses.

The purpose of introducing the hierarchy of abstraction model is to demonstrate that the component-focused risk management technique and the system-focused technique analyze risk in fundamentally different ways, yet complement each other. Both techniques are valuable risk management tools when applied to the appropriate types of problems.

How to Choose the Best Risk Management Methodology

The component-based risk management technique and the system technique can be used in parallel to obtain a complementary view of risk. For example, the top-down approach can help identify the most critical systems, interactions, or weaknesses, which can then be analyzed in more detail using the bottom-up approach.

Each of these methods brings value in its own way, so neither is superior to the other. However, they are better suited to different types of risk management issues:

  • Component-based approach is most effective when analyzing risks associated with existing technical vulnerabilities. An example might be a situation where an organization has a computer that, for operational reasons, cannot be updated or secured. This type of risk analysis allows for the assessment of what safeguards can be applied around this sensitive point in the system to minimize the risks arising from the unpatched vulnerability.
  • Systemic approach is useful when analyzing large, complex systems, especially in the context of errors arising from interactions. It may reveal that while each component of the system operates correctly on its own, there are flaws in the way they interact that could lead to security breaches. An example might be the risk of fraud in an online payment system. In this case, the component-based approach may not fully account for the impact of user systems on the security of the entire system, which is why the systemic approach is more effective.

By employing these techniques together, the organization can gain a more comprehensive view of the risks, better understand the threats, and implement more effective protective measures.

How to conduct a risk assessment

In the following sections of the article, we will describe the approach to risk assessment that is most commonly used in practice and is detailed in the guide of the Polish Data Protection Authority. We will focus on the methodology based on the ISO 27005 standard, which provides widely accepted guidelines for information security risk management.

The choice of this approach is based on several significant premises. It is a well-known methodology that is widely used in organizations around the world, enabling the creation of coherent frameworks for risk assessment. This approach offers a standard set of tools for the accurate identification, assessment, monitoring, and control of information security risks. This is particularly important in the context of legal compliance, including GDPR. The ISO 27005 standard also provides flexibility. Organizations can tailor the level of detail and sophistication of the analysis to their specific needs and capabilities. This is crucial for companies at varying levels of maturity in information security management.

Working with good GDPR tools - it's not work!

We chose this methodology also because its assumptions and processes are discussed in the guide of the Polish Data Protection Authority. This facilitates its application in organizations operating in the Polish market, including public institutions, which often base their actions on the guidelines of supervisory authorities.

The ISO 27005 standard is based on key stages of risk management. This approach includes the following actions:

  1. Identification of assets and threats – identifying the informational resources of the organization and potential threats that may affect the confidentiality, integrity, or availability of these resources.
  2. Determination of vulnerabilities and potential impacts – analyzing weaknesses in security that may be exploited by threats, and assessing the consequences of their realization.
  3. Risk assessment – evaluating the likelihood of threats occurring and their possible impact on the organization, which allows for the classification of risk according to its significance level.
  4. Planning and implementing remedial actions – establishing appropriate security measures that will allow for the reduction of risk to an acceptable level or its control.

The ISO 27005 standard, as a systematic approach to risk management, not only supports compliance with legal requirements but also increases the transparency of the security management process within the organization. This allows for better collaboration between teams responsible for information security and the management of the organization. It also facilitates decision-making based on an informed risk assessment and established priorities. For organizations that wish to meet high security standards, this is a proven and effective methodology that enables the implementation of an approach compliant with international standards and best industry practices.

Step One – Inventory of Resources and Processes

We should begin the risk analysis by defining the processing operations that are carried out remotely. This can be most easily achieved by reviewing the records of processing activities and the records of categories of processing activities maintained by the organization. These records reveal all operations in which the organization acts as a data controller or data processor. In the article Records of Processing Activities and GDPR – Everything You Need to Know, we explain what these records are and how to maintain them correctly.

For the purposes of this article, we assume that the process being analyzed will be employment.

The next step is the detailed identification of all resources used in data processing operations related to a given process. At this stage, it is crucial to determine all elements supporting data processing, including hardware, software, network infrastructure, and technological solutions that directly or indirectly support the execution of operations.

Through comprehensive inventorying of resources, the organization gains a fuller picture of the environment in which data processing operations are carried out. This is essential for the subsequent stages of risk analysis and the effective implementation of remedial measures.

To assist you in identifying all groups of resources used in a given process, we present the following typology.

-+Hardware

  • Portable devices – laptops, tablets, smartphones, wearable devices (for example, smartwatches), portable hard drives.
  • Desktop devices – desktop computers, servers, workstations.
  • Peripheral devices – printers, scanners, cameras, card readers, keyboards, monitors.
  • Data carriers – optical discs (CD/DVD), microfilms.
  • Electronic carriers – USB drives, SSDs, external drives.
  • Other carriers – SD cards, SIM cards, network drives (NAS).

-+Software

  • Operating systems – Windows, macOS, Linux, mobile systems (Android, iOS).
  • Service or maintenance software – antivirus tools, backup systems, update management systems.
  • Administrative software – identity management software (IAM), ERP systems, CRM.
  • Business applications – software specific to the organization's activities (for example, project management applications, accounting applications, customer service support systems).

-+Network

  • Media and supporting services – internet infrastructure, internet connections, VPN, satellite connections.
  • Active or passive relays – routers, switches, proxy servers, Wi-Fi access points.
  • Communication interfaces – network cables (Ethernet), USB interfaces, Bluetooth, NFC, fiber optic interfaces.

-+Personnel

  • Top management – decision-makers in the organization, responsible for strategy and security policies.
  • Users – operational employees who use systems and applications on a daily basis.
  • Operations or maintenance staff – IT administrators, technicians, service specialists responsible for the ongoing maintenance of the infrastructure.
  • Software developers – programmers, testers, quality assurance (QA) specialists, individuals responsible for the development and implementation of applications.

-+Locations

  • External environment – the area around the headquarters, physical security (for example, fencing, monitoring).
  • Headquarters – buildings of the organization, offices, workspaces.
  • Core services – data centers, server rooms, locations for storing critical resources.
  • Connectivity – telecommunications infrastructure (for example, telephone lines, internet networks).
  • Utility and technical services – power supply systems, air conditioning, heating, fire protection systems.

-+Organization

  • Authorities – supervisory institutions, regulatory bodies, external auditors.
  • Organizational structure – HR department, IT department, operations department, legal department, which support resource management and security.
  • Project or system organization – project structure, project resource management, roles and responsibilities within IT projects.
  • Subcontractors/suppliers/manufacturers – partner companies, technology providers, external IT service and technical support providers, who may impact data security or access to the organization's systems.

Step two – identification of threats

Marcin Kuźniak

PROMOTIONAL OFFER

Time for GDPR risk analysis

Are you wondering how to effectively assess risks to personal data? During a brief conversation, you will learn about the offer and receive a discount

CHOOSE A MEETING TIME

The next step is to identify potential threats to personal data processed within remote processes. According to GDPR regulations, these threats primarily include the following events:

  • Accidental or unlawful destruction of personal data – situations in which data is irreversibly lost or deleted due to error, failure, or deliberate unlawful action.
  • Accidental or unlawful loss of personal data – cases in which data is unintentionally lost, preventing further processing or recovery.
  • Accidental or unlawful modification of personal data – the risk of unintended or illegal changes to data that may affect its integrity and reliability, leading to potential errors in processing.
  • Unauthorized disclosure or access to personal data – situations in which data is shared with individuals who do not have the appropriate permissions, exposing the organization to the risk of privacy breaches.

Each of these threats can lead to serious consequences for the security and privacy of personal data, which is why early detection and understanding of them is essential. Identifying threats forms the basis for developing remedial measures and an action plan that will minimize the risk of data breaches in remote processing activities.

Threat Identification - Examples

 

Step Three – Identification of Safeguards

In the next part of the analysis, the organization should identify and assess existing safeguards for individual resources. This will help avoid unnecessary work or additional costs when implementing the risk management plan, for example, by preventing duplication of safeguards or their excessive implementation.

The following actions may assist in identifying existing or planned safeguards:

  • Review of security documentation – analysis of documents containing information about current and planned safeguards, such as implementation plans for risk management actions or security policy documentation.
  • Interviews with key individuals responsible for data security – conducting discussions with individuals holding key positions related to personal data protection, such as the Data Protection Officer (DPO), system administrator, or other security specialists. It is also important to seek the opinions of users to verify the actual state of safeguard implementation in practice.
  • Audits – conducting audits that may include both personal and automated processes to independently assess the level of safeguards and detect any gaps or areas requiring improvement.
  • Review of internal audit results – analysis of reports from internal audits, which may provide valuable insights into the state and effectiveness of existing safeguards, as well as indicate areas where additional protective measures need to be implemented.

These actions allow for a comprehensive understanding of the current level of security and the preparation of a more effective risk management plan tailored to the specific needs and resources of the organization.

GDPR. Support is useful!

Step Four – Identification of Vulnerabilities

The next step in the risk analysis is the identification of vulnerabilities in the utilized resources that may increase the likelihood of threats. It is crucial to understand which elements of infrastructure, procedures, or employee behaviors may facilitate the realization of risks, particularly under specific conditions such as remote work.

At this stage of the analysis, it is worth considering various sources of vulnerabilities:

  • Technical Vulnerabilities – including hardware, software, and system security, such as lack of encryption, weak passwords, lack of access controls, or absence of regular updates. These can increase the risk of cyberattacks.
  • Physical Vulnerabilities – arising from the workplace, for example, lack of physical security for company equipment, the possibility of leaving documents or devices in publicly accessible home spaces.
  • Organizational Vulnerabilities – encompassing policies, procedures, and security culture within the organization that may be ill-suited to the specifics of remote work. Examples include lack of clear rules regarding the use of personal devices for work, absence of training on remote work security, or insufficient confidentiality protection rules in a home environment.
  • Personal Vulnerabilities – related to employee behaviors and habits that may lead to unintentional data disclosure. Attention should be paid to situations such as conducting conversations with clients in the presence of other household members, sending business documents via personal email accounts, or using unsecured personal devices.

Conducting a vulnerability analysis allows for a better understanding of which areas are most likely to face threats and enables the implementation of preventive measures that will reduce the risk of threats materializing in the future.

Identification of Vulnerabilities - Examples

 

Step Five – Estimating the Probability and Impact of Threats

Subsequent actions focus on estimating the likelihood of a given threat occurring and its potential consequences for the individuals whose data is concerned (for example, clients).

For both the likelihood and the severity of the threat, we recommend adopting a scale from 1 to 4. This helps avoid selecting middle values and reduces the risk of distorting the results of the analysis (which could occur with a scale of 1–3 or 1–5).

For the severity of the threat, the following legend can be adopted:

    • Low severity of threat (value 1) – individuals whose data is concerned will not be affected by the consequences of the breach or will encounter minor inconveniences that they can overcome without any problems (time needed to re-enter data, impatience, irritation, etc.).
    • Medium severity of threat (value 2) – individuals whose data is concerned may face significant inconveniences that they will be able to overcome despite certain difficulties (additional costs, fear, misunderstanding, stress, minor physical injuries, etc.).
    • High severity of threat (value 3) – individuals whose data is concerned may encounter significant inconveniences that they should be able to overcome, but with serious difficulties (financial fraud, being placed on a list of unserviceable clients at banks, property damage, loss of employment, lawsuits, deteriorating health, etc.).

Knowledge Base GDPR
Free knowledge about GDPR.
Use it freely!
Webinars, articles, guides, training, snapshots, and assistance. Welcome to the ODO 24 knowledge base.
I'M IN

  • Very high severity of threat (value 4) – individuals whose data is concerned may face significant, and even irreversible consequences that they may not be able to overcome (financial troubles, for example, resulting from unpaid debt or inability to work, long-term psychological or physical injuries, death, etc.).

 

For the likelihood of the threat, the following explanations can be adopted:

  • Low likelihood (value 1) – the materialization of the threat in connection with the exploitation of vulnerabilities of resources involved in processing operations does not seem possible for the selected sources of risk.
  • Medium probability (value 2) – the realization of a threat related to the exploitation of vulnerabilities of resources involved in processing operations seems difficult for selected risk sources.
  • High probability (value 3) – the realization of a threat related to the exploitation of vulnerabilities of resources involved in processing operations seems possible for selected risk sources.
  • Very high probability (value 4) – the realization of a threat related to the exploitation of vulnerabilities of resources involved in processing operations seems exceedingly easy for selected risk sources.

Estimating the probability and impact of threats - examples

 

The final risk level is the product of the weight of the threat and its probability for a given resource involved in the processing operation. Possible combinations of the indicated values are presented in the table below.

Low (1)
Medium (2)
High (3)
Very High (4)
Weight
4 Low
Low risk: Requires monitoring
8 Medium
Medium risk: Actions required in the long term
12 High
High risk: Actions required in the short term
16 Very High
Very high risk: Immediate actions required
3 Low
6 Medium
9 High
12 Very High
2 Low
4 Low
6 Medium
8 High
1 Low
2 Low
3 Medium
4 High

The result of this stage of the risk analysis is a list of risks with assigned significance levels. Based on this, the organization should develop a risk management plan. This plan will define the priorities for implementing specific remedial actions, the individuals responsible for their execution, and the timelines for these actions.

It is worth emphasizing that in relation to the identified risks, the organization may adopt one of four courses of action:

  • risk reduction,
  • risk acceptance,
  • risk avoidance,
  • risk transfer.

It is recommended that the organization take active measures to reduce the level of risk. It should select appropriate safeguards so that the residual risk (remaining after the implementation of the actions specified in the risk management plan) can be reassessed as acceptable risk. In this article, we assume that acceptable risk is defined as low or medium-level risk.

The accredited DPO course will confirm your high competencies

Step Six – Risk Management Plan

The management's decision to adopt a risk management plan should be based on a strategic analysis of the impact of threats on operational activities and on data security indicators. After reviewing the risk analysis report, management verifies the recommended remedial actions, taking into account the costs of their implementation, available resources, and the potential impact of residual risk (remaining after the application of remedial measures). A key criterion for the decision is the compliance of the adopted actions with the organization's security policy and legal requirements, such as the GDPR, as well as the cost-effectiveness of the proposed solutions.

In the adopted risk management plan, management must clearly define the priorities for implementing individual remedial measures and assign responsibility for their execution to appropriate individuals or departments. It is important to establish measurable performance indicators for the implemented actions (KPIs). These indicators will allow for ongoing monitoring of the plan's implementation. Management also defines a schedule of actions along with periodic reviews, enabling the assessment of the effectiveness of the measures taken and the introduction of necessary adjustments. Such a decision-making structure allows for systematic risk management and ensures compliance with regulatory frameworks and the strategic security objectives of the organization.

How to Document Risk Analysis Results for GDPR Purposes

Documenting the results of the risk analysis for GDPR purposes requires a methodical approach to ensure full transparency and auditability of the process. The results of the risk analysis should be presented in the form of a report that contains detailed information about identified threats, vulnerabilities, assessed levels of risk, and recommended remedial measures. Each stage of the analysis should be documented in a way that allows for clear tracking of the decisions made and the criteria adopted for assessment.

The report should include the following elements:

  • Asset Identification – a list of resources that are analyzed in the context of risk, such as IT systems, operational processes, personal data.
  • Description of Threats and Vulnerabilities – a detailed discussion of the threats and weaknesses of the utilized resources that may affect data security.
  • Risk Assessment – a detailed classification of risk based on a scale of probability and impact, to which specific values are assigned to each risk in order to standardize the assessment.
  • Risk Management Plan – a comprehensive description of the actions that will be taken to reduce, accept, transfer, or avoid risk, including responsible persons, resources, and a timeline for actions.
  • Summary and Control Indicators – established key performance indicators (KPIs) that will allow monitoring of the implemented remedial measures and conducting periodic reviews of the effectiveness of the actions taken.

From our experience, the Polish Data Protection Authority often expects that the adoption of the risk management plan will be formally approved by the organization's management in the form of a resolution. In this way, management demonstrates that it prioritizes data protection and consciously accepts responsibility for implementing the recommendations from the risk analysis.

Moreover, a formal management resolution gives the documentation greater significance within the organization and ensures that the remedial measures become part of the business strategy, rather than merely an ad hoc response to legal requirements. This allows management and those responsible for data security to continuously monitor the effectiveness of the implemented actions. They are aware that the risk management plan is not only an operational document but also a component aligned with the security management objectives throughout the organization.

How Often Should the Risk Assessment Be Updated

The risk assessment should be updated regularly to remain aligned with actual threats and the dynamically changing conditions of data processing. It is generally recommended to update it once a year or at other established intervals consistent with the organization's policy. However, there are situations that require additional, immediate verification of the risk assessment. These include:

  • Significant Changes in Data Processing Processes – for example, the introduction of new IT systems, changes in the scope of personal data, modification of data collection or processing methods, which may affect the level of risk.
  • Occurrence of a security incident – any data breach should prompt the organization to review and assess the risks again to determine whether the implemented safeguards are sufficient.
  • New legal regulations or guidelines – changes in the regulations or guidelines of the Polish Data Protection Authority may require adjustments to the risk analysis to meet new standards.

Therefore, the frequency of updates should be flexible and tailored to the specifics of the organization's activities. However, regular reviews at least once a year and after any significant change ensure that the risk analysis meets the requirements of the GDPR and effectively protects personal data.

Risk analysis – common mistakes

GDPR Audit
Do you also prefer prevention over treatment?
A GDPR compliance audit is a holistic examination that shows where the organization stands.
SEE MORE
Despite six years of the GDPR being in effect, risk analysis remains an area where organizations frequently make mistakes – and the consequences can be costly. Examples of decisions from the Polish Data Protection Authority show that the lack of a formal risk analysis, improper approach to its execution, and failure to implement the findings are the most common mistakes in data protection. Here is what we can learn from high-profile cases involving penalized companies.

  1. Lack of formal risk analysis: Morele.net

The Polish Data Protection Authority found that the company Morele.net, one of the largest online stores, did not conduct a formal, documented risk analysis for the personal data being processed. According to the decision ZSPR.421.2.2019, the analysis was performed on an ad-hoc basis, in an informal manner, and covered selected processes rather than the entire spectrum of data processing. Therefore, Morele.net could not demonstrate that the risk assessment was conducted prior to the data security breach. This constitutes a violation of Article 32(1) of the GDPR, which requires risk assessments and the implementation of appropriate data protection measures. As a result of these shortcomings, the Polish Data Protection Authority imposed a substantial fine on Morele.net, noting that an undocumented approach to risk management deprives the company of real tools to protect its customers' data.

  1. Inadequate Approach to Risk Analysis: Virgin Mobile

The company Virgin Mobile made another mistake by improperly assessing the likelihood of risk. The Polish Data Protection Authority, in decision DKN.5112.1.2020, indicated that the company based its risk analysis solely on past experiences – on the premise that since a particular incident did not occur in the past, it is unlikely to happen in the future. This erroneous assumption overlooks the possibility of new threats emerging. The Polish Data Protection Authority emphasized that the risk assessment should take into account future incident possibilities, rather than relying solely on historical statistics. In this case, the company paid a high price for its approach, and the decision served as a signal to the market that risk analysis must be dynamic and consider a broader context of data security, not just the organization's history.

  1. Failure to Implement Recommendations from Risk Analysis: President of the District Court in Zgierz

Another common mistake is the lack of implementation of recommendations resulting from the risk analysis. In the case of the President of the District Court in Zgierz, the Polish Data Protection Authority, in decision DKN.5131.22.2021, stated that although the court identified a medium level of risk for the threat of "loss of equipment, media," the actions taken were limited to training employees. Meanwhile, the implementation of adequate technical safeguards – such as encryption of media or strict access rules – could have better protected the data. The Polish Data Protection Authority reminded that training alone can raise staff awareness, but is not sufficient to reduce the risk of loss of media or eliminate other technical threats. This decision illustrates that implementing a full spectrum of technical and organizational safeguards is essential to meet GDPR requirements.

  1. Focus on the Organization's Perspective Instead of Protecting Data Subjects

One of the most common, yet more subtle mistakes is conducting a risk analysis from the perspective of the organization rather than the individuals whose data is being processed. It often happens that companies focus on financial and reputational risks to themselves, while overlooking the real consequences for individuals. However, a risk analysis compliant with the GDPR requires that the priority be to look at the privacy protection of users, clients, or employees. Focusing solely on threats to the organization can lead to the implementation of inadequate or insufficient safeguards, which creates the risk of personal data being exposed or accessed unlawfully.

What are the consequences of failing to conduct a risk analysis in accordance with the GDPR

Failing to conduct a risk analysis in accordance with the requirements of the GDPR can have serious and far-reaching consequences. They significantly impact the security of personal data as well as the stability of the organization—both financially and reputationally.

The lack of a formal and comprehensive risk analysis means that the organization is unable to properly identify threats and implement appropriate safeguards to protect the personal data being processed. This oversight leads to an increased risk of security incidents, such as unauthorized access to data, loss, modification, or disclosure of data. The provisions of the GDPR clearly indicate that data controllers must systematically assess the risks associated with data processing and take actions that effectively minimize these risks.

One of the main consequences of failing to fulfill this obligation is high financial penalties. The Polish Data Protection Authority may impose a fine that, depending on the severity of the violation and the number of affected individuals, can reach millions of zlotys. An example is the case of Morele.net. According to the decision of the Polish Data Protection Authority, the company did not conduct a formal risk analysis, which exposed customer data to significant threats. As a result, a penalty was imposed on it, which could have been avoided had the risk analysis process been conducted in accordance with the requirements of the GDPR.

Failure to take appropriate actions in the area of risk analysis also entails other legal consequences. If a data breach occurs, the individuals whose data is affected may file lawsuits for damages, citing violations of their privacy rights. An organization that does not meet the GDPR requirements regarding risk assessment and management may find it difficult to demonstrate that it has taken all necessary measures to prevent incidents—further strengthening the position of the affected individuals.

Ignoring risk analysis also has a reputational dimension. In an era of widespread awareness regarding personal data protection, clients and business partners have high expectations concerning security standards. A data-related incident, especially one resulting from a lack of risk assessment and the implementation of appropriate safeguards, can permanently damage the organization's reputation. Companies in the retail sector, such as Morele.net, particularly feel the impact of such losses, as security incidents negatively affect customer trust, and consequently, financial results.

Read also:

Receive a free package of 4 tutorials and 4 e-learning trainings
The controller of your data is ODO 24 sp. z o. o.