Artikel 3(1) van de Cyber Resilience Act, Verordening (EU) 2024/2847, definieert een product met digitale elementen als "een software- of hardwareproduct en de bijbehorende oplossingen voor gegevensverwerking op afstand". Artikel 3(2) definieert gegevensverwerking op afstand als "gegevensverwerking op afstand waarvoor de software door of onder de verantwoordelijkheid van de fabrikant is ontworpen en ontwikkeld en zonder welke het product met digitale elementen een van zijn functies niet zou kunnen vervullen". Of uw product überhaupt onder het toepassingsgebied valt hangt af van artikel 2 en overweging 12. Zodra dat zo is, is de volgende vraag voor elk bedrijf met een app en een cloud welke delen van de cloud mee naar binnen zijn gekomen, want die delen gaan in de risicobeoordeling, de essentiële eisen, het technisch dossier en de meldplicht.

De richtsnoeren van de Commissie over de toepassing van de verordening, C(2026) 5252 van 27 juli 2026, deel 8, punten 178 tot 208, beantwoorden die vraag preciezer dan de verordening doet. Dit artikel is dat deel, met zijn vijf gebruiksgevallen, gelezen voor een softwarefabrikant.

Twee cumulatieve toetsen

Punt 184 splitst de definitie in drie elementen: of de verwerking op afstand plaatsvindt, of het ontbreken ervan het product zou beletten een van zijn functies te vervullen, en of de software door of onder de verantwoordelijkheid van de fabrikant is ontworpen en ontwikkeld. Punt 185 zet het eerste vervolgens opzij als "relevant maar niet voldoende": cloud, edge en de eigen servers van de fabrikant op locatie tellen allemaal als op afstand (punt 187), zodat het eerste element zelden iets beslist. Punt 188 stelt de regel: het tweede en het derde zijn "de twee beslissende en cumulatieve vragen", en "als beide vragen bevestigend worden beantwoord, kwalificeert de gegevensverwerking op afstand" als oplossing voor gegevensverwerking op afstand.

Punt 202 geeft de drie uitkomsten. Beide ja: het is deel van uw product, en bijlage I is erop van toepassing. De functietoets nee: geen deel van het product, maar "fabrikanten moeten de risico's die voortvloeien uit het bestaan van die gegevensverwerking beoordelen als onderdeel van hun risicobeoordeling". De functietoets ja maar de verantwoordelijkheidstoets nee: "fabrikanten moeten de oplossing van de derde als een component behandelen", de risico's van de integratie beoordelen en beperken, en "zorgvuldigheid betrachten".

Toets één: zou het ontbreken ervan een functie stilleggen

Het woord is "functies", niet kernfunctionaliteit. Punt 189: "het begrip 'functies' in deze definitie is niet beperkt tot de 'kernfunctionaliteit' of het 'beoogde doel' van het product met digitale elementen", en omvat "zowel functies die het beoogde doel van het product met digitale elementen zoals gebruikers dat ervaren rechtstreeks vervullen als functies die de algehele prestaties van het product ondersteunen". Punt 190 noemt zes voorbeelden van verwerking op afstand waar een product niet zonder kan: "(i) opdrachten naar een apparaat sturen; (ii) bestanden synchroniseren; (iii) de gebruiker onboarden; (iv) configuratie (personalisering van het product met digitale elementen); (v) geautomatiseerde distributie van updates, met inbegrip van functie-updates en beveiligingspatches; (vi) identiteits- en toegangsbeheer".

Twee verfijningen doen ertoe voor software. Een functie die de gebruiker zowel op afstand als handmatig kan uitvoeren, de lamp geschakeld vanuit een app of met de hand, telt nog steeds: "het op afstand uitvoeren van deze functie wordt ook beschouwd als onderdeel van de functies die het product met digitale elementen biedt" (punt 191). En het tegenvoorbeeld is telemetrie: "analyse op afstand van telemetriegegevens die louter voor statistische doeleinden of toekomstige productontwikkeling worden verzameld" is geen functie die het product nodig heeft, dus geen gegevensverwerking op afstand (punt 192), al voegt punt 193 toe dat de risico's van die componenten op afstand wel in de risicobeoordeling thuishoren.

Websites krijgen een eigen punt, 194. Een website die alleen informatie over het product draagt, valt er niet onder, "zelfs als het product naar die website doorverwijst". Een website die "een functie mogelijk maakt of ondersteunt" wel: "een authenticatieportaal dat inloggegevens of tokens uitgeeft die het product met digitale elementen nodig heeft om te werken, zou als RDPS worden beschouwd". Voor de meeste softwarebedrijven plaatst die ene zin de inlogdienst binnen het product.

Toets twee: door u, of onder uw verantwoordelijkheid, ontworpen en ontwikkeld

