Styring af IKT-projekter med security by design i 2026

Projektet var til tiden, indtil revisionen stillede ét spørgsmål

CISO’en i en hurtigt voksende betalingsteknologivirksomhed havde gode nyheder til bestyrelsen. Den nye platform til kundeonboarding var klar til lancering. Produktteamet havde leveret den mobile oplevelse, udviklingsteamet havde integreret identitetsverifikation, juridisk afdeling havde godkendt cloud- og API-udbyderne, og driften havde øvet idriftsættelsesplanen.

Så stillede den interne revisor ét spørgsmål:

“Vis mig, hvor sikkerhed og databeskyttelse blev vurderet på hvert trin i projektet.”

Projektrummet blev stille.

Der var en rapport fra penetrationstesten, men den kom sent. Der var et cloudarkitekturdiagram, men ingen dokumentation for, at dataflows var blevet vurderet i forhold til GDPR-principperne. Der var et spørgeskema til leverandør-due diligence, men det var ikke koblet til risikoregistret. Der var en ændringssag for udrulning til produktionsmiljøet, men godkendelsen nævnte ikke påvirkning af kritiske tjenester, hændelsesrapportering, robusthedstest, kundeunderretning eller eskalering ved brud på persondatasikkerheden. Der var sprintnoter, men sikkerhedskravene var spredt over user stories og chatbeskeder.

Intet var åbenlyst forsømmeligt. Alt lignede et travlt, moderne IKT-projekt. Men for en finansiel enhed omfattet af DORA, en SaaS-udbyder potentielt omfattet af NIS2 og en dataansvarlig eller databehandler under GDPR var spørgsmålet ikke længere kun, om sikkerhed fandtes. Spørgsmålet var, om security by design kunne dokumenteres.

Det er 2026-problemet. IKT-projekter vurderes ikke længere kun på leveringshastighed, omkostningsstyring og teknisk kvalitet. De vurderes på styringsdokumentation: risikovurderinger, designbeslutninger, leverandør-due diligence, registreringer for sikker udvikling, ændringsgodkendelser, beslutninger om databeskyttelse, testresultater og ledelsestilsyn.

ISO/IEC 27001:2022 giver organisationer en praktisk ledelsessystemmæssig rygrad til at løse problemet. Den hjælper CISO’er, complianceansvarlige, projektsponsorer, DPO’er, arkitekter, indkøbsteams og revisorer med at omsætte væsentlige IKT-projekter til juridisk og revisionsmæssigt forsvarlig dokumentation for security by design.

Hvorfor styring af IKT-projekter nu er et regulatorisk dokumentationsproblem

En cloudmigrering, kundeportal, betalingsplatform, CRM-implementering, ændring af identitetsudbyder, analysepipeline, API-integration, SaaS-workflow, low-code-applikation eller overgang til en administreret tjeneste kan alle ændre organisationens risikobillede. I 2026 sker disse ændringer under overlappende forpligtelser.

NIS2 gælder bredt for væsentlige og vigtige enheder på tværs af Annex I- og Annex II-sektorer, herunder digital infrastruktur, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester og digitale udbydere. NIS2 Article 20 gør ledelsesorganer ansvarlige for at godkende foranstaltninger til styring af cybersikkerhedsrisici og føre tilsyn med gennemførelsen. NIS2 Article 21 kræver passende og proportionale tekniske, operationelle og organisatoriske foranstaltninger for risikostyring, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, sikker udvikling, sårbarhedshåndtering, vurdering af effektivitet, cyberhygiejne, kryptografi, adgangsstyring, politik for aktivstyring og sikker kommunikation.

DORA gælder for finansielle enheder og fokuserer på digital operationel robusthed. DORA Article 5 placerer ansvaret for styring af IKT-risiko hos ledelsesorganet. DORA Article 6 kræver en sund, omfattende og veldokumenteret ramme for IKT-risikostyring. DORA dækker også rapportering af IKT-relaterede hændelser, test af operationel robusthed, IKT-forretningskontinuitet, respons og genopretning, deling af cybertrusselsoplysninger, styring af IKT-tredjepartsrisiko, kontraktlige aftaler og tilsyn med kritiske IKT-tredjepartsudbydere.

