First establish which duties apply to your entity
Germany’s NIS2 implementing act was promulgated on 5 December 2025 and generally entered into force on 6 December 2025. The current BSI Act governs the German corporate duties described here. The EU Directive provides the European framework; its October 2024 transposition deadline is not the date on which German law entered into force. Federal Law Gazette 2025 I No. 301, Article 30, Directive (EU) 2022/2555, Article 41.
Check the legal entity, the services it actually provides and the corresponding entity type in Annex 1 or 2. “IT”, “food” or “health” alone does not answer the question. Size, relationships between undertakings, jurisdiction and special rules must then be considered. Section 28 BSIG.
On narrow screens, scroll the table sideways.
| General size rule | Requirement in addition to the corresponding entity type |
|---|---|
| Important entity | Offering goods or services for remuneration, an entity type in Annex 1 or 2, and at least 50 employees or annual turnover and annual balance sheet total each above EUR 10 million; classification as a particularly important entity takes precedence. |
| Particularly important entity | An offering for remuneration, an entity type in Annex 1, and at least 250 employees or annual turnover above EUR 50 million and annual balance sheet total above EUR 43 million. |
| Special rules | In particular, operators of critical installations, DNS service providers, TLD registries and qualified trust service providers; telecommunications and other entity types have their own classification rules. The general size table is not sufficient here. |
The thresholds are in section 28(1) and (2). Employee numbers and financial figures must be determined under subsection (4), taking account of the EU SME rules specified there. Part-time work, reference years, partner enterprises and linked enterprises can change the result. Having a separate GmbH does not automatically make group figures irrelevant; the statutory exception for independent IT systems and services requires a specific assessment. Activities that are negligible relative to the overall activity may be disregarded under subsection (3). This does not create a freely selectable de minimis percentage.
Four examples to check your classification: A business operating solely as a restaurant does not become a food undertaking under Annex 2 simply by employing 50 people; that provision concerns wholesale and industrial production and processing. A machinery manufacturer of a covered entity type, however, may be important with 60 employees. For an independent undertaking, 40 employees, EUR 20 million turnover and a EUR 9 million balance sheet total do not meet the general size rule. A small provider of DNS services to third parties can be particularly important regardless of this size rule; merely operating its own domain does not make it such a provider. Annex 2, points 4 and 5.4, Section 2, point 8 BSIG.
For certain energy, telecommunications, financial and telematics entities, section 28(5)–(7) provides exceptions to specified BSIG duties. This is not a blanket exemption from cybersecurity or every registration duty. Public and municipal entities also require a separate classification.
For cross-border digital services, the competent supervisory authority must also be established. For the providers listed in section 60(1), central German jurisdiction depends in particular on having their main EU establishment in Germany; special representative rules apply where there is no EU establishment. A German customer alone does not establish universal BSI jurisdiction. Section 60 BSIG.
Address deadlines and responsibility in parallel
Registration under section 33(1) is due no later than three months after the requirements are first met or met again. Thus 6 March 2026 was the first deadline for entities already in scope on 6 December 2025. Entities that enter scope later count from that later date. Critical installations are subject to additional information requirements and the transitional provisions in section 66; the transition to the new KRITIS ordinance does not remove existing BSIG duties. Section 33, section 66 BSIG.
Management must implement the measures under section 30 and oversee their implementation. It must also regularly attend training itself. Registration, incident reporting readiness and technical improvements therefore proceed in parallel; a lengthy security project does not postpone existing duties. Section 38 BSIG.
How to use the ten areas of measures
Section 30(1) requires appropriate, proportionate and effective technical and organisational measures, and documentation of them. Risk exposure, size, costs, likelihood and possible consequences form part of the assessment. Subsection (2) specifies the minimum areas below. It expresses alignment with the state of the art and relevant standards as a “should” requirement; the all-hazards approach and coverage of the areas are mandatory. For certain digital services and trust services, Implementing Regulation (EU) 2024/2690 takes precedence. Section 30(1)–(3) BSIG, Regulation, Articles 1–2 and Annex.
The implementation steps below are practical examples. Not every example is required by law for every entity. For each area, record the person responsible, the service considered, the risk, the measure, evidence of effectiveness and the next review or decision date. “Open” is a work status, not legal permission to defer action.
1. Risks and security policies
Required area: section 30(2), second sentence, point 1. Establish which services depend on which systems, people and suppliers. Assess human error, outages and physical hazards as well as attacks. The provision does not prescribe a single assessment method.
Start with an inventory of essential services and their dependencies. Describe plausible harm scenarios, prioritise risks and decide on measures, responsibilities and resources. A risk list without implementation remains incomplete.
Useful evidence: A traceable risk register with decisions and verified measures. Counterexample: A good website grade says nothing about whether production control, identity services or recovery were considered.
2. Handle security incidents
Required area: point 2. Define detection, internal escalation, containment, preservation of evidence and recovery. Designate deputies and a communication channel that works if the normal email system fails.
Use a synthetic scenario to practise who assesses the incident and who can submit a report to the authority. Early warning and follow-up notification under section 32 generally have maximum deadlines of 24 and 72 hours, each running from awareness of the significant incident. A full root cause analysis need not be complete by then. Trust service providers have additional, separate eIDAS notifications within 24 hours; the general BSIG follow-up notification does not replace them. Details, recipients and special cases are explained in the incident reporting guide.
Useful evidence: Reachable responsible people, working access to reporting channels and an evaluated exercise record. Counterexample: A contact list with no deputies and no usable access does not ensure readiness to report.
3. Protect operations, backups and recovery
Required area: point 3. Determine the downtime and data loss a service can withstand. Use this to establish the backup strategy, protected recovery paths and crisis organisation.
Check whether backups remain available if production administrator accounts are compromised. Test recovery of a representative service, including identities, configuration and dependencies. A common backup scheme may help; the law does not prescribe a universal “3-2-1” recipe here.
Useful evidence: A restore record showing the time required, data recovered and discrepancies resolved. Counterexample: A successful backup notification does not yet prove successful recovery.
4. Include direct suppliers
Required area: point 4. Record direct suppliers and service providers on which your services depend. Assess access, security commitments, incident information and exit options according to the actual risk.
For an outsourced email service, relevant matters include administrative rights, recovery, contacts and prompt incident information. Clarify which evidence the provider supplies and what you must check yourself. A service provider’s certificate does not assume responsibility for your own entity.
Useful evidence: A reasoned supplier assessment with agreed and verified requirements. Counterexample: A provider logo or external scan does not cover contractual, staffing or recovery arrangements.
5. Secure acquisition, development and maintenance
Required area: point 5. Security belongs in system selection, development, changes and ongoing maintenance. This includes vulnerability handling and disclosure.
Link supported versions to the teams responsible for them. Prioritise fixes by exploitability and consequences, test changes and plan rollback paths. Choose testing methods appropriate to the system: configuration reviews, code reviews and targeted penetration tests answer different questions.
Useful evidence: A resolved finding with a risk decision, a change and a subsequent check. Counterexample: Patching a web server does not compensate for unsafe object permissions in the application.
6. Demonstrate effectiveness
Required area: point 6. Check whether measures achieve their protection objective in actual operation. Set the scope and frequency according to risk, taking changes and incidents into account.
Combine technical observations with functional checks: does a block take effect? Does the restore work? Does an alert reach the person responsible? This provision does not impose a statutory annual full audit on every important entity. Additional rules apply to operators of critical installations and evidence required by authorities, in particular sections 39, 61 and 62.
Useful evidence: Test objective, method, result, discrepancy and follow-up. Counterexample: An unchanged scanner score may also reflect unchanged gaps in testing.
7. Train employees and raise awareness
Required area: point 7. Teach basic security knowledge suited to people’s tasks and risks. Employees should recognise suspicious activity and know a simple internal reporting route.
Add specific content for roles with special privileges or potential to cause harm: administration, purchasing, accounting and human resources need different examples. Check understanding and the usability of the reporting route. Avoid exercises that humiliate employees or endanger production data.
Useful evidence: Content, attendance and traceable improvements. Management’s own training under section 38(3) is an additional duty and is not fulfilled by training employees.
8. Consider cryptography throughout its lifecycle
Required area: point 8. Define which data and connections need cryptographic protection, how keys are managed and how renewal, revocation and recovery work.
Transport encryption protects a section of the transmission path. It does not automatically establish who may read at the endpoint, how stored data is protected or whether particularly confidential content needs additional protection. Select methods and operating processes together.
Useful evidence: Protection needs, methods used, responsibility for keys and checks performed. Counterexample: A valid TLS certificate for the website does not prove secure communication throughout the undertaking.
9. Manage personnel, access and ICT assets
Required area: point 9. Connect employee onboarding, role changes and departures with access policies and a maintained inventory of systems, products and processes.
Pay particular attention to privileged and shared accounts, service accounts and external users’ access. Permissions should be justified, adjusted after changes and reviewed at suitable intervals. An inventory needs an accountable maintenance process.
Useful evidence: Samples of permission approvals, role changes and removal of access that is no longer needed. Counterexample: A published policy does not prove that a departed administrator’s account was disabled.
10. Protect authentication and communication
Required area: point 10. The statutory area covers multi-factor or continuous authentication, secure voice, video and text communication, and secure emergency communication where appropriate. Effective and proportionate implementation depends on the specific risk and, where applicable, more detailed sectoral requirements.
Prioritise access with a particularly high potential for harm, account for recovery and emergency accounts, and test bypass routes. For crisis communication, it matters whether it still works when normal systems fail or are compromised.
Useful evidence: Controlled sign-in paths, tested recovery and a usable crisis channel. Counterexample: MFA for a single application proves neither complete access security nor secure email transmission.
What an external check can contribute
An external check can reveal selected publicly reachable configurations of a website, domain or API. This particularly supports work on technical findings and checking their resolution. The target, time, characteristics actually measured and measurement limits are decisive.
On narrow screens, scroll the table sideways.
| Context | Examples |
|---|---|
| Technical observation possible | Selected HTTP headers, certificate and DNS configurations, depending on the particular check and what it can measure. |
| Additional evidence needed | Effects on real application workflows, actual message signatures, all sending routes, internal systems and handling of exceptions. |
| Not a result of a domain check | Legal scope, complete risk management, management oversight, training, supplier management, or NIS2, GDPR and ISO compliance. |
Even a complete individual technical result is not a complete examination of the statutory duty. An unmeasured value is neither a pass nor automatically a serious deficiency.
Your next useful step
First record the reasoned classification of your entity and the deadlines currently running. Then choose a responsible person and the next reliable piece of evidence for each of the ten areas. Address active incidents and due reports immediately; order improvements by risk and dependencies.
Further reading: NIS2 incident reporting, management responsibility and liability, NIS2 and ISO 27001. The Web Security Check and Email Security Check provide a limited initial technical finding. Their results belong in your assessment as individual pieces of evidence, not as approval of the whole checklist.