The new EU cybersecurity framework (NIS2 Directive) imposes an obligation on companies to effectively manage and respond to incidents. In practice, this means that organisations must formally plan, monitor and remedy the effects of security breaches. The Directive introduces personal responsibility of senior management for the implementation of risk management measures and attaches great importance to incident response. Obligated entities are required to report significant incidents within short timeframes, i.e. within 24 hours for the first warning (known as an ‘early warning’), 72 hours for full notification with additional data, and 30 days for the final report. In practice, this means the need for 24/7 readiness and a well-thought-out ‘response system’, i.e. a team, processes and tools capable of quickly detecting, analysing and mitigating the effects of an incident.

 

The roles of CSIRT, SOC and CERT in the response system in accordance with NIS2 requirements

An effective response system requires clearly defined roles and cooperation between several key units. In the context of NIS2 requirements, organisations must have a structure in place to detect, analyse and respond to incidents, and it is not just about names, but about specific functions and competences.

SOC (Security Operations Centre) is an operational security monitoring centre, i.e. the first line of defence for detecting threats and anomalies in the IT infrastructure. It operates continuously, using SIEM, EDR and SOAR tools to monitor the environment and initiate responses.

CSIRT (Computer Security Incident Response Team) is a team of experts responsible for the comprehensive handling of incidents – from classification and mitigation to communication and reporting. CSIRT coordinates internal and external activities, ensures compliance with NIS2 (including reporting within 24/72 hours) and manages the entire incident lifecycle.

CERT (Computer Emergency Response Team) operates at the national or sectoral level. Organisations cooperate with it in the event of more serious threats, submitting reports and using expert support. In Poland, the main point of contact for many entities is CSIRT NASK.

In practice, many companies use a hybrid model, where some operations (SOC) are outsourced to specialised providers (MSSP), and the internal CSIRT performs a coordinating and reporting function. However, one thing is key: regardless of the model, the division of roles must be clear, documented and integrated into the company’s management system.

 

Management and the role of senior management according to NIS2

The NIS2 Directive clearly shifts responsibility for cybersecurity, including the functioning of response systems, to the board of directors and senior management. This is not only a semantic change, but above all a regulatory one, as management cannot delegate full responsibility to IT departments or operational teams. Active supervision, real commitment and competence to assess cyber risk and the effectiveness of implemented solutions are expected.

In practice, this means that clear management mechanisms for the incident response process must be established. The management board should receive regular reports on the state of operational security (including data from SOC and CSIRT), have access to information about identified vulnerabilities, the scale of breaches and plans for improvements. The management board is also responsible for providing adequate financial, human and technological resources to build an effective response system.

NIS2 also requires management to have adequate knowledge of cybersecurity. This does not mean that they need to have a technical education, but rather that they need to be aware of processes, know the risks and understand the role of structures such as SOC or CSIRT. In many companies, this means that dedicated training for management boards is necessary and that cybersecurity must be included in the regular agendas of management and supervisory committee meetings.

Another important responsibility of the board is to formalise the role of response systems in the organisational structure, including through policies, CSIRT/SOC operating procedures, responsibility matrices (e.g. RACI), escalation paths, and provisions in business continuity and incident management plans. For organisations that use outsourcing, the management board must ensure that contracts with suppliers include key elements, including service levels (SLAs), audit rights, reporting requirements, obligations to report incidents immediately, and compliance with NIS2.

 

Response team organisation and operating model compliant with the NIS2 Directive

Effective response to cybersecurity incidents is not only a matter of technology, but above all a well-designed process organisation involving a competent team, clear division of roles, formal procedures and consistent escalation and communication paths. The NIS2 Directive requires that every entity covered by it has structures capable of acting quickly and effectively in crises. Importantly, the directive does not impose a specific organisational model – it allows for the establishment of in-house CSIRT and SOC teams as well as the use of specialised external services (e.g. MSSP, SOC-as-a-Service), provided that compliance with the requirements for detection, response and timely reporting of incidents is ensured.

Large organisations with sufficient resources usually have internal SOC teams that monitor infrastructure 24/7 and CSIRTs responsible for analysis, coordination of corrective actions, communication with stakeholders and reporting obligations (e.g. 24/72 hour reporting). In smaller companies, especially in the SME sector, a more effective solution may be to outsource these tasks to an external partner, provided that real control over the process is maintained, which means precisely defining response times, escalation levels, cooperation rules and periodic testing of the quality of these services in the SLA.

