Since the NIS2 Directive was transposed into Italian law through Legislative Decree 138/2024, the same question keeps coming up in our client meetings, sometimes almost under their breath: “We don’t have an in-house SOC. Are we breaking the law?”
It’s a fair question, and today more relevant than ever. For many organisations, the registration and formal compliance phase is behind them. Now comes the real work: adopting the baseline security measures required by Italy’s National Cybersecurity Agency (ACN), to be completed within eighteen months of being notified of inclusion in the scope.
The deadlines, however, depend on when an organisation was added to the NIS list. Organisations on the list since 2025 must complete the baseline measures by October 2026, and for many that deadline is just weeks away. Organisations added for the first time in 2026 follow the dates set by ACN Determination 127434/2026: mandatory incident reporting from 1 January 2027 and baseline measures by 31 July 2027.
The short answer is reassuring: no, NIS2 does not require anyone to have an in-house SOC. The long answer is more interesting, because it explains what the regulation really asks for and where the real risks of non-compliance lie.
The big misconception: NIS2 doesn't require structures, it requires results
Nowhere in the regulation will you find an obligation to set up a Security Operations Center, a team of analysts working around the clock, or any specific technology. NIS2 takes a different approach: it requires technical, operational and organisational measures that are appropriate and proportionate to the risks the organisation faces.
Proportionate is the key word. The size of the company, its sector, its risk exposure and the impact an incident would have on customers and services all determine how robust its defences need to be. A mid-sized manufacturer is not a large energy operator, and the regulation takes that into account.
That doesn't mean anything goes, though. It means compliance is measured by what the organisation is actually able to do, not by the size of its org chart.
What It Really Asks For: Four Pillars
1. Governance That Engages Top Leadership
This is the most significant change compared to the first NIS Directive. Management and governing bodies must approve cybersecurity risk-management measures, oversee their implementation, and be held accountable for non-compliance. They must also undergo specific cybersecurity training.
In other words, cybersecurity is no longer “just an IT issue” but becomes a board-level priority. No external provider can assume this responsibility on behalf of the company.
2. A Structured Approach to Risk Management
The regulation identifies a set of areas that must be addressed, including:
- Risk analysis and information systems security policies;
- Business continuity, backup management, and disaster recovery;
- Supply chain security, including supplier security;
- Access control, multi-factor authentication, and encryption;
- Asset inventory and IT resource management;
- Security in the acquisition, development, and maintenance of systems, including vulnerability management and disclosure;
- Periodic assessment of the effectiveness of the measures implemented;
- Basic cyber hygiene and staff training.
3. The Ability to Detect and Manage Incidents
This is where the SOC comes into play. NIS2 requires organizations to be able to detect incidents, assess their severity, and respond accordingly. This requires logs to be collected and retained, adequate monitoring, and clearly defined incident response procedures. How these activities are carried out—by an internal team, an external provider, or a hybrid model—is up to the organization.
4. Reporting Significant Incidents
When a significant incident occurs, the organization must notify CSIRT Italia within specific timeframes. It is important to note that this obligation is already in force. For entities included in the list in 2025, it has been applicable since January 2026 (nine months after notification of their inclusion). There are three deadlines:
- Within 24 hours of becoming aware of the incident: an early warning.
- Within 72 hours: a formal incident notification, including an initial assessment of its severity and impact.
- Within one month of the 72-hour notification: a final report. If the incident is still ongoing at that point, a progress report must be submitted instead, followed by the final report within one month of the incident-handling process being concluded.
Penalties at a Glance
Essential entities may face penalties of up to €10 million or 2% of their total worldwide annual turnover, while important entities may face penalties of up to €7 million or 1.4% of their total worldwide annual turnover, whichever amount is higher in each case. Additional measures may also be taken against members of the management bodies themselves.
The Real Challenge for Organizations Without a SOC: The 24-Hour Deadline
If there is one area where companies without a structured security function are truly at risk, it is not the lack of a SOC. It is time.
The good news is that the solution does not require additional technology. It requires someone to monitor alerts outside business hours and know who to escalate them to, and within what timeframe. Let’s look at why this matters so much.
Let’s consider a scenario that is far from uncommon. On Friday evening at 10 p.m., a compromised account begins moving through the corporate network. Security tools generate alerts, but no one reviews them until Monday morning. By the time someone notices, at 9 a.m. on Monday, the incident has been ongoing for around 60 hours, making it difficult to demonstrate that it was handled with the promptness required by the regulation.
In this case, the problem is not technological: the alerts were there. The problem lies in the processes.
That is why the right questions to ask are not “What tools do we have?” but rather:
- Who monitors alerts at night, over the weekend, and during the summer holiday period?
- Who determines whether an incident is “significant” under the regulation?
- Who is responsible for preparing and submitting the notification to CSIRT Italia, and what information is required?
If the answer to any of these questions is “we don’t know,” that is where efforts should be focused.
Practical Options for SMEs
For most small and medium-sized enterprises (SMEs), building and maintaining an in-house SOC operating 24/7 is not a viable option, either financially or in terms of the specialized skills required, which can be difficult to find in the market. There are essentially three practical alternatives.
SOC-as-a-Service or MDR services. A specialized provider continuously monitors systems, analyzes events, and responds according to predefined service agreements. This is the most comprehensive option for organizations without dedicated internal resources.
A hybrid model. Monitoring is outsourced, while final assessments, decision-making, and incident reporting remain the responsibility of an internal point of contact. This is often the best compromise: specialized expertise is provided externally, while accountability and business knowledge remain in-house.
Managed security tools. EDR or XDR solutions combined with a response service provided by the vendor or a partner can be a good starting point, provided there is a clear understanding of what the service covers and what it does not. In particular, monitoring must extend beyond endpoints to include identities, VPNs, firewalls, and remote access in general, all of which are explicitly referenced in ACN's security measures.
Important: Outsourcing the Service Does Not Mean Outsourcing Responsibility
Outsourcing monitoring to a third-party provider is fully compatible with NIS2. However, responsibility for compliance remains with the organization. There is also an often-overlooked detail: the security service provider becomes part of your supply chain and must therefore be assessed and managed accordingly.
Checklist: What to Check in a SOC/MDR Provider Contract
Before signing, it is worth checking that the contract clearly addresses the following points:
- Detection and escalation times: Deadlines aligned with the 24-hour notification window, supported by written service-level agreements (SLAs).
- Clearly defined roles: Responsibilities for incident classification and support in preparing incident notifications.
- Log retention: Which logs are collected (identities, VPNs, firewalls, endpoints, servers, and cloud environments), how long they are retained, where they are stored, and how your organization can access them.
- Effective 24/7 coverage: Continuous monitoring, including public holidays, rather than merely an on-call service.
- Periodic reporting: Reports that are also understandable to management and help demonstrate the oversight required of governing bodies.
- Log export at contract termination: The logs belong to your organization and must be provided in a usable format if you change providers.
- Containment actions: Measures the provider is authorized to take without waiting for your approval, such as disabling an account, terminating an active session, or isolating an endpoint.
- Joint testing and exercises: At least once a year.
- Security clauses and audit rights: Contractual security requirements and the right to audit the provider itself.
Answers to the Three Questions
Let's return to the three outstanding questions. Here's how to answer them.
Who monitors alerts at night, over the weekend, and during the summer holiday period? It depends on which of the models outlined above is chosen. With SOC-as-a-Service or an MDR service, the provider takes responsibility, with 24/7 coverage explicitly stipulated in the contract. With managed security tools, it is important to verify what happens outside business hours. In any case, there must be a clearly identified person or team responsible—not just a vague reference to “someone.”
Who determines whether an incident is “significant”? The criteria should not be improvised: ACN has already defined them in Annexes 3 and 4 of Determination No. 379907/2025. The incident categories are IS-1, IS-2, and IS-3 for important entities, with IS-4 also applying to essential entities. IS-3 and IS-4 are based on service levels and parameters that the organization must define in advance (measure DE.CM-01). If these thresholds have not been established beforehand, the organization will have no benchmark against which to assess an incident when it occurs.
Who submits the notification to CSIRT Italia, and what information must it contain? The notification is submitted by the CSIRT contact designated by the organization, through the ACN portal, providing the information required at each stage: the early warning, the incident notification, and the final report. Under the hybrid model, the provider supports the process with technical analysis, while submission remains an internal responsibility. This is why it is essential to establish in advance who the designated contact is and who their backups are, ensuring that together they provide 24/7 coverage.
Where to Start, as Early as Tomorrow
A major overhaul is not necessary. What is needed is a series of concrete steps, taken in the right order:
- A gap analysis against ACN's baseline security measures to identify where the organization is already compliant and where gaps remain.
- A written incident response plan that is concise, practical, and genuinely usable, with names, phone numbers, and clearly defined steps. The plan should include recording the exact time at which evidence of the incident is obtained, as this determines when the 24-hour countdown begins. In the Friday scenario, if evidence is obtained on Monday at 9 a.m., the early warning must be submitted by Tuesday at 9 a.m. However, the 60 hours that have elapsed since Friday at 10 p.m. still count, and this is precisely the gap that continuous monitoring helps prevent.
- An exercise, even a simple one. Running a tabletop incident simulation is the quickest way to identify weaknesses in the process.
- An internal point of contact with a clear mandate and a defined decision-making chain, so that valuable time is not wasted figuring out who needs to do what.
- Management training, which, beyond being a regulatory requirement, is one of the most effective ways to secure leadership attention and budget.
In Conclusion
NIS2 does not ask companies to become large; it asks them to become capable. Capable of detecting, deciding, and communicating within the required timeframes, with informed and engaged leadership.
For organizations without an in-house SOC, the way forward almost always involves working with specialized partners. However, the difference between a service that merely generates alerts and one that supports compliance lies in the processes, people, and clearly defined responsibilities within the organization itself.
Want to Assess Where Your Organization Stands?
The Eetech team can support you with an initial assessment of your organization’s compliance with NIS2 requirements and ACN security measures, helping you identify priorities and develop a sustainable roadmap!