01One incident, several reporting chains
Under today's law, an event like Log4Shell (CVE-2021-44228) would trigger three chains at once. The manufacturer whose product embeds the affected library reports to the CSIRT and to ENISA under Art. 14 of the Cyber Resilience Act. If the same vulnerability is exploited in the entity's own network, § 32 BSIG applies, addressed to the BSI. If personal data is compromised in the process, Art. 33 GDPR applies in parallel, addressed to the data protection supervisory authority. The deadlines overlap; the triggers and the recipients do not.
A single incident ticket with fields for all regimes keeps the deadlines together. It forces, at the outset, the details that determine which chain starts running: in which member states the affected product was made available, and whether personal data is involved. A designated on-call rotation with a deputy carries the 24-hour deadline across a weekend, and whoever runs through the chain once without cause finds the gap in the calendar rather than in a live incident.
02The supply chain as the common denominator
Three requirements converge on the same data foundation: supply chain security under § 30 BSIG, the manufacturer's due diligence for integrated third-party components under Art. 13 of the Cyber Resilience Act, and the proof provided by the software bill of materials (SBOM). Whoever maintains a reliable SBOM serves all three from a single source.
The duty does not end at your own source code. It reaches the supplier only through the contract: commitments on the support period, upstream reporting of vulnerabilities, delivery of a bill of materials in a common machine-readable format. Where these clauses are missing, the manufacturer ends up holding an obligation it cannot actually fulfill.
For open-source components, that contracting partner does not exist. This is where the bridge leads to our FOSS compliance practice area. A bill of materials that cleanly identifies open-source components and their licenses answers security and licensing questions in one pass.
03Data Act and CRA on the same product
A connected product is routinely both at once: a product with digital elements and the object of data access rights. Data access, security requirements, and the protection of trade secrets have to be designed together, not one after the other.
An access design that satisfies the Data Act while undercutting the security requirements of the Cyber Resilience Act is not progress. It merely shifts the problem from one authority to the other.
04Distinct from data protection
Neither the Cyber Resilience Act nor the Data Act is data protection law. Where personal data is affected, the General Data Protection Regulation applies alongside them, with its own legal bases, its own reporting channels, and its own supervision.
Within the firm, this is a matter of division of labor. For questions concerning the processing of personal data, the path leads to our data protection & data law practice area; for contract questions around software, cloud, and procurement, to IT contract law.
05Special case: the financial sector and DORA
Financial entities within the scope of the DORA Regulation are exempt from the obligations under §§ 30, 31, 32, 35, 36, 38, and 39 BSIG. To that extent, DORA takes precedence as the more specific law.
The registration obligation under § 33 BSIG remains untouched. Anyone who reads the exemption as a complete carve-out overlooks it.
06When the BSI is not the competent authority
If a product also qualifies as a high-risk AI system under the AI Act, Regulation (EU) 2024/1689, market surveillance under Art. 52(14) of the Cyber Resilience Act lies not with the BSI but with the authority designated for AI supervision.
For connected products with an AI component, this allocation needs to be clarified up front. For questions of AI regulation, the path leads to our AI & legal tech practice area.