GDPR tilføjer ansvarlighedslaget for personoplysninger. GDPR Article 25 kræver databeskyttelse gennem design og standardindstillinger. Dataansvarlige skal kunne dokumentere overholdelse af principper som lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Hvor behandling sandsynligvis medfører høj risiko, kan en konsekvensanalyse vedrørende databeskyttelse efter GDPR Article 35 også være påkrævet.

Fællesnævneren er dokumentation. Tilsynsmyndigheder og revisorer spørger ikke kun, om en platform var krypteret, patchet, scannet eller testet. De spørger, om organisationen kan dokumentere, at sikkerhed, databeskyttelse, leverandørrisiko og robusthed var en del af beslutningsgrundlaget fra begyndelsen.

Derfor er ISO/IEC 27001:2022-projektstyring så stærk. Den gør det muligt for organisationen at håndtere NIS2, DORA, GDPR, NIST CSF 2.0, kontraktlige forpligtelser og kunders assurancekrav gennem én gentagelig ISMS-proces frem for flere adskilte tjeklister.

ISO 27001-rygraden for projektstyring

ISO/IEC 27001:2022 misforstås ofte som en certificeringsøvelse. For IKT-projekter er den operationelle værdi bredere. Den giver en styringsmæssig rygrad for forretningsændringer.

Punkt 4.1 til 4.4 kræver, at organisationer forstår interne og eksterne forhold, interessenter, juridiske, regulatoriske og kontraktlige krav, ISMS-omfang, grænseflader og afhængigheder. I projekttermer betyder det, at projektgrundlaget bør identificere berørte tjenester, kunder, leverandører, regler, forretningsprocesser, personoplysninger, kritiske driftsaktiviteter og udliciterede tjenester.

Punkt 5.1 til 5.3 kræver ledelsesforpligtelse, tilpasning til politikker, ressourcer, integration i forretningsprocesser og tildelte ansvar. Det er vigtigt, fordi både NIS2 og DORA placerer cybersikkerhed og IKT-risiko under ledelsesorganets ansvar. Et projekt, der ændrer en kritisk kundeplatform, kan ikke nøjes med en uformel sikkerhedskommentar i en chattråd. Det kræver klar ansvarlighed.

Punkt 6.1.1 til 6.1.3 kræver en gentagelig proces for risikovurdering og risikobehandling, risikokriterier, risikoejere, vurdering af fortrolighed, integritet og tilgængelighed, risikobehandlingsplaner, anvendelighedserklæring og godkendelse af restrisiko. Det er her, projektrisiko bliver til revisionsbevis.

Punkt 7.1 til 7.5 kræver ressourcer, kompetence, bevidsthed, kommunikation og styring af dokumenteret information. Det er sådan, projektregistreringer bliver til pålidelig dokumentation frem for spredte artefakter.

Punkt 8.1 kræver operationel planlægning og styring, dokumenteret information, der viser, at processer er gennemført som planlagt, styring af planlagte ændringer, gennemgang af utilsigtede ændringer, afbødning af negative virkninger og styring af eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS. Punkt 8.2 og 8.3 kræver risikovurderinger og risikobehandling vedrørende informationssikkerhed med planlagte intervaller eller når væsentlige ændringer opstår.

Anneks A forbinder derefter denne ledelsescyklus med praktiske kontroller. For security by design i IKT-projekter er tre ISO/IEC 27001:2022 Anneks A-kontroller centrale:

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan behandler informationssikkerhed i projektledelse som et styringsanliggende på tværs af alle projekttyper, ikke kun softwareudvikling:

“Ethvert projekt, en migrering af et marketingsystem, en flytning af en bygning, et redesign af en forretningsproces, en HR-onboardingplatform eller endda en fusion eller et opkøb, kan påvirke oplysningers fortrolighed, integritet eller tilgængelighed. Og når det sker, skal sikkerhed have en plads ved bordet.”

