Artikel 28, stk. 1, i forordning (EU) 2022/2554, DORA, gør kundens IKT-risikostyringsrammeværk til det, din tjeneste er en del af, og Kommissionens delegerede forordning (EU) 2024/1774 af 13. marts 2024, offentliggjort den 25. juni 2024 og i kraft siden den 15. juli 2024, fastsætter det rammeværk i toogfyrre artikler: politikkerne, procedurerne, protokollerne og værktøjerne i artikel 9, stk. 2, i DORA, detektionsmekanismerne i artikel 10, kontinuitets- og genopretningsplanerne i artikel 11 og et forenklet rammeværk for de små enheder i artikel 16. Det meste af det er kundens eget husarbejde. Ni artikler nævner tredjepartsudbyderen af IKT-tjenester, og hver af dem er et spørgsmål, kundens rammeværk skal kunne besvare om dig, altså et spørgsmål, du vil få stillet. Denne artikel læser de ni i EU-Tidende på CELLAR den 12. september 2026, fra leverandørens side. Den er ikke juridisk rådgivning.
Aktivfortegnelsen vil have dine slutdatoer for support, artikel 4
Artikel 4 kræver en politik for forvaltning af IKT-aktiver, hvorefter enheden fører registreringer over hvert IKT-aktiv: en entydig identifikator, dets fysiske eller logiske placering, dets klassificering, dets ejer, de forretningsfunktioner, det understøtter, dets kontinuitetskrav, herunder mål for genopretningstid og genopretningspunkt, om det er eksponeret mod eksterne netværk, dets forbindelser og indbyrdes afhængigheder med andre aktiver og, litra b), nr. ix), i stk. 2, hvor det er relevant, slutdatoerne for tredjepartsudbyderens almindelige, udvidede og skræddersyede supporttjenester, hvorefter aktivet ikke længere understøttes. For en leverandør betyder det en offentliggjort supportlivscyklus pr. produktversion, med datoer, for kundens fortegnelse har en kolonne til det, og en tom kolonne er en afvigelse ved kundens næste revision.
Sårbarhedsproceduren kontrollerer dig, og sporer dine biblioteker, artikel 10
Artikel 10 kræver procedurer for sårbarhedsstyring, der blandt andet kontrollerer, om tredjepartsudbydere af IKT-tjenester håndterer sårbarheder i de leverede tjenester, og om de rettidigt rapporterer mindst de kritiske sårbarheder samt statistik og tendenser til enheden; og som sporer brugen af tredjepartsbiblioteker, herunder open source-biblioteker, i tjenester, der understøtter kritiske eller vigtige funktioner, og af tjenester, som en udbyder har udviklet eller tilpasset til enheden. Forordningen tilføjer, at enheden anmoder udbyderne om at undersøge de relevante sårbarheder, fastslå grundårsagerne og gennemføre afhjælpende foranstaltninger, og at den overvåger versioner og opdateringer af tredjepartsbiblioteker, hvor det er hensigtsmæssigt i samarbejde med udbyderen. Enheden selv kører automatiseret sårbarhedsscanning mindst ugentligt på aktiver, der understøtter kritiske eller vigtige funktioner, og dens patchstyring fastsætter frister med eskalering.
Læst fra leverandørens side er det tre leverancer: en proces for håndtering af sårbarheder, hvis eksistens kunden kan kontrollere, en periodisk sårbarhedsrapport, der mindst nævner de kritiske med statistik og tendenser, og en liste over tredjeparts- og open source-komponenterne i produktet med deres versioner, altså den softwarestykliste, som Cyber Resilience Act kræver af en fabrikant af egne grunde. En leverandør, der allerede laver den til CRA, besvarer artikel 10, stk. 2, litra d), med det samme dokument.
Data- og systemsikkerhed: roller mellem dig og kunden, foranstaltninger på din infrastruktur, artikel 11
Artikel 11 kræver en procedure for data- og systemsikkerhed, hvis elementer for IKT-aktiver eller -tjenester, der drives af en tredjepartsudbyder af IKT-tjenester, litra k), omfatter identifikation og gennemførelse af krav til at opretholde digital operationel modstandsdygtighed i overensstemmelse med dataklassificeringen og IKT-risikovurderingen. Til det punkt overvejer enheden gennemførelsen af leverandørens anbefalede indstillinger på de elementer, den selv driver, en klar fordeling af roller og ansvar for informationssikkerhed mellem enheden og udbyderen i overensstemmelse med enhedens fulde ansvar efter artikel 28, stk. 1, litra a), i DORA, de kompetencer, den har brug for til at styre og sikre tjenesten, og tekniske og organisatoriske foranstaltninger til at minimere risiciene ved den infrastruktur, udbyderen bruger til sine tjenester, under hensyn til førende praksis og standarder. Litra f), nr. ii), i samme artikel, om slutbrugerudstyr, kræver sikkerhedsmekanismer, som medarbejdere eller tredjepartsudbydere af IKT-tjenester ikke uautoriseret kan ændre, fjerne eller omgå.
For en SaaS-leverandør er rollefordelingen dokumentet om delt ansvar: hvilke sikkerhedsindstillinger kunden konfigurerer, hvilke leverandøren driver, og hvilke kunden ikke må slå fra. Foranstaltningerne på din infrastruktur er de foranstaltninger, dit certifikats omfang beskriver, og kundens rammeværk vil bede om dem med henvisning til en standard.
Krypterede forbindelser over tredjeparters netværk, artikel 13
Artikel 13 kræver netværkssikkerhedsforanstaltninger, der omfatter kryptering af netværksforbindelser over virksomhedsnetværk, offentlige netværk, hjemmenetværk, tredjeparters netværk og trådløse netværk for de anvendte kommunikationsprotokoller, under hensyn til dataklassificeringen, og for enhedens netværkstjenester dokumentation af, om de leveres af en koncernintern udbyder eller af tredjepartsudbydere. Leverandørens svar er kryptering under overførsel for hver forbindelse mellem kunden og produktet og mellem produktet og dets underleverandører, med protokolversionerne skrevet ned.
Kildekode fra udbydere analyseres og testes før produktion, artikel 16
Artikel 16 kræver en politik for anskaffelse, udvikling og vedligeholdelse af IKT-systemer og en procedure for test og godkendelse af alle IKT-systemer før brug og efter vedligeholdelse, afpasset efter kritikaliteten af de berørte forretningsprocesser og aktiver. Proceduren indeholder foranstaltninger til at beskytte integriteten af kildekode, der er udviklet internt eller af en udbyder og leveret til enheden, og fastsætter, at proprietær software og, hvor det er muligt, kildekode fra tredjepartsudbydere eller fra open source-projekter analyseres og testes før ibrugtagning i produktionsmiljøet. For en leverandør, hvis produkt installeres af kunden, er det kundens ret til at teste din release, før den går i drift, og til at se integritetsforanstaltninger på det, du leverer: signerede releases, kontrolsummer, en build-pipeline, du kan beskrive. For en SaaS-leverandør er det kundens interesse i dine egne releasetest, for ibrugtagningen i produktion sker på din side.
En navngiven konto til hver af dine medarbejdere med adgang, artikel 20
Artikel 20 kræver politikker for identitetsstyring, hvorefter hver medarbejder hos enheden eller hos en tredjepartsudbyder af IKT-tjenester, der har adgang til enhedens informationsaktiver og IKT-aktiver, tildeles en entydig identitet med en entydig brugerkonto. Hvor dine supportmedarbejdere rækker ind i kundens miljø, vil kunden udstede navngivne konti til dem og forvente, at du fortæller, hvem der kommer, og hvem der går; hvor de kun rækker ind i dit eget miljø, vil kundens spørgeskema bede dig vise den samme regel anvendt hjemme.
Dine hændelsesunderretninger er en af kundens detektionskilder, artikel 23
Artikel 23 kræver en mekanisme til hurtigt at opdage unormale aktiviteter, som blandt andre kilder indsamler, overvåger og analyserer underretninger om IKT-relaterede hændelser fra en tredjepartsudbyder af IKT-tjenester, opdaget i udbyderens egne systemer og netværk, og som kan påvirke enheden. Kundens alarmering er indrettet til at modtage dine underretninger som et feed ved siden af dens egne logfiler og trusselsefterretninger og til at prioritere dem, så de håndteres inden for dens forventede løsningstid, i og uden for arbejdstiden. Artiklen om større hændelser forklarer, hvad der så sker: fristen på fire timer hos kunden begynder, når den klassificerer, og din underretning er det, der lader den klassificere.
Kontinuitetstest omfatter din tjeneste og din insolvens, artikel 25 og 26
Artikel 25 kræver, at testen af enhedens IKT-beredskabsplaner, hvor det er relevant, omfatter test af IKT-tjenester leveret af tredjepartsudbydere og procedurer til at verificere, at enhedens medarbejdere, dens udbydere, dens systemer og dens tjenester kan reagere tilstrækkeligt på scenarierne i artikel 26; for udbyderscenarierne tager enheden behørigt hensyn til udbyderens insolvens eller svigt og politiske risici i udbyderens jurisdiktion. Artikel 26 kræver, at respons- og genopretningsplanerne overvejer scenarier, hvor en kritisk eller vigtig funktion forringes eller svigter, med den mulige virkning af en udbyders insolvens eller andet svigt, og politisk og social ustabilitet i udbyderens jurisdiktion og der, hvor dataene lagres og behandles, og at der gennemføres kontinuitetsforanstaltninger til at afbøde svigt hos udbydere af tjenester, der understøtter kritiske eller vigtige funktioner. Leverandørens del er exit- og overgangsproceduren i tjeklisten over klausulerne i artikel 30, 30(3)(f), og dens vilje til at deltage i kundens kontinuitetstest, som litra c) i artikel 30, stk. 3, allerede sætter i kontrakten.
Hvad et ISO 27001-system allerede besvarer
Den delegerede forordning nævner ingen standard, og det følgende er StandardOS' læsning af, hvor et ISO/IEC 27001:2022-ledelsessystem frembringer svarene, uden formodning om overensstemmelse. Artikel 4, stk. 2, litra b), nr. ix), er aktivfortegnelsen, A.5.9, hvis fortegnelsen bærer slutdatoer for support. Artikel 10 er foranstaltningen for sårbarhedsstyring, A.8.8, og leverandørernes rapporteringsvilkår i A.5.20; komponentlisten er den samme registrering, CRA beder om. Artikel 11, litra k), er leverandøraftalen, A.5.20, og konfigurationsforanstaltningen, A.8.9; litra f), nr. ii), er A.8.1 og A.8.7. Artikel 13 er A.8.20 til A.8.22 og kryptografiforanstaltningen, A.8.24. Artikel 16 er sikker udvikling, A.8.25 til A.8.29, med releasetesten i A.8.29 og ændringsstyringen i A.8.32. Artikel 20 er A.5.16, identitetsstyring, og A.5.18, adgangsrettigheder. Artikel 23 er planlægningen af hændelseshåndtering i A.5.24 og logningen og overvågningen i A.8.15 og A.8.16, som underretningen kommer fra. Artikel 25 og 26 er A.5.29 og A.5.30 og de kontinuitetstest, de kræver. Det, standarden ikke giver dig, er kundens fortegnelse, dens klassificering af din tjeneste og dens scenarier; det er spørgsmål, du besvarer med fakta, og databladet til registret rummer dem om lokationer og underleverandører.
Hvad du bør gøre, før rammeværkets spørgsmål kommer
Offentliggør en supportlivscyklus med datoer pr. version. Lav en komponentliste med versioner og en periodisk sårbarhedsrapport, og skriv rapporteringskadencen ind i kontrakten. Skriv dokumentet om delt ansvar, der fordeler rollerne efter artikel 11, litra k), herunder de indstillinger, kunden ikke må slå fra. Dokumentér krypteringen under overførsel med protokolversioner. Beskriv release-pipelinen og dens integritetsforanstaltninger. Anvend navngivne konti på dine egne medarbejdere, og tilbyd besked om til- og fratrædelse for konti i kundens miljø. Før dine hændelsesunderretninger ind i en kanal, kunden kan optage. Og øv exit med kunden, når den beder om det, for artikel 25 siger, at den vil. DORA-hubben rummer datoerne for forordningen og dens retsakter.