Alle artikler

DORA · Compliance

DORA og Secure SDLC: Hvad dit udviklingsteam skal kunne bevise

· 12 min. læsning · Sebastian Andersen

Under forordningen om digital operationel modstandsdygtighed (DORA) kan en banks tilsyn spørge, hvordan en enkelt ændring kom i produktion. DORA's tekniske standarder beskriver præcis, hvad svaret skal vise: sikkerhedskrav godkendt, før arbejdet startede, kode testet før release, afhængigheder tjekket, ingen rigtige kundedata i test og godkendelse fra en anden end udvikleren. Bygger du software til en bank, et forsikringsselskab eller en betalingsvirksomhed, når de samme spørgsmål dig gennem din kundes kontrakt.

De fleste udviklingsteams gør allerede meget af dette. Under DORA er spørgsmålet, om de kan bevise det. Har du en solid sikker softwareudviklingslivscyklus (Secure SDLC), er du nået det meste af vejen.

DORA, formelt forordning (EU) 2022/2554, skal holde finansielle tjenester kørende, når teknologien svigter eller bliver angrebet. Selve forordningen fastlægger principperne, mens de detaljerede regler står i de tekniske reguleringsstandarder (RTS) for risikostyring af informations- og kommunikationsteknologi (IKT), delegeret forordning (EU) 2024/1774. Dens Article 16 (ikke at forveksle med DORA's egen Article 16) er i praksis en Secure SDLC-politik skrevet af tilsynsmyndighederne. Dette indlæg kobler hvert krav til din livscyklus, så du kan se, hvad du skal beholde, hvad du skal tilføje, og hvad du skal kunne dokumentere.

Hvem skal egentlig forholde sig til DORA?

DORA omfatter 20 typer finansielle enheder i EU samt de IKT-virksomheder, der leverer til dem (DORA Art. 2).

SektorOmfattede enheder
Bank og betalingerKreditinstitutter, betalingsinstitutter, kontooplysningstjenesteudbydere, e-pengeinstitutter
Investering og markederInvesteringsselskaber, markedspladser, centrale modparter, værdipapircentraler, transaktionsregistre, udbydere af dataindberetningstjenester
FondeForvaltere af alternative investeringsfonde, UCITS-administrationsselskaber
Forsikring og pensionForsikrings- og genforsikringsselskaber, forsikrings- og genforsikringsformidlere, arbejdsmarkedsrelaterede pensionskasser
KryptoUdbydere af kryptoaktivtjenester og udstedere af aktivbaserede tokens (under forordningen om markeder for kryptoaktiver)
AndreKreditvurderingsbureauer, administratorer af kritiske benchmarks, udbydere af crowdfundingtjenester, securitiseringsregistre
TeknologiTredjepartsudbydere af IKT-tjenester til alle ovenstående

Nogle små enheder inden for disse typer er helt undtaget, fx forvaltere af alternative investeringsfonde under EU's størrelsesgrænser, forsikringsselskaber, der er for små til Solvens II (EU's kapitalregler for forsikringsselskaber), pensionskasser med højst 15 medlemmer og forsikrings- og genforsikringsformidlere, der er mikrovirksomheder eller små og mellemstore virksomheder (DORA Art. 2(3)).

For alle, der er omfattet, skalerer DORA. Reglerne gælder i forhold til virksomhedens størrelse og samlede risikoprofil og til arten, omfanget og kompleksiteten af dens tjenester (DORA Art. 4). En lille betalingsinstitution kan nøjes med en lettere opsætning end en stor bank, men begge skal kunne fremlægge dokumentationen.

Den vigtigste regel er, at en finansiel enhed bevarer det fulde ansvar for at overholde DORA, også når den outsourcer til en software- eller cloududbyder (DORA Art. 28(1)).

