SkarpChapter 3 of 3
Resolve a boundary between cyber regimes
Develop regulatory scope and digital products while working to advise boards and product teams.
1. Start with the regulated object
Map before you classify
Use four columns: actor, object, trigger, and obligation holder. A single vulnerability can create distinct duties for a manufacturer, a financial customer, and a GDPR controller.
Do not let the customer's sector decide every answer. First ask whether the legal issue concerns an entity's systems, an ICT service, a marketed product, or personal data.
2. Test NIS2 at entity level
Entity-level question
NIS2 scope turns on the undertaking and activity, not on the fact that its customer is regulated. Test Annex I or II, Article 2, and any applicable exception.
For digital suppliers, document the actual service and supplying undertaking. NIS2 jurisdiction generally follows establishment, while Article 26 contains specific rules for certain cross-border services.
3. Apply the DORA boundary narrowly
DORA is not a blanket supplier exemption
For covered financial entities, DORA is the sector-specific NIS2 regime for the relevant cyber obligations. Analyse the customer and supplier separately.
An ICT provider is not automatically a DORA "financial entity". It may still be independently in NIS2 scope, while its financial customer must manage the outsourcing relationship under DORA.
4. Put CRA on a separate product track
Product role is separate
CRA asks whether a product with digital elements is made available on the Union market and who manufactures it. That analysis can run alongside NIS2 and DORA.
On 17 September 2026, CRA Article 14 reporting already applies. Main CRA obligations apply on 11 December 2027, subject to the transition rule for products already on the market.
An SBOM is required in the manufacturer's vulnerability-handling process. CRA does not generally require public SBOM disclosure; Annex II(9) applies only if the manufacturer chooses to provide it to users.
5. Keep GDPR as a parallel data track
A separate factual test
GDPR turns on processing personal data and on actual controller or processor roles. A cyber event can trigger product or operational-resilience duties without being a personal-data breach.
Check telemetry, logs, and account data separately. Do not assume that DORA or NIS2 removes GDPR duties merely because the incident is cyber-related.
6. Translate the result into the contract
Three DORA Article 30 layers
30(1) is written allocation and service levels. 30(2) is the baseline for every ICT-service contract. 30(3) adds requirements where a service supports a critical or important function.
Classify the financial entity's function first. A supplier cannot settle that legal conclusion simply by accepting or rejecting a "critical" label in negotiations.
7. Apply the matrix: the Oriole case
Thought exercise: give the board one answer, not one acronym
Oriole Systems sells a network-monitoring appliance with a cloud console to Union customers. A payment institution uses it to monitor its payment gateway. The appliance software contains an actively exploited vulnerability; the console stores named administrator logs. Oriole is not itself authorised as a financial entity.
Reasoned decision: advise a four-track response. Oriole, as possible CRA manufacturer, must assess Article 14 reporting now; the product evidence should include component traceability and the technical-documentation record. The payment institution must assess its DORA incident and third-party-risk position, including whether the monitoring function is critical or important and therefore triggers Article 30(3) additions. Oriole must separately assess its own NIS2 status based on its actual service and scope facts. GDPR must be assessed for the administrator logs.
Fact that could reverse the result: if the cloud console is not designed or developed by Oriole, or its absence does not prevent a product function, the CRA remote-processing analysis changes. If Oriole becomes a licensed financial entity, DORA applies to it in that role. Ask for architecture, market-placement, licence, and function-criticality evidence before final advice.
Scenario quiz: choose the best next decision
Oriole's board wants a single instruction after learning that its payment-institution customer calls the monitoring service "critical." What is the best next decision?
What should counsel recommend first?
- Treat Oriole as DORA-regulated because its customer is a financial entity, and stop the NIS2 and GDPR analysis.
- Create an actor-object matrix: assess Oriole's CRA manufacturer role and NIS2 status, the customer's DORA obligations and function classification, and GDPR roles for the administrator logs.
- Wait until 11 December 2027 because CRA obligations are not relevant before its main application date.
Show Answer
Answer: B) Create an actor-object matrix: assess Oriole's CRA manufacturer role and NIS2 status, the customer's DORA obligations and function classification, and GDPR roles for the administrator logs.
Option B is the best next decision because each regime attaches to a different legal actor and object. The customer must classify its own function under DORA; that does not make the supplier a financial entity. Oriole must assess CRA reporting now because Article 14 has applied since 11 September 2026, while its NIS2 and GDPR exposure depend on separate scope facts. Option A collapses distinct roles. Option C ignores the CRA's already-applicable reporting obligations.
Key Terms
- SBOM
- Software bill of materials: a formal record of components and their supply-chain relationships in a product's software elements.
- Financial entity
- For DORA, an entity listed in Article 2(1)(a)-(t), subject to the Regulation's exclusions and options.
- Actor-object matrix
- A practical map separating the legal person, regulated object, factual trigger, and resulting obligation.
- Product with digital elements
- CRA term covering software or hardware products and qualifying remote data processing solutions.
- Critical or important function
- A DORA classification based on the consequences of disruption or defective performance for the financial entity.
- ICT third-party service provider
- An undertaking providing ICT services; it is not, solely by that status, a DORA financial entity.