Budget decisions under NIS2: Calculating investments in technology, personnel and audits

Anyone preparing budget decisions under NIS2 today rarely faces the question „How much does security cost?“, but three more precise problems: what is legally mandatory, what is sensible on a risk-based basis — and how can this be represented in a budget so that operations, procurement, HR, compliance and management share the same logic. NIS2 is not a purely technical matter. The directive targets risk management measures, demonstrability and leadership obligations. Therefore, budget means not only licenses and hardware, but above all personnel, processes, assessments and the ability to report within defined deadlines and remain operationally capable in an incident.

This article presents a robust calculation logic for investments in technology, personnel and assessments — with regard to governance, operational consequences and the audit perspective. You will receive decision aids, checklists and template components that you can transfer into your planning (CapEx/OpEx), your risk register and your action roadmap.

Why budgeting under NIS2 works differently than „security projects“

In traditional security programs, budgeting often follows a „tool first“ approach: EDR here, SIEM there, an awareness training on top. Under NIS2 this order changes. What matters is that your company systematically identifies risks, implements effective controls and can demonstrate that these controls are operated. „Demonstrate“ means: traceable decisions, documented responsibilities, logs, reports, tests, evidence from incident exercises and supplier evaluations.

This creates three cost realities that are often underestimated in budgets:

• Run costs: operations, maintenance, tuning, alert handling, reporting, training, access recertification.
• Evidence costs: creating evidence, versioning, reviewing; answering audit questions; making controls testable.
• Coordination costs: roles, governance bodies, approvals, risk acceptances, escalations — especially with outsourcing and multiple sites.

The budget question therefore is: which combination of measures achieves effective risk reduction and audit readiness without overburdening IT operations with additional complexity?

Clarify scope and affected parties: without clear boundaries any figure is arbitrary

Before you calculate, you need a reliable scope definition. This is not a formality, but the lever that can change your budget by factors. Scope here means: which business areas, locations, critical services, systems and service providers are affected by the NIS2 requirements and must be included in risk analyses, controls and evidence?

In practice, a three-tier scope approach has proven effective:

Relevant for budgeting is that NIS2 does not consider only the “Core”. In particular, supply chain risks (risks from service providers and software/cloud dependencies) are a separate cost block: contract clauses, due diligence, security requirements for providers, evidences and, where applicable, migration/switching costs.

Mini-checklist: scope data you need for a reliable cost estimate

• Inventory of services and systems (at least roughly): applications, servers/VMs, cloud accounts, network segments, locations.
• Criticality per service: impact on revenue, security, supply/production, legal obligations.
• Dependencies: identity (IAM), DNS, e-mail, storage, backup, monitoring, third parties.
• Current operating model: internal/external, on-call/standby, SLAs, handover points.
• Regulatory interfaces: data protection, KRITIS-related requirements (if applicable), industry standards.

Budget decisions under NIS2: the cost framework in three blocks

For planning with executive management and controlling a simple structure is essential. The following three-part division has proven effective and can be used as a budget and reporting structure:

• Technology (Controls & Platforms): tools, integrations, architectural measures.
• Personnel (Build & Run): roles, operational effort, qualifications, on-call/standby.
• Assurance: audits, assessments, penetration tests, exercises, supplier audits.

Important: each expenditure must be traceable to a risk and to evidence. Otherwise you will later face discussions about why an item should be labeled “NIS2”, and the audit will lack a coherent thread.

Calculating technology investments: less of a tool list, more focus on control effectiveness

Technology budgets become viable under NIS2 when you plan them as control families. Control families are groups of measures that together cover an area of risk (e.g. identities, logging, vulnerability management). This allows you to prioritize, even if not everything can be funded immediately.

1) Identity & Access: MFA, roles, privileged access

Identity is the most common lever for limiting damage. Budget drivers here are less the MFA license costs and more role concepts, lifecycle processes and, where applicable, PAM (Privileged Access Management: secure management of highly privileged accounts with approvals, session control and logging).

• One-time effort: define role model, authorization interface, system integrations, emergency access (Break-Glass).
• Ongoing: recertification, joiner/mover/leaver process, review of admin rights, token and device management.

2) Asset and vulnerability management: inventory, prioritization, patching reality

Without a reliable inventory you cannot properly justify either risk or budget. An asset register does not have to be perfect immediately, but it must be verifiable: which systems are in scope, who is responsible, how are updates and vulnerabilities handled.

Budget items frequently missing in practice:

• Scan infrastructure (on-prem, Cloud, remote sites) and maintenance of the scanners.
• Exception processes (e.g., legacy systems): risk assessment, compensating controls, documentation.
• Patch windows and operational effort: testing, rollback, change management (CAB), acceptance.

3) Logging, monitoring and detection: SIEM, XDR, Use Cases, operations

Under NIS2 the goal is not „to buy a SIEM“, but rather to detect, assess and respond. SIEM (Security Information and Event Management) collects and correlates logs; XDR (Extended Detection and Response) links detection across endpoints, identity, network and cloud. A crucial budget decision is whether you will operate it yourself or procure it as a managed service.

Typical cost drivers:

• Log volume (storage, ingestion), retention and data protection requirements.
• Use-case engineering: alert rules, correlation, baselines, fine-tuning against false positives.
• 24/7 on-call or defined response times, including escalation chains.

A budgeted decision needs a target state: which events must you reliably see (e.g., admin logins, privilege escalation, unusual data exfiltration, changes to critical policies), and within what time must you be able to respond?

4) Backup, recovery and business continuity: RTO/RPO as budget parameters

Many incidents only become expensive because recovery takes too long or does not work reliably. A clear translation into RTO (Recovery Time Objective: maximum time to resume operations) and RPO (Recovery Point Objective: maximum data loss measured in time) helps here. These two metrics are your budget „controls.“

• One-time effort: architecture (immutable backups, separated admin domains), RESTore tests, documentation.
• Ongoing: regular RESTore validation, media rotation, monitoring, capacity planning.

Under NIS2 it also counts that you not only „have“ it, but practice it and can demonstrate the results. That shifts budget toward audits and personnel (see below).

5) Network segmentation and hardening: planned measures instead of „Big Bang“

Segmentation (separation of network zones) and system hardening (secure baseline configuration) are often more effective than additional tools, but they create project and operational workload: firewall rules, exception processes, troubleshooting, documentation. If you budget here, be sure to plan for change effort and coordination with business units, because network changes can quickly become production-critical.

Staffing calculations: roles, FTE logic and operational implications

NIS2 makes visible what is already scarce in many IT organizations: time for clean operations and robust risk management. Personnel budget is therefore not a „nice to have“, but a prerequisite for technical measures not ending up as half-finished projects.

Role model: who needs to be funded, even if there was no „Security-Headcount“?

Depending on size and maturity, you don’t necessarily need new full-time positions, but you need clear role allocations. Typical roles under NIS2:

• CISO/Informationssicherheitsverantwortung: governance, risk and measures portfolio, reporting to management.
• ISMS-Manager (ISMS = Informationssicherheits-Managementsystem: processes and rules to manage security systematically): policies, evidence, internal controls.
• Security Operations: monitoring, triage, incident handling, threat intelligence (as required).
• IT-Betrieb/Plattformteams: patching, hardening, backup/recovery, identity, network – as co-responsible for controls.
• Compliance/Legal: notification processes, documentation obligations, supply chain, contract clauses.

Budget logic: if you introduce new tools, you must plan for operational hours (triage, maintenance, reporting). Without these hours the effectiveness decreases, and the audit lacks the „operational evidence“.

Pragmatic FTE estimation: effort buckets instead of speculative figures

Instead of naming a flat FTE number, many organizations work better with effort buckets that you budget per quarter and scale by maturity:

• Governance & Reporting: maintain the risk register, management reporting, policy review cycles.
• Vulnerability & Patch: scans, assessment, change planning, implementation, exception handling.
• Detection & Response: alert handling, use-case maintenance, playbooks, lessons learned.
• Awareness & Exercises: training planning, phishing simulation (if used), tabletop exercises.
• Lieferkette: security assessments, evidence requirements for providers, review of reports.

These buckets can be presented as OpEx and proportionally reduced with Managed Services – with the caveat that control and responsibility remain internal.

Training and qualification: budget time, not just training costs

Awareness under NIS2 is not an „E-Learning checkbox“. What matters for decisions is that target groups are differentiated: IT admin, service desk, developer teams (if present), management, business units with critical processes. The largest cost block is often staff time and coordination (scheduling, follow-up, measurement of effectiveness). For audit readiness you need evidence: participation rates, content, repetition cycles, measures for non-attendance.

Assessments and evidence: What „assurance“ really costs

Assessments under NIS2 are not only external audits, but a continuum of internal checks, technical tests and management reviews. The objective is that, in the event of inspections or incidents, you can demonstrably show what was decided and implemented.

Penetration tests, red teaming, technical assessments: define scope clearly

A common budgeting mistake is to „buy a pentest“ without defining scope and objectives. For reliable proposals and internal planning you should at minimum define:

• Test targets: external attack surface, central applications, identity, cloud configuration, network segments.
• Test type: blackbox/graybox, authenticated/unauthenticated, social engineering yes/no.
• Follow-up: re-test, prioritization, remediation tracking, risk acceptance for findings.

Also budget for the internal support: provisioning of access, maintenance windows, coordination with operations and business units, as well as implementation of the findings (which often represents the larger share).

Audit readiness: evidence collection as a continuous process

Audit readiness does not mean assembling documents shortly before an assessment. You need an operation that produces evidence „incidentally“: logs, reports, approvals, tickets, configuration states, exercise reports. That requires structure.

Practical minimum of evidence categories:

• Governance: roles, responsibilities, decision bodies, management review minutes.
• Risk: methodology, assessment, acceptances, action plan, status.
• Technical controls: baselines, patch reports, backup tests, logging coverage, IAM reviews.
• Incident response: playbooks, exercises, lessons learned, communication and reporting channels.
• Supply chain: supplier classification, security requirements, evidence/reports, exceptions.

Tabletop exercises and crisis management: budget for time slots and decision-making training

NIS2 is closely linked to notification obligations and management responsibility. Tabletop exercises (played-through scenarios at the table) are therefore an efficient way to test notification paths, decision rights and communication routines. Costs are primarily: preparation time, facilitation, participation by executives, follow-up and adjustment of the runbooks.

Prioritization: a risk-based portfolio instead of „everything at once“

Hardly any company can implement all measures immediately. What is decisive is that your prioritization is plausible in an audit. Risk-based means: you combine likelihood of occurrence, impact and detection/response capability into a traceable sequence.

A practical prioritization framework

• Damage limitation first: identity (MFA/PAM), backup/recovery, admin separation, incident response.
• Establish visibility: logging coverage, centralized alerting, baseline monitoring, asset inventory.
• Reduce attack surface: patch and vulnerability process, hardening, segmentation, secure default configurations.
• Strengthen demonstrability: evidence process, regular reviews, internal audits/checks, supplier file.

This sequence is deliberately not tool-centered. It is operations-centered: What helps you avoid incidents, detect them more quickly and restore operations — and do so demonstrably?

Build vs. Buy: Managed services, internal teams and the hidden handover costs

Under NIS2, „outsourcing“ is not a free pass. You can assign detection, log operation or vulnerability management to service providers, but you retain responsibility and must be able to govern them. Budget decisions should therefore distinguish three levels:

• Service: What does the provider do concretely (monitoring, triage, response support)?
• Interfaces: How are tickets, alerts and changes handed over (ITSM, API, e-mail)?
• Evidence: Which reports, logs and KPIs deliver auditable evidence?

Hidden costs typically arise in handovers: unclear escalation chains, missing responsibilities, no shared severity definitions, and breaks in media between SOC tooling and ITSM. These costs are real, even if they don’t appear on an invoice: delays, false positives, unclear decisions during an incident.

Calculation template: How to build an NIS2 budget that stands up to controlling and audit

A robust template consists of three tables that are logically linked: risk → measure → budget item. Below is a compact framework that you can transfer to Excel/Sheets or your portfolio tool.

1) Risk and measures list (portfolio level)

Fields (recommended)
- Risk ID
- Service/System (scope reference)
- Risk description
- Impact (financial/operational/legal)
- Likelihood (qualitative or scale)
- Existing controls
- Planned controls (measure ID)
- Target date / milestone
- Risk acceptance required? (yes/no, by whom)
- Evidence source (which proof demonstrates effectiveness?)

2) Budget items (CapEx/OpEx, technology/personnel/audit)

Fields (recommended)
- Measure ID
- Cost block (technology / personnel / audits)
- Cost type (CapEx / OpEx)
- One-time (setup/project) / recurring (operations)
- Cost drivers (e.g. log volume, endpoints, locations, criticality)
- Dependencies (e.g. IAM before PAM, asset inventory before vulnerability program)
- Operational consequences (additional changes, maintenance windows, on-call)
- Evidence/benefit (which audit evidence or what risk reduction)
- Responsible (owner) + contributors

3) Evidence plan (audit-readiness backbone)

Fields (recommended)
- Control/process (e.g. patch management)
- Evidence artifact (report, ticket excerpt, log, exercise document)
- Frequency (monthly/quarterly/annually/event-based)
- Producer (role/team)
- Storage location (DMS, GRC tool, ticketing, repo)
- Review (who reviews, who signs)
- Retention and access protection

With this triad, budget decisions under NIS2 are no longer „gut feeling“ but a controllable portfolio with an evidentiary logic.

Governance and responsibilities: Budget requires decision paths

NIS2 increases management’s liability exposure: decisions must be made deliberately and documented. For the budget this means: you need a governing body or a fixed process that decides on risk acceptances, priorities and exceptions. In practice this is often a Security Steering Committee or an expanded IT risk committee.

Minimal governance set that stabilizes budget planning:

• RACI (Responsible, Accountable, Consulted, Informed): Who implements, who decides, who is involved?
• Decision thresholds: At what risk level must executive management decide?
• Exception process: How are deviations (e.g. unpatched legacy systems) approved for a limited period?
• Reporting cadence: Monthly operational report, quarterly management review.

Without these paths the budget gets „sliced up“ over the year: projects start, but operational effort and audits remain unfunded or are pushed onto teams that are already at their limit.

Typical budget pitfalls – and how to avoid them in planning

Pitfall 1: Tools without an operational concept

As alert sources grow, triage effort grows. Plan at a minimum: responsibilities, response time, ticket flow, KPI set (e.g. Time to Acknowledge, Time to Contain) and regular tuning.

Pitfall 2: Patch and hardening measures without change capacity

Technical debt cannot be „bought away.“ If your change windows are tight, you need budget for test automation (where possible), for additional maintenance windows, or for phasing out legacy. Otherwise findings remain open and audit questions become uncomfortable.

Pitfall 3: Supply chain treated as an afterthought

NIS2 requires that you actively manage supplier risks. Budget for the ability to classify suppliers, request evidence, adjust contracts and evaluate alternatives for critical dependencies. This is effort in procurement, IT and compliance – not just a contract appendix.

Pitfall 4: „One audit and done“

Evidence ages. Responsible parties change. Systems evolve. Therefore plan continuous checks and regular exercises – otherwise audit readiness becomes a special project every year with high friction.

Decision support: Which questions should be part of every NIS2 budget proposal?

• Which risks are we concretely reducing, and how do we measure that (KPI/evidence)?
• What operational consequences arise (change load, on-call requirements, training, ticket volume)?
• What dependencies does the measure have, and what is the realistic timeline?
• What is decided internally, what can be delivered externally, and how do we govern the service provider?
• What evidence do we need in 6 and 12 months, and who will produce it?

Conclusion: A good NIS2 budget is an operated system – not a shopping list

The central shift for IT leadership and management is: under NIS2, budget decisions must fund technology, personnel and audits as an interconnected system. Technology without operations creates new risks. Personnel without clear governance dissipates in day-to-day work. Audits without an evidence process become hectic one-off efforts. If you define scope cleanly, prioritize measures based on risk and link every expense to risk and evidence, you produce a budget that connects internally – and remains plausible externally in an audit.

When planning the next steps, the most pragmatic starting point is usually: tighten the scope, set up a risk portfolio, prioritize three to five control families (identity, recovery, visibility, patching/hardening, incident response) and, in parallel, establish the evidence plan. Then investments become plannable – and NIS2 shifts from an ad-hoc project to a controllable operational discipline.

For this topic, NIS2 budget and NIS2 compliance costs are also important. This article places these aspects into clear perspective and shows what matters in day-to-day operations.