BCM under NIS2: Build Business Continuity Management (2026)

1. Legal basis of the BCM duty (DE and AT)

In Germany the BCM duty sits in § 30(2) no. 3 BSIG and in Austria in § 32(4)(c) NISG 2026 — ISO 22301 and BSI Standard 200-4 are the route there, not the duty itself.

§ 30(2) no. 3 BSIG requires "business continuity, such as backup management and disaster recovery, and crisis management" (Aufrechterhaltung des Betriebs).

The yardstick is set by § 30(1) BSIG: appropriate, proportionate and effective technical and organisational measures to avoid disruptions to the availability, integrity and confidentiality of IT systems and to keep the impact of security incidents small; compliance must be documented. Under § 30(2) sentence 1 BSIG the measures should "meet the state of the art, take the relevant European and international standards into account and must be based on an all-hazards approach". This is exactly where ISO 22301 and BSI Standard 200-4 come in: as standards that can be taken into account and from which the depth of implementation can be derived.

The duty is addressed to particularly important entities and important entities under § 28 BSIG. An entity qualifies as a particularly important entity if it is of a type specified in Annex 1 BSIG and employs at least 250 employees, or has an annual turnover of more than EUR 50 million and in addition an annual balance sheet total of more than EUR 43 million; an entity qualifies as an important entity if it is of a type specified in Annex 1 or Annex 2 and has at least 50 employees, or an annual turnover and an annual balance sheet total of more than EUR 10 million each, unless it is already a particularly important entity (§ 28(1) and (2) BSIG). In addition, operators of critical installations, qualified trust service providers, top-level domain name registries, DNS service providers and certain telecommunications providers count as particularly important entities irrespective of size. So check in this order: first the allocation to a type of entity in the Annexes, then the size threshold. Annex 1 BSIG covers the highly critical sectors energy, transport, finance (banking and financial market infrastructures), health, water (drinking water and waste water), digital infrastructure including the management of ICT services, and space; Annex 2 covers postal and courier services, waste management, manufacture, production and distribution of chemicals, production, processing and distribution of food, manufacturing, digital service providers and research; federal administration entities are not covered via Annex 1 but separately under § 29 BSIG. To check which types of entity the Annexes name in detail, use the NIS2 self-test. In Austria the same check runs in parallel via § 24 and § 25 NISG 2026, where allocation to an Annex 1 or Annex 2 type is a precondition for classification as an essential or important entity.

This yardstick is given concrete shape by BSI Standard 200-4 and by the ENISA "Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690" (June 2025, version 1.0) on Implementing Regulation (EU) 2024/2690 of 17 October 2024. In practice this means: what the supervisory authorities look to for the state of the art is the same material for each of the ten areas of measures in § 30(2) BSIG — BSI IT-Grundschutz modules, ISO 27002, the ENISA Technical Implementation Guidance and sector-specific standards. This is not a static standard; the selection must be kept up to date on an ongoing basis.

Note how far this concretisation reaches in Germany: the quantitative criteria of the Implementing Regulation on the threshold for a significant security incident apply only to certain digital types of entity — among them DNS service providers, TLD name registries, cloud and data centre services, CDN, managed (security) service providers, online marketplaces, search engines, social networks and trust service providers (cf. § 30(3) BSIG). For all other entities § 2 no. 11 BSIG remains decisive until a statutory instrument is issued under § 56(5) BSIG.

DE/AT note: This guide reflects the German legal position (BSIG 2025). In Austria the NISG 2026 applies instead of the BSIG (BGBl. I Nr. 94/2025, promulgated on 23 December 2025, applicable from 1 October 2026): there, business continuity is a risk management measure under § 32(4) NISG 2026 — within the catalogue (a) to (j) it is (c) —, the responsibility of management bodies is governed by § 31 NISG, and fines follow § 45(2) and (3) NISG 2026 (up to EUR 10 million or 2% of worldwide annual turnover for essential entities, EUR 7 million or 1.4% for important entities). The competent supervisory authority is the Cybersecurity Authority (Cybersicherheitsbehörde, Austria); significant incidents must be reported to the competent CSIRT under § 34 NISG (24 h / 72 h / 1 month).

