With the transposition of NIS 2 into French law approaching, organizations must prepare for a significant strengthening of cybersecurity requirements. For the entities concerned, the question is no longer whether operational security will be affected, but how. This article explains the main impacts of NIS 2 on SOCs, whose missions, processes and expected standards are set to evolve. 

 

The NIS 2 directive 

A European directive… 

 

Directive (EU) 2022/2555 also known as the NIS 2 Directive (Network and Information Security 2), is a European directive adopted at the end of 2022. It aims to strengthen the cybersecurity and resilience of essential entities (EE) and important entities (IE) operating in critical sectors within the European Union. 

 

It was officially published on 27 December 2022 and requires Member States to transpose its provisions into national law by 17 October 2024 at the latest. 

 

The directive is supplemented by several texts and documents that clarify its implementation, in particular: 

• The NIS 2 Directive – Commission implementing Regulation C (2024) 7151, which accompanies the NIS 2 Directive and details the requirements applicable to certain types of digital service providers: DNS providers, TLD domain name registries, security providers, etc. (link). 
• ENISA recommendations, which provide guidance for implementing the NIS 2 Directive: NIS 2 Technical Implementation Guidance | ENISA. These recommendations are not, however, regulatory requirements and are intended solely to support compliance efforts. 

 

Transposition at national level 

The transposition of the NIS 2 Directive into French law is ongoing, through a national legislative process and work by the French Cybersecurity Agency (ANSSI) to define the requirements. A first working version, not yet legally enforceable, of the French Cybersecurity Framework (ReCyF) was published by ANSSI on 17 March 2026. It sets out a series of security objectives (20 in total) intended to clarify the requirements applicable to important and essential entities. 

 

At the same time, ANSSI has also made guidance available to help organizations identify their status under NIS 2, in particular to determine whether they fall within the scope of the entities subject to this regulation. 

 

Focus on the impact of NIS 2 on SOCs 

Operational security in NIS 2 

A SOC (Security Operations Center) brings together the human, organizational and technical capabilities dedicated to monitoring the security of the information system. Its missions include collecting and analyzing security events, detecting suspicious activity, qualifying and escalating alerts, and supporting incident response. 

 

Although the NIS 2 Directive does not directly target the SOC as a function, it imposes several requirements directly related to cyber risk management and security incident management. As a result, NIS 2 directly affects the organization, processes and expected capabilities of SOCs within the entities in scope, notably through two key articles: 

• Article 21, which defines cybersecurity risk-management measures. 
• Article 23, which defines notification and information obligations in the event of a significant incident. 

 

Focus on outsourced SOCs 

Today, many organizations rely on an external or hybrid model, entrusting all or part of their SOC activities to MSSPs. This outsourcing makes regulatory compliance more complex, particularly with NIS 2. 

In this case, it is important to distinguish between the obligations that apply to the in-scope entity and those that may apply directly to the MSSP. 

 

The NIS 2 Directive defines the cybersecurity requirements applicable to essential and important entities. These requirements remain the responsibility of the entity, although the entity may rely on service providers (such as MSSPs) to implement all or part of them. In general, entities are not responsible for ensuring their providers’ compliance with NIS 2 requirements that apply directly to those providers. However, they must ensure that critical providers maintain an appropriate level of security. 

 

ENISA is currently working on a European certification scheme (EUMSS) for managed security service providers. This scheme aims to harmonize requirements across the EU and strengthen trust in these providers by making it easier to assess their security level and compliance with European regulatory requirements (NIS 2, DORA, etc.). 

 

For MSSPs, the European Commission published Commission Implementing Regulation C(2024) 7151, which sets out risk-management and incident-management requirements directly applicable to MSSPs (and certain other digital providers). This implementing regulation requires MSSPs to be capable of managing cybersecurity risks and incidents end to end, not only for their clients but also within their own scope. In particular, it requires MSSPs to: 

• Implement cyber risk management within their own scope (identify risks and apply appropriate security measures) 
• Be able to demonstrate compliance with NIS 2 requirements 
• Have operational capabilities for detecting, qualifying and responding to incidents, including notifying authorities, clients and stakeholders where required 
• Assess risks related to their own suppliers 

 

SOC objectives in ReCyF 

ReCyF covers security incident management in particular through the following objectives: 

• Objective 12 : Identification of and response to security incidents 
• Objective 20 : Monitoring of information system security 

 

These two objectives reflect a simple expectation: the entity must be able to detect an incident, qualify it and respond to it in a structured manner. This requires clear procedures, effective use of security events, and the ability to identify and handle alerts. 

 

These objectives mainly apply to essential entities (EE). Point 12.3, which requires a process to be defined for analyzing and qualifying anomalous events, is an exception, as it applies to both important entities (IE) and essential entities (EE). 

 

Action Plan for Compliance 

Checklist for compliance 

The NIS 2 Directive, as well as national frameworks such as those issued by ANSSI, primarily define security objectives to be achieved. However, they deliberately remain relatively non-prescriptive regarding the means to be implemented. But what does compliance mean in practice? 

 

The first step is to carry out a gap analysis to assess the entity’s current level of compliance with regulatory requirements across its entire scope. This includes precisely identifying activities performed internally and those outsourced to service providers (notably MSSPs or outsourced SOCs). It is essential to remember that, even in the event of outsourcing, responsibility for compliance remains fully with the entity. 

 

We have identified eight key points to address the main NIS 2 requirements, based on our synthesis of the requirements most impactful for the SOC and ENISA’s recommendations. This list is intended to support compliance efforts but does not replace a gap analysis based directly on the regulatory texts. 

To improve readability, the key points have been grouped so that they can be addressed through the definition and implementation of two policies: an incident management policy and a detection policy. For each key point, we propose key steps to implement, mainly based on ENISA recommendations. 

 