Samme afsnit indfanger den centrale implementeringslære:

“Målet med denne kontrol er ikke at belaste projekter med bureaukrati. Det er at sikre, at sikkerhed behandles som et designinput, ikke som en testfase.”

Denne skelnen adskiller symbolsk compliance fra forsvarlig security by design.

Hvordan security by design ser ud inde i et IKT-projekt

Security by design starter før det første sprint, den første indkøbsanmodning, det første arkitekturdiagram eller den første migrerings-runbook. Det stiller ét enkelt spørgsmål: Hvad kan dette projekt ændre ved risikoen?

En praktisk projektstyringsmodel anvender syv dokumentationsporte.

Pointen er ikke bureaukrati. Pointen er at gøre sikkerhed synlig dér, hvor projektbeslutninger faktisk træffes.

Clarysec Enterprise Informationssikkerhedspolitik udtrykker dette direkte:

“Sikkerhedsstyring skal integreres med virksomhedsstyring, projektledelse, indkøb og juridiske tilsynsfunktioner for at sikre, at informationssikkerhed ikke isoleres, men indlejres i hele forretningens beslutningstagning.”

Fra afsnittet “Styringskrav”, politikklausul 5.5.

Den gør også projektlivscyklusser til et implementeringskrav:

“Projektlivscyklusser (f.eks. sikker udvikling, trusselsmodellering)”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.1.1.

Og den fastslår det revisionsprincip, som mange organisationer opdager for sent:

“Alle implementerede kontroller skal kunne revideres, understøttes af dokumenterede procedurer og opbevaret dokumentation for drift.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.6.1.

Med andre ord vil sikkerhedsarbejde, der ikke styres, opbevares og kortlægges, ofte fejle i revisionen, selv om de tekniske teams traf rimelige beslutninger.

Fra trusselsmodellering til dokumentation: et praktisk fintech-eksempel

Overvej et projekt om lancering af en ny EU-kundeonboardingportal for en fintechvirksomhed. Portalen indsamler identitetsdokumenter, udfører biometrisk verifikation via en tredjepart, lagrer onboardingstatus, integrerer med CRM, udløser kundeunderretninger og føder risikoscore.

En security by design-tilgang opbygger dokumentationen, efterhånden som projektet skrider frem.

Først oprettes en registrering for projektets sikkerhedsklassificering. Identificér, om projektet påvirker kritiske eller vigtige funktioner, personoplysninger, særlige kategorier af personoplysninger, autentifikation, kundevendt tilgængelighed, udliciterede IKT-tjenester, regulerede rapporteringsprocesser eller kundekommunikation. Under GDPR er biometriske data, der anvendes til entydig identifikation, en særlig kategori af personoplysninger, medmindre en specifik undtagelse gælder. Det øger straks det krævede niveau for juridisk analyse og sikkerhedsforanstaltninger.

Dernæst udarbejdes en projektrisikovurdering. Clarysec SME Politik for risikostyring gør risikostyring til en del af planlægningen, ikke en kvartalsvis regnearksøvelse:

“1.2 Den sikrer, at risikostyring er en aktiv komponent i planlægning, projektgennemførelse, leverandørudvælgelse og håndtering af sikkerhedshændelser, i overensstemmelse med ISO 27001, ISO 31000 og gældende regulatoriske krav.”

Fra afsnittet “Formål”, politikklausul 1.2.

For virksomhedsmiljøer definerer Clarysec Enterprise Politik for risikostyring omfanget på tværs af projektmæssige og tekniske niveauer:

“Den dækker informationssikkerhedsrisici på strategisk, operationelt, projektmæssigt og teknisk niveau og er obligatorisk for alt personale, kontrahenter og tjenesteudbydere, der deltager i aktiviteter under ledelsessystem for informationssikkerhed (ISMS).”

Fra afsnittet “Omfang”, politikklausul 2.3.