DE and AT side by side

Each row of the table names the decisive provision of the respective jurisdiction. All entries are statutory rules, not practical recommendations.

2. Business impact analysis (BIA)

The BIA is the working step that turns the statutory formula into a list of priorities: it determines which processes must be "maintained" at all, and how quickly. Without this basis, the proportionality required by § 30(1) BSIG cannot be justified — and neither, in Austria, can the suitability and proportionality of the risk management measures under § 32(1) NISG 2026.

BIA steps:

1. Create an inventory of business processes. Record all value-adding and regulated processes, with a process owner. Without an inventory, the selection of protected processes remains open to challenge.
2. Per process: assess criticality (money, reputation, law). The legal dimension expressly includes reporting and evidence duties: a process whose failure triggers a significant security incident is critical irrespective of its contribution to turnover.
3. Per critical process: document IT dependencies. Name applications, interfaces, data centres and external service providers — the dependency chain is the bridge to supply chain security under § 30(2) no. 4 BSIG or § 32(4)(d) NISG 2026.
4. Per IT system: define the maximum tolerable period of disruption (MTPD). The MTPD is the upper limit beyond which the damage is no longer manageable; it is set on business grounds, not technical ones.
5. Derive RTO/RPO targets from this. RTO and RPO must sit below the MTPD, otherwise the target is already missed on paper.

Record the methodology, the assessment scale and the result in writing — the BIA is the document from which every later prioritisation can be explained, and therefore a core element of the documentation duty named in section 1. Practical recommendation: update the BIA whenever a process or IT system changes materially, and in any event once a year.

3. Defining RTO and RPO

RTO (recovery time objective) sets out how long a process may be unavailable at most, RPO (recovery point objective) how much data loss is acceptable — both per process, derived from the BIA and owned by management.

The following matrix is a practical example for typical SME processes, not a statutory requirement; the rows show how technical architecture decisions follow from business target values.

Three points decide whether these values hold up. First, sign-off by management — under § 38(1) BSIG responsibility for implementing and supervising the measures lies with management itself and cannot be delegated. Second, reconciliation with service provider contracts: where a process relies on external services, the contractually agreed recovery time must support the internal RTO; otherwise either the contract or the target has to change. Third, evidence: RTO and RPO only become reliable target values once a test has confirmed them.

4. Emergency plan and crisis team

The emergency plan implements the element "crisis management" in § 30(2) no. 3 BSIG (section 1) — and must be built so that it supports the statutory reporting deadlines.

Contents of the emergency plan:

• Crisis team list with 24h reachability (mobile, private email) and a named deputy for each role — because the early warning deadline runs from knowledge, not from the start of the incident, and knowledge can arise at night and at weekends. Minimum staffing proven in practice: a management representative (decision on and sign-off of the report), the IT or information security officer (technical situation), the data protection officer (assessment of the GDPR reporting track under Art. 33 GDPR), communications (internal and external messaging), the business owner of the affected process (impact assessment) and a record keeper (time stamps for the chain of deadlines) — a practical recommendation, not a statutory requirement
• Escalation workflow: who decides what and when — including the decision whether a significant security incident exists, and a named deputy for every role
• Communication plan: employees, customers, authorities, press — with prepared wording blocks, so that the 24-hour report does not fail over drafting
• Backup locations (alternative site, home office) — including access credentials and evidence that access works without the failed environment
• Emergency contacts at suppliers — for the service providers identified in the BIA as dependencies of critical processes
• Rollback procedures — a documented way back to the last known good state, with a release criterion for returning to operation

The trigger for the reporting duties is the significant security incident: an incident that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (§ 2 no. 11 BSIG); § 35(1) NISG 2026 mirrors the same two limbs, but in limb 1 requires severe financial loss. This assessment belongs on the crisis team's agenda as item one.

Deadlines the crisis team must know