Incident management policy 

Define a process for reporting anomalous events 

Before implementing complex monitoring through the collection and analysis of IT logs, it is important to ensure that a mechanism for reporting and analyzing anomalous events is in place. The first line of detection already relies on employee involvement, who may detect and report weak signals and suspicious events, such as phishing emails or anomalous system behavior. 

 

It is therefore essential to: 

• Provide employees, suppliers and customers with a mechanism enabling them to report suspicious events. Multiple reporting channels should be provided and made easy to access and use 
• Train employees on how to use the incident reporting mechanism and communicate the reporting process to suppliers and customers 
• Define suspicious events according to non-exhaustive criteria and list the information to be included in reports 

 

Define an incident management process 

Regardless of the source of an incident, whether it comes from an employee report or from an alert raised by a detection tool, it must be handled according to a defined process. This is why ANSSI requires an incident handling procedure to be defined : 

• Define an incident management policy including: 
  • an incident categorization system: severity, type, etc., as well as criteria enabling categorization, such as operational impact, criticality of the affected scopes, regulatory impact, etc., and the criteria for classifying events as incidents. Ensure that the incident management policy covers different types of incidents 
  • an incident triage and escalation plan 
  • the roles and responsibilities of stakeholders in handling the incident 
• Regularly review the incident management policy and response playbooks. In particular, review roles, responsibilities and procedures at least once a year 
• Define a communication plan for communicating incidents to the relevant stakeholders and personnel 

 

Align the policy with local requirements 

Article 23 of the NIS 2 directive requires entities to report incidents to the competent authorities. This illustrates the need to ensure that the incident management policy is consistent with applicable laws, regulations and standards, as well as with business needs: 

• Ensure that the procedure complies with applicable laws, regulations and industry standards 
• Align the incident management procedure with business needs and the business continuity and disaster recovery plan 
• Define a communication plan that complies with regulations, including in particular: 
• A procedure for notifying the CSIRT and competent authorities 
• A procedure for communicating with customers and suppliers 

 

Anticipate the response to the main incident types 

The incident management policy must be comprehensive and enable all types of incidents to be handled. It can be supplemented with documents targeting incidents identified as likely or critical: 

• Set up response playbooks and incident response procedures covering containment, eradication and service restoration (return to normal) after the incident 
• Define the roles and responsibilities for the actions identified in the response playbooks 

 

Retain incident records 

The objectives set by ANSSI emphasize the need to retain incident records, both for internal traceability and for potential legal use. Therefore, organizations should: 

• Retain technical records that enabled the incident to be detected 
• Retain records of the actions taken in response to the incident: 
• Time of detection and closure of the incident 
• Indicators of compromise and description of the incident 
• Actions taken to investigate, qualify and resolve the incident 
• Communications to customers, suppliers and stakeholders during and after incident resolution 
• Notifications to the CSIRT and authorities 
• Post-incident analysis report 
• Retain records from tests of incident response procedures 
• Set up an infrastructure for storing & retaining technical records 
• Restrict access to technical records, in particular write access, to prevent any unauthorized access or modification 

It should nevertheless be recalled that these records must be stored in compliance with applicable regulations, particularly those relating to the protection of personal data. 

 

Conduct post-incident analyses 

While retaining incident records may serve legal purposes, it is also valuable for improving incident response processes through post-incident analyses, and organizations should: 

• Conduct post-incident analyses to determine root causes and identify the actions needed to prevent recurrence of the incident 
• Ensure that post-incident analysis reports are considered when defining security policies 
• Regularly review recent incidents to ensure that post-incident analyses have been carried out where relevant 

 

Detection policy 

 

While incident response procedures guide the entity once an incident has been detected, it is also crucial to define a detection policy, aimed at setting out the detection strategy and the types of events to be detected. 

 

Define a detection strategy 

The detection policy must first define the detection strategy, namely: 

• Identify the scopes to be monitored, the detection objectives, and the data, algorithms and tools required for detection 
• Rely on detection tools to automate detection and minimize false positives and false negatives 
• Ensure that alert handling is carried out in accordance with documented procedures and within controlled timeframes 
• Conduct exercises to test incident response procedures at least once a year 
• Leverage on post-incident analyses to identify areas for improvement in processes, record the actions taken to resolve the incident and identify the actions needed to improve the response to this type of incident 
• Regularly review recent incidents to ensure that post-incident analyses have been carried out where relevant 
• Update the detection policy regularly and after every major incident, organizational change, or change in the security strategy, also taking post-incident reports into account 

 

Collect the appropriate logs 

Once the detection strategy has been defined, it should be implemented as follows: 

• Ensure the collection of monitoring data across the relevant scopes, for example: network, user management, system access, authentication, security events such as antivirus alerts, physical access, etc. 
• Implement analysis of the collected logs in terms of volume, type and other relevant indicators to detect any unusual or undesirable trend. Where appropriate, alerts may be set up in the event of anomalies, such as an interruption in log collection, together with appropriate response actions 
• Protect logs and data against unauthorized access and modification 
• Retain backups of monitoring data and protect them against unauthorized access and modification. Regularly test the completeness and reliability of backups, as well as recovery processes 

 

Conclusion 

 

NIS 2 compliance requires a comprehensive approach that spans all aspects of cybersecurity. Operational security and the role of the SOC must not be overlooked, particularly when addressing incident response requirements. 

Because the SOC involves many teams and, in some cases, service providers, its strategy can be difficult to steer. This is why we have detailed here the main points to ensure SOC compliance with the NIS 2 directive. We therefore recommend that entities subject to the regulation anticipate its implementation in France and assess, as of now, the level of compliance of their incident response capabilities with the regulation, in order to define a compliance action plan where necessary.