The NIS2 "FTE Trap": Why 5 Analysts for 24/7 Security is Actually 8 (and Why the Board Needs to Know)

“WE CAN COVER NIS2 WITH FIVE ANALYSTS, RIGHT?”

The room goes quiet when the CFO says it.
The CISO does a quick mental calculation: three shifts, sickness, holidays, training, project work, on‑call. The number in their head is nowhere near five. But pushing back means explaining shift patterns, coverage factors, and NIS2 Article 21 to a board that thinks in EBITDA, not rota math.

This is where many organizations fall into the NIS2 FTE trap: underestimating how many humans (or service equivalents) it really takes to deliver continuous detection and incident response — and leaving both the business and the board exposed.

This article shows how to avoid that trap with clear math, realistic models, and board‑ready language.

---

What you’ll learn

• Why NIS2 turns 24/7 security from “best practice” into a governance obligation
• The simple coverage math that makes “5 FTE for 24/7” a dangerous illusion
• How to design a realistic 24/7 coverage model (in‑house, MDR, or hybrid)
• Concrete approaches to blend automation and services to reduce net FTE need
• How to explain the gap — and the options — to the board in business terms
• The counter‑intuitive reason adding people can make you less compliant

---

Why NIS2 Makes 24/7 Security Non‑Negotiable

NIS2 does not literally say “you must run a 24/7 SOC,” but its combination of risk‑based controls, strict incident reporting, and management liability makes continuous detection and response de facto mandatory for most essential entities. Article 21’s ten minimum measures and Article 23’s 24‑hour early‑warning requirement are almost impossible to satisfy with office‑hours monitoring.

For boards, that means NIS2 security is no longer “we bought some tools”; it is “we can prove we can see and react to serious incidents at any time.”

NIS2’s key pressure points on operating hours:

• All‑hazards, state‑of‑the‑art risk management (Art. 21). Entities must implement “appropriate and proportionate” measures based on their risk and impact. If your digital services are 24/7, regulators will expect alignment in monitoring.
• Tight incident reporting (Art. 23). A “significant” incident triggers: early warning within 24 hours, more detail within 72 hours, and a final report within a month. That is incompatible with discovering a breach on Monday that started on Friday night.
• Management accountability (Art. 20). The management body must approve and oversee cyber risk measures and can be held liable for infringements. Claiming “we didn’t realise five people weren’t enough” will not help in an enforcement action.

For high‑criticality services (energy, healthcare, transport, large digital platforms, public administration), most authorities and ENISA guidance converge on a simple expectation: someone must be watching, or contractually on the hook, 24/7. How you achieve that is a design choice — but “we hoped our office‑hours team would be enough” will be a hard sell.

Key Takeaway
Under NIS2, 24/7 detection and incident handling is not a technical luxury; it is how the board proves it is exercising due care over essential services.

---

The FTE Trap: Why 5 Analysts Don’t Cover 24/7

The classic mistake is to confuse headcount with coverage. On a slide, 24 hours ÷ three 8‑hour shifts looks like “3 people plus some backup — call it 5 FTE.” In reality, employment law, human physiology, and NIS2 expectations blow that number apart.

The core issue: an analyst FTE does not equal 40 hours of sustained console time, 52 weeks a year.

Consider a typical EU analyst contract:

• ~220 working days per year (after statutory holidays)
• 25–30 days of annual leave
• 5–10 days of training, conferences, and internal workshops
• Sickness, parental leave, jury duty, internal projects, and meetings

Once you subtract all of this — conservatively — you end up with perhaps 70–75% of that FTE’s time available for live monitoring. The rest is essential overhead.

Now look at the requirement side:

• 24/7 is 168 hours per week
• That is roughly 8,760 hours per year of coverage per “seat”

If one FTE can sustainably provide, say, 1,400–1,500 hours of actual watch‑floor time per year, the arithmetic for one always‑occupied analyst seat is:

8,760 ÷ 1,500 ≈ 5.8 FTE

That’s without:

