NIS2 for Small Enterprises 50-100 Employees: Quick Compliance

Main article: NIS2 implementation in Germany — scope, measures under Section 30 BSIG, management obligations, reporting obligations and fines at a glance.

Who is affected?

An organisation with 50–100 employees is as a rule an important entity, not a particularly important entity — provided both apply together: an entity type under Annex 1 or Annex 2 BSIG (one of the NIS2 sectors such as energy, banking, health, water, digital infrastructure) and the size threshold of § 28(2) no. 3 BSIG. To that extent the classification follows company size, not the sector alone (Section 28 BSIG): from this threshold onwards you count as a medium-sized enterprise and therefore as an important entity. Particularly important entities — the class supervised more strictly and proactively — are by contrast large enterprises of the Annex 1 types (§ 28(1) no. 4 BSIG) as well as, irrespective of size, operators of critical installations, qualified trust service providers and TLD/DNS service providers (§ 28(1) nos. 1 and 2 BSIG). Exactly one size-dependent constellation changes class within this band: providers of publicly available telecommunications services and operators of public telecommunications networks are already covered here as particularly important entities by § 28(1) no. 3 BSIG. Without any link to Annex 1 or 2, § 28(2) BSIG additionally covers trust service providers and certain smaller telecommunications providers, insofar as they are not already particularly important entities. The size-dependent thresholds of both classes are set out in the table below.

Two details decide the assessment more often than the sector name: first, turnover alone is never sufficient — every turnover branch additionally requires a balance sheet total: more than EUR 43 million in the large-enterprise branch of § 28(1) no. 4 BSIG, more than EUR 10 million each in the 50-employee branches of § 28(1) no. 3 and (2) no. 3 BSIG; only the number of employees works as a standalone criterion. Second, for important entities there is no upper employee limit: anyone who can only be assigned to an Annex 2 type remains an important entity even as a large enterprise. For calculating the number of employees, annual turnover and balance sheet total, Recommendation 2003/361/EC applies with the exception of Art. 3(4) of its Annex (§ 28(4) BSIG). You should therefore not check the three size figures for your own unit alone: where shareholdings or group membership exist, the number of employees, turnover and balance sheet total must be determined on a consolidated basis under § 28(4) BSIG; record the result in writing, including the companies taken into account, before registering.

Austria: The size thresholds are identical, but the NISG 2026 (BGBl. I Nr. 94/2025) applies instead of the BSIG. Classification as a large or medium-sized enterprise is governed by § 25 NISG; registration takes place within three months with the Cybersecurity Authority (§ 29 NISG, not with the BSI), and fines are governed by § 45 NISG. In Austria, too, providers of public electronic communications networks or services in this size band fall into the higher class: they count as essential entities under § 24(1) no. 2 in conjunction with § 25(3) NISG 2026 (medium-sized enterprise from 50 employees) — in this respect there is no difference from Germany at 50–100 employees. Irrespective of size, providers of public electronic communications networks or services that are not already essential entities under subsection 1 count as important entities under § 24(2) no. 3(a) NISG 2026.

Which obligations the classification triggers

Classification as an important entity gives rise to four strands of obligations: registration, risk management, incident reporting and management obligations. A fifth — evidence of implementation — applies in Germany as a regular evidence obligation primarily to operators of critical installations (§ 39(1) BSIG), whereas in Austria it applies to all essential and important entities (§ 33 NISG 2026). The four strands apply regardless of whether you have 55 or 95 employees — only the depth of the measures is scalable, because § 30(1) BSIG requires 'appropriate, proportionate and effective' measures and documentation of compliance with them. The following overview gives, for each obligation, the triggering event and the source in both jurisdictions.

The risk management strand breaks down into ten areas — the following table lists them in full. In Austria the same catalogue runs under § 32(4)(a) to (j) NISG 2026, in the same order ((d) = supply chain, (g) = cyber hygiene and training). The documents column is a practice set: it shows which papers usually carry an area — § 30(2) BSIG does not prescribe a particular number or designation of policies — the catalogue requires that every area be addressed. The last column refers to the week of the roadmap in the next section.

8-week roadmap

The roadmap spreads the build-up work over eight weeks — the timing is a practical recommendation, not a statutory deadline and not a prescribed sequence; the only statutory elements are the sources named in the 'Why' column. The 'Responsible' column is likewise a practical recommendation: the law does not prescribe who leads which week — the only requirement is that implementation and supervision of the measures lie with the management (§ 38(1) BSIG). What cannot wait is registration: it does not depend on the progress of the build-up and therefore appears as a row of its own right at the top.

Realistically: the eight weeks build up documentation and core measures, they do not replace ongoing operation. The specialist article on Section 30 BSIG puts the initial effort for a complete programme, where IT security already exists (e.g. ISO 27001 certification), at 3–6 months of adjustment and around 0.5 FTE, and without an existing ISMS at 9–12 months of build-up and around 1 FTE — practical values, not statutory deadlines.

Of that, the eight-week roadmap delivers the documented initial implementation: registration done, all ten areas of § 30(2) BSIG addressed and documented in accordance with § 30(1) BSIG, and reporting capability established for 24 hours, 72 hours and the final report.

Reporting obligations: 24 hours, 72 hours, one month