For det tredje gennemføres en trusselsmodel, før udviklingen begynder. Enterprise Politik for sikker udvikling er tydelig:

“Alle nye applikationer og væsentlige ændringer skal gennemgå sikkerhedsarkitekturgennemgang og trusselsmodellering, før udviklingen påbegyndes.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

For onboardingportalen bør trusselsmodellen dække eksponerede grænseflader, identitetsflows, privilegiegrænser, API-misbrugsscenarier, webhook-spoofing, replay-angreb, kompromitterede legitimationsoplysninger, datalækageveje, afhængighedsrisiko, logningskrav, backupforudsætninger, gendannelseskrav og leverandørers fejlscenarier.

For det fjerde opdateres dokumentationen for databeskyttelse. SME Databeskyttelses- og privatlivspolitik fastlægger baseline:

“5.3.1. Databeskyttelse gennem design og standardindstillinger skal håndhæves i alle nye systemer og tjenester”

Fra afsnittet “Styringskrav”, politikklausul 5.3.1.

Projektregistreringen bør omfatte formål, behandlingsgrundlag, rolle som dataansvarlig eller databehandler, beslutninger om dataminimering, opbevaringsregler, adgangsroller, krypteringsvalg, vurderinger af påvirkning for registrerede, gennemsigtighedskrav, databehandlervilkår og underretningsveje ved brud på persondatasikkerheden.

For det femte registreres dokumentation for sikker udvikling. SME Politik for sikker udvikling giver en kortfattet dokumentationsliste, der fungerer for små og mellemstore teams:

“5.3 Den administrerende direktør (GM) skal opbevare registreringer over: 5.3.1 Alle aktive softwareudviklingsprojekter og de ansvarlige udviklere eller leverandører 5.3.2 Sikkerhedstjeklister anvendt for hvert projekt 5.3.3 Udførte kodegennemgange og de personer, der udførte dem 5.3.4 Testresultater forud for udrulning 5.3.5 Tredjepartskomponenter og deres tilknyttede licens- eller risikostatus”

Fra afsnittet “Styringskrav”, politikklausul 5.3.

For det sjette styres udrulningen som en ændring. SME Politik for ændringsstyring fastslår:

“1.1 Denne politik sikrer, at alle ændringer af IT-systemer, konfigurationer, forretningsapplikationer eller cloudtjenester planlægges, risikovurderes, testes og godkendes før implementering.”

Fra afsnittet “Formål”, politikklausul 1.1.

For onboardingportalen bør ændringssagen omfatte berørte tjenester, risikovurdering, testresultater, tilbagerulningsplan, overvågningsplan, sikkerhedsgodkendelser, godkendelse fra DPO, leverandørberedskab, opdateringer af hændelseseskalering og udløsere for kundekommunikation.

Endelig kortlægges forpligtelserne. SME Politik for juridisk og regulatorisk efterlevelse giver driftsreglen:

“5.2.2 Hvor en regulering gælder på tværs af flere områder (f.eks. gælder GDPR for opbevaring, sikkerhed og databeskyttelse), skal dette tydeligt kortlægges i efterlevelsesregisteret og træningsmaterialet.”

Fra afsnittet “Styringskrav”, politikklausul 5.2.2.

Dette efterlevelsesregister bliver broen mellem ISO/IEC 27001:2022-kontroller, NIS2 Article 21-foranstaltninger, DORA-forpligtelser vedrørende IKT-risiko, GDPR-ansvarlighed og kundekontraktforpligtelser.

Kortlægning af én projektdokumentationspakke til NIS2, DORA, GDPR og NIST CSF 2.0

Den mest effektive compliance-strategi er ikke at duplikere arbejdet. Det er at kortlægge ét stærkt dokumentationssæt til flere forpligtelser.

Zenith Blueprint anbefaler i risikostyringsfasen, trin 14, denne type krydshenvisningsarbejde:

“For hver regulering, hvis relevant, kan du oprette en enkel kortlægningstabel (eventuelt som bilag i en rapport), der oplister reguleringens centrale sikkerhedskrav og de tilsvarende kontroller/politikker i dit ISMS.”