Every row of this table is a statutory deadline; the point at which each deadline starts is given in the "Trigger" column.

Two follow-up duties belong in the same process. In Germany, the BSI may at any time request an interim report on relevant status updates; if the incident is still ongoing after one month, a progress report first takes the place of the final report, which then follows once handling is complete (§ 32(1) no. 3 and (2) BSIG) — in Austria this corresponds to § 34(2) no. 3 and no. 5 NISG 2026. And where a personal data breach that exists at the same time is likely to result in a high risk to the rights and freedoms of natural persons, the data subjects must be notified without undue delay under Art. 34(1) GDPR; the notification may be dispensed with under the conditions of Art. 34(3) GDPR, for example where the affected data are effectively encrypted. If a data protection supervisory authority has already imposed a fine under the GDPR for the same conduct, an additional fine under the BSIG is precluded (§ 65(11) BSIG).

Practical recommendation on the exercise rhythm — three formats with different purposes and different frequencies, which do not replace one another:

• Restore test (technical: recovery of individual systems in the test environment) — quarterly
• Tabletop exercise (crisis team: decision and reporting paths around the table) — at least annually, with the full crisis team
• Live test (switchover of a critical application in live operation) — every two years

In addition, after every real incident there should be a lessons-learned workshop with an update of the plan. These rhythms are values drawn from practice, not a restatement of a statutory deadline.

5. Disaster recovery

Disaster recovery is the technical part of § 30(2) no. 3 BSIG — specifically the "backup management and disaster recovery" named there (section 1).

DR components:

• 3-2-1 backup: 3 copies, 2 media, 1 offsite — this principle (or an equivalent one) prevents a single event from hitting production and backup together
• Immutable backup against ransomware — backups that cannot be overwritten or deleted during the retention period; the purpose is that an attack on the production environment does not take the backup with it
• Quarterly DR test (practical recommendation, not a statutory deadline) with recovery into a test environment — the test evidences the RPO and measures the actual recovery time against the RTO; it is the restore test from the exercise rhythm in section 4 and is distinguished there from the tabletop exercise and the live test
• RPO-compliant replication mechanism — replication interval and retention must fit the target values set in section 3, not the other way round
• Documented recovery procedures — step by step, executable by deputies as well, available offline, with a named sign-off for returning to operation

The test results have a double value. On the one hand they are the evidence for the documentation of compliance required by § 30(1) BSIG. On the other hand they pay into a separate area of duties: § 30(2) no. 6 BSIG requires "concepts and procedures to assess the effectiveness of risk management measures in the field of information technology security". Without records, the evidence for both is missing. Anyone already certified to ISO 27001 largely covers the BCM area through the continuity requirements there; in a gap analysis, look first at the areas that ISO 27001 does not cover to NIS2 depth: the reporting duties under § 32 BSIG or § 34 NISG 2026 and supply chain security under § 30(2) no. 4 BSIG or § 32(4)(d) NISG 2026.

6. Eight-week roadmap for SMEs

A BCM framework that can withstand review can be built in eight weeks — the following schedule is a practical recommendation for SMEs and does not replace any of the statutory deadlines named in sections 1 and 4.

Alongside this run the fixed dates. In Germany the BSIG has applied since 6 December 2025 with no transition period; the three-month registration deadline under § 33(1) BSIG expired on 6 March 2026 — anyone who missed it registers late, as the duty continues to exist. In Austria the NISG 2026 becomes applicable on 1 October 2026 (§ 51(1) and (2)); registration with the Cybersecurity Authority must take place within three months of entry into force (§ 29(2) and (3) NISG 2026), that is, by the end of 2026. The self-declaration of the risk management measures implemented must be submitted within twelve months of the registration duty arising (§ 33(1) NISG 2026). The authority may call for evidence provided by an independent body at the earliest two years after entry into force, that is, from 1 October 2028; from the request, a two-year evidence period then runs, with essential entities having to evidence operational and organisational implementation within two months of the request (§ 33(2) NISG 2026).