Hvem svarer til hvem under DORA Kompetente myndigheder (nationale tilsyn, og ECB for de største banker) fører direkte tilsyn med finansielle enheder, og EU's tilsynsmyndigheder overvåger kritiske IKT-udbydere direkte. Finansielle enheder bevarer det fulde ansvar og giver DORA-forpligtelser videre til softwareleverandører og kritiske IKT-udbydere gennem kontrakter. HVEM SVARER TIL HVEM UNDER DORA FØRER DIREKTE TILSYN OVERVÅGER DIREKTE KONTRAKTER (DORA ART. 28–30) KOMPETENTE MYNDIGHEDER NATIONALE, SAMT ECB EU-TILSYN (ESA'ERNE) EBA, EIOPA, ESMA FINANSIELLE ENHEDER FULDT ANSVARLIGE, ART. 5–30 SOFTWARELEVERANDØRER OMFATTET VIA KONTRAKTER KRITISKE IKT-UDBYDERE 19 UDPEGEDE, ART. 31–44 DIREKTE TILSYN FORPLIGTELSER GIVET VIDERE GENNEM KONTRAKTER Hvem svarer til hvem under DORA Kompetente myndigheder (nationale tilsyn, og ECB for de største banker) fører direkte tilsyn med finansielle enheder, og EU's tilsynsmyndigheder overvåger kritiske IKT-udbydere direkte. Finansielle enheder bevarer det fulde ansvar og giver DORA-forpligtelser videre til softwareleverandører og kritiske IKT-udbydere gennem kontrakter. HVEM SVARER TIL HVEM UNDER DORA FØRER DIREKTE TILSYN KONTRAKTER (ART. 28–30) OVERVÅGER DIREKTE KOMPETENTE MYNDIGHEDERNATIONALE, SAMT ECB FINANSIELLE ENHEDERFULDT ANSVARLIGE, ART. 5–30 SOFTWARELEVERANDØREROMFATTET VIA KONTRAKTER KRITISKE IKT-UDBYDERE19 UDPEGEDE, ART. 31–44 EU-TILSYN (ESA'ERNE)EBA, EIOPA, ESMA DIREKTE TILSYN FORPLIGTELSER GIVET VIDERE GENNEM KONTRAKTER
HvemHvordan DORA gælderHvad de har ansvaret forCentrale artikler
Banker, forsikringsselskaber, fonde, betalingsvirksomheder og andre finansielle enhederDirekte, under tilsyn af deres kompetente myndighed (national, eller ECB for de største banker)Hele IKT-risikorammen, herunder SDLC-reglerne i dette indlæg, test, hændelsesrapportering og styring af deres leverandørerDORA Art. 5–30,
RTS 2024/1774
Visse små eller undtagne enheder, oplistet i DORA Art. 16(1)Direkte, under en lettere ordningEn forenklet IKT-risikoramme, fastlagt i RTS 2024/1774 afsnit III i stedet for Article 16-reglerne i dette indlægDORA Art. 16,
RTS afsnit III
Software- og IKT-leverandørerIndirekte, gennem kundekontrakterVilkår om sikkerhed, hændelsesstøtte og opsigelse i alle kontrakter, samt revisionsret og exit-vilkår, når tjenesten understøtter en kritisk eller vigtig funktionDORA Art. 28–30
Kritiske IKT-udbydereDirekte, overvåget af EU's tilsynsmyndighederTilsyn fra en ledende tilsynsførende, som vurderer deres IKT-risikostyring og kan udstede henstillinger, oven i deres kontraktlige forpligtelserDORA Art. 31–44

