The BSI portal entry has been confirmed, the contact details are on file and the ticket can be closed. That is precisely when a dangerous sense of completion appears. Registration fulfils a specific obligation and establishes a communication channel. It does not show that the scope is correct, risk-management measures operate effectively, changes are maintained or management decisions can be evidenced. Stopping at the portal checkmark means you have supplied an address – not built a governable security model.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
The false finish line: “We are NIS2 compliant now”
Germany's recast BSI Act has applied since 6 December 2025. The BSI opened the second stage of its registration process through the BSI portal on 6 January 2026. Under section 33 of the BSIG, essential and important entities and domain-name registry service providers must generally provide the specified information no later than three months after they first or again qualify as such an entity or begin providing the relevant service. Changes to that information must be submitted without undue delay and no later than two weeks after the entity becomes aware of them.
The BSI explains that regulated companies must conduct a risk analysis and implement and document appropriate measures. Section 30 BSIG requires suitable, proportionate and effective technical and organisational measures. Under section 38, the management of essential and important entities must implement those measures, oversee their implementation and attend training regularly. For culpably caused loss, section 38 generally ties liability to the company-law rules applicable to the entity’s legal form; the BSIG’s own liability rule applies only where those company-law provisions contain no corresponding rule.
The portal record therefore confirms only that the entity was registered with the required information. It does not show which legal entities, services, locations and dependencies are actually in scope. It records neither the criteria used to assess risks nor the operating and effectiveness status of the measures. Nor does it reveal which gaps an authorised body accepted, funded or escalated, or which submitted data has changed since registration. Portal registration also does not prove that the BSI has granted a general tolerance or grace period. Without an applicable official primary source, a date circulating inside or outside the organisation must not be treated as a statutory deadline or established supervisory practice.
A registration confirmation is credible evidence – of registration. A fire extinguisher is not a fire-safety programme either, despite its reassuring shade of red.
The three gaps that emerge after the portal checkmark
1. The registered legal entity and operational scope drift apart
The registration data includes the entity's name and legal form, contact details, public IP address ranges, sector and information about relevant activities in EU Member States. In practice, these facts change. Groups restructure, services migrate, networks expand, providers are replaced and responsible people move roles.
The entity therefore needs a maintained scope and registration register connecting the legal entity, affected services, material systems, operating locations, critical dependencies and data submitted to the BSI. Every relevant change needs a trigger and an owner. This converts the two-week update deadline from a calendar surprise into an operating process.
Consider an explicitly hypothetical operating scenario. A registered German entity runs a customer-facing service whose platform is migrated to another cloud provider six months later. At the same time, a sister company takes over parts of Support and the registered contact moves to a different internal role. Each change looks like ordinary business in isolation. Taken together, they alter technical dependencies, responsibilities and potentially the facts underlying both registration and the scope assessment.
A working mechanism does not begin with an annual reminder email. Approval of the provider change triggers a scope review; the organisational move triggers a contact review. The accountable role compares the new position with the submitted data, records the assessment and initiates any necessary update. If relevance is unclear, the question receives a decision-maker and a deadline. The unresolved status then remains visible and can be escalated in time.
In the hypothetical case, the service owner takes responsibility for the business change, the cloud architect records the new technical dependencies and Procurement provides the contractual and supplier material. The NIS2 coordination role checks this information against the scope register and portal data. It does not replace specialist judgement on every detail, but turns three local changes into one coherent governance event. Closure of the migration project is linked to the scope review. The project therefore cannot become formally green while the registration and risk baseline still describe the old provider.
The obvious governance failure would be to update only the visible portal details. The contact might then be correct while changed recovery assumptions, support dependencies and access routes remain stale in the control registers. The register therefore needs relationships: the change points to affected services, risks, measures, evidence and decisions. Accountable owners confirm which artefacts remain valid, which require another test and which interim deviation applies in the meantime.
This produces a genuine resource decision for management. If the new provider is technically ready but a priority recovery test and the review of privileged support access are missing, management has several options: delay the migration, release only a limited part, or accept the residual deviation for a defined period. The decision paper must name the consequences, deadline, accountable role and stopping criterion. The red dot alone would be decorative; the decision makes it useful.
2. Measures exist, but their effect remains unproven
Section 30 BSIG covers areas including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and development, effectiveness assessment, training, cryptography, personnel security, access control and multi-factor authentication. A generic list of policies is not enough.
For governance purposes, each prioritised risk treatment should connect the business risk and affected service to a control objective and a specific measure. It also needs an accountable role with decision authority, expected evidence, a review interval and the current operating and effectiveness status. Any open deviation needs a deadline, risk decision and escalation path. These relationships matter more than the number of control rows because they show how a finding becomes an accountable action.
“MFA exists” is an existence claim. A decision-useful statement identifies the privileged access for which MFA is enforced, the exceptions, the method used to test the configuration and the date of the next effectiveness review.
3. Management receives status slides instead of decisions
Section 38 BSIG makes the leadership dimension explicit. A traffic-light slide without sources, decisions or residual uncertainty is not adequate governance. Management needs decision-ready material that sets out the risk, affected services, available options, costs and deadlines, the relevant decision authority and the evidence that will later demonstrate implementation.
From a professional governance perspective, the management cycle should clearly distinguish three things: confirmed facts, professional assessment and decision. Otherwise, “a backup policy exists” quickly becomes “recovery is under control”. Only a restore test stands between those statements – and, occasionally, a very long Monday.
Evidence timelines also require careful separation. Section 39 BSIG requires operators of critical installations to demonstrate implementation of the relevant measures at a date set by the BSI: no earlier than three years after they first qualify, or no later than three years after they again qualify, as an operator of a critical installation; evidence is then due every three years. This specific KRITIS evidence cycle is neither a general three-year transition period for all essential or important entities nor a deferral of risk management, documentation or management oversight. The governance register should therefore distinguish evidence needed continuously for internal control from evidence that additionally falls within the statutory KRITIS cycle.
Scope, measures and leadership form one operating loop
The three gaps are not independent. An outdated scope causes risks to be assessed against the wrong technical or organisational state. Measures based on that assessment can be formally complete while missing the current service. Management then receives a reassuring status built on an obsolete data model. Governance must close the chain in the opposite direction: changes update scope, scope shapes risk assessment, risks determine measures and evidence, and open deviations become management decisions.
Different operating rhythms meet in practice. Projects work towards go-live, Procurement towards contract dates, IT Operations towards stable changes, security functions towards risk reviews and management towards periodic decision meetings. None of these rhythms is inherently wrong. The problem arises when an early project milestone effectively pre-empts a later governance decision. Binding handover points prevent this. Current scope must be confirmed before technical release; missing evidence and the time limit must be visible before risk acceptance; and operating evidence and open actions must transfer into steady-state ownership after go-live.
The evidence architecture should represent this loop without constructing a second company out of documents. Stable identifiers connect service, risk, measure, evidence and decision. Versions and validity periods show which claim belongs to which operating state. A central register points to specialist artefacts rather than multiplying uncontrolled copies. A manager can then navigate from the open risk to the latest test while the technical owner continues to work in the appropriate specialist system.
Common metrics become meaningful only in this context. A count of closed actions says little if critical services lack current effectiveness evidence. More useful measures include overdue tests for priority controls, scope changes without a completed assessment, time-bounded exceptions nearing expiry and decisions without confirmed implementation. Each metric receives a defined response and decision-maker. Without that link, reporting is busy but not necessarily leading.
A practical 30-day plan after registration
Days 1–5: Connect registration and scope
Store the registration confirmation, submitted data and responsible contacts in a controlled location. Reconcile the legal entity, sector classification and affected services with the internal applicability analysis. Define concrete change triggers for contact data, IP ranges, EU activities, M&A, new services and provider changes. Portal maintenance and authority communication need a business owner and a named deputy.
Days 6–15: Connect risks, measures and evidence
Prioritise the most important service-related risks, not the longest control catalogue. Assign concrete measures, owners, evidence and an effectiveness criterion to each priority risk. Mark missing or stale evidence; document existence is not a substitute for effectiveness. Transfer deviations into an action register with due dates, budget requirements and escalation routes.
Days 16–23: Test reporting and crisis capability
Section 32 BSIG establishes a staged reporting chain for significant incidents: an early warning without undue delay and no later than 24 hours after becoming aware of the incident; a confirmed or updated incident notification with an initial assessment without undue delay and no later than 72 hours; and, in principle, a final report no later than one month after the 72-hour notification. If the incident is still ongoing at that point, a progress report is submitted first. These statutory windows do not create separate internal preparation time: assessment, approval and submission all run against the same clock.
Run a short tabletop exercise with a technical alert, incomplete facts and the primary contact unavailable. Check timestamps, deputies, approval authority, contact routes and the separation of facts from assumptions.
In a hypothetical exercise, monitoring reports unusual access to a priority service late on Friday. The technical observation is real, but its cause remains open. The primary contact is unavailable, and the first situation report mixes confirmed logs with a theory about the attack route. The exercise succeeds if the deputy takes control, keeps assumptions visible and produces an approvable decision brief in time. It does not succeed merely because everyone finishes with a remarkably complete record of their uncertainty.
This tests the governance mechanism under load. Awareness is timestamped, responsibility transfers in a controlled way, uncertainty receives a next review time, and management receives options rather than raw telemetry. Handover failures observed during the exercise become actions with owners. The organisation is therefore testing its ability to operate the documented model, not simply admiring the document.
In the continuous hypothetical scenario, the alert affects the service that was migrated earlier. This immediately reveals whether the governance chain held. The incident team needs the current service owner, the new provider’s support contacts, valid access routes and the latest evidence. If the register still points to the old operating state, the team loses time and management decides on an incomplete basis. If scope and relationships are current, the deputy can place the technical finding in context without pretending to have certainty. The value of post-registration work is demonstrated not in the portal but in a defensible handover under time pressure.
Days 24–30: Establish management decisions and steady-state operation
Prepare a concise decision brief covering top risks, evidence gaps, options, cost and timing. Resources, risk acceptances and escalations should be decided explicitly. Then establish monthly operational reviews and an appropriate management cadence. Link the scope, risk, action and evidence registers through stable identifiers. Put the next effectiveness test and management decision pack in the calendar before the 30-day plan ends.
What follows is the less dramatic but decisive discipline of maintaining evidence. A restore test, access review or supplier assessment does not remain current merely because the file still opens. Each item of evidence therefore needs an operational validity context: the service and period it covers, the measure it supports and the event that requires an earlier review. A material architecture change can make a recent test report substantively stale.
The monthly review should therefore test statements rather than count documents. It compares the measure’s operating status, the strength of its effectiveness evidence, expanded exceptions and new dependencies with the stated scope. A negative finding leads either to an operational correction or a visible risk decision. This keeps registration connected to the live environment rather than allowing it to end as an administrative event in a closed project folder.
A short management review keeps registration operational
- Legal entities, services, portal data and the current scope analysis are traceably connected.
- Priority risks lead to specific measures, current evidence and effectiveness criteria.
- Changes, exceptions and evidence gaps have owners, deadlines and escalation routes.
- Management material separates facts, assessment, options, decisions and implementation evidence.
- Reporting and crisis roles are exercised with deputies against the 24-hour, 72-hour and one-month stages, and the next review is scheduled.
Conclusion and A-R-C action prompt
Registration is a necessary administrative milestone. It becomes compliance work only through continuous risk governance, effective measures, evidence and documented management decisions.
The next step is testable: Choose one critical service and connect its scope, top risks, measures, evidence and open decisions in one governable view within a week. If this cannot be done for one service, the enterprise-wide problem will not be solved by more policies.
As an Interim CISO and ISMS/GRC adviser, A-R-C helps make information security governable, auditable and management-ready – from scope and action governance to defensible decision and evidence paths.
Professional boundary
This article provides professional analysis of information security, governance and implementation practice. It is not legal advice, an authority ruling, certification or an independent audit. Applicability, obligations, deadlines and acceptable evidence must be assessed for the specific legal entity and facts. A-R-C does not guarantee legal compliance, certification or a particular audit outcome.
Primary sources
- German Federal Office for Information Security (BSI), “Cybersicherheitsrecht: NIS-2-Umsetzungsgesetz ab morgen in Kraft”, published 5 December 2025, checked 2 August 2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/251205_NIS-2-Umsetzungsgesetz_in_Kraft.html
- German Federal Office for Information Security (BSI), “Zweiter Schritt zur NIS-2-Registrierung: BSI-Portal ab sofort freigeschaltet”, published 6 January 2026, checked 2 August 2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260601_NIS2_BSI-Portal.html
- German Federal Ministry of Justice/Federal Office of Justice, BSI Act (BSIG), particularly sections 30, 32, 33, 38 and 39, current version, checked 2 August 2026: https://www.gesetze-im-internet.de/bsig_2025/BJNR12D0B0025.html
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.