More and more organisations are opting for a hybrid model, in which the strategic and decision-making part remains in-house (e.g. CISO, risk committee, CSIRT leader), while operational tasks such as threat monitoring, log analysis and basic response are performed by an external provider. This approach combines the benefits of scale and access to specialised technology with maintaining control and regulatory compliance. However, regardless of the model chosen, each organisation must have a designated person responsible for incident management, ensures the integration of the security team with other departments (IT, legal, HR, communications) and treats incident response as an interdisciplinary process. Incidents have not only a technical dimension, but also an operational, legal, reputational and often strategic one. NIS2 enforces a holistic approach, which means that management must be fully aware of who is responsible for what, how the response system is organised, whether contracts are complete and enforced, and whether the organisation actually meets legal requirements – not only ‘on paper’ but in practice.

 

 

SOC architecture and monitoring tools

Compliance with NIS2 requires not only the readiness to respond to incidents, but also the ability to quickly detect, analyse and document them. A key element of this capability is an efficient SOC, or security operations centre, which acts as the ‘nervous system’ of an organisation’s cybersecurity.

A SOC can take many forms, from simple local solutions to advanced, automated environments managed internally or in a service model (SOC-as-a-Service). Regardless of scale, the basis of a functional SOC architecture consists of:

– SIEM – a system for aggregating, correlating and analysing log data, enabling early detection of incidents,

– EDR/XDR – tools for monitoring endpoints and automatically responding to threats,

– TIP – Threat Intelligence platforms enabling the use of external threat data (e.g. IOC, TTP),

– SOAR – solutions that automate operational activities, reducing response times and increasing team efficiency,

– Dashboards and reporting – visualisation of key data for security teams and management.

Importantly, simply having the tools does not guarantee effectiveness. The SOC must be integrated with organisational processes and supported by a trained team. Regular system testing is recommended, e.g. red teaming exercises, incident simulations or post-incident analyses (‘lessons learned’), so that the architecture is not only compliant with regulations but also genuinely supports operational security.

 

Recommendations for management boards and practical steps

From the perspective of the management board, it is crucial to treat incident security as part of the decision-making process. Here are some universal recommendations for implementation:

– Develop or update your incident response policy

The policy should clearly define roles, procedures and deadlines for detecting, analysing, mitigating damage, removing causes and reporting incidents. Ensure that it is consistent with business continuity plans and includes escalation mechanisms (so-called playbooks) for typical scenarios (phishing, ransomware, DDoS, etc.).

– Invest in monitoring tools

Implement SIEM, EDR/XDR and coordinate their operation in the SOC. These systems should automatically detect anomalies and send alerts to the SOC/CSIRT team. According to NIS2 guidelines, monitoring must be continuous and automatic wherever possible. Logs from all relevant systems (servers, network devices, cloud services) should be collected centrally and securely archived.

– Appoint a competent team and conduct training

The CISO or CTO responsible for security must have the necessary personnel support. Ensure that SOC analysts have the appropriate certifications and experience. Regularly organise exercises with the incident response team, such as simulated attacks, to verify the effectiveness of procedures.
Remember that, according to NIS2, board members should also be trained in cyber threats.

– Create clear channels of cooperation and communication

Define how the response team (internal CSIRT or external service provider) connects with management, PR, suppliers and regulators. In the event of an incident, decision-makers must receive reliable information about the risk. At the same time, you must report serious incidents to the relevant national CSIRT or competent authority. According to NIS2, an early warning must be issued within 24 hours and a full notification within 72 hours of detection.

– Regularly review and improve the system

Monitor changes in the environment (e.g., new vulnerabilities or threats) and update procedures accordingly. The management board should receive regular reports on the security status and test results. Audit SOC/CSIRT services for detection effectiveness and response time, with KPIs such as MTTD/MTTR (mean time to detect/mean time to respond), helping to assess the efficacy.

 

Summary

A well-organised CSIRT/SOC organisation and clearly defined processes are not a luxury today, but a necessity. The combination of management strategy (policy, reporting, accountability) with modern technologies (SIEM, EDR, SOAR, CTI) and a well-trained team will not only ensure compliance with NIS2 but will also realistically increase the company’s resilience to attacks. As ENISA points out, effective incident management is an ‘essential tool for overall management’ of a company – it is an indispensable element of good ‘digital hygiene’ and building trust among customers and regulators.