Den tilføjer, at dette er nyttigt, fordi det viser revisorer og assessorer, “at du ikke styrer sikkerhed i et vakuum, men er opmærksom på den juridiske kontekst.”

Clarysecs Zenith Controls: Vejledning til efterlevelse på tværs af krav understøtter den samme integrerede tilgang ved at kortlægge ISO/IEC 27001:2022-kontroller til andre rammeværker, revisionsforventninger og compliancebehov. For styring af IKT-projekter beskriver den A.5.8, A.8.25 og A.8.32 som forebyggende kontroller, der beskytter fortrolighed, integritet og tilgængelighed på tværs af styring, applikationssikkerhed, økosystem, beskyttelse samt system- og netværkssikkerhed.

Denne tabel erstatter ikke juridisk analyse. Den er en styringsaccelerator. Den sikrer, at CISO, DPO, projektsponsor, indkøbsansvarlig, systemejer og intern revisor ser på den samme dokumentation.

NIST CSF 2.0 passer også naturligt ind i denne model. Dens GOVERN-funktion hjælper organisationer med at etablere politikker, roller, risikovillighed, tilsyn og juridisk eller kontraktlig bevidsthed. Dens IDENTIFY-, PROTECT-, DETECT-, RESPOND- og RECOVER-funktioner hjælper teams med at drøfte aktiver, leverandørtjenester, adgangsstyring, datasikkerhed, platformsikkerhed, sikker softwareudvikling, overvågning, hændelseshåndtering og genopretning på et fælles operationelt sprog.

Én ISO 27001-tilpasset proces centreret om Anneks A.5.8 kan generere forsvarlig dokumentation for alle disse forventninger.

Sikker udvikling er bredere end at skrive kode

Mange IKT-projektfejl opstår, fordi organisationen behandler sikker udvikling som noget, kun udviklere gør. I 2026 omfatter sikker udvikling også SaaS-konfiguration, workflowautomatisering, infrastruktur som kode, API-integrationer, identitetsregler, landingszoner i cloud, analysepipelines, robotic process automation og low-code-forretningsapplikationer.

Zenith Blueprint, fasen Controls in Action, trin 20, behandler ISO/IEC 27002:2022-kontrol 8.25 Secure Development Life Cycle:

“Denne kontrol gælder, uanset om du skriver dine egne applikationer, konfigurerer platforme som ERP- eller CRM-systemer, tilpasser SaaS-workflows eller administrerer infrastructure-as-code-miljøer.”

Den forklarer også, at sikkerhedskrav skal stå side om side med funktionelle krav, og at trusselsmodellering hjælper med at identificere eksponerede dele af systemet, risikofyldte brugerroller og dataflows, der kræver højere beskyttelse.

For et moderne projekt kan dokumentation for sikker udvikling omfatte:

• Sikkerhedskrav knyttet til forretningskrav
• Trusselsmodel eller sikkerhedsarkitekturgennemgang
• Tjekliste for sikker kodning eller sikker konfiguration
• Registreringer for kodegennemgang eller peergennemgang
• Komponentfortegnelse og status for afhængighedsrisiko
• Beslutninger om håndtering af hemmeligheder
• Design for adgangsstyring og mindst privilegieprincip
• Krav til logning og overvågning
• Resultater fra sårbarhedsscanning og registreringer for afhjælpning
• Sikkerhedstest før produktionsmiljø
• Backup-, gendannelses- og robusthedstest hvor relevant
• Dokumentation for udrulningsgodkendelse og tilbagerulning

Målet er ikke at tvinge alle projekter gennem den samme tunge proces. Målet er proportionalitet. En mindre intern workflowændring kræver ikke samme dokumentation som en migrering af en central betalingsplatform. Men hvert projekt bør klassificeres, risikovurderes og styres efter påvirkning.

Ændringsstyring beskytter projektet mod sig selv

