Chapter 3 of 3
Separate product and service obligations
Develop regulatory scope and digital products while working to advise boards and product teams.
1. Start with the regulated object, not the commercial label
Two maps, not one label
A commercial label such as "platform" does not determine scope. Map the product and the service separately before selecting legal obligations.
For each component, capture provider, user, data flow, operational dependency, market placement, and whether failure prevents a product function.
A shared security programme can support several regimes, but it does not merge their legal addressees, evidence requirements, or enforcement routes.
2. Draw the Cyber Resilience Act boundary
CRA product perimeter
CRA scope begins with a product with digital elements made available on the Union market and a direct or indirect logical or physical data connection.
Remote processing belongs in the product perimeter only if it is under the manufacturer's responsibility and its absence prevents a product function.
Do not confuse the provisions: CRA Article 3(2) defines remote data processing; Article 3(39) defines the software bill of materials.
3. Analyse the service provider as its own entity
Separate entity question
Ask whether the ongoing operation is a covered NIS2 service and whether the supplier meets the applicable size threshold or a size-independent case.
CRA conformity answers a product question. It does not decide whether the operating supplier is a NIS2-regulated entity.
DORA can displace specified NIS2 obligations for a covered financial entity where Article 4 equivalence is met. It does not switch off CRA or GDPR.
4. Run the personal-data overlay independently
A distinct data trigger
GDPR turns on processing and territorial scope, not on whether an item is a regulated product or a NIS2-covered service.
Allocate controller and processor roles service by service. A CRA remote function may process no personal data; a non-product support portal may still be fully subject to GDPR.
5. Keep DORA Article 30 layers distinct
Article 30(1)
Put rights and obligations in writing, with service levels, in one durable and accessible contractual document.
Article 30(2)
Apply the baseline service terms to all ICT services: scope, locations, data protection, recovery, service levels, incident assistance, cooperation, and termination.
Article 30(3)
Add heightened requirements only where the ICT service supports a critical or important function: measurable performance, audit, continuity, testing, and transition arrangements.
6. Build evidence without collapsing the regimes
One library, separate tags
Use one evidence library, but tag each item by legal addressee and obligation. Shared artefacts are not proof of identical compliance.
CRA documentation should connect the product risk assessment, architecture, vulnerability handling, support-period rationale, and user information.
Draft separate product and managed-service definitions. Describe technical dependencies without automatically characterising an optional cloud feature as CRA remote processing.
7. Fact inversion check
Test the conclusion
Take a cloud feature and change one fact: the product continues to perform every advertised function if the cloud is unavailable. Reassess the CRA boundary. Then change a second fact: the cloud operator sells managed monitoring to multiple enterprise customers. Reassess NIS2 entity scope and, for financial customers, DORA contracting.
Reflection: Which additional fact could change your advice, and why? Focus on functional necessity, who controls development and operation, the customer's regulated status, and whether personal data are processed.
Scenario quiz: Aurora Grid
Aurora Grid sells connected energy controllers with embedded software. Its manufacturer-operated relay service is necessary for the controllers to execute their advertised remote shut-off function. Aurora also sells an optional, separately priced managed monitoring dashboard. A bank intends to use the dashboard for a function it classifies as critical or important. The dashboard processes named employee access logs.
What is the best next decision?
What is the best next decision?
- Treat the entire offer solely as a CRA product and provide the bank with the CRA technical file.
- Create separate product, managed-service, DORA contract, and GDPR workstreams; confirm whether the dashboard supplier is independently in NIS2 scope before concluding it is.
- Treat the relay service and dashboard solely as NIS2 services because both are cloud-enabled.
Show Answer
Answer: B) Create separate product, managed-service, DORA contract, and GDPR workstreams; confirm whether the dashboard supplier is independently in NIS2 scope before concluding it is.
The required relay service is likely within the CRA product perimeter if it is under the manufacturer's responsibility and its absence prevents the advertised product function. The optional dashboard requires its own service analysis. The bank's DORA position can require Article 30(3) terms if the dashboard supports a critical or important function, while access logs require an independent GDPR role analysis. This decision could change if the relay service is not functionally necessary, is developed outside the manufacturer's responsibility, the dashboard is not an ICT service used by the bank, or the bank's classification changes. NIS2 scope still depends on the entity, service category, and applicable threshold or exception.
Key Terms
- Remote data processing
- CRA Article 3(2) concept: processing at a distance under the manufacturer's responsibility whose absence would prevent a product from performing one of its functions.
- Product with digital elements
- CRA term for a software or hardware product and its remote data processing solutions, including separately placed software or hardware components.
- Critical or important function
- A DORA classification that triggers heightened contractual requirements under Article 30(3).
- ICT third-party service provider
- A provider that supplies ICT services to a DORA financial entity.
- Software bill of materials (SBOM)
- A formal record of components and their supply-chain relationships within a product's software elements.