SkarpChapter 3 of 3
Separate product and service obligations · New case 6
Develop regulatory scope and digital products while working to advise boards and product teams.
1. Start with the commercial unit, not the label
Inventory first
A commercial label such as "platform" does not decide scope. Separate the product, function-critical remote processing, standalone services, and personal-data flows.
The CRA functional test
Remote processing joins the CRA product only when its absence would prevent the product from performing one of its functions.
2. Apply the functional-dependency test
Conflicting facts matter
AsterLink's controller works locally during an outage. Its key-rotation and update channel may nevertheless be function-critical; its optional analytics dashboard may not be.
Do not choose by sales model
A bundled subscription can contain both a CRA product dependency and a separate managed service. Record the evidence supporting each boundary.
3. Run a boundary-evidence exercise
Evidence, not terminology
Ask what fails, whether local secure operation exists, who controls the remote software, and whether technical and contractual materials tell the same story.
Board-ready output
Classify each component as an in-product dependency, a standalone service, or a fact gap. State what evidence could change the conclusion.
4. Keep CRA product duties separate from service duties
Current CRA timing
On 18 September 2026, Article 14 reporting duties already apply. The CRA's main obligations apply from 11 December 2027.
SBOM nuance
Maintain SBOM evidence in technical documentation. Annex II(9) addresses where users can access an SBOM only if the manufacturer elects to provide one.
5. Assess the standalone service under NIS2
Separate NIS2 question
Evaluate the managed service as an entity activity. Product sales, a customer contract, and a GDPR processor role do not themselves establish NIS2 scope.
Avoid invented national rules
NIS2 is a Directive. Confirm the relevant Member State's implemented framework before advising on supervision or enforcement.
6. Add DORA without collapsing Article 30
DORA attaches differently
The financial customer assesses DORA. The provider's contract should support that assessment, but a supplier is not automatically a DORA financial entity.
Keep Article 30 distinct
Article 30(1) allocates rights in writing; 30(2) sets baseline ICT-contract content; 30(3) adds requirements for critical or important functions.
7. Use GDPR as an overlay, not a scope shortcut
GDPR is a separate lens
Personal-data processing may trigger GDPR, but controller or processor status does not answer the CRA functional-dependency test or NIS2 entity-scope question.
Best next decision
Approve one dependency map and three workstreams: CRA evidence, NIS2 scope validation, and customer-specific DORA/GDPR contracting.
Scenario decision: classify before drafting
Choose the best next decision
AsterLink's product team wants one CRA file for the controller, Pulse Insights, and WatchTower. The payment-institution customer asks for Article 30(3) audit clauses for every service. Evidence shows the controller works securely without Pulse Insights, but not without the manufacturer-controlled key-rotation service. WatchTower may support payment authentication, but its criticality has not yet been assessed by the customer.
What is the best next decision?
- Classify all cloud offerings as part of the CRA product and apply Article 30(3) to every contract to eliminate uncertainty.
- Treat the key-rotation service as a potential CRA product dependency, separately assess Pulse Insights and WatchTower as services, and require the financial customer to determine whether WatchTower supports a critical or important function before selecting Article 30(3) clauses.
- Exclude all cloud services from CRA because they are sold under subscriptions, and use the GDPR processor agreement as the complete contractual solution.
Show Answer
Answer: B) Treat the key-rotation service as a potential CRA product dependency, separately assess Pulse Insights and WatchTower as services, and require the financial customer to determine whether WatchTower supports a critical or important function before selecting Article 30(3) clauses.
The functional evidence supports treating manufacturer-controlled key rotation as a potential in-product CRA dependency. Pulse Insights and WatchTower require separate service analyses. Article 30(3) is not a universal ICT-contract rule: it applies where services support a critical or important function. The result could change if Pulse Insights becomes necessary for a product function, or if the financial customer documents that WatchTower supports a critical or important function.
Key Terms
- SBOM
- A software bill of materials: a formal record of component details and supply-chain relationships in the software elements of a product with digital elements.
- Remote data processing
- Manufacturer-controlled remote processing whose absence would prevent the product with digital elements from performing one of its functions.
- Managed service provider
- A NIS2 Annex I ICT service management (business-to-business) category requiring a separate entity-scope analysis.
- Product with digital elements
- Under the CRA, 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 determines whether the additional contractual requirements in Article 30(3) apply.