Det mest risikofyldte tidspunkt i mange projekter er ikke design eller kodning. Det er udrulning.

Et team kan gennemføre trusselsmodellering, kodegennemgang, leverandørvurdering og privatlivsgennemgang og alligevel skabe et nedbrud eller brud gennem en forhastet ændring i produktionsmiljøet. Et debug-flag forbliver aktiveret. En firewallregel er bredere end godkendt. Et migreringsscript kopierer personoplysninger til et ikke-produktionsmiljø. Et tredjeparts webhook-endpoint udrulles uden autentifikation. En logningsændring registrerer numre fra identitetsdokumenter. Et backupjob fejler tavst efter overgangen.

Zenith Blueprint, fasen Controls in Action, trin 21, beskriver ISO/IEC 27002:2022-kontrol 8.32 Change Management direkte:

“Ændring er uundgåelig, men i cybersikkerhed er ukontrolleret ændring farlig.”

Den fortsætter:

“I sin kerne er effektiv ændringsstyring en gentagelig arbejdsgang. Den begynder med et klart forslag, der beskriver, hvad der ændres, hvorfor, hvornår og hvilke potentielle risici der er.”

En stærk IKT-ændringsregistrering bør besvare:

• Hvilket system, hvilken tjeneste, hvilket dataflow, hvilken leverandør eller hvilken konfiguration ændres?
• Hvilke risici blev identificeret, og hvem ejer dem?
• Påvirker ændringen personoplysninger, kritiske tjenester, autentifikation, logning, sikkerhedskopier eller hændelseshåndtering?
• Hvilke sikkerheds-, databeskyttelses-, robustheds- og leverandørkontroller blev udført?
• Hvilke test blev gennemført før udrulning?
• Hvilken overvågning vil bekræfte forventet adfærd?
• Hvilken tilbagerulnings- eller gendannelsesplan findes?
• Hvem godkendte restrisiko?
• Hvilken dokumentation opbevares?

For DORA understøtter dette dokumenteret styring af IKT-risiko, robusthed, kontinuitet, hændelsesklassificering og læringspunkter. For NIS2 understøtter det risikostyringsforanstaltninger, sikker udvikling, hændelsesforebyggelse og kontinuitet. For GDPR hjælper det med at dokumentere, at ændringer, der påvirker personoplysninger, blev gennemgået i forhold til formål, dataminimering, opbevaring, adgang og sikkerhedsprincipper.

Leverandør- og cloudbeslutninger skal være en del af projektdesignet

I moderne IKT-projekter er den designbeslutning med højest risiko ofte “køb” frem for “byg”. Cloudtjenester, API-udbydere, platforme til identitetsverifikation, betalingsformidlere, analyseleverandører, udbydere af administrerede tjenester og udbydere af administrerede sikkerhedstjenester bliver en del af risikofladen.

NIS2 omfatter udtrykkeligt sikkerhed i forsyningskæden, sårbarheder hos direkte leverandører og tjenesteudbydere, leverandørers cybersikkerhedspraksis, procedurer for sikker udvikling og resultater af koordinerede risikovurderinger af forsyningskæden. DORA går dybere for finansielle enheder. Den kræver styring af IKT-tredjepartsrisiko som en del af rammen for IKT-risikostyring, fortsat ansvar selv når IKT-tjenester udliciteres, informationsregistre, prækontraktuelle vurderinger, analyse af koncentrationsrisiko, kontraktkontroller, revisions- og inspektionsrettigheder, ophørsudløsere og testede exit-strategier for kritiske eller vigtige funktioner.

For onboardingportalen kan udbyderen af biometrisk verifikation ikke godkendes alene, fordi indkøb kan lide prisen, og API-dokumentationen er god. Projektet kræver dokumentation for sikkerhedsmæssig due diligence, behandlingsrolle, datalokation, underleverandører, tilgængelighedsforpligtelser, hændelsessupport, revisionsrettigheder, bistand ved ophør, exit-mulighed og overvågningsforpligtelser.

