Chapter 6: Risk Management and DPIAs – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide


The Regulation notes that controllers and processors “should evaluate the risks inherent in the processing and implement measures to mitigate those risks”115. This same consideration is mentioned several times throughout the Regulation, requiring the controller and the processor to take risks into account at many stages throughout the lifecycle of the personal data in question. While it stops short of saying that the organisation should have an explicit risk management programme, it is clear that a systematic and comprehensive approach is the best way to ensure compliance.

Risk management is now a standard expectation of corporate management and, while smaller organisations might manage risk relatively informally, most organisations of any size will now have a formal approach to the subject, which will include, for instance, a board risk register and regular board reviews of corporate risk. Risk management is not necessarily complicated, but there is a variety of ways you might approach it, along with associated standards, models, training opportunities, consultants, and so on.

Effective risk management is also an important tool for achieving compliance with the GDPR. The Regulation reinforces the risk management that organisations must execute in order to build the necessary preventive measures against data breaches and other forms of cyber attack.

DPIAs as part of risk management

DPIAs are essentially a form of risk management. You use them to identify risks to the data subject’s privacy, the security of their personal data, and their rights and freedoms in relation to their data. Data protection risks (the risks to data subjects) should now be identified and managed alongside risks to the organisation as part of business as usual. A DPIA should therefore inform and be part of your larger corporate risk management activity. The DPIA identifies a set of risks specific to personal data or the data subject’s rights, the risk management programme then categorises and analyses these risks, and finally determines an appropriate response. This is all part of the privacy compliance framework.

Risk management standards and methodologies

Risk management is a vast field. For decades, organisations around the world have been dealing with ideas about managing risks to almost every facet of business, so there are a variety of methodologies and standards that account for different industries and sectors, geographical or political regions, languages and corporate ideologies. You could likely find a new risk management model in every Member State of the EU.

Because of this variety, and because your organisation may already have a risk management model in place, we’ll focus here on the more common methodologies espoused by ISO standards – ISO 27001, ISO 27005 and ISO 31000 in particular. ISO standards are appropriate because they can be integrated with many management systems, they are based on decades of studying best practice, and they are widely popular, which makes finding support or resources relatively simple.

ISO 31000

ISO 31000:2009, Risk management – Principles and guidelines, is the central repository for risk management practices in the ISO standards. It is widely used across the world. Many disciplines that ISO has developed standards for will have their own variety of risk management, but ISO 31000 provides a framework into which these more specific risk management methodologies can fit, enabling the organisation to consolidate diverse risk management activities.

For an organisation that needs to comply with the GDPR, ISO 31000 can provide a model framework to integrate your various risk management processes. This may not be necessary at all for organisations that already manage a variety of types of risk, but for smaller organisations or those that haven’t historically taken a systematic approach to risk, the framework could be a useful tool. At the very least, the Standard provides valuable guidance.

ISO 31000’s definition of “risk” is the “effect of uncertainty on objectives”116. ISO 31000 goes on to clarify that “an effect is a deviation from the expected – positive and/or negative”, which provides some additional clarity. Essentially, a risk is something that can impact your ability to meet objectives. In the context of the GDPR, those objectives would be to protect personal data, and to comply with the Regulation and relevant local laws.

In accordance with this definition, the risk management framework that ISO 31000 espouses is focused on reducing the threats to your objectives. It quite clearly states this in the first principle of risk management: “Risk management contributes to the demonstrable achievement of objectives”117.

ISO 31000 outlines a basic structure for a risk management framework, which is informed by a set of risk management principles and carried out practically through a set of defined processes. This framework is illustrated, in a marginally simplified format, in Figure 7.

Figure 7: A basic structure for a risk management framework

The principles, framework and processes operate at different levels within the organisation. The principles, being constants, are simply objectives for risk management; the framework is operated from the governance level by senior management and/or the board; and the processes are managed at the procedural level by appropriately skilled and qualified staff.

You’ll also note that the framework can be conveniently visualised in a PDCA (Plan-Do-Check-Act) cycle.

Critically, ISO 31000 states that it is intended to “harmonize risk management processes in existing and future standards. It provides a common approach in support of standards dealing with specific risks and/or sectors, and does not replace those standards”118. That is, the framework and core practices should be taken as universal – an overarching approach to risk management, if you will – while the processes will generally be informed or wholly replaced by whatever processes are necessary for the types of risk under consideration. For GDPR compliance, these will be privacy and data protection risks.