• Double‑seating for high‑risk periods
• A team lead or incident manager
• Project and engineering work (tuning use cases, onboarding new logs, playbook development)

This is why, in practice, the commonly cited “coverage factor” for 24/7 operations is around 4–6 FTE per staffed seat, depending on contracts and culture.

So where does the “5 analysts” myth come from?

• Simple shift charts that ignore leave and sickness
• Assuming the team will “just pick up extra” during holidays
• Confusing a 9×5 on‑site team with a true 24/7 operation
• Underestimating the non‑monitoring workload NIS2 creates (supply‑chain assessments, reporting, audits)

Under that lens, a plan that says “five analysts for 24/7” is really a plan for:

• Chronic understaffing
• Burnout and attrition
• Gaps in coverage — exactly when attacks are most likely to hit

Mini‑Checklist: Is Your Plan in the FTE Trap?

• Coverage math done in hours per year, not FTE labels
• Annual leave, training, and sickness explicitly modelled
• Night/weekend premiums and fatigue risk considered
• Non‑monitoring work (tuning, reporting, audits) resourced
• Explicit answer to “who is on console at 03:00 on Sunday?”

---

Designing a Realistic 24/7 Coverage Model

Once you accept that 5 ≠ 24/7, the next step is to design a model that is both NIS2‑credible and economically defensible. That means moving from “how many people can we afford?” to “what coverage pattern does our risk profile demand?”

The design variables:

1. Minimum seats per time slice

   • Nights/weekends: is one analyst enough, or do you require a two‑person rule?
   • Business hours: do you need extra eyes for volume, investigations, and stakeholder interaction?

2. Role mix

   • L1 monitoring vs L2 incident responders vs L3 engineers/use‑case owners
   • Team lead/shift supervisor vs pure analysts

3. Work pattern

   • Fixed shifts vs rotating
   • Four‑on/four‑off vs classic 5×8 patterns
   • How you handle on‑call for surge events

4. Quality targets

   • Acceptable detection latency relative to NIS2 reporting clocks
   • Maximum sustainable alert volume per analyst
   • Time for continuous improvement (tuning, hunts, purple‑team exercises)

A pragmatic pattern many NIS2‑regulated organizations converge on is something like:

• Nights & weekends: 1 analyst on console, with L2/L3 on call
• Business hours: 2–3 analysts plus a lead
• Engineering & compliance: 1–2 people focused on tuning, onboarding, and audits

When you convert that into annual hours and apply realistic availability, you often land in the region of:

• 7–8 FTE for a lean but viable internal 24/7 function
• Plus management time, platform operations, and third‑party coordination

Key Takeaway
If your spreadsheet shows fewer than ~7–8 distinct people backing a 24/7 incident detection and response function, you probably have not modelled time — only titles.

From a NIS2 perspective, document this model explicitly:

• Map it to Article 21 controls (incident handling, business continuity, supply‑chain oversight)
• Show how it supports Article 23 timelines
• Explain how you handle multi‑entity or multi‑country operations (e.g., shared SOC for several legal entities)

That way, when supervisors ask “why is this proportionate to your risk?”, you have a defensible answer.

---

Options to Close the Gap: Automation, MDR, and Hybrid SOCs

Most boards will balk at adding three or four unplanned FTE on top of an already stretched security budget. The answer is not to pretend 5 FTE is enough; it is to change the capacity equation with technology and services.

Three main levers:

1. Automation and better tooling

Modern SIEM/XDR, SOAR, and continuous control‑monitoring platforms can:

• Deduplicate noisy alerts
• Auto‑enrich events with context
• Execute low‑risk responses automatically (block IP, disable account, open ticket)
• Generate NIS2‑aligned incident reports directly from case data

Well‑implemented automation reduces the number of analysts needed per unit of monitored infrastructure, and crucially, it also reduces fatigue — a major cause of missed signals. But it does not eliminate the need for humans, especially for:

• Triage of novel or complex incidents
• Cross‑entity communication and escalation
• Root‑cause analysis and lessons‑learned