I en moden dokumentationsmodel ligger leverandør- og cloudbeslutninger inde i projektets dokumentationspakke, ikke i en adskilt leverandørmappe. Når revisoren spørger, hvorfor en tredjepart blev accepteret, bør svaret omfatte forretningsbehov, risikovurdering, kontraktlige sikkerhedsforanstaltninger, gennemgang af databeskyttelse, robusthedspåvirkning og løbende overvågning.

Hvordan revisorer vil gennemgå dokumentation for security by design

Forskellige revisorer tilgår det samme IKT-projekt fra forskellige vinkler. En certificeringsrevisor, intern revisor, DORA-revisor, NIS2-kompetent myndighed, privatlivsrevisor, NIST-orienteret assessor eller COBIT-lignende revisor kan efterspørge lignende dokumentation, men fortolke den forskelligt.

Revisorer ønsker ikke flot præsentationsmateriale. De ønsker sporbarhed. De vil se, at krav førte til risici, risici førte til kontroller, kontroller førte til implementeringsdokumentation, og implementering førte til gennemgang.

Derfor er Zenith Controls nyttig i revisionsforberedelsen. Den hjælper teams med at forklare, hvorfor Anneks A.5.8, A.8.25 og A.8.32 er forebyggende kontroller, der beskytter fortrolighed, integritet og tilgængelighed, før forudsigelige fejl når produktionsmiljøet.

Den minimale Clarysec-projektdokumentationspakke

En stærk dokumentationspakke for security by design behøver ikke være enorm. Den skal være konsistent, proportional og kortlagt.

For et IKT-projekt med middel risiko anbefaler Clarysec typisk følgende minimumspakke:

1. Registrering af projektets sikkerhedsklassificering
2. Notat om regulatorisk anvendelighed, der dækker NIS2, DORA hvor relevant, GDPR og kontraktlige forpligtelser
3. Kort over dataflows og påvirkning af aktiver
4. Projektrisikovurdering og risikobehandlingsplan
5. Trusselsmodel eller sikkerhedsarkitekturgennemgang
6. Vurdering af leverandør og cloudtjeneste hvor relevant
7. Tjekliste for sikker udvikling eller konfiguration
8. Sikkerhedstestresultater og dokumentation for afhjælpning
9. Ændringsgodkendelse med tilbagerulnings- og overvågningsplan
10. Registrering for databeskyttelse gennem design, herunder behandlingsgrundlag og opbevaring, hvor personoplysninger indgår
11. Opdateringer af hændelseshåndtering og overvågning
12. Gennemgang efter implementering og læringspunkter
13. Kortlægning i efterlevelsesregister til kontroller og forpligtelser

Zenith Blueprint giver køreplanslogikken. Trin 22 bringer informationssikkerhed ind i alle projektfaser. Trin 20 indbygger sikker udvikling i planlægning, design, kode, test og udrulning. Trin 21 gør ændringsstyring struktureret, sporbar og gennemgåelig. Trin 14 anbefaler krydshenvisning af GDPR, NIS2, DORA og andre forpligtelser, så efterlevelseskrav ikke falder mellem to stole.

Politikkerne giver driftsreglerne. Informationssikkerhedspolitik integrerer sikkerhed med projektledelse, indkøb og juridisk tilsyn. Politik for risikostyring gør projektrisici til en del af ISMS-aktiviteten. Politik for sikker udvikling kræver trusselsmodellering. Politik for ændringsstyring kræver planlagte, risikovurderede, testede og godkendte ændringer. Databeskyttelses- og privatlivspolitik kræver databeskyttelse gennem design og standardindstillinger. Politik for juridisk og regulatorisk efterlevelse kræver, at reguleringer på tværs af flere områder kortlægges i efterlevelsesregisteret.

Tilsammen omsætter disse værktøjer security by design fra en ambition til en revisionsbar driftsmodel.

Almindelige fejlmønstre i IKT-projekter

Fejlene er normalt forudsigelige.