Even when it describes the “process” level, it does so by providing guidance on appreciating things like the internal context, how to define risk criteria, evaluating risks, and so on. In short, it simply recognises that all risk management processes have a broadly similar set of inputs, outputs, and processes to derive outputs from the inputs, and gives the reader some context. It is not a specification and it cannot be certified, ISO 31000 is simply guidance.

The process of risk management laid out in ISO 31000 is strikingly simple once you pare it down to the core:

  1. Ensure that communication and consultation take place throughout the risk management process (Clause 5.2 of ISO 31000). People will be informed and asked for input, others may proffer information or experiences that had not been considered. You should ensure that those who are involved in risk assessment and treatment are open to such communication and that they understand the need for consultation.119
  2. Establish the context of the risk assessment, both internally and externally (Clause 5.3). Who are the stakeholders? What is important? What is the legal, regulatory and contractual environment? What are the organisation’s objectives? Understanding the context is an important feature of many management systems; it informs how you go about your risk assessment, how you determine risk criteria, what you deem to be a risk, the resources you have to mitigate risks, and so on.
  3. Identify the risk (Clause 5.4.2). This can be approached a number of ways. You could examine your information assets to identify the threats that are likely to impact them or you could consider scenarios that could cause harm to an asset or assets. We’ll look more at asset- and scenario-based risk assessments a little later in this chapter. Regardless, you should be aiming to identify all of the relevant risks within the context of the risk assessment. In the case of a GDPR risk assessment, it should be risks to personal data and the rights and freedoms of data subjects.
  4. Analyse the risk (Clause 5.4.3) by identifying how likely it is and the potential impact on the organisation should the risk occur.
  5. Evaluate the risk (Clause 5.4.4) against the risk criteria. ISO 31000 states that the risk criteria “should reflect the organization’s values, objectives and resources”120. This should include your organisation’s attitudes to compliance with the GDPR. Risk criteria will be used to determine how important a given risk is, which will be based on your organisation’s risk appetite. The criteria are the measure of the risk, and the results of how a risk is evaluated against the criteria will inform how you choose to respond to the risk.
  6. Respond to the risk (Clause 5.5). Your risk response will be based on the outputs of the risk evaluation, taking into account the severity of the risk, where it sits in relation to the risk criteria, the organisation’s risk appetite and the availability of treatment options for the risk.
  7. Develop a risk treatment plan (Clause 5.5.3) to formally document the identified risks, your chosen responses and how the responses are to be implemented. This should include noting who is responsible for the treatment of each risk, when the treatment should be completed, and so on.
  8. Subject the risk assessment to monitoring and review (Clause 5.6). You will need to determine how to measure the state of implementation as well as metrics to ensure that the treatment is in place and active. These measurements should be subject to formal review and any discrepancies with the planned results should then receive corrective action. Like almost everything else, the risk treatments should also be looked at as part of continual improvement.

Annex A of ISO 31000 describes the attributes of a mature and effective risk management framework. You can look over this in order to gauge the effectiveness of your risk management regime, or to set objectives as part of the continual improvement process.

ISO 27001 and ISO 27005

ISO 27001, which has been mentioned several times already in this manual, is the ISO standard for information security management. Part of the specification relates to information security risk assessment and treatment, which is clearly of interest in relation to the GDPR. It’s broader than a privacy risk assessment, and it could easily be argued that such a risk assessment in conjunction with a DPIA should be adequate for compliance.

ISO 27001 leaves the detail of the risk assessment methodology up to the organisation, stating that “the organization shall define and apply an information security risk assessment process”121. This process must fall within certain specified parameters. As you’ll see, this process isn’t much different from that outlined in ISO 31000.

ISO 27001 requires you to establish a set of criteria for the risk assessment (Clause 6.1.2 a). These should include the organisation’s risk acceptance criteria and the criteria under which the organisation will perform information security risk assessments. These are both derived from the organisation’s risk appetite, which should reflect the organisation’s attitude to the repercussions of a data breach.

The risk assessment methodology needs to produce “consistent, valid and comparable results” (Clause 6.1.2 b). This is necessary to ensure that the organisation can accurately apply appropriate treatments. If the same risk could be assessed multiple times and achieve different outcomes, there could be no confidence in the risk assessment and the resulting treatments.

ISO 27001 also requires that the risk assessment process identifies the risks to the confidentiality, integrity and availability of information assets (Clause 6.1.2 c). The focus on identifying risks to confidentiality, integrity and availability ensures that risks are not identified simply for the perceived risk of harm: the organisation must have a reasonable expectation that there is a risk to at least one of the three attributes of information security.

Each risk should be assigned a risk owner (Clause 6.1.2 c) whose job it is to ensure that the selected risk response is properly implemented. In most cases, this involves implementing the measures that were selected to mitigate the risk. It’s worth noting that a single risk may impact a number of assets, and so the risk owner should ensure that all of the relevant assets are protected from the risk.

As in ISO 31000, the process includes an analysis of the risks (Clause 6.1.2 d). This analysis should focus on three factors: the consequences of the risk occurring; the “realistic likelihood” of the risk occurring; and, as a factor of impact and likelihood, the levels of risk. In most risk assessment programmes, this will be represented by a table mapping impact against likelihood, as shown in Figure 8.

Figure 8: Impact vs likelihood

In this method, mapping the risk’s impact against its likelihood provides the level of risk. Measures of impact and likelihood should be determined. These measures are typically qualitative or might have a numeric aspect. For instance, you might decide that “very low impact” is annualised damages of less than £100, while very high impact is annualised damages of more than £50,000. Equally, “very unlikely” might be taken to mean “it will occur less than once per year” and “very likely” as “it will occur every day”.

Once you have analysed the risks, evaluate them against the risk acceptance criteria (Clause 6.1.2 e). One approach might be to decide that risks categorised as “low” or “very low” fall within the organisation’s appetite for risk, but that more severe risks will require an appropriate response. The actual response may even be related to this table, such as deciding to terminate all activities that face “critical” risks.

The final stage of the risk assessment, just as in ISO 31000, is to determine the responses to the risks and to document the risk treatment plan (Clause 6.1.3). This comprises two main stages: selecting an appropriate response for each risk, and determining the controls necessary to implement those responses. This risk treatment plan should be clearly documented. It should also be signed off by the risk owners.

ISO 27001 also mandates the creation of a Statement of Applicability, which is a record of all of the controls that the organisation has selected, whether they have been implemented, and justifications for excluding any controls from Annex A of the Standard. This is an exercise in ensuring that the organisation has considered the full set of best practice controls.

Controls are processes or practices that you put in place to reduce the impact or likelihood (or both) of a risk. They’re often considered best practice, and there are a number of sources that provide more information122. Controls are often very broad, of course (such as a “secure perimeter”), so you’ll need to determine for yourself just how the control should be implemented in your organisation. The risk owner will also be responsible for making sure that controls are implemented effectively and that they are monitored to ensure they continue being effective.

ISO 27005 is a related standard that focuses explicitly on information security risk management. It provides additional context and guidance for organisations that want to establish a more complete risk management framework to support their information security efforts. If you’re interested in going down this path, it’s important to remember that ISO/IEC 27005:2009 actually predates ISO/IEC 27001:2013. As such, some of the content could be seen as outdated or superseded by ISO 27001. Despite this, the actual changes introduced by ISO 27001 simply provide more options for risk assessment, and do not completely negate the guidance in ISO 27005.

Risk responses

You will need to respond to each risk that exceeds your organisation’s risk acceptance criteria. This is sometimes called risk treatment, and comprises four broad categories of response:

  1. Treat (also called “control” or “risk modification”).
  2. Tolerate (also called “risk acceptance” or “risk retention”).
  3. Terminate (also called “risk avoidance”).
  4. Transfer (also called “risk sharing”).

Risk treatment involves applying controls to reduce the level of risk. A control might reduce the impact of the risk or its likelihood, or it might reduce both; it might even eliminate the risk entirely (although that’s probably excessive). The goal when applying controls is to reduce the risk until it falls within your risk acceptance criteria.

Figure 9: The organisation’s risk acceptance criteria (line) vs the level of a given risk (circle)

In the example shown in Figure 9, the line represents the organisation’s risk acceptance criteria, while the level of a given risk is circled at the top. To treat this risk, the organisation could take a couple of routes: they could apply controls to reduce both the impact and the likelihood, or apply enough controls to reduce the impact considerably. In either case, once the controls are applied, the risk should then fall within the risk acceptance criteria.

Risk tolerance is an informed decision to do nothing. This is generally the default response to risks that already fall within the risk acceptance criteria, but it may also be applied to risks where the cost of treatment outweighs the business benefits. A risk that could come to pass fifty times a day, for instance, may only have an annualised financial impact of £10. Alternatively, it could have a significant impact but be so vanishingly unlikely that you have to wonder why you even included it as a risk in the first place.

Risk termination is the elimination of the risk in its entirety. This is normally done by simply removing the target of the risk, such as by terminating the process or getting rid of the asset in question. You might choose this response if the cost of treating the risk is excessive and the return on investment would not be worth the effort.

Risk transfer is the act of sharing the risk with other parties. There are several ways to do this, such as by outsourcing the process or asset to another company so that they have to face the risk themselves (but note that transferring a data protection risk in this way will not absolve a data controller of its accountability under the GDPR for protecting personal data), or by purchasing insurance to reduce the impact of the risk, and so on. You might choose to transfer the risk if the cost of treating it is excessive but the process or asset is too valuable to terminate.

Risk relationships

When considering something abstract like privacy risks, it’s important to understand the full range of actual risks and how seemingly disparate forms of risk can have significant impacts on privacy.

In particular, you should remember that physical risks can also be privacy risks. For instance, having information visible on a screen close to a window, unlocked doors and physical damage are all physical risks that could also be privacy risks.

Cyber risks, which are risks related to information and communication technologies, have a more obvious overlap with privacy risks. Given the modern reliance on and saturation of IT in processing information, any significant cyber risk is likely to also be a significant privacy risk., and the speed with which cyber risks can come to pass and the volumes involved can make them significantly more dangerous than other kinds of risks.

Continuity risks can prevent an organisation from operating, either permanently or temporarily. As the GDPR requires you to provide data subjects with access to their information, this can quickly become a privacy risk. If you suffer a continuity incident and cannot provide data subjects with that access for any extended period of time, you’re not just suffering from your own loss of access, you’re also incidentally inhibiting the data subject’s ability to act on their rights.

A loss of continuity could raise other risks. If a continuity incident results in electronic doors failing to lock, they pose a physical risk to the premises that is, as we’ve seen, a potential privacy risk.

As your organisation gains experience in conducting risk assessments, you’ll find that the relationships between different types of risk become more apparent, and that a comprehensive risk management framework that can take these risks into account and deal with them appropriately is the best way to protect both the organisation and the personal data that it holds.

Risk management and personal data

The key additional step that an organisational risk management framework has to make to accommodate GDPR compliance is to recognise that the risks to the rights and freedoms of data subjects of any particular processing activity may have a different profile than it does in relation to the organisation. The corruption of the data of one data subject may have a minimal impact on an organisation processing thousands of data records but it may have a significant impact on that individual. The GDPR requires organisations to consider that impact on the individual and to determine appropriate controls that will reduce those individual impacts to levels that are likely to be acceptable both under the law and to the data subjects. This additional thought process is a critical one for the organisational risk manager and will have to be documented and appropriate audit trail evidence retained to demonstrate that the organisation has dealt with its obligation to identify and implement appropriate organisational and technical controls.


115 GDPR, Recital 83.

116 ISO/IEC 31000:2009, Clause 2.1.

117 ISO/IEC 31000:2009, Clause 3 a).

118 ISO/IEC 31000:2009, Clause 1.

119 You may recall the RACI (responsible, accountable, consulted, informed) matrix described in Chapter 1. Risks related to information assets or processes, for instance, should trigger some form of communication/consultation with the relevant asset or process owner.

120 ISO/IEC 31000:2009, Clause 5.3.5.

121 ISO/IEC 27001:2013, Clause 6.1.2.

122 Annex A of ISO 27001 is the obvious source; each of the controls listed there has extensive guidance available in ISO 27002, the companion code of practice. Other sources include COBIT, the Cloud Security Alliance’s Cloud Controls Matrix, NIST’s SP 800-53, and so on.