For softwareleverandører betyder det, at DORA kommer i form af sikkerhedsspørgeskemaer, revisionsret og spørgsmål om, hvordan du bygger og tester din software. Har du softwarestyklister (SBOM'er), scanningsresultater, opsummeringer af penetrationstests og en proces for indrapportering af sårbarheder klar, bliver hver kundegennemgang lettere. Kun få udbydere bliver udpeget som kritiske. De første 19, primært store cloud- og platformsvirksomheder, blev udpeget i november 2025.

Hvad DORA kræver af udviklingen

Reglerne for udviklingen står to steder. Article 16 i RTS'en dækker, hvordan software bygges, og resten af DORA dækker ledelsen og driften omkring den. Livscyklussen nedenfor viser reglen bag hver fase, og hvordan det, du lærer i driften, føres tilbage til planlægningen.

Secure SDLC: otte faser koblet til DORA De otte faser i en sikker SDLC, fra Planlæg til Drift, hver med den DORA- eller RTS-artikel, der gælder. En pil viser, at erfaringer fra driften føres tilbage til planlægningen. SECURE SDLC · 8 FASER KOBLET TIL DORA ERFARINGER FØDER NÆSTE CYKLUS 1PLANLÆGDORA ART. 5, 13(6) 2KRAVRTS ART. 15, 16(1) 3DESIGNDORA ART. 8, 9 4KODERTS ART. 16(3), 16(7) 5BYGRTS ART. 10, 16(4) 6TESTDORA ART. 24, 25 7RELEASERTS ART. 17 8DRIFTDORA ART. 10, 11, 13 Secure SDLC: otte faser koblet til DORA De otte faser i en sikker SDLC, fra Planlæg til Drift, hver med den DORA- eller RTS-artikel, der gælder. En pil viser, at erfaringer fra driften føres tilbage til planlægningen. SECURE SDLC · 8 FASER KOBLET TIL DORA ERFARINGER FØDER NÆSTE CYKLUS 1PLANLÆGDORA ART. 5, 13(6) 2KRAVRTS ART. 15, 16(1) 3DESIGNDORA ART. 8, 9 4KODERTS ART. 16(3), 16(7) 5BYGRTS ART. 10, 16(4) 6TESTDORA ART. 24, 25 7RELEASERTS ART. 17 8DRIFTDORA ART. 10, 11, 13

Article 16, krav for krav

Article 16 i RTS'en har ni stykker. Tilsammen fortæller de, hvad din politik for sikker udvikling skal indeholde, og hvad dine teams og din pipeline rent faktisk skal håndhæve.

Article 16 · hvad din SDLC-politik skal sige og håndhæve
Stk.KravDin politik skal sigeDin SDLC skal håndhæve
16(1)(a)Navngiv din sikkerhedspraksisHvilke metoder og rammeværk for sikker udvikling du følger (fx NIST SSDF, OWASP SAMM)Teams arbejder efter den standard, og enhver afvigelse dokumenteres
16(1)(b)Fastlæg krav fra startHvert system skal have tekniske specifikationer og sikkerhedskrav, godkendt af forretningsejeren og ejeren af IKT-aktivetIngen udvikling eller indkøb starter uden godkendte sikkerhedskrav
16(1)(c)Forhindr manipulationHvordan du forhindrer utilsigtede eller bevidste ændringer under udvikling, vedligehold og udrulningBeskyttede branches, obligatorisk review, begrænsede udrulningsrettigheder, signerede artefakter
16(2)Test og godkend før idriftsættelseEn procedure for at teste og godkende hvert system før brug og efter vedligehold, med en dybde, der passer til systemets kritikalitetEn release-gate: test bestået og godkendelse registreret, plus gentest efter vedligehold og ændringer
16(3)Gennemgå kode, statisk og dynamiskKildekodegennemgang skal omfatte statisk og dynamisk test samt sikkerhedstest af systemer, der vender mod internettetStatisk (SAST) og dynamisk (DAST) applikationssikkerhedstest i pipelinen, hvor hvert fund analyseres, får en plan for udbedring og følges til det er lukket
16(4)Test softwarepakker tidligtPakker og afhængigheder sikkerhedstestes senest ved integrationScanning af afhængigheder i buildet, der blokerer kendte kritiske sårbarheder
16(5)–(6)Hold rigtige data ude af testIkke-produktionsmiljøer indeholder kun anonymiserede, pseudonymiserede eller randomiserede data og er beskyttedeDatamaskering eller syntetiske data som standard. Enhver brug af rigtige data er enkeltstående, tidsbegrænset, godkendt og rapporteres til IKT-risikofunktionen
16(7)Beskyt kildekodens integritetIntegritetskontroller gælder både for kode bygget internt og kode leveret af leverandørerAdgangskontrol til repositories, signerede commits, integritetstjek af leveret kode
16(8)Test tredjeparts- og open source-kodeLeverandørsoftware og, hvor det er muligt, leverandørers og open source-projekters kildekode analyseres og testes som din egenIngen udrulning uden scanningen, og en registreret begrundelse, når kildekoden ikke er tilgængelig
16(9)Medtag skygge-ITAlt ovenstående gælder, risikobaseret, for værktøjer bygget eller drevet uden for IT-funktionenEn oversigt over regneark, scripts og low-code-apps med en lettere gennemgangsproces

Hvor meget test et system kræver, afhænger af, om det understøtter en kritisk eller vigtig funktion, altså en funktion, hvis svigt alvorligt ville skade virksomhedens økonomi, kontinuiteten i dens tjenester eller dens compliance. Virksomhederne klassificerer selv deres systemer, og alle systemer, der understøtter en sådan funktion, skal testes mindst én gang om året (DORA Art. 24(6); mikrovirksomheder er undtaget). Et offentligt betalings-API kræver derfor langt mere end et internt rapportværktøj. Nogle virksomheder, som tilsynet udpeger ud fra deres betydning, systemiske karakter og IKT-risikoprofil, skal desuden gennemføre trusselsbaseret penetrationstest (TLPT) på produktionssystemer mindst hvert tredje år (DORA Art. 26).

Automatiserede scanninger er grundlaget, ikke hele testprogrammet. SAST, DAST og scanning af afhængigheder finder kendte mønstre, fx injektionsfejl og sårbare biblioteker, men ikke fejl i forretningslogik, autorisation eller timing: en overførsel fra en andens konto, et negativt beløb eller to ens forespørgsler, der skaber to overførsler. DORA's testprogram skal omfatte en række test, og eksemplerne går fra sårbarhedsscanninger og kildekodegennemgange til scenariebaserede test og penetrationstest (DORA Art. 24(2), 25(1)). Testene skal udføres af uafhængige testere, interne eller eksterne (DORA Art. 24(4)). Ekspertledet penetrationstest af de vigtigste systemer finder det, scannerne overser.

Stk. 16(4), 16(7) og 16(8) dækker også kode, du ikke selv har skrevet. I praksis betyder det en SBOM for hvert build, scannede og fastlåste afhængigheder og kontrakter, der giver dig sikkerhedsforpligtelser og, for kritiske eller vigtige funktioner, revisionsret over for dine leverandører (DORA Art. 28–30). SBOM'en dækker også en særskilt pligt til at holde styr på de tredjeparts- og open source-biblioteker, der bruges af systemer, som understøtter kritiske eller vigtige funktioner (RTS Art. 10(2)(d)).

Omkring koden

Omkring koden · ledelse og drift
OmrådeHvad DORA kræverSådan gør duHvor det står
LedelseLedelsen ejer IKT-risikoen, og medarbejderne er uddannedeEn bestyrelsesgodkendt politik og træning i sikker kodningDORA Art. 5, 13(6)
DesignKend dine risici og afhængighederTrusselsmodellering og kortlægning af afhængighederDORA Art. 8, 9
AdgangMindst mulige rettigheder for personer og pipelinesAdskilt udvikler- og produktionsadgang, kortlivede credentials til pipelines og logget administratoradgangRTS Art. 8, 20, 21
KrypteringBeskyt data og nøglerKryptering under overførsel og i hvile, ingen hemmeligheder i koden, administrerede nøgler med rotationRTS Art. 6, 7
ReleaseKontrollerede, godkendte ændringerÆndringsanmodninger, en separat godkender og en plan for rollbackDORA Art. 9,
RTS Art. 17
DriftOvervåg, patch og lærUgentlige sårbarhedsscanninger af systemer, der understøtter kritiske eller vigtige funktioner, patchfrister efter alvorlighed, gentest efter rettelser og evaluering efter hændelserDORA Art. 10, 11, 13,
RTS Art. 10

Intet af dette behøver at gøre leverancerne langsommere. De fleste af disse kontroller kører som automatiske gates i pipelinen. Godkendelsen er altid uafhængig af udvikleren, men dens omfang følger risikoen: en ændring med lav risiko får et hurtigt tjek, en med høj risiko en fuld gennemgang (RTS Art. 16(2), 17). Hver gate logger sit resultat, så revisionssporet bygger sig selv.

Praktisk eksempel: sikring af et betalings-API

For at se, hvordan det fungerer i praksis, kan du følge én ændring gennem livscyklussen. En betalingsvirksomhed tilføjer et nyt endpoint til sit offentlige API, så kunder kan planlægge overførsler. Ledelsesdelen fra planlægningsfasen er allerede på plads, så ændringen starter ved kravene. Gå gennem eksemplet nedenfor for at se, hvad der sker i hver fase, og hvilken dokumentation den efterlader.

Eksempel · én ændring gennem livscyklussen

En betalingsvirksomhed tilføjer et “planlæg overførsel”-endpoint til sit offentlige API.

Trin 1 af 7RTS Art. 16(1)(a), 16(1)(b)
Krav

Teamet arbejder efter virksomhedens standard for sikker udvikling, baseret på NIST SSDF. Før der skrives kode, godkender produktejeren (forretningsejeren) og ejeren af betalingssystemet (ejeren af IKT-aktivet) sikkerhedskravene, herunder stærk kundeautentifikation, rate limits pr. klient og en post i revisionsloggen for hver planlagt overførsel. Hvert krav bliver et acceptkriterium med en tilhørende testcase.

DokumentationGodkendte krav og testcases
Trin 2 af 7DORA Art. 8, 9
Design

En trusselsmodel af det nye flow kortlægger, hvordan en angriber kan misbruge det, for eksempel ved at ændre beløbet, genafspille en forespørgsel eller planlægge en overførsel fra en andens konto. Designet imødegår derefter hver trussel med signerede forespørgsler, idempotensnøgler og autorisationstjek på objektniveau ved hvert kald.

DokumentationTrusselsmodel og planlagte modforanstaltninger
Trin 3 af 7RTS Art. 16(1)(c), 16(3), 16(7), 16(8)
Kode

Udvikleren åbner en pull request mod en beskyttet branch med signerede commits. CODEOWNERS sender den til en reviewer fra betalingsteamet, og scanning efter hemmeligheder kører ved hvert push. Pull requesten tilføjer også et nyt open source-bibliotek til at håndtere gentagne tidsplaner. Pipelinen markerer det som en ny afhængighed, og revieweren godkender det efter at have tjekket, at det vedligeholdes aktivt og ikke har kendte sårbarheder. SAST finder en SQL-injektion i planlægningsforespørgslen, som rettes med en parametriseret forespørgsel før merge.

DokumentationSignerede commits, review-historik, SAST-resultater, godkendt afhængighed
Trin 4 af 7RTS Art. 10(2)(d), 16(4), 16(7), 16(8)
Byg

En midlertidig runner med kortlivede OIDC-credentials bygger containeren og laver en CycloneDX-SBOM. Pipelinen scanner afhængighederne, containerens base image og infrastructure-as-code-skabelonerne og blokerer et ældre datobibliotek, som projektet allerede bruger, og som har en kendt kritisk sårbarhed, så teamet fastlåser en rettet version. Et software development kit til svindelscoring fra en leverandør tjekkes mod leverandørens signerede udgivelse og scannes og testes derefter som intern kode, før det integreres. Imaget signeres med SLSA-provenance.

DokumentationSBOM, scanninger, verificeret leverandørkode, signeret image
Trin 5 af 7RTS Art. 16(2), 16(3), 16(5) og DORA Art. 24(4), 25
Test

Staging har de samme adgangskontroller som produktion og indeholder kun syntetiske kundedata. Her kører autentificeret DAST mod API'et ud fra dets OpenAPI-specifikation. Fordi endpointet vender mod internettet, skal det også sikkerhedstestes, og virksomhedens politik gør det til en penetrationstest af en uafhængig tester med fokus på forretningslogikken, fx negative beløb og race conditions på idempotensnøglen. Et fund af middel alvor kommer ind i handlingsplanen for sårbarheder med en ejer og en frist på 30 dage, og systemejeren accepterer formelt risikoen før release.

DokumentationDAST-resultater, pentestrapport, risikoaccept
Trin 6 af 7RTS Art. 17
Release

Udrulningsjobbet knytter releasen til en ændringsanmodning med en risikovurdering. Fordi den berører betalinger, klassificeres ændringen som høj risiko og får en fuld gennemgang. Som alle ændringer godkendes den af en anden end forfatteren. En admission-politik kører kun signerede images, og en canary-udrulning med automatisk rollback begrænser konsekvensen af en eventuel fejl.

DokumentationÆndringsregistrering, godkendelse, udrulningslog
Trin 7 af 7DORA Art. 10, 13, 24(6) og RTS Art. 10
Drift

Alarmer går i gang ved usædvanlige planlægningsmønstre, fx mange overførsler til den samme nye modtager. Den gemte SBOM tjekkes dagligt mod nye sårbarhedsadvarsler, så en nyoffentliggjort fejl i en kørende komponent straks opretter en sag. Fundet af middel alvor rettes og gentestes inden for fristen, og en ny SAST-regel plus en linje i kodestandarden forhindrer, at den samme fejl vender tilbage. Fordi API'et understøtter en kritisk funktion, kræver loven, at det testes hvert år, og virksomhedens politik gør det til en ny penetrationstest hver gang.

DokumentationLukket fund, SBOM-overvågning, ny SAST-regel, årlig pentest

Fem spørgsmål til dit udviklingsteam i denne uge

DORA beder sjældent om helt ny praksis. Den beder dig koble den praksis, du har, til reglerne og gemme dokumentationen. Disse fem spørgsmål viser hurtigt, hvor dit team står. Hvert af dem kan et tilsyn eller en kundes revisor stille, og eksemplet ovenfor viser, hvordan et godt svar ser ud. Under hvert svar står et typisk hul, du kan kigge efter.

Fem spørgsmål · sådan ser et godt svar ud
#SpørgsmålEt godt svarHvor det står
1Kan vi vise, hvem der godkendte sikkerhedskravene, før arbejdet startede?Krav godkendt af forretningsejeren og ejeren af IKT-aktivet, hver koblet til en testcaseTypisk hul: Krav, der kun er godkendt af udviklingsteamet, ikke af forretningsejeren og ejeren af IKT-aktivetRTS Art. 16(1)(b)
Eksempel: trin 1
2Kan vi følge hvert sikkerhedsfund til en rettelse eller en formel risikoaccept?Hvert fund registreret med en ejer og en frist og derefter gentestet efter rettelsen eller accepteret af systemejerenTypisk hul: Fund, der lukkes uden gentest, eller accepterede risici uden ejer eller slutdatoDORA Art. 24(5),
RTS Art. 10(2)(g)–(h), 16(3)
Eksempel: trin 5, 7
3Kan vi vise, at hver release blev testet og godkendt uafhængigt?En release-registrering med test- og scanningsresultater, en penetrationstest, hvor risikoen kræver det, og en godkender, der ikke er udviklerenTypisk hul: Udviklere, der godkender deres egne ændringer, eller test, der springes over ved “små” releasesRTS Art. 16(2), 17
Eksempel: trin 5, 6
4Kan vi liste tredjepartsbibliotekerne i et kørende system og se, når et af dem bliver sårbart?En SBOM for hvert build, scanning af afhængigheder, der blokerer kendte kritiske fejl, og daglige tjek mod nye sårbarhedsadvarslerTypisk hul: Et leverandør-SDK, der aldrig er blevet scannet, eller advarsler om afhængigheder, som ingen følger op påRTS Art. 10(2)(d), 16(4)
Eksempel: trin 3, 4, 7
5Kan vi forklare, hvilke systemer der kræver årlig, uafhængig test, og hvorfor?En klassificering af de systemer, der understøtter kritiske eller vigtige funktioner, et testprogram, der dækker hvert af dem hvert år, og testere, der er uafhængige af teametTypisk hul: Ingen skriftlig begrundelse for, hvorfor ét system får en penetrationstest og et andet ikke gørDORA Art. 8(1), 24(4), 24(6)
Eksempel: trin 5, 7

Er det ærlige svar på et af dem “ved ikke”, så start der. Vælg ét kritisk system, kør en enkelt ændring gennem trinene i eksemplet, og luk de huller, du finder.

Vil du have et uafhængigt blik på dit teams svar, eller har du brug for uafhængige penetrationstests til dit DORA-testprogram? SSA IT gennemgår din Secure SDLC op mod DORA, udfører de penetrationstests, du har brug for, og hjælper dig med at bygge sikkerhedsgates og revisionsspor ind i din pipeline.

Kontakt os.

Referencer

Fandt du artiklen nyttig? Del den med dit netværk.