SkarpChapter 3 of 3
Resolve a boundary between cyber regimes · New case 4
Develop regulatory scope and digital products while working to advise boards and product teams.
1. Start with the regulated object
Four regulatory objects
Do not ask which regime "wins". First separate the product, the supplier's service activity, the financial-customer relationship, and any personal-data processing.
A connected product can be subject to CRA analysis while its supplier may separately fall within NIS2, and its financial customer may have DORA duties.
2. Map the fictional launch
Visual: four-box map
`Gateway appliance` → `Remote console` → `NordAegis operations` → `Administrator and audit data`.
Each box may trigger a different scope analysis.
Conflicting labels are not legal conclusions. "DORA supplier" describes a commercial relationship; it does not decide whether the appliance is a CRA product or whether NordAegis operates a NIS2-covered service.
3. Decide the CRA boundary
Product perimeter
Test whether the console is remote data processing whose absence prevents the gateway from performing one of its functions. Confirm its architecture and any CRA exclusions.
Document intended purpose, relevant software versions, system architecture and vulnerability handling. Annex VII makes technical documentation a product evidence file, not a sales brochure.
On 18 September 2026, CRA Article 14 already applies, but the Regulation generally applies from 11 December 2027. Do not describe all CRA requirements as currently applicable.
4. Keep DORA's contract layers distinct
DORA is not product classification
DORA makes the payment institution responsible for ICT-risk management and for sound third-party arrangements. It does not automatically make its supplier a DORA financial entity.
30(1) written allocation and service levels. 30(2) baseline ICT-service contract content. 30(3) additional clauses for services supporting critical or important functions. The customer assesses this in the first instance, subject to competent-authority review.
5. Thought exercise: test the NIS2 branch
Ask one activity question
Write one sentence describing what NordAegis actually does: "It remotely monitors, detects, and assists customers to manage cybersecurity risks," or "It sells a product and provides incidental update infrastructure."
The first description may point towards a managed security service provider activity under NIS2; the second may not. NIS2 scope is entity-and-activity based, using Annex I or II categories and the size rule, subject to the Directive's specified exceptions and national implementation. Do not infer NIS2 coverage solely from a DORA customer or a CRA product.
For financial entities identified under NIS2, DORA is expressly a sector-specific Union legal act for NIS2 Article 4 purposes. That rule concerns the financial entity; it is not a blanket exclusion for its ICT supplier.
6. Run GDPR alongside the cyber analysis
Parallel data question
Administrator identities, IP addresses and audit logs may be personal data. Automated security monitoring can therefore be GDPR processing.
Run a separate data-flow review: roles, purpose, legal basis, retention, access, transfers and contract terms. GDPR documentation is not a substitute for CRA or DORA evidence.
7. Give the board a conditional decision
Best next decision
Use a dual-track launch gate: CRA product evidence, DORA customer-contract assessment, then separate NIS2 and GDPR assessments.
The console's place in the gateway's CRA perimeter could change if its absence does not prevent the gateway from performing one of its functions. The gateway still needs its own CRA assessment, separately marketed console software may need a separate assessment, and a relevant exclusion could alter either conclusion.
Scenario quiz: choose the next decision
The product lead asks for one launch decision
NordAegis has a gateway with a purpose-built remote console. A payment institution says the console may support a critical function, but NordAegis has not assessed whether its own monitoring activity falls within NIS2.
What is the best next decision?
- Classify NordAegis as a DORA financial entity and defer CRA work until 11 December 2027.
- Treat the gateway and console as the provisional CRA perimeter while confirming whether the console's absence prevents a gateway function, obtain the customer's DORA assessment for Article 30, and separately assess NordAegis under NIS2 and GDPR.
- Apply only GDPR because the console stores administrator names and audit logs.
Show Answer
Answer: B) Treat the gateway and console as the provisional CRA perimeter while confirming whether the console's absence prevents a gateway function, obtain the customer's DORA assessment for Article 30, and separately assess NordAegis under NIS2 and GDPR.
Option 2 preserves the separate legal objects. DORA affects the payment institution's ICT-risk and contractual controls, with Article 30(1), (2), and potentially (3) applying at different levels. The customer assesses in the first instance whether the service supports a critical or important function, subject to competent-authority review. This does not displace CRA product analysis or decide NordAegis's NIS2 position. GDPR may apply to console data, but it does not replace the other analyses. The console's place in the gateway's CRA perimeter could change if its absence does not prevent a gateway function. The gateway would still need its own CRA assessment, separately marketed console software may need a separate assessment, and a relevant exclusion could alter either conclusion.
Key Terms
- CRA product perimeter
- The product with digital elements and any remote data-processing solution whose absence would prevent the product from performing one of its functions, assessed together for Cyber Resilience Act purposes.
- Software bill of materials
- A formal record containing details and supply-chain relationships of components included in a product with digital elements, covering at least its top-level dependencies for the CRA vulnerability-handling requirement.
- Critical or important function
- A DORA classification that the financial customer assesses in the first instance, subject to competent-authority review, and that determines whether Article 30(3) additional contractual provisions are required.
- ICT third-party service provider
- A supplier providing ICT services to a financial entity; it is not automatically a DORA financial entity.
- Managed security service provider
- A NIS2-relevant activity category requiring an entity-and-activity scope assessment, not an assumption based on customer sector.