Pro Tip
When presenting automation to the board, position it as protection of scarce human capacity rather than a way to avoid hiring altogether.

2. Managed Detection & Response (MDR) / SOC‑as‑a‑Service

For many NIS2 entities, outsourcing part of the 24/7 burden is the only viable path. A good MDR provider can:

• Deliver 24/7 monitoring for your logs and endpoints
• Provide incident triage and containment actions under pre‑agreed playbooks
• Supply evidence and timelines to populate your Article 23 notifications

Key NIS2‑specific checks when assessing MDR:

• Where are analysts physically located? (EU residency, language, and time zone matter.)
• How are incident hand‑offs and joint investigations handled?
• Who owns the data, and how long is it retained?
• Can they support your sector’s OT environments, not just IT?

3. Hybrid SOC models

Most mature organizations end up here:

• Internal team covers business hours, internal escalation, and regulatory interaction
• MDR/SOCaaS provides 24/7 alerting and first‑line response
• Automation glues the two together

In FTE terms, that might mean:

• 3–4 internal FTE (lead, L2, engineer, compliance interface)
• Equivalent of 4–6 FTE delivered as a service

The point: the board still pays for “8‑ish worth of coverage,” but not all of it shows up as headcount.

---

How to Brief the Board on NIS2 Security Staffing

Boards do not need shift charts; they need risk, options, and trade‑offs. The goal is to turn the FTE trap into a structured conversation that links NIS2 obligations, operational resilience, and financial decisions.

A concise framing works well:

1. Start from obligations, not org charts

   • “Under NIS2 we must be able to detect and respond to significant incidents 24/7 and notify within 24 hours. Today we cannot credibly do that with our current staffing pattern.”

2. Show the simple math

   • One slide: hours of coverage required vs effective analyst hours per year.
   • Make the gap visible: “Five FTE give us X hours; we need Y.”

3. Present options as packages
   For example:

   • Option A – In‑house 24/7 SOC
     • +3 FTE, plus automation upgrades
     • Full control, higher fixed cost
   • Option B – Hybrid with MDR
     • +1 FTE, MDR contract, targeted automation
     • Shared responsibility, predictable OPEX
   • Option C – Minimum viable uplift
     • +1 FTE, no 24/7, documented residual risk

4. Explicitly call out residual risk

   • “If we stay at 5 FTE, we accept the risk that major incidents at night or weekends go undetected for many hours, which could put us in breach of NIS2 reporting timelines and business continuity expectations.”

5. Link back to management liability

   • Not as a threat, but as context: “The directive explicitly assigns responsibility to this board. Choosing Option C is a conscious risk decision, not an accident.”

Key Takeaway
The board conversation is not “can I have three more people?”; it is “here are three ways we can meet — or not meet — our NIS2 duty, with clear costs and residual risks.”

---

The Counter-Intuitive Lesson Most People Miss

The instinctive reaction to NIS2 is “add people.” Yet beyond a point, throwing more analysts at an immature SOC can actually reduce real security and increase non‑compliance risk.

Why?

• Alert noise scales faster than process maturity. Without disciplined tuning and automation, more eyes just mean more overwhelmed humans. Missed alerts remain missed, only now you are paying more for them.
• Complex shift patterns amplify inconsistency. If you grow from 5 to 9 FTE without standardised playbooks, you multiply the number of ways an incident can be mishandled — and regulators will see those inconsistencies in your post‑incident reports.
• Project work gets squeezed out. Over‑staffed watch floors with no dedicated engineering capacity end up spending all their time “keeping the lights green,” with no space for improvements in detection logic, supply‑chain onboarding, or NIS2 evidence management.

The pattern that actually works under NIS2 is:

1. Right‑size human coverage to your risk — no less, but not blindly more.
2. Invest heavily in structure and automation: use cases, runbooks, SOAR playbooks, data quality.
3. Separate roles for monitoring, engineering, and compliance interface, even if some people wear multiple hats.

Boards should therefore be sceptical of both extremes:

• “We’ll be fine with five people and some tools.”
• “We need to double the team, then we’ll figure out processes later.”

The sweet spot is a lean team, well supported by automation and a credible MDR or partner ecosystem, operating within a clearly defined NIS2 control framework.

Pro Tip
Maturity before mass: use your next NIS2 readiness review to assess not just headcount, but signal‑to‑noise ratio, playbook coverage, and time reserved for continuous improvement.

---

Key Terms (Mini‑Glossary)

• NIS2 Directive – EU law (Directive (EU) 2022/2555) setting minimum cybersecurity and incident‑reporting requirements for essential and important entities.
• Essential / Important Entity – Categories of in‑scope organizations under NIS2, with essential entities facing stricter, proactive supervision.
• Article 20 (Management Body) – Provision assigning cybersecurity oversight duties and potential liability to an entity’s management body.
• Article 21 (Risk‑Management Measures) – Section listing ten minimum technical, operational, and organizational security measures NIS2 entities must address.
• Article 23 (Incident Reporting) – Clause mandating 24‑hour early warning, 72‑hour notification, and one‑month final reporting for significant incidents.
• SOC (Security Operations Center) – Team and capability responsible for continuous monitoring, detection, and response to security events.
• MDR (Managed Detection and Response) – Outsourced service that provides 24/7 threat monitoring, investigation, and response on behalf of the customer.
• SIEM (Security Information and Event Management) – Platform aggregating and correlating logs for security monitoring, compliance, and forensics.
• SOAR (Security Orchestration, Automation and Response) – Technology that automates incident response workflows and playbooks across tools.
• Coverage Factor – The ratio between analyst FTEs and staffed shifts required to maintain continuous operations (often >1:4 for 24/7).

---

FAQ

Q1: Does NIS2 explicitly require a 24/7 SOC?
NIS2 does not prescribe a specific operating model, but its risk‑based controls, 24‑hour reporting, and management accountability effectively demand continuous detection and response for most critical 24/7 services.

Q2: Can a small important entity avoid 24/7 coverage?
Possibly, if its services are not time‑critical and a documented risk assessment justifies slower detection. However, the entity must still meet reporting obligations and demonstrate that its measures are “appropriate and proportionate.”

Q3: How many FTE do we really need for in‑house 24/7 monitoring?
For one analyst seat staffed at all times, realistic coverage factors typically land around 5–6 FTE. Once you add redundancy, engineering, and leadership, most lean internal 24/7 models sit around 7–8 FTE.

Q4: Does using MDR remove our NIS2 responsibility?
No. MDR can deliver capabilities, but legal responsibility remains with the entity and its management body. Contracts and oversight must ensure the provider supports your NIS2 obligations.

Q5: How does automation change the staffing picture?
Good automation reduces the number of analysts required per monitored asset and protects against burnout, but you still need humans to design use cases, supervise automation, and handle complex incidents.

Q6: What should we show regulators about our staffing model?
Document your coverage assumptions, shift design, escalation paths, and how these support Article 21 and 23. Be explicit about how MDR, automation, and internal teams interact.

Q7: How often should we revisit our 24/7 model?
At least annually, and after any major change: acquisitions, new services, significant incidents, or regulatory feedback. NIS2 expects continuous improvement, not a one‑off design.

---

Conclusion

When the board asks, “Can’t we do NIS2 with five analysts?”, the honest answer — backed by math and by the Directive — is no. Not if you want credible 24/7 coverage, sustainable workloads, and defensible compliance.

The real choice is not between 5 and 8 FTE; it is between:

• Under‑resourced, brittle security that leaves the organization and the board exposed, or
• A thoughtfully designed mix of people, automation, and managed services that delivers continuous detection, fast response, and clear evidence of due care.

Closing the NIS2 FTE trap means reframing the discussion: from headcount to coverage, from tools to capabilities, and from “IT cost” to board‑level risk and resilience. Once that shift happens, the number eight stops being a shock — and becomes a strategic investment in keeping both your services and your executives out of trouble.