A significant security incident triggers a three-stage reporting scheme — and the 24-hour deadline runs from becoming aware, not from the start of the incident. An incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (§ 2 no. 11 BSIG); in Austria, § 35(1) no. 1 NISG 2026 requires severe financial loss in this respect, while the damage to third parties under no. 2 is worded identically. For certain digital entity types — including cloud and data centre services, managed service providers and providers of digital services — Commission Implementing Regulation (EU) 2024/2690 gives this threshold concrete form with quantitative criteria (cf. § 30(3) BSIG); for all others, the definition in § 2 no. 11 BSIG applies until a statutory instrument under § 56(5) BSIG is issued. For organisations of this size this means in practice: the reporting path must work outside office hours — at night and at weekends just as on working days — and the decision 'significant or not' needs a named person with a deputy. That is a practical consequence of the deadline, not a separate availability rule: what is required is the report within 24 hours, not a particular standby model. Practical recommendation: record the time of becoming aware with the date and time, because the 24 hours run from that point. Also keep a brief written record of the significance assessment itself — who, when, which criteria of § 2 no. 11 BSIG were examined — so that a decision not to report can also be evidenced. In case of doubt, report to preserve the deadline: the initial report under § 32(1) no. 1 BSIG is an early warning that is refined in any event through the 72-hour report and the final report.

What makes up the budget

The budget consists of four items — security tools, backup, external consultancy days and templates. The table shows, for each item, what the amount depends on; the amounts themselves follow from current quotations and your existing licences and documents.

What these items do not include is ongoing operation: as a practical value, the main article on NIS2 implementation in Germany puts ongoing ISMS maintenance at around 0.5 FTE plus an external audit every two years (practice rhythm, not a statutory deadline). In any event, what counts is not the invoice total but the standard of § 30(1) BSIG: appropriate, proportionate and effective — proportionality is measured against the entity's risk.

What you can outsource — and what you cannot

Operations and specialist expertise can be outsourced — the management's responsibility remains. The table shows, for each service, what the price depends on; clarify the amounts through quotations. The allocation to the obligation areas is a practical classification, not a statutory requirement.

The strongest lever for organisations with 50–100 employees is round-the-clock availability (see reporting obligations above) — that is what the SOC service provider in the table is for. Vulnerability scans and penetration tests are likewise well suited to outsourcing; an annual penetration test is a common practice rhythm, but the standard does not prescribe an interval.

Anyone who outsources also shifts a piece of supply chain risk: service providers that operate your security functions belong in the assessment under § 30(2) no. 4 BSIG — with risk classification, cybersecurity clauses in the contract and a contractual obligation on the service provider to report incidents to you. In Austria the parallel obligation is in § 32(4)(d) NISG 2026.

What you must do YOURSELF

Three points stay with you even if you buy in everything else: the management's risk acceptance, liability and the management's own training, and crisis team readiness. Nothing here can be outsourced, because § 38(1) BSIG assigns implementation and supervision of the measures to the management itself — a service provider can support, but the obligation does not move with it.

Risk acceptance by the management. § 38(1) BSIG obliges the management to implement the risk management measures under Section 30 and to supervise their implementation; the law assigns this responsibility to the management itself. In practice this means: residual risks are decided on in documented form, not tacitly accepted — the practical recommendation is a written resolution with a date and a recurring reporting item in the management meeting. In Austria, § 31(1) NISG 2026 requires the same: ensuring and supervising the measures under Section 32.

Liability and the management's own training obligation. If the management breaches these obligations, it is liable to its own entity for culpably caused damage under the rules of the company law applicable to the legal form (§ 38(2) BSIG); under the BSIG itself this liability applies only subsidiarily, namely where the relevant company law contains no such rule (§ 38(2) sentence 2 BSIG). On top of that comes the management's own training obligation: § 38(3) BSIG requires the management to attend training regularly. § 31(2) NISG 2026 correspondingly requires the management bodies to attend specifically designed cybersecurity training. Practical recommendation for this size of organisation: document attendance like any other training — date, content, duration, person attending — and tie the repetition to the same rhythm as the training of employees, so that 'regularly' can be evidenced. The NISG 2026, by contrast, does not contain an express internal liability rule in § 31 comparable to § 38(2) BSIG.

Crisis team readiness. Crisis management is part of the obligation area 'business continuity' (§ 30(2) no. 3 BSIG). For 50–100 employees, a small named group has proven effective — management, IT function, communications — with contact details that remain available even if the affected systems fail. Availability, deputising and the reporting decision path follow the section on reporting obligations above. Practical recommendation: a tabletop exercise once a year with an exercise record — date, participants, scenario played through, the measured time from becoming aware to the reporting decision, and the corrective actions derived; this record is the evidence that feeds into the effectiveness assessment under § 30(2) no. 6 BSIG and into the documentation under § 30(1) BSIG.

Austria: what applies to an Austrian sister company

For Austrian units it is not the BSIG that applies but the NISG 2026 (BGBl. I Nr. 94/2025, promulgated on 23 December 2025) — with application from 1 October 2026; from that day the risk management obligations under § 32 NISG 2026 apply, and for existing entities the registration deadline therefore runs until 31 December 2026 (three months from the start of application, § 29(2) and (3) NISG 2026). The registration and change notification deadlines in detail are set out in the obligations table above.

Two differences from the German position are material for planning. First, the evidence route: while in Germany the regular evidence obligation under § 39(1) BSIG (every three years) concerns primarily operators of critical installations, in Austria all essential and important entities must submit a structured self-declaration of the measures implemented within twelve months of the registration obligation arising (§ 33(1) NISG 2026) — for existing entities therefore by 1 October 2027; upon request, evidence of implementation by an independent body follows (§ 33(2) NISG 2026). Second, the reporting route: incident reports do not go to a joint reporting office but to the competent sector-specific CSIRT, or failing that to the national CSIRT (§ 34(1) NISG 2026); administrative fines are imposed by the district administrative authority (§ 44(1)), while supervision and enforcement remain with the Cybersecurity Authority (§§ 38 and 39). Group structures with a German and an Austrian unit must register separately in both countries.