Three frameworks, one incident, different responsibilities

This educational scenario is not a CYTIZEN client case. A software vendor supplies a connected product used by an industrial company and a financial institution. An actively exploited vulnerability affects the product and a customer experiences disruption. The same technical chain can create several obligations, but actors, scope and channels are not interchangeable. The manufacturer, business user and financial entity do not become one organisation because they share incident information.

The method reuses facts and evidence while preserving separate regulatory decisions. Notification under one framework must not be assumed to satisfy another. Programme leadership can organise inventory, collection and exercises; legal classification and notification decisions remain with competent functions, using applicable law and authority instructions. This article is not individual legal advice.

Understand the timetable on 4 October 2026

DORA has applied since 17 January 2025 and addresses digital operational resilience in the financial sector within its defined scope. An industrial company does not automatically fall under DORA because it uses SAP or cloud services. It may receive contractual requirements from a financial customer or participate in a third-party chain. Direct obligations and contractual requirements must be distinguished: similar evidence does not mean identical responsibility.

NIS2 is a directive. The transposition deadline was 17 October 2024, but practical application requires checking national implementation, entity classification and competent rules. In July 2026, the Commission still reported referral of several states, including France, to the Court of Justice for failure to notify transposition measures. It would therefore be incorrect to claim an identical, completed national regime everywhere since 2024. Proposals for amendment in 2026 are not treated here as already effective national rules.

The Cyber Resilience Act concerns products with digital elements within its own scope. Reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security have applied since 11 September 2026; the main general requirements apply from 11 December 2027. The Commission and ENISA confirm these dates. SaaS is not automatically classified as covered or excluded: assessment depends on the product and relevant remote data-processing functions.

Build a scope matrix before a compliance dashboard

Amine, the scenario's programme manager, creates four columns: legal entity, activity or product, framework to examine and validated scope decision. One row covers the financial institution and critical functions, another the software manufacturer, and a third the industrial company and its sector. Each conclusion references the text, competent assessment and review date. An “out of scope” entry has a justification rather than an unexplained blank.

The matrix links business functions, applications, infrastructure, data and suppliers. It is more than a vendor list. One host may support services of different criticality; an internal application may depend on an essential indirect provider. Amine identifies chains where identity, connectivity or backup failure could interrupt several functions. This map identifies common evidence without merging obligations.

Owners attest what they know. The business describes disruption effects, IT dependencies and recovery capacity, procurement the contract, security the controls and legal the classification. A PMO-only register would be fragile. The PMO coordinates consistency, versions and open decisions; it must not fabricate technical or legal expertise on behalf of those responsible for it.

One factual core, separate outputs

The shared incident core contains detection time, available facts, affected services and products, versions, observed effects, affected populations, actions and uncertainty. Facts are separated from hypotheses. A timestamped chronology explains what was known at each decision. Evidence is retained with limited access and controlled amendments so that corrections do not erase the initial state.

Each owner uses this core to prepare their framework-specific output: classification, recipient, content and deadline checked against applicable text and authority guidance. This guide does not propose one universal notification deadline; timing depends on the regime, event and trigger. Early internal alerts give accountable functions time to decide rather than waiting for a supplier to complete its investigation.

The evidence library contains reusable dependencies, contracts, support commitments, recovery exercises, vulnerability handling and risk-acceptance decisions. Each record states scope, date and tested version. An old report does not prove that a recently changed service can be recovered. Reuse reduces collection effort; it does not remove assessment of relevance to each obligation.

Recovery must demonstrate a business outcome

Amine stages an outage affecting a document service and associated identity capability. Teams recover the application but discover that some users cannot access required documents. The exercise is not closed when servers return. It checks authentication, rights, data and the business workflow. Recovery objectives reflect business needs and owner acceptance rather than an unexamined inherited technical contract.

The report separates observed duration, tested scope and limitations. Partial file restoration is not described as complete service recovery. Discrepancies receive owners and deadlines; critical discrepancies require a decision about current exposure. Management needs to know whether an improvement was tested or merely requested from the supplier.

Third-party evidence receives the same scrutiny. Certificates and audit reports may be useful, but their scope must cover the relevant service, entity and operations. Exceptions and exclusions are read. A completed supplier questionnaire does not show the customer's own ability to continue during failure. Contract, architecture and exercise must tell a consistent story.

In practice: exercise the decisions

The illustrative exercise begins with incomplete manufacturer information: a version may be affected by active exploitation. The product owner checks versions; the business assesses suspension effects; security preserves facts; regulatory owners classify their own obligations. Amine maintains chronology and open decisions. He does not wait for perfect certainty to assemble these people or impose one shared notification.

Each team explains what it would decide, on which facts and at what time. Debrief identifies missing contacts, contracts lacking useful information-sharing provisions and systems whose versions cannot quickly be established. These become concrete operational corrections. An additional committee or questionnaire template cannot by itself fix their causes.

The role changes the required evidence

A financial entity relates controls to its functions and applicable DORA requirements. A manufacturer tracks product security and relevant CRA channels. An industrial business assesses potential NIS2 scope and national requirements while controlling production dependencies. A multinational checks local rules rather than copying head-office conclusions. Technical facts are shared; mandates, responsibilities and outputs remain assigned.

Sources, method and limitations

Official sources checked on 4 October 2026. Timetables reflect the cited pages; national positions and authority instructions must be rechecked at decision time. Scenarios and matrices are educational, not compliance attestations or legal advice.