Under the NIS2 Directive now in force across the EU, essential and important entities have just 24 hours to file an early warning notification of a significant cybersecurity incident from the moment it is detected. A deadline that short means the organisation has to know in advance which threats are most likely to materialise, which assets are critical, and who makes the calls in the first hours after an attack. Risk assessment and incident response have to form a single cycle, run consistently across the whole organisation. This article discusses how to set that cycle up, step by step.
Introduction to Risk Assessment and Incident Response
A great many companies still run risk assessment and incident response as two separate processes. The risk management or compliance team maintains the risk register and presents it to the board once a year. IT handles day-to-day incidents and operates according to its own procedures. The two streams rarely intersect. Risk managers and compliance officers often have little visibility into the attacks that actually occurred during the previous quarter, while IT teams rarely consult the risk register and may not know which assets have been designated as critical. As a result, the same type of security incident can recur several times before anyone recognises the pattern.
In reality, risk assessment and incident response are two stages of the same cycle. Every incident should feed back into the risk register, and every newly identified risk should make its way into the procedures of the team handling incidents. Without this feedback loop the organisation learns slowly, and the board receives mixed signals from two teams looking at the same security posture from different vantage points.
How to Identify Information Assets Within the Organisation
Before an organisation can analyse risks, it has to compile a complete list of the resources it needs to protect. That list has to be refreshed regularly, because IT environments and business processes change faster than most companies notice. Five categories of assets are typically distinguished. Security teams give the most attention to information assets, namely data and documentation.
| Asset Category | Examples | Who Manages It |
| Information | Customer databases, technical documentation, source code | Process owner |
| Technical (IT) | Servers, applications, network, cloud environments | IT department |
| Physical | Data centre, end-user devices, storage media | Facilities, IT |
| Human | Critical roles, experts, administrators | HR, line managers |
| Process | Claims handling, production, settlements | Process owner |
Frameworks such as ISO 27001 allow organisations to group assets in different ways. The key requirement is that every entry in the register has a designated owner who confirms any changes resulting from significant reconfigurations, business or technical changes, and as part of internal audits. Without this, the data quickly becomes outdated.
Asset Classification and Prioritisation
Asset classification is the work in which the security team assesses how much protection each resource needs. The most common method is the CIA triad, which means assessing the confidentiality, integrity, and availability of every resource. Customer databases above all need protection against leaks, while financial reporting systems need protection against data manipulation. Classification also takes into account requirements coming from outside the organisation, such as GDPR and the NIS2 Directive. Personal data and trade secrets are classified as the most sensitive information assets.
Once classification is in place, the organisation selects specific safeguards. Most companies use a scale with three or four sensitivity levels, ranging from public information to strictly confidential. The higher the level, the stronger the protection, including stronger authentication and shorter recovery time after an outage (lower RTO and RPO values). The remaining resources are covered by the standard set of safeguards used across the whole organisation. This kind of distinction helps the organisation strike the right balance between the cost and the scope of protection.
The Risk Assessment Process Step by Step
Once assets have been classified, the organisation knows which of them require the most protection. Risk assessment then helps establish the order in which to address them. The assessment process generally runs in five steps.
1. Establishing the Context
Before the security team starts identifying threats, it has to define the scope of the assessment and the risk acceptance threshold. Without these settings, it is hard to compare the results of successive assessments.
2. Threat and Vulnerability Identification
At this stage, the team identifies the threats that could affect each asset group. In information security, the most common threats include phishing, ransomware, and malicious insider actions. When developing the threat catalogue, the team can make use of the guidance contained in ISO/IEC 27005 and the annual ENISA Threat Landscape report.
3. Risk Analysis
Every threat is assessed against the likelihood of its occurrence and the severity of the consequences for the organisation. In banking and insurance, quantitative methods such as FAIR (Factor Analysis of Information Risk) are increasingly used, expressing risk in monetary terms. Other industries rely on a qualitative approach, where the assessment draws on expert judgement and data from previous incidents.
4. The Risk Matrix
The results of the analysis are plotted on a risk matrix. The vertical axis represents the likelihood of a given risk, while the horizontal axis represents its consequences. Risks with high likelihood and severe consequences call for immediate action, while those that are unlikely and carry no serious consequences can be consciously accepted.
5. Risk Treatment Decision
The organisation can reduce the risk through controls, transfer it to a third party through insurance, or formally accept it. In some cases, the most appropriate response is to abandon a particular activity altogether.
The outcome of the assessment is an updated register and a treatment plan. Both documents become the reference point for controls and for incident response.
How to Design and Implement Security Controls
The 2022 edition of ISO/IEC 27002 divides controls into three functional categories. The split mirrors the full cycle, moving from prevention through detection to response.
Preventive Controls
Preventive security controls are meant to stop incidents before they happen. Multi-factor authentication is central, as is strict management of staff access rights at every stage of employment. Network segmentation matters just as much, isolating systems from one another, alongside their hardening, namely the removal of configuration weaknesses. Encryption of data both at rest and in transit provides another essential layer.
In the era of NIS2, the organisational layer carries growing weight. This includes staff training as well as oversight of IT supplier security, which has become a frequent target of attack. The effectiveness of these measures depends, however, on keeping access lists and password policies current. Procedures that no one applies, or rules that have not been reviewed for years, give the board nothing more than a false sense of security.
Detective Controls
Since no organisation can prevent every attack, the second layer of defences is built around detecting incidents as quickly as possible. The standard tool here is a SIEM (Security Information and Event Management) system, which gathers digital traces from across the network, links them into a coherent whole, and alerts the team to any anomalies. Monitoring is supplemented by IDS (Intrusion Detection System) and IPS (Intrusion Prevention System) tools, which can recognise intrusion attempts and block them automatically. Detection rests on the analysis of known attack patterns or unusual behaviours that depart from the normal daily baseline.
Corrective Controls
When systems detect a threat, corrective controls come into play. Their purpose is to restore the organisation to a normal state of operations. They include response procedures, recovery plans, and isolation mechanisms for compromised systems, along with the use of backups. The effectiveness of this layer is verified through regular data restoration tests and incident simulations. A real ransomware attack is the worst possible moment to discover that a backup was incomplete or simply did not work.
Monitoring and Incident Detection Tools
Security monitoring tools form the backbone of an organisation’s detection capability. They serve as the data source for the response team and provide the evidentiary trail required for post-incident reporting under NIS2.
The central tool here is a SIEM, which collects logs from systems and network devices, correlates them according to defined rules, and presents them in one place. Without it, security monitoring scatters across several separate consoles, and the analyst has no chance of seeing the full context of an event. A SIEM on its own is not enough either, because without well-defined rules and a working handling process it produces hundreds of alerts a day and becomes a source of noise.
The remaining solutions are classes of network tools. IDS detects attempted attacks at the network or host level and reports them to the team without interfering with the traffic itself. IPS goes a step further and automatically blocks the detected traffic before it reaches its target. The current standard at the boundary between the internal network and the internet is an IDPS (Intrusion Detection and Prevention System), which combines both functions. The choice of a particular tool depends on network architecture and risk profile, and in production environments, also on tolerance for false alarms.
The Incident Response Process
Effective remedial action is planned well in advance. A prepared strategy, clearly assigned roles, and procedures verified on a regular basis are what allow monitoring to do its job and provide the organisation with real support during a crisis. A vital part of this is the preservation of evidence, such as digital logs and images of compromised drives. Securing this material at the moment of an attack makes it possible to establish the cause of the incident reliably and supports any later proceedings before a court or regulatory body. A properly written runbook names the specific people responsible for protecting evidence before service restoration begins.
Incident handling itself is best built on a proven model with six stages. The first is preparation, which covers gathering the necessary tools and assigning competent people to specific tasks. The team then moves on to detection and analysis, identifying the type of threat and estimating its impact on the business. The next stage is containment through the isolation of infected systems, followed by eradication of the source, for instance malware or compromised credentials. The fifth stage covers safe restoration of services and verification that the systems are working correctly. The cycle closes with lessons learned, which feeds the update of the risk register and any necessary changes to existing safeguards.
The smooth running of these phases matters all the more given that regulations such as NIS2 impose strict deadlines for incident reporting. The first early warning notification has to reach the supervisory authorities within just 24 hours.
Integration With ISO 27001, ISO 22301, and NIS2 directive
Risk management and incident response should not function in isolation. They achieve their greatest effectiveness when they form part of a coherent system built on recognised standards. ISO 27001 places the emphasis on a systemic approach to information security, in which risk assessment determines the choice of safeguards. The NIS2 Directive in turn imposes specific obligations regarding the resilience of essential entities. Alongside the protection itself, it expects sound business continuity management.
This is where the link with ISO 22301 becomes important, as the standard focuses on the organisation’s ability to survive crisis situations. Combining these standards helps avoid duplicated procedures and improves the flow of information. The business impact analysis (BIA) from the continuity domain, for example, should feed into the IT risk assessment process, while recovery plans following a ransomware attack have to align with the company’s overall crisis strategy. This holistic approach turns security from a purely technical activity into an integral part of running the whole organisation.
Common Mistakes and Challenges
Implementing security mechanisms rarely goes without a hitch, and sustaining their effectiveness over time can be difficult. The most common problems include the following.
A risk register that lives in isolation
The document often remains a dead file that is opened only once a year, ahead of the audit, while the incident response team never refers to it at all.
Excessive documentation
Security policies sometimes run to over a hundred pages, with the result that no one can identify who is actually responsible for incidents in the production environment.
Choosing controls for the auditor
The main criterion for selecting safeguards is sometimes nothing more than alignment with the auditor’s checklist. The level of protection should derive directly from the risk assessment that has been carried out.
No testing of response plans
A procedure can be written down, but if it is never rehearsed, it may turn out that it does not perform its function under pressure.
Fragmented accountability
The risk register often stays in the hands of IT or the risk or compliance team, when it should sit under the supervision of the business process owner. It is the process owner who bears the consequences when a threat materialises, and without their involvement, the register becomes nothing more than a technical document.
These mistakes leave security systems working only on paper. Removing such barriers is what allows procedures to be genuinely linked to the daily operations of the company.
Summary and Best Practices
Building organisational resilience is a continuous process that calls for more than ticking off checklists. Effective protection starts from solid asset classification and systematic risk assessment, which lets the organisation invest in security controls deliberately, where they are needed most. The integration of ISO 27001, ISO 22301, and NIS2 requirements creates an environment in which technology, refined procedures, and well-informed staff work together to limit the impact of incidents. The best practices here remain regular testing of response plans and the involvement of business process owners in risk decisions, which turn paper documentation into a real shield for the company.