Den første er sen inddragelse af sikkerhed. Sikkerhedsgennemgange sker, efter arkitekturen er fastlagt, kontrakterne er underskrevet, og leveringsdatoerne er offentlige. På det tidspunkt bliver sikkerhed en blokering frem for et designinput.

Den anden er fragmenteret dokumentation. Projektet har testresultater i ét værktøj, leverandørgennemgang i et andet, kommentarer om databeskyttelse i e-mail, risikoaccept i en mødeoptagelse og ændringsgodkendelse i en sag. Ingen enkelt tråd dokumenterer styringen.

Den tredje er blinde vinkler ved leverandører. Projektet afhænger af en cloudtjeneste eller API-udbyder, men ingen kontrollerer underleverandører, datalokation, revisionsrettigheder, hændelsessupport, exit-planer eller koncentrationsrisiko.

Den fjerde er formålsglidning i databeskyttelse. Et system, der er bygget til ét formål, begynder at understøtte analyser, AI-eksperimenter, marketingeksporter eller operationel overvågning uden fornyet vurdering af behandlingsgrundlag, gennemsigtighed, dataminimering eller opbevaring.

Den femte er ugennemgået ændring. En udrulning til produktionsmiljøet godkendes for funktionalitet, men vurderes ikke for adgang, logning, kryptering, backup, robusthed, personoplysninger eller rapporteringspåvirkning.

Den sjette er svagt ledelsestilsyn. Projektrisici med høj påvirkning accepteres på et for lavt niveau, uden dokumentation for, at den ansvarlige risikoejer forstod de regulatoriske konsekvenser.

Disse problemer løses ikke ved at købe endnu en scanner. De løses ved at integrere sikkerhedsstyring i den måde, projekter foreslås, designes, indkøbes, bygges, testes, ændres og gennemgås på.

CISO’ens hovedpointe for 2026

Security by design i IKT-projekter er nu et bestyrelses-, revisions- og regulatorisk anliggende. NIS2 gør styring af cybersikkerhedsrisici til et ledelsesorgananliggende. DORA gør IKT-risiko, robusthedstest, hændelsesstyring og tredjepartstilsyn til en struktureret forpligtelse i den finansielle sektor. GDPR kræver ansvarlighed for behandling af personoplysninger og passende sikkerhed. ISO/IEC 27001:2022 leverer ledelsessystemstrukturen, der gør disse forpligtelser operationelle.

For CISO’er er muligheden at stoppe med at kæmpe med projektteams ved afslutningen af leverancen. Indbyg sikkerhed i initiering, krav, design, leverandørudvælgelse, udvikling, test, ændringsgodkendelse og gennemgang efter implementering.

For complianceansvarlige er muligheden at erstatte spredt dokumentation med én kortlagt projektdokumentationspakke.

For revisorer er muligheden at teste projektlivscyklussen, ikke kun det endelige system.

For forretningsejere er muligheden hurtigere og sikrere levering. Security by design reducerer omarbejde, forebygger complianceoverraskelser, forbedrer leverandørbeslutninger og giver ledelsen en forsvarlig risikofortælling.

Hvis jeres IKT-projekter bevæger sig hurtigere end jeres dokumentationsmodel, så begynd med ét pilotprojekt. Brug Clarysecs Zenith Blueprint til at definere sikkerhedsporte for projekter, anvend Clarysec-politikker for risikostyring, sikker udvikling, ændringsstyring og databeskyttelse, og brug Zenith Controls til at kortlægge ISO/IEC 27001:2022-projektstyring til NIS2, DORA, GDPR og NIST CSF 2.0.

Clarysec kan hjælpe jer med at opbygge en genanvendelig projektdokumentationspakke for security by design, tilpasse den til jeres ISMS og forberede den til intern revision, certificeringsrevision, DORA-beredskab, NIS2-styring og GDPR-ansvarlighed.

Start med jeres næste væsentlige IKT-projekt. Hvis det ændrer systemer, leverandører, data, adgang, robusthed eller kundetillid, fortjener det security by design fra dag ét.