Erwägungsgrund 12

Software ist nur dann ein Produkt mit digitalen Elementen, wenn sie dem Nutzer bereitgestellt und auf dessen System ausgeführt wird. Web-Apps, die ausschließlich über den Browser genutzt werden, und reine Informations-Websites sind selbst keine Produkte — sie fallen nur als Remote Data Processing in den Scope, wenn sie eine Funktion eines Produkts unterstützen.

Kernaussagen

• Lokal installierte Anwendungen sind Produkte — auch Browser-Extensions und mit Web-Technologien gebaute Desktop-Apps, die lokal ausgeführt werden.
• Web-Apps und Progressive Web Apps, die nur im Browser laufen, sind keine Produkte mit digitalen Elementen (Erwägungsgründe 11 und 12).
• Ein lokal installierter Client plus die Datenverarbeitung „at a distance“, auf die er für seine Funktionen angewiesen ist, bilden zusammen das Produkt.

Remote-Datenverarbeitung ist Teil des Produkts, wenn drei Kriterien kumulativ erfüllt sind: Verarbeitung „at a distance“, Funktionsnotwendigkeit (ohne sie könnte das Produkt eine Funktion nicht erfüllen) und Entwicklung durch den Hersteller oder unter seiner Verantwortung. Die Leitlinien übersetzen das in zwei Prüffragen mit Entscheidungsbaum.

Kernaussagen

• „Wer betreibt“ ist unerheblich: On-Premises- oder Private-Cloud-Lösungen können genauso RDPS sein wie Public-Cloud-Lösungen.
• „Funktionen“ meint mehr als Kernfunktionalität: auch Onboarding, Datei-Sync, Konfiguration, automatische Update-Verteilung und Identity/Access Management zählen.
• Telemetrie rein für Statistik oder Produktentwicklung ist kein RDPS — die Risiken solcher Remote-Komponenten gehören aber trotzdem in die Risikobewertung.
• IaaS/PaaS: Läuft die eigene (oder beauftragte) Software auf fremder Infrastruktur, kann sie RDPS sein; Standard-SaaS von Dritten ist kein RDPS, wird aber wie eine Dritt-Komponente behandelt (Risiken mitigieren + Due Diligence).
• „Unter Verantwortung des Herstellers“ = maßgeschneidert für den Hersteller nach dessen Designs/Spezifikationen — nicht das bloße Lizenzieren eines bestehenden Dienstes.
• Interne Systeme (HR, CRM, CI/CD-Pipelines, Update-Verteilung an Edge-Standorte, Pentest-/Red-Team-Infrastruktur) sind kein RDPS.
• Websites nur bei Funktionsbeitrag: ein Auth-Portal, das Tokens für das Produkt ausstellt, kann RDPS sein — eine Info-Website nicht, selbst wenn das Produkt auf sie verlinkt.

Fünf durchgespielte Fälle zeigen die Abgrenzung: Bei der Mobile-Banking-App ist das selbst entwickelte Banking-Interface RDPS, nachgelagerte Ledger-/Kontensysteme nicht, der Support-Chat (Dritt-SaaS) ist eine Dritt-Komponente. Smart Thermostat und Industrieroboter: eigene Cloud-Software auf Dritt-IaaS ist RDPS. e-Reader: Dritt-SaaS-Storage ist kein RDPS, aber als Komponente zu behandeln. Das Mobilfunknetz ist reiner Kommunikationskanal — kein RDPS, keine Due Diligence nötig.

Kernaussagen

• Der CRA erfasst nur die Systemteile, mit denen das Produkt direkt interagiert — Risiken dahinterliegender Systeme (z. B. kompromittiertes Ledger) sind produktseitig zu mitigieren (starke Backend-Authentisierung, Integritätsschutz, sichere Kanäle).
• Bei Dritt-IaaS: RDPS und IaaS-Nutzung in der technischen Doku dokumentieren; vom Provider z. B. NIS-2-Nachweise einholen.
• Netz-Infrastruktur (5G, Ethernet, WLAN, Router) ist Kommunikations-Enabler, nicht Datenverarbeitung, deren Fehlen eine Produktfunktion verhindert.

Nur, wenn es als Remote-Datenverarbeitung im Sinne des CRA fungiert — also Teil eines Produkts mit digitalen Elementen ist. Reine Web-Anwendungen ohne Produktanbindung bleiben außerhalb. Cloud-Backends für IoT-Geräte sind erfasst.

Datenverarbeitung, die der Hersteller bereitstellt und die für die bestimmungsgemäße Funktion des Produkts notwendig ist — typisch bei Smart-Home-Apps, vernetzten Industriesteuerungen mit Cloud-Backend, Wearables mit Cloud-Sync.

Frage: Funktioniert das Produkt ohne diese Cloud? Wenn nein (Smart-Home-App ist notwendig für Gerätesteuerung) → CRA. Wenn ja (Web-Portal als zusätzliche Funktion, Produkt funktioniert standalone) → außerhalb CRA.