Many companies in the automotive industry are subject to the requirements of NIS-2. We have outlined who is affected in our NIS-2 for the automotive industry FAQ .
The respective NIS-2 implementation laws are gradually coming into force in the individual member states, most recently the amended provisions in the BSIG in Germany. The provisions have been in force since December 5, 2025. There is a transition period of three (3) months for the obligation to register affected companies with the BSI, which therefore expires on March 5, 2026.
Companies that are subject to the requirements for the first time since December 5, 2025, are currently increasingly asking themselves when and how serious security incidents must be reported to the BSI. The following FAQ is intended to assist with the initial assessment and determination of the measures to be taken.
1. Do NIS-2 regulated companies have to report IT security incidents from December 5, 2025, or only from the expiry of the registration requirement on March 5, 2026?
The reporting obligation applies from the moment the legal obligations come into force, i.e. from December 5, 2025 , regardless of the registration deadline.
The three-month transition period applies only registration with the BSI, but not the ongoing security and reporting obligations.
Practical implications for legal/compliance: Incident reporting processes must be operational.
2. We have not yet registered on the BSI portal. Does the reporting obligation already apply? How do I then submit the report?
Yes. The obligation still applies. Failure to register does not change the legal situation. In this case, companies must:
Act in parallel:
- Register with the BSI immediately in order to be able to communicate with the BSI via the official channel (their own account with the BSI) at least "as soon as possible."
- Prepare incident report immediately anyway
Reporting channel:
- Use the emergency/transitional channels provided by the BSI (e.g., general reporting forms, contact points for cyber security incidents)
- Documentation why regular portal access did not yet exist (e.g., by referring to the ongoing registration period)
3. Is it even a serious security incident? How do I determine that specifically?
That's the key question that many companies currently ask themselves, as they still lack experience in dealing with the provisions of the BSIG or NIS-2.
A reportable incident is is generally if it:
- the availability, integrity, authenticity, or confidentiality of IT systems or data and
- has or had a significant impact on the provision of services.
Typical indicators for situations in the automotive industry:
Ransomware causing production downtime: 🔴 very likely to be reported
Attack on supply chain IT with production planning failure 🔴 very likely to be reported
Compromise of backend systems for connected vehicles 🔴 very likely to be reported
Short-term internal disruption with no external impact 🟡 Case-by-case assessment
Compromise of trade and business secrets 🟡 Case-by-case assessment
Pure phishing email without compromise 🟢 Rather not reportable, but case-by-case assessment
Questions that Legal/Compliance/IT security should ask:
- Are there production, logistics, or security implications?
- Are customers, vehicles, or safety-related systems affected?
- Is there significant economic damage possible?
- Is there reputational or regulatory risk?
In case of doubt, as with the GDPR, the rule of thumb here is probably "report it" – failure to report is more risky from a regulatory perspective than over-reporting.
4. Do the reporting obligations differ depending on whether I am an important or essential institution within the meaning of the BSIG?
In practice there are are hardly any differences in the reporting process. Both "essential" and "important" facilities under the BSIG are subject to:
- incident reporting obligations
- risk management obligations
- Documentation obligations
Differences tend to lie in:
- Supervisory intensity
- Potential fines
- Expectations regarding the maturity of the security organization
For legal/compliance teams, this means: Set up the reporting process with the same robustness—no "light version" for "important" institutions.
5. What requirements do we need to be aware of and comply with as part of the reporting process?
The MeThe message is a legally structured, step-by-step process under the BSIG (implementation of the NIS2 Directive)that must be followed. Violations may be subject to sanctions.
Legally prescribed reporting stages:
Stage 1: Early warning - Immediately, within 24 hours at the latest after becoming aware of a significant security incident
Purpose:
- Advertisement that a significant incident is likely to have occurred
- Initial classification of whether illegal or malicious acts are suspected
Typical content:
- Time of discovery
- Initial description of the disruption
- Initial assessment of the impact on services
Stage 2: Follow-up report / Interim report: within 72 hours after becoming aware
Purpose: To provide more specific details on the initial report based on the incident analysis to date.
Typical content:
- Updated assessment of the severity
- Affected systems/locations
- Presumed cause (if known)
- Initial containment measures
- Cross-border effects, if applicable
Stage 3: Final report: No later than one month after initial notification
Purpose: Complete investigation of the incident.
Typical content:
- Root cause
- Actual impact (operations, safety, supply chain, etc.)
- Duration of the incident
- Final damage assessment
- Permanent measures taken and planned
What this mean in practical terms for Legal & Compliance teams:
Start of the 24hr deadline: Starts with knowledge at the company level – not only after completion of the IT analysis
Providing incomplete information: permissible in early notification – further refinement is planned
Documentation: Decision-making ("why reportable/not reportable") must be verifiable
Internal coordination: IT, security, data protection, and legal departments must work together immediately
Interplay with other obligations: Deadlines are parallel to other obligations (e.g., 72 hours according to Art. 33 GDPR). An incident can therefore trigger several deadlines at the same time – with different authorities.
Rule of thumb: Alert within 24 hours – explain within 72 hours – conclude within 1 month.
6. How does this relate to other reporting obligations, for example under Art. 33 GDPR? What do we need to bear in mind here?
In addition to NIS-2/BSIG, the following may also apply:
- Art. 33 GDPR – Reporting of data breaches to data protection supervisory authorities
- Contractual reporting obligations (OEMs, Tier 1 suppliers), if applicable
- Product safety law for vehicle-related IT systems
An incident may trigger all of these obligations at the same time.
Different deadlines and content must be considered in parallel and and implemented in the process.
7. We have branches in various European countries, all or at least some of which are affected by an incident. Do we have to report the incident individually to each competent national authority, or is a central report to a supervisory authority in one of the member states sufficient?
Mostly yes.
Under the NIS2 Directive, there is no complete "one-stop shop" principle as in GDPR.
The following factors are decisive to determine who has to report what to which authority, among others:
- the registered office of the company concerned
- the location of the services concerned
- the respective national implementation
Key practice for corporations in the automotive industry must therefore entail a central incident coordination at group level, combined with the following steps:
- Review of each affected national subsidiary
- Involvement of local legal/compliance function
- Parallel reports to multiple authorities possible, but usually also necessary
In any case, group-wide incident governance is a clear compliance factor!