Punt 195: in eigen huis gebouwde software voldoet, en software die een externe leverancier voor u bouwt ook, maar "onder de verantwoordelijkheid van de fabrikant" betekent "op maat gemaakt voor de fabrikant", gevallen waarin "de software uitsluitend door of namens de fabrikant is gebouwd, op basis van door hem verstrekte ontwerpen en specificaties". Een bestaande dienst in licentie nemen, "of licht gewijzigde versies daarvan", is dat niet.

Wie het beheert, is niet relevant. Punt 196: "het begrip 'wie de oplossing exploiteert' is geen beslissende factor, aangezien de CRA-definitie alleen verwijst naar ontwerp en ontwikkeling". Een backend die u schreef en een hostingbedrijf beheert, is van u.

De punten 197 tot 200 sorteren vervolgens de drie cloudmodellen. Op IaaS van een derde zet u uw eigen besturingssystemen en toepassingen uit; die software "is door of onder de verantwoordelijkheid van de fabrikant ontworpen en ontwikkeld en kan daarom kwalificeren" (punt 198). Op PaaS van een derde zet u uw eigen toepassing uit op de runtime van de aanbieder; "de toepassing is daarom door de fabrikant ontworpen en ontwikkeld" en kan kwalificeren (punt 199). Een SaaS-toepassing van een derde die in uw product is geïntegreerd, "is daarom niet door de fabrikant ontworpen en ontwikkeld" (punt 200) en is geen gegevensverwerking op afstand, welke functie zij ook ondersteunt.

Wat buiten de definitie valt, valt niet buiten uw verantwoordelijkheid. Punt 201: de hypervisor onder uw IaaS, het besturingssysteem onder uw PaaS, de SaaS van een derde "moeten als vergelijkbaar met componenten van derden worden beschouwd" waar zij de beveiliging van het product raken, en de fabrikant "is verplicht de risico's in verband met de integratie van die elementen te identificeren en te beoordelen en ze aan te pakken door de essentiële eisen op het product met digitale elementen zelf toe te passen", met "een verplichting vergelijkbaar met de zorgvuldigheidsplicht van artikel 13(5)".

De grens: modules waarmee uw product praat, niet alles daarachter

Dit is het deel dat bepaalt hoe groot het technisch dossier wordt. Punt 205: de gegevensverwerking op afstand die onder de conformiteitsbeoordeling van het product valt "moet beperkt blijven tot de softwaremodules die verantwoordelijk zijn voor de functionaliteit van het product met digitale elementen, en tot de interfaces die die modules met externe diensten gebruiken. Verdere backend-systemen die de daaropvolgende verwerking uitvoeren en waarmee het product met digitale elementen niet rechtstreeks interageert, worden niet als RDPS beschouwd". Punt 206 houdt ze in de risicobeoordeling als "externe afhankelijkheden die moeten worden beoordeeld" en "door maatregelen op productniveau" moeten worden beperkt.

Punt 182 somt op wat de definitie nooit heeft willen bereiken, op grond van overweging 11: "interne systemen voor de eigen personeelszaken van de fabrikant, salarisadministratie, klantrelatiebeheer, CI/CD-pijplijnen (continuous integration/continuous delivery), de distributie van beveiligingsupdates naar edge-locaties, mogen niet als RDPS worden beschouwd", en evenmin "systemen die verband houden met audit- en testactiviteiten, zoals penetratietests, threat hunting en red teaming". De CRA dekt het product, niet "de gehele IT-infrastructuur van een organisatie". Dat is het terrein van NIS2, en overweging 12 zegt dat.

Het geval mobiel bankieren, dat het geval van de meeste softwarebedrijven is

Deel 8.3.1 loopt de app van een bank door met een zelf gehoste backend en een supportchat van een derde. De app praat met een "bankinterface" die de bank bouwde, die op haar beurt een rekeningbeheersysteem en een grootboek bevraagt. De interface authenticeert de klant, dient overboekingsopdrachten in en geeft hun status terug; zij "is noodzakelijk opdat de app zijn functies kan vervullen" en "is onder de verantwoordelijkheid van de fabrikant ontworpen en ontwikkeld", dus zij is gegevensverwerking op afstand en "moet daarom worden opgenomen in de cyberbeveiligingsrisicobeoordeling en in de uitvoering van de essentiële eisen". Het rekeningbeheersysteem en het grootboek zijn dat niet: "de app interageert er niet rechtstreeks mee", en "hoewel hun beschikbaarheid nodig kan zijn om een functie te voltooien, dekt de CRA alleen de delen van het systeem die rechtstreeks met het product interageren". Zij blijven externe afhankelijkheden waarvan de compromittering "een aanvaller in staat zou kunnen stellen transactieresultaten te beïnvloeden", te beperken op productniveau, "zoals sterke authenticatie van backend-interfaces, integriteitsbescherming van transactiegegevens, beveiligde communicatiekanalen en verificatie van de door de app ontvangen antwoorden".

