Den del af jeres backend, som en funktion i produktet hviler på, og som I selv har designet eller fået designet, er fjerndatabehandling og hører med til produktet efter Cyber Resilience Act. Systemerne bag den, som produktet ikke taler direkte med, er eksterne afhængigheder, der skal med i risikovurderingen, men ikke er en del af produktet.
Grænsen afgør, hvad risikovurderingen, den tekniske dokumentation og indberetningerne skal dække. Den bør derfor kunne lægges oven på arkitekturtegningen og passe.
Definitionen
Forordning (EU) 2024/2847 bruger begrebet i artikel 3, nr. 2, om behandling af data et andet sted end hos brugeren, når fabrikanten har stået for softwaren eller har haft ansvaret for den, og når produktet mister en funktion, hvis behandlingen falder væk. Artikel 3, nr. 1, regner sådanne løsninger med til produktet.
Kommissionens vejledning C(2026) 5252 (ikke bindende) læser definitionen som tre led i punkt 184 og 188. Behandlingen sker på afstand. Produktet mister en funktion, hvis den mangler. Og fabrikanten har selv lavet softwaren eller fået den lavet efter egne specifikationer. De to sidste led er efter vejledningen de afgørende, og de skal begge være opfyldt.
Hvad en funktion er
Vejledningen begrænser ikke funktioner til produktets kernefunktion (punkt 189 til 192). Den nævner som eksempler at sende kommandoer til en enhed, synkronisere filer, onboarding, konfiguration, automatisk distribution af opdateringer samt identitets- og adgangsstyring.
Telemetri, der alene bruges til statistik eller fremtidig produktudvikling, er ikke fjerndatabehandling. Den kan stadig skabe risici, som skal vurderes og afbødes (punkt 193), men den hører ikke til produktets omfang.
Hvad under fabrikantens ansvar betyder
Punkt 187 og 195 til 196 forklarer, at løsningen er under fabrikantens ansvar, når den er skræddersyet til fabrikanten efter dennes design og specifikationer. En licens til en eksisterende tjeneste er ikke nok. Hvem der driver løsningen, er ligegyldigt, og egne servere og privat sky kan lige så vel være fjerndatabehandling som offentlig sky.
Interne systemer er uden for. Vejledningens punkt 182 nævner HR, løn, CRM, CI/CD-pipelines, distribution af sikkerhedsopdateringer til kantlokationer og systemer til audit og test som eksempler på noget, der ikke er fjerndatabehandling.
Kun det, klienten taler direkte med
Punkt 205 og 206 trækker den grænse, de fleste softwarehuse har brug for. Kun de softwaremoduler, der står for produktets funktionalitet, og de grænseflader, de bruger mod eksterne tjenester, hører med. Bagvedliggende systemer, som produktet ikke interagerer direkte med, gør ikke. De er eksterne afhængigheder, der skal med i risikovurderingen og afbødes med foranstaltninger i selve produktet.
Vejledningens bankapp-eksempel i afsnit 8.3.1 gør det konkret. Bankens grænseflade, som appen taler med, er fjerndatabehandling. Konto- og bogføringssystemerne bag den er ikke, men risiciene fra dem afbødes i produktet med stærk autentificering af grænsefladerne, beskyttelse af transaktionsdatas integritet, sikre kanaler og kontrol af svar. En chat-tjeneste fra en tredjepart, der er bygget ind i appen, er heller ikke fjerndatabehandling. Den behandles som en tredjepartskomponent, som beskrevet i tredjeparts-SaaS, platform og infrastruktur i produktet.
Grænsen lagt på arkitekturtegningen
En praktisk måde at prøve grænsen på er at tage arkitekturtegningen og markere hver tjeneste med et af fire mærker. Metoden er praksis.
- Fjerndatabehandling · Hvad det betyder: Del af produktet og dets krav · Tænkt eksempel: (API, som appen synkroniserer med)
- Ekstern afhængighed · Hvad det betyder: I risikovurderingen, afbødes i produktet · Tænkt eksempel: (Faktureringssystem bag API’et)
- Tredjepartskomponent · Hvad det betyder: Omhu ved integration efter artikel 13, stk. 5 · Tænkt eksempel: (Indkøbt tjeneste til push-beskeder)
- Uden for · Hvad det betyder: Ingen rolle i produktet · Tænkt eksempel: (Intern HR-løsning)
Hvem der har adgang til serverne, og hvordan logningen er sat op, handler om driften. Det spørgsmål tages op i en teknisk gennemgang af driften.
Én backend, flere produkter
Bærer samme backend flere produkter, skal den efter vejledningens punkt 204 stå i hvert produkts tekniske dokumentation. Dokumentationen må gerne genbruges. Af dokumentationen skal det også fremgå, om produktet selv har fjerndatabehandling, eller om det hviler på løsninger, andre driver på afstand, og hvordan de ser ud.
Kommissionens tjenestegrenes FAQ (4.1.1, vejledende) og vejledningens punkt 178 siger samstemmende, at risikovurderingen skal dække hele produktet inklusive fjerndatabehandlingen. Kravene gælder fra 11. december 2027. En aktivt udnyttet sårbarhed i fjerndatabehandlingen er en sårbarhed i produktet, og den pligt til indberetning, der står i artikel 14, har gjaldt siden september 2026.
Hvad det kræver, og hvad det koster at lade være
Det kræver en opdateret arkitekturtegning og en arkitekt, der kan forklare, hvilke funktioner der går i stå, hvis en given tjeneste forsvinder. Mærkningen tager tid første gang og skal ses igen ved større ændringer.
Trækkes grænsen for bredt, kommer interne systemer med i produktets krav uden grund. Trækkes den for snævert, mangler en del af produktet i risikovurderingen, og det er den fejl, der er sværest at forklare bagefter.
Det skal I lade være med
- At regne hele backend med til produktet · bagvedliggende systemer er afhængigheder, der afbødes i produktet.
- At udelade login og opdateringsdistribution · vejledningen nævner begge som funktioner.
- At lade hvert produkts dokumentation henvise til en anden · fælles backend skal stå i hver enkelt.
Det skal auditten kunne vise
- ☐ En arkitekturtegning, hvor hver tjeneste er mærket.
- ☐ For hver fjerndatabehandling, hvilke funktioner der afhænger af den.
- ☐ Risici fra eksterne afhængigheder og de foranstaltninger, produktet har mod dem.
- ☐ Beskrivelse af fjerndatabehandlingen i hvert berørt produkts dokumentation.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 3, nr. 1 og 2, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 178, 182, 184 til 206 og afsnit 8.3.1, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 4.1.1, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag arkitekturtegningen frem, og mærk hver tjeneste efter de fire kategorier.
Læs også: Ren SaaS er uden for CRA · Mobilapps
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
