How to Conduct a Cybersecurity Risk Assessment

A cybersecurity risk assessment is the systematic process of identifying threats to your information systems, analysing vulnerabilities that those threats could exploit, evaluating the potential impact and likelihood of exploitation, and documenting the results in a form that supports risk treatment decisions. It is not a penetration test (which evaluates specific technical vulnerabilities), not a compliance audit (which evaluates adherence to specific requirements), and not a business impact analysis (which evaluates the consequences of process disruption). A risk assessment subsumes elements of all three but serves a broader purpose: providing the organisation with a comprehensive, prioritised view of its cyber risk landscape.

Under EU regulations, risk assessment is not discretionary. NIS2 Article 21(2)(a) lists risk analysis as the first mandatory measure category for essential and important entities. DORA Article 8 requires financial entities to identify all sources of ICT risk, assess cyber threats and ICT vulnerabilities relevant to their ICT-supported business functions, and assess the potential impact of ICT disruptions. GDPR Article 35 mandates Data Protection Impact Assessments (DPIAs) for processing operations likely to result in high risk to individuals' rights and freedoms. Each regulation has slightly different scoping and documentation requirements, but all share a common expectation: that organisations systematically evaluate the risks they face and make documented decisions about how to address them.

The frequency of risk assessment is also regulated. DORA Article 8(6) requires financial entities to perform ICT risk assessments upon major changes to network and information system infrastructure, processes, or procedures. NIS2, through its transposition into national law, typically requires regular reassessment — with the exact cadence varying by Member State. GDPR DPIAs must be performed before commencing the relevant processing activity and reviewed when there is a change in the risk. Best practice is to conduct a comprehensive organisational risk assessment annually, supplemented by targeted assessments triggered by significant changes, incidents, or new threat intelligence.

Threat identification answers the question: what could go wrong? A threat is any circumstance or event with the potential to adversely affect an asset through unauthorised access, destruction, disclosure, modification, or denial of service. Threats can be intentional (targeted cyberattacks, insider threats, state-sponsored espionage), unintentional (misconfiguration, accidental data exposure, human error), or environmental (natural disasters, power failures, pandemic-related disruptions). A thorough risk assessment considers all three categories.

For EU organisations in 2026, the threat landscape has several distinctive characteristics. State-sponsored cyber operations targeting EU critical infrastructure have escalated significantly since 2022, with ENISA's Threat Landscape 2025 identifying state-nexus actors as a top-tier threat to energy, transport, and government sectors — all NIS2 Annex I categories. Ransomware remains the most financially impactful threat to EU businesses, with DORA-obligated financial entities being particularly attractive targets due to their perceived willingness to pay to restore operations. Supply chain attacks have matured from theoretical concerns to operational realities, with the exploitation of managed service providers and software dependencies accounting for an increasing proportion of EU incidents. And the EU AI Act's entry into application introduces a new threat vector: adversarial manipulation of AI systems used in high-risk decision-making.

Vulnerability analysis identifies the weaknesses that threats could exploit. Vulnerabilities are not limited to unpatched software (though that remains the most commonly exploited category). They include architectural weaknesses (flat networks without segmentation, single points of failure), procedural weaknesses (lack of multi-factor authentication, inadequate access reviews, missing logging), human weaknesses (susceptibility to social engineering, insufficient security awareness), and supply chain weaknesses (reliance on single vendors, lack of vendor security assessment, unclear contractual security obligations). For each threat-vulnerability pair, assess whether existing controls adequately mitigate the risk or whether residual exposure remains.

Use structured methodologies for threat identification rather than brainstorming sessions. The STRIDE model (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) provides a systematic way to identify threats to technical systems. ENISA's threat taxonomy provides a comprehensive categorisation of threat types relevant to EU organisations. For DORA-specific assessments, the threat-led penetration testing (TLPT) framework under Article 26 — based on the TIBER-EU framework — provides a threat-intelligence-driven methodology for identifying realistic attack scenarios against financial entities.