De supportchat, "ontwikkeld en geëxploiteerd door een derde aanbieder", is nodig voor een functie maar zakt voor de verantwoordelijkheidstoets, dus zij is "geen RDPS" en "moet als een component van een derde worden behandeld", geïsoleerd van de kernfuncties, met zorgvuldigheid jegens de aanbieder.

Vertaal dat naar een typische B2B-SaaS met een desktop- of mobiele client: de API-gateway en de authenticatiedienst die de client aanroept, zitten in het product; het datawarehouse drie stappen daarachter is een externe afhankelijkheid; de ingebedde analyse-, chat- of betaalwidgets van derden zijn componenten. De andere vier gevallen bevestigen het patroon: de cloudfuncties van een thermostaat op IaaS van een derde zitten erin (8.3.2), de SaaS-opslag van een derde voor een e-reader is een component (8.3.3), de visiedienst van een robot op IaaS zit erin (8.3.4), en het 5G-netwerk van een telefoon is geen van beide, "slechts een communicatiekanaal", zonder zorgvuldigheidsplicht jegens de operator (8.3.5).

Wat in het dossier gaat, en wat u kunt hergebruiken

Punt 204: fabrikanten "moeten (i) in de technische documentatie aangeven dat hun product met digitale elementen RDPS heeft of op oplossingen op afstand van derden steunt en (ii) die oplossingen beschrijven", en waar één backend meerdere producten bedient, wordt zij in het dossier van elk product opgegeven en "kan de documentatie van de ene conformiteitsbeoordeling naar de andere worden hergebruikt".

Voor de diensten van derden waarop u steunt, noemt punt 207 de zekerheidsdocumenten die ter ondersteuning van uw beoordeling en zorgvuldigheid kunnen worden hergebruikt: bewijs dat de aanbieder de NIS2-uitvoeringsverordening naleeft, DORA, een certificaat onder een Europese cyberbeveiligingscertificeringsregeling, of "bewijs van conformiteit met ISO/IEC 27017:2015 of ISO/IEC 27001:2022". Punt 208 voegt de contractuele kant toe: beveiligingsgaranties in dienstverleningsovereenkomsten, "met inbegrip van toezeggingen dat aanbieders kwetsbaarheden adequaat afhandelen", en een grote wijziging bij een aanbieder is geen substantiële wijziging van uw product, maar kan een herziening van uw risicobeoordeling vergen.

Van de andere kant gelezen is punt 207(d) ook wat uw eigen klanten van u kunnen vragen. Als uw product gegevensverwerking op afstand is voor het hunne, is uw ISO 27001-certificaat het document dat de richtsnoeren noemen voor hun dossier.

De bepaling, in zes regels

Leg voor elke dienst op afstand die uw product aanroept vast:

  1. De dienst en de functie die hij ondersteunt, in de zin die de richtsnoeren aan functie geven.
  2. Toets één: zou het product die functie zonder hem verliezen. Telemetrie en informatiewebsites: nee.
  3. Toets twee: door u of naar uw specificatie gebouwd, of een in licentie genomen toepassing van een derde. IaaS en PaaS zetten uw code aan de binnenkant; SaaS zet de toepassing aan de componentkant.
  4. De uitkomst onder punt 202: deel van het product, een component om met zorgvuldigheid te beoordelen, of een externe afhankelijkheid om te beoordelen.
  5. De grens onder punt 205: met welke modules het product rechtstreeks interageert, en welke systemen daarachter zitten.
  6. Het document dat u voor elke dienst van een derde hebt, uit de lijst van punt 207, en de datum waarop u het kreeg.

Die tabel is het deel over verwerking op afstand van het technisch dossier, de invoer voor de risicobeoordeling die artikel 13 vereist, en het antwoord op de tweede vraag in onze toepassingsbepaling. Het is ook de lijst van systemen waarvan de compromittering de meldklok start, want punt 178 zegt dat het product, verwerking op afstand inbegrepen, is waarover artikel 14 rapporteert.

Bronnen

  • Verordening (EU) 2024/2847, artikel 3(1), (2) en (4), artikel 13(2), (3) en (5), overwegingen 11 en 12.
  • Europese Commissie, richtsnoeren van de Commissie over de toepassing van Verordening (EU) 2024/2847, C(2026) 5252 final van 27 juli 2026, bijlage, deel 8, punten 178 tot 208 en gebruiksgevallen 8.3.1 tot 8.3.5.
  • Richtlijn (EU) 2022/2555 (NIS2) en Uitvoeringsverordening (EU) 2024/2690 van de Commissie, voor de clouddiensten die de richtsnoeren aan hen overlaten.

Dit is geen juridisch advies. Deel 8 is elf pagina's en de vijf gevallen zijn het duidelijkste deel van de hele richtsnoeren; lees ze voordat u uw eigen grens trekt.