2.1 Risk management framework

Requirement

For the purpose of Article 21(2), point (a) of Directive (EU) 2022/2555, the relevant entities shall establish and maintain an appropriate risk management framework to identify and address the risks posed to the security of network and information systems. The relevant entities shall perform and document risk assessments and, based on the results, establish, implement and monitor a risk treatment plan. Risk assessment results and residual risks (12) shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies.

Guidance

• The entity can use its current risk management framework or adopt a new one (13). A risk management framework is the structured approach used by an entity to identify, assess, manage and mitigate its cybersecurity risks.
• Create a risk treatment plan that associates the identified risks with assets and the measures mitigating the associated risks and takes into account, at least, elements (g) to (h) in point 2.1.2 of the Annex to the regulation. The plan should at least include:
  • a description of the identified risk and how it can negatively affect security objectives;
  • a risk treatment option (for example risk avoidance, risk mitigation, risk transfer or sharing or risk acceptance);
  • the assets associated with the risk;
  • the measures which mitigate the risk;
  • a procedure for assessing the effectiveness of implementation of the measure(s);
  • implementation timelines; and
  • responsible roles.
• Consider residual risks from third parties, for example, data breaches, unaddressed vulnerabilities, regulatory non-compliance from the from the third-party side and over-reliance on a single third party.
• Ensure residual risks are accepted by management bodies or, where applicable, persons who are accountable and have the authority to manage risks, in line with the acceptable residual risk levels of the entity.
• Make sure that management bodies or, where applicable, persons who are accountable and have the authority to manage risks approve the risk-assessment results and risk-treatment plan.

Examples of evidence

• Documented risk management framework.
• Documented results from previous risk assessments.
• Documented risk treatment plan.
• Record of approval of risk assessment results by management bodies or by persons who are accountable and have the authority to manage risks.
• Record of approval of residual risks by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks.

Requirement

For the purpose of point 2.1.1, the relevant entities shall establish procedures for identification, analysis, assessment and treatment of risks (‘cybersecurity risk management process’). The cybersecurity risk management process shall be an integral part of the relevant entities’ overall risk management process, where applicable. As part of the cybersecurity risk management process, the relevant entities shall: (a) follow a risk management methodology; (b) establish the risk tolerance level in accordance with the risk appetite of the relevant entities; (c) establish and maintain relevant risk criteria; (d) in line with an all-hazards approach, identify and document the risks posed to the security of network and information systems, in particular in relation to third parties and risks that could lead to disruptions in the availability, integrity, authenticity and confidentiality of the network and information systems, including the identification of single point of failures; (e) analyse the risks posed to the security of network and information systems, including threat, likelihood, impact and risk level, taking into account cyber threat intelligence and vulnerabilities; (f) evaluate the identified risks based on the risk criteria; (g) identify and prioritise appropriate risk treatment options and measures; (h) continuously monitor the implementation of the risk treatment measures; (i) identify who is responsible for implementing the risk treatment measures and when they should be implemented; (j) document the chosen risk treatment measures in a risk treatment plan and the reasons justifying the acceptance of residual risks in a comprehensible manner.

Guidance

• Select a risk management methodology (14).
• Establish the entity's risk appetite, that is the amount of risk that the entity is strategically willing to accept to achieve its objectives. Criteria may include (indicative, non-exhaustive list):
  • business strategic objectives;
  • stakeholder expectations;
  • regulatory requirements; and
  • organizational culture.
• Define the risk tolerance level, which refers to the level of risk that an entity is willing to accept in pursuit of its long-term objectives. Examples may include (indicative, non-exhaustive list):
  • acceptable downtime for systems for which criticality is high (e.g. up to two hours of downtime per month);
  • tolerance for data loss (e.g. loss of data with low criticality within a 24-hour window);
  • maximum financial loss that can be absorbed without jeopardizing operations (e.g. up to EUR 100,000 in recovery costs);
  • willingness to invest a certain percentage of revenue in measures (e.g. 5% of annual revenue);
  • adherence to regulatory obligations with specific penalties or fines influencing risk acceptance;
  • acceptable level of customer dissatisfaction or negative media exposure from a data breach (e.g. tolerating one major incident every few years);
  • acceptance of certain vulnerabilities based on risk mitigation measures in place (e.g. outdated software provided that it is monitored and patched regularly);
  • time frame for responding to and recovering from incidents (e.g. a maximum of 48 hours for containment); and
  • acceptance of minor incidents as part of normal operations while prioritizing major threats.
• Define risk acceptance criteria, which may include (indicative, non-exhaustive list) (15) :
  • accepting risks categorized as low severity, such as minor data leaks that don't expose sensitive information;
  • accepting risks assessed as having a low likelihood of occurrence (e.g. certain rare types of cyberattacks);
  • accepting risks if the cost of mitigation exceeds the potential impact (e.g. not upgrading legacy systems if the upgrade cost is significantly higher than potential losses);
  • accepting specific compliance risks if there is a plan in place to address them within a defined timeframe (e.g. temporarily accepting minor non-compliance with a commitment to remediate within six months);
  • allowing certain risks in low-criticality systems or departments that do not affect core business operations (e.g. accepting a risk in a test environment);
  • accepting certain vulnerabilities for a defined period while planning for remediation (e.g. accepting the risk of outdated software for three months until a full upgrade can be completed);
  • accepting risks where the expected incident impact falls below a predetermined financial threshold (e.g. losses under EUR 50,000 accepted without further action);
  • accepting risks after informing stakeholders and receiving their agreement, particularly if they understand the trade-offs involved; and
  • accepting residual risks where existing measures reduce the likelihood or impact to an acceptable level (e.g. using encryption for sensitive data but accepting risks of loss due to user error).
• Define risk criteria, that is, how the entity evaluates the significance of the risks that it identifies and makes decisions concerning risks. Risk criteria may include (indicative, non-exhaustive list):
  • alignment with risk appetite: accepting risks that align with the organization's overall risk appetite, such as delays in internal reporting processes that do not impact customer service or compliance;
  • regulatory and legal exposure: prioritizing risks based on potential legal or regulatory consequences, such as treating violations of the General Data Protection Regulation (GDPR) involving customer data as high-risk due to potential fines and reputational damage;
  • reputational impact: escalating risks that could significantly harm the organization's public image, such as incidents likely to attract media attention;
  • risk velocity: giving higher priority to risks with high velocity, such as zero-day exploits that can be weaponised before patches are available;
  • recovery complexity: treating risks as critical if they involve complex or time-consuming recovery, such as cyber-attacks on legacy systems with limited vendor support;
  • emerging technology risks: Considering risks involving emerging technologies as higher priority, such as AI systems producing unexplainable or non-compliant decisions due to lack of transparency;
  • stakeholder sensitivity: re-evaluating risks that concern key stakeholders, such as risks flagged by the board, regulators or major customers, even if the assessed technical risk is low.
• Criteria for performing cybersecurity risk assessments refer to consequences, likelihood or level of risk. These may refer to (indicative, non-exhaustive list):
  • the importance of assets;
  • the severity of threats;
  • the vulnerability of network and information systems (16);
  • impact analysis;
  • existing measures; and
  • stakeholders concerns or requirements.
• Make a list of the main risks for the security of network and information systems, taking into account the main threats to the assets in scope.
• Make sure that each risk is associated with at least one:
  • of the risk treatment options or a combination of them, in line with the results of the risk assessment and in accordance with the entity’s policy on the security of network and information systems (recital 11 of the regulation); and
  • specific risk treatment measure.
• Develop risk-treatment plans to address the elements in points (i) and (j) in point 2.1.2 of the Annex to the regulation.
• Assign responsibilities to appropriate individuals or teams for executing these risk treatment plans.

Examples of evidence

• Documented cybersecurity risk-management process that takes into account elements referred to in point 2.1.2 of the Annex to the regulation.
• Documented risk-management methodology and/or tools that take into account at least elements (a) to (f) in point 2.1.2 of the Annex to the regulation.
• List of the main risks described at a high level, including underlying threat(s) and unaddressed vulnerabilities and their potential impact on the security of networks and services.
• Make sure that the entity follows an all-hazards approach (check that the risk-assessment approach addresses a wide range of potential threats and risks, not just the cyber ones, but natural or man-made, accidental or intentional threats and risks).
• Evidence that residual risks resulting from dependencies on third parties are listed and mitigated.

Requirement

When identifying and prioritising appropriate risk treatment options and measures, the relevant entities shall take into account the risk assessment results, the results of the procedure to assess the effectiveness of cybersecurity risk-management measures, the cost of implementation in relation to the expected benefit, the asset classification referred to in point 12.1 and the business impact analysis referred to in point 4.1.3.

Guidance

• Make sure that personnel take into account the elements referred to in point 2.1.3 of the Annex to the regulation.

Examples of evidence

• Guidance for personnel on assessing risks that takes into account the elements referred to in point 2.1.3 of the Annex to the regulation.

Requirement

The relevant entities shall review and, where appropriate, update the risk assessment results and the risk treatment plan at planned intervals and at least annually and when significant changes to operations or risks or significant incidents occur.

Guidance

• Review risk assessment results and risk treatment at least annually taking into account:
  • results of audits and previous reviews,
  • status of implementation of the measures described in the risk treatment plan (see the policy on the assessment of the effectiveness of measures in line with the Annex to Regulation, point 7.1.1);
  • changes to the information systems;
  • changes to the environment of operation;
  • post-incident review findings (section 3.6); and
  • trends and changes related to threats and vulnerabilities, as they may affect risks.

Examples of evidence

• Documentation of the review process.
• Review comments or change logs for the risk assessment and risk treatment plan.

Tips: guidance

• Ensure that key personnel use the risk management methodology and tools.
• Overall, the entity has four risk treatment options associated with each risk. Each option should be accompanied by specific risk treatment measures (indicative, non-exhaustive list of examples):
  • Risk avoidance: as a measure to treat this risk, the entity might choose to eliminate activities or conditions that expose the entity to this risk, for example, discontinuing the use of a vulnerable software application.
  • Risk mitigation: as a measure to treat this risk, the entity might choose to implement measures to reduce the likelihood or impact of such a risk. This can include installing firewalls, using encryption and conducting regular security training for employees.
  • Risk transfer or sharing: as a measure to treat this risk, the entity might choose to shift parts of the risk impact to another party, typically through insurance or outsourcing certain functions to third-party providers. However, it is important to note that such arrangements do not eliminate the entity’s overall accountability or legal obligations regarding the risk. For instance, purchasing cyber insurance may cover potential data breach costs, but the entity remains responsible for implementing appropriate security measures and complying with data protection regulations.
  • Risk acceptance: as a measure to treat this risk, the entity might choose to acknowledge the risk and decide to accept it without taking any specific action, often because the cost of mitigation is higher than the potential impact. This approach is usually accompanied by a contingency plan to manage the risk if it materialises. The approach should be clearly documented, supported by a realistic estimation of potential costs and including financial provisions to address the impact should the risk materialise.
• Make sure that the risk from vulnerabilities assigned to the highest classification (e.g. ‘critical’ in the common vulnerability scoring system (CVSS)) or equivalent is not accepted, if possible (section 6.10).
• Concerning the risk treatment plans, the entity might additionally take into account:
  • findings of the review;
  • implementation steps; and
  • resources needed.
• Manage any exceptions in the risk treatment plans’ implementation.

Tips: examples of evidence

• Documented action plans developed in response to review findings.
• Key personnel knowing the main risks (e.g. evidence from emails, interviews and awareness-raising sessions).
• Documented risk treatment plan implementation exceptions.
• Risk register.