Risk treatment is where the assessment translates into action. For each risk above your organisation's risk acceptance threshold, you must select a treatment strategy: mitigate (implement controls to reduce impact or likelihood), transfer (shift the risk to a third party through insurance or contractual arrangements), avoid (cease the activity that generates the risk), or accept (acknowledge the risk and retain it, with documented justification). Under DORA Article 6(8), financial entities must document their ICT risk treatment decisions and obtain approval from their management body — risk acceptance is not a unilateral decision by the IT department.

For each risk to be mitigated, develop a treatment plan that specifies the control or controls to be implemented, the expected risk reduction (how the residual risk compares to the inherent risk after treatment), the implementation timeline, the responsible owner, the required resources, and the success criteria. Treatment plans should be realistic and sequenced — attempting to implement fifty new controls simultaneously will result in none being implemented effectively. Prioritise based on the risk assessment results: address the highest-scoring risks first, and sequence treatments so that foundational controls (access management, logging, network segmentation) are implemented before dependent controls (anomaly detection, automated response).

Risk transfer through cyber insurance is increasingly relevant but also increasingly complex for EU organisations. The cyber insurance market has matured significantly, with insurers now requiring evidence of specific controls (multi-factor authentication, endpoint detection and response, offline backups, incident response plans) before underwriting policies. For DORA-obligated entities, insurance does not satisfy the regulatory obligation to implement ICT risk management measures — you cannot insure your way out of Article 9 protection and prevention requirements. Insurance is a complement to, not a substitute for, operational controls.

Residual risk — the risk remaining after treatment — must be formally evaluated and accepted. Every organisation retains some residual risk; the question is whether the retained risk falls within the organisation's risk appetite. Document residual risk levels in your risk register, obtain management body approval for risk acceptance decisions, and review accepted risks at least annually to determine whether the acceptance rationale remains valid. GDPR Article 35(7)(d) requires DPIAs to describe the measures envisaged to address risks, including safeguards and mechanisms to ensure personal data protection — making risk treatment documentation not just good practice but a legal requirement where personal data is involved.

A risk assessment is not a one-time activity but a recurring process that must be refreshed as the threat landscape, business environment, and regulatory context evolve. The question of how often to reassess has both regulatory and practical dimensions. DORA Article 8(6) requires reassessment upon major infrastructure changes. NIS2 Article 21(2)(a) implies ongoing risk analysis. GDPR Article 35 requires review when processing changes. Beyond regulatory mandates, best practice dictates reassessment when new threat intelligence indicates a material change in the threat landscape, when a significant security incident occurs (whether at your organisation or at a comparable entity), when major organisational changes occur (mergers, divestitures, new product launches, geographic expansion), or when the regulatory environment shifts.

Between full reassessments, maintain a continuous risk monitoring capability. This does not require a full assessment cycle — it means that new threats are evaluated against existing vulnerabilities as they emerge, that changes to the control environment are evaluated for their impact on residual risk levels, and that near-miss incidents are analysed for their implications on risk likelihood estimates. Continuous monitoring bridges the gap between periodic assessments and ensures that your risk picture does not become stale between formal review cycles.

Track assessment quality metrics to drive improvement. Useful metrics include: the percentage of risk scenarios that materialised as actual incidents (if this is high, your assessment is accurate; if it is low, either your controls are excellent or your threat identification is incomplete), the accuracy of impact and likelihood estimates for materialised risks (how close were your estimates to actual outcomes), the timeliness of risk treatment implementation (are treatments being delivered on schedule), and the trend in residual risk levels over time (is your overall risk posture improving or deteriorating). These metrics turn risk assessment from a compliance exercise into a management tool.

Finally, solicit feedback from assessment participants and stakeholders after each cycle. Business unit leaders who participated in the assessment can identify whether the process captured the risks they are actually worried about. Technical teams can identify whether the vulnerability analysis was accurate and complete. And leadership can identify whether the assessment results informed their decision-making or sat unused in a shared drive. Use this feedback to refine your methodology, improve your threat sources, and increase the assessment's practical value in each subsequent cycle.