NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany

1. The Hook: Why This Should Be on Your Radar Now

For two decades, "cybersecurity regulation" in Germany mostly meant KRITIS — a short list of large operators of critical infrastructure (energy grids, hospitals, water utilities). If you ran a 60-person IT consulting or managed-services firm, it simply wasn't your problem.

The EU's NIS2 Directive (Directive (EU) 2022/2555) ends that. It roughly multiplies the number of regulated entities in Germany by 10–15x, pulling in mid-sized companies across 18 sectors — including, explicitly, managed service providers (MSPs) and managed security service providers (MSSPs). Germany is transposing NIS2 into national law via the NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz); the transposition has been delayed multiple times relative to the EU's October 2024 deadline, so it's worth checking the current legislative status, but the substance of the obligations is already fixed at EU level and will not change.

Here's the part that should actually grab your attention: NIS2 doesn't just regulate companies directly in scope. It also flows down through supply chains — meaning even a small consultancy that is technically below the size threshold can be contractually forced into NIS2-equivalent obligations by a client who is in scope. And for the first time in German cyber-regulation, members of management ("Geschäftsführung") face personal liability for non-compliance, not just the company.

So this isn't an "IT department" topic. It's a business-risk topic that touches contracts, governance, and personal liability for anyone running or advising a consulting firm.

2. Core Concepts in Plain Language

2.1 Who's actually in scope?

NIS2 splits regulated organizations into two tiers:

• Essential entities — larger or higher-risk organizations (energy, transport, banking, health, digital infrastructure operators like DNS/cloud providers, etc.)
• Important entities — a broader tier that includes postal services, waste management, chemicals, food, manufacturing, digital providers, and critically: "managed service providers" and "managed security service providers" as their own named sub-sector under "ICT service management (B2B)."

The general size threshold is ≥50 employees OR ≥€10M annual turnover/balance sheet. Below that, you're typically out of direct scope — but a handful of entity types (e.g., qualified trust service providers, top-level domain registries, providers of public electronic communication networks) are in scope regardless of size.

Why the distinction matters less than people think: "important" entities get lighter-touch supervision (mostly reactive, post-incident) versus "essential" entities (proactive audits), but the substantive security obligations are identical for both tiers. There's no "important = less work."

2.2 The Article 21 obligations — your actual to-do list

Article 21 of NIS2 lists ten categories of minimum cybersecurity risk-management measures that in-scope entities must implement, "based on an all-hazards approach." In plain terms, the ten buckets are:

1. Risk analysis & information system security policies
2. Incident handling
3. Business continuity & disaster recovery (backups, crisis management)
4. Supply chain security — including security in relationships with suppliers/service providers
5. Security in network/system acquisition, development, and maintenance (incl. vulnerability handling)
6. Policies to assess the effectiveness of your security measures
7. Basic cyber hygiene practices and security training
8. Policies on cryptography and encryption
9. HR security, access control, and asset management
10. Use of multi-factor authentication, secure voice/video/text communications, and secure emergency communications

This is essentially a codified version of what a mature IT security baseline already looks like — but it's now a legal floor, not a best-practice suggestion.

2.3 Incident reporting — the clock that catches people out

If you have a "significant incident," NIS2 imposes a strict, multi-stage reporting timeline to the national CSIRT/competent authority (BSI in Germany):

• Within 24 hours of becoming aware: an early warning (is it suspected to be unlawful/malicious, could it have cross-border impact?)
• Within 72 hours: a fuller incident notification (initial assessment, severity, impact, indicators of compromise)
• Within 1 month: a final report (root cause, mitigation, cross-border impact if any)

Most firms' incident response plans today are built around "contain, eradicate, recover" — not around a legally binding 24-hour external reporting clock starting the moment someone notices something is wrong. That mismatch is where companies actually get caught out.

2.4 Governance and personal liability — the real shift

This is the part that changes board-level conversations:

• Management bodies must approve the cybersecurity risk-management measures, oversee their implementation, and can be held personally liable for failures to do so.
• Management must attend training on cyber risk and offer similar training to employees.
• For essential entities, repeated serious non-compliance can lead to temporary bans on holding management positions — comparable to GDPR-style personal accountability, but for security governance specifically.
• Fines mirror GDPR's structure: up to €10M or 2% of global annual turnover for essential entities, €7M or 1.4% for important entities — whichever is higher.

3. Three Concrete Examples

Example 1 — The MSP that didn't think it was in scope. A 70-employee managed IT services firm in NRW provides outsourced helpdesk, patching, and network monitoring to ~40 SMB clients. They assumed NIS2 was for "critical infrastructure operators," not them. But "managed service provider" is an explicitly named category under Annex I (ICT service management, B2B), and they're well above the 50-employee threshold. They are an important entity — directly, on their own merits, independent of any client relationship.

Example 2 — The 12-person consultancy pulled in through a client contract. A small, 12-person cybersecurity advisory firm is technically below the NIS2 size threshold and has no direct obligation. But one of their clients is a regional energy distributor — an essential entity under NIS2. Article 21(2)(d) requires that essential entity to manage supply chain security, which in practice means it must assess and contractually bind its suppliers (including this small advisory firm) to NIS2-equivalent controls: incident notification SLAs, security questionnaires, audit rights, MFA requirements. The advisory firm never registers with BSI, but it now has to operate as if it were in scope — because its client's compliance depends on it.

Example 3 — The reporting clock in practice. A mid-market consultancy detects ransomware activity on a client's file server at 09:00 on a Monday. Under NIS2 (as transposed), if this qualifies as a "significant incident" affecting an in-scope entity: an early warning is due to BSI by 09:00 Tuesday, a detailed notification by 09:00 Thursday, and a final report within one month. If the consultancy's incident response retainer/SOP doesn't have someone explicitly responsible for triggering and tracking that external notification clock — separate from the technical containment work — the deadline gets missed by default, not by negligence.

4. Actionable Takeaway

This week, do a 30-minute NIS2 exposure check for your own firm and your top 3–5 clients:

1. Scope check: Does your firm meet the ≥50 employees / ≥€10M threshold, and do you fall under one of the named Annex I/II sectors (especially "ICT service management — B2B" if you do MSP/MSSP work)?
2. Supply-chain check: Do any of your clients qualify as essential or important entities? If so, expect (or proactively offer) a security questionnaire, contractual security clauses, and incident-notification SLAs from them.
3. Clock check: Does your incident response plan name a specific person/role responsible for the 24h/72h/1-month external reporting clock — distinct from whoever is doing technical remediation?

If the answer to #1 or #2 is "yes" or "unsure," that's the prioritized next step — not a generic security audit, but specifically a gap analysis against the ten Article 21 measures and your reporting workflow.

Reflection question: Which one of your current clients, if breached tomorrow, would create a supply-chain reporting or compliance obligation that flows back to you — and do you currently have a contract clause or process that covers it?

← All articles