Hvis du først begynder at samle dokumentation, når en kunde, en distributør eller en myndighed spørger efter den, er du allerede bagefter under CRA.
I denne artikel får du en praktisk forståelse af, hvorfor dokumentation bliver et af de mest afgørende konkurrenceparametre, når Cyber Resilience Act (CRA) rammer produkter med digitale elementer. Du får også en konkret måde at tænke kravene ind fra start, så dokumentation ikke bliver et dyrt “slutprojekt”.
Vi gennemgår, hvad CRA betyder i praksis, hvilke dokumenter der typisk efterspørges, hvordan du bygger en dokumentationskæde fra udvikling til drift, hvad det kan koste, og hvilke faldgruber jeg ser igen og igen i teams, der ellers leverer teknisk stærke produkter.
CRA i kort form: hvad det er, og hvorfor dokumentation pludselig får tænder
Cyber Resilience Act er EU-regulering, der stiller krav til cybersikkerhed for produkter med digitale elementer gennem hele deres livscyklus. Kort sagt: du skal kunne dokumentere, at produktet er udviklet, leveret og vedligeholdt med passende sikkerhed, herunder sårbarhedshåndtering og sikkerhedsopdateringer.
Det afgørende skifte er, at “vi har styr på sikkerhed” ikke længere kan være en mundtlig forsikring eller et par interne wiki-sider. Under CRA bliver dokumentation både bevis og styringsværktøj: den skal kunne tåle audit, kundekrav og interne overdragelser, også når nøglepersoner skifter job.
Mini-konklusion: CRA handler ikke kun om at være sikker, men om at kunne bevise det systematisk og gentageligt.
Hvorfor dokumentation bliver den nye flaskehals (og den nye genvej)
Mange virksomheder undervurderer, hvor hurtigt et dokumentationsgab kan stoppe et salg eller forsinke en release. I B2B ser jeg ofte, at sikkerheds- og compliance-spørgeskemaer kommer sent i indkøbsprocessen, men bliver afgørende for sign-off. CRA skubber den virkelighed helt ind i produktkernen.
Bevisbyrden flytter fra “efter” til “undervejs”
Hvis du først efterrationaliserer risikovurdering, sikkerhedskrav og testspor, ender du med “pæne dokumenter” uden troværdig sporbarhed. Det er svært at genskabe historik: hvorfor valgte vi denne kryptoløsning, hvem godkendte den, hvilke trusler adresserer den, og hvilken test dækker den?
Et konkret eksempel fra praksis: Et team kunne dokumentere, at de kørte SAST og dependency scanning. Men de kunne ikke vise, hvordan findings blev triageret, hvilke deadlines der gjaldt, eller hvem der tog beslutningen om at acceptere en risiko. Resultat: de måtte etablere proces og genbehandle historik under tidspres.
Dokumentation er også et drift- og supportværktøj
CRA skærper forventningerne til sårbarhedshåndtering og opdateringer. Når en kritisk CVE rammer, er det dokumentationen, der afgør, om du på timer kan svare på: Er vi påvirket? Hvilke versioner? Hvilke kunder? Hvad er workaround? Hvornår er patch klar?
Mini-konklusion: God dokumentation er ikke papirarbejde; det er en reducering af reaktionstid, salgsfriktion og release-risiko.
Hvad skal kunne dokumenteres: de typiske “beviser” kunder og audit vil se
Kravene varierer efter produkttype og risikoprofil, men de samme dokumentationstyper går igen. Tænk i sporbarhed fra krav → design → implementering → test → release → drift.
- Risikostyring og trusselsmodellering: metode, scope, resultater og beslutninger
- Sikkerhedskrav: både funktionelle (fx auth, logging) og ikke-funktionelle (fx patch-tider)
- SBOM (Software Bill of Materials): komponentliste, versioner, licenser og afhængigheder
- Sårbarhedshåndtering: intake, triage, prioritering, deadlines og release-noter
- Secure development practices: coding guidelines, review-krav, CI/CD-kontroller
- Test- og verifikationsspor: sikkerhedstest, pentest-resuméer, scanningsrapporter og afhjælpning
- Release- og ændringsstyring: sign-offs, rollback-planer, kompatibilitet
Det vigtigste er ikke at have “alt”, men at have et konsistent sæt artefakter, der hænger sammen og kan forklares.
Mini-konklusion: Dokumentation skal kunne fortælle en sammenhængende historie om, hvordan sikkerhed bliver skabt og vedligeholdt.
Tænk CRA ind fra start: en praktisk model for “documentation by design”
Den mest effektive tilgang er at bygge dokumentation ind i arbejdsgangene, så den opstår som et biprodukt af at udvikle rigtigt. Jeg anbefaler at tænke i tre lag: produkt, proces og bevis.
Lag 1: Produkt (hvad skal være sikkert?)
Start med et tydeligt scope: Hvad er produktets digitale elementer, hvilke interfaces har det (API’er, mobilapp, cloud, OTA-opdatering), og hvor er de mest kritiske dataflows? En simpel arkitekturtegning og et dataflow-diagram kan spare mange timers forklaring senere.
Lag 2: Proces (hvordan arbejder vi?)
Definér få, men faste kontrolpunkter i udviklingsflowet: fx “ingen release uden SBOM”, “kritiske findings skal triageres inden 24 timer”, eller “trusselsmodel opdateres ved større arkitekturændringer”. Det behøver ikke være tungt, men det skal være konsekvent.
Lag 3: Bevis (hvordan viser vi det?)
Det er her, teams ofte fejler: De gør de rigtige ting, men kan ikke vise det. Sørg for at artefakter gemmes i systemer, der kan audit-spores (ticketing, CI logs, signeret release, versionerede dokumenter). I praksis betyder det, at en beslutning om risikoaccept ikke må være en Slack-besked, men en ticket med ejer og begrundelse.
Mini-konklusion: Når “beviset” er indbygget i workflowet, bliver CRA mindre et projekt og mere en vane.
Sporbarhed i praksis: fra user story til sikkerhedsbevis
Et godt mål er, at en udenforstående (kunde, auditor eller ny kollega) kan følge en kæde: krav → implementering → test → release. Det kræver ikke enterprise-værktøjer, men det kræver disciplin.
- Tilføj sikkerhedskriterier til relevante user stories (fx “rate limiting”, “audit logging”, “secure defaults”).
- Link pull requests til tickets, så ændringer kan spores til et krav eller en risiko.
- Gem CI-resultater (SAST, dependency scan, IaC scan) per build og per release.
- Definér triage-regler: hvad er “kritisk”, hvem vurderer, og hvad er SLA’en.
- Dokumentér undtagelser: hvis noget ikke kan fixes, skal kompensation og accept være tydelig.
- Udgiv release-noter, der nævner sikkerhedsrelevante ændringer uden at lække unødige detaljer.
Det lyder banalt, men forskellen mellem et modent og umodent setup er ofte, om links og beslutninger faktisk findes, når man leder efter dem.
Midt i maskinrummet: sådan ser “dokumentation under CRA” ud i hverdagen
Det hjælper at oversætte CRA til daglige rutiner: hvem skriver hvad, hvornår, og hvor ligger det. En del virksomheder ender med at gøre dokumentation til et kvartalsprojekt, hvilket skaber store “spikes” og lav kvalitet.
Hvis du vil se, hvordan krav og forventninger typisk konkretiseres, er dokumentation under CRA et godt udgangspunkt for at forstå, hvilke typer materiale der ofte bliver efterspurgt, og hvordan de kan struktureres.
Min anbefaling er at udpege en dokumentationsansvarlig pr. produkt (ikke pr. organisation), som sikrer sammenhæng, men at ejerskabet for indhold ligger i teamet: udviklere, QA, DevOps og product security skal hver især levere deres del af beviskæden.
Mini-konklusion: Dokumentation virker, når den har en ejer, en rytme og en “single source of truth” pr. produkt.
Hvad koster det: tid, værktøjer og “skjulte” omkostninger
Et typisk spørgsmål er: “Hvad koster CRA-dokumentation?” Svaret afhænger af modenhed og kompleksitet, men her er en realistisk måde at tænke det på: Omkostningen er sjældent værktøjerne; det er arbejdstiden til at skabe sporbarhed og reducere variation.
Som tommelfingerregler fra projekter jeg har set:
- Hvis I allerede har stabil CI/CD, ticketing-disciplin og regelmæssige scanninger, kan ekstra dokumentationsarbejde ofte holdes nede på 5–10% af teamets kapacitet i en periode, primært til struktur og standarder.
- Hvis I mangler SBOM, triage-proces og release-disciplin, kan opstarten føles som 2–6 ugers intensiv oprydning pr. produktlinje, før det bliver “business as usual”.
- Den dyreste omkostning er ofte forsinkede releases eller tabt salg, fordi dokumentation ikke kan leveres i tide.
Værktøjer som SBOM-generator, scanning og compliance-rapportering kan hjælpe, men de kan ikke erstatte beslutningsspor og ansvar.
Mini-konklusion: Budgettér med en opstartsfase og et vedligeholdelsesniveau—ikke et engangsprojekt.
Typiske fejl og faldgruber (og hvordan du undgår dem)
Der er nogle klassikere, som går igen på tværs af brancher—og som er relativt lette at forebygge, hvis man ser dem tidligt.
Fejl 1: Dokumentation som “compliance-teater”
Hvis dokumenterne ikke afspejler virkeligheden, bliver de hurtigt afsløret: datoer stemmer ikke, beslutninger kan ikke forklares, og teamet arbejder stadig ad hoc. Løsningen er at dokumentere det, I faktisk gør, og derefter forbedre praksis trin for trin—ikke omvendt.
Fejl 2: Ingen styring af tredjepart og open source
Mange produkter er 60–90% afhængigheder, især i moderne software stacks. Uden en opdateret SBOM og en fast proces for at håndtere sårbarheder i tredjepart bliver reaktionen langsom og uforudsigelig. Et simpelt krav om “ingen nye dependencies uden ejer og begrundelse” kan gøre en stor forskel.
Fejl 3: Sårbarheder bliver en inbox, ikke en proces
En sårbarhedshåndteringsproces skal have tydelige roller: hvem modtager rapporter, hvem triagerer, hvornår eskalerer man, og hvordan kommunikerer man til kunder? Jeg anbefaler at definere SLA’er pr. alvorlighed og at øve en “CVE-dag” én gang i kvartalet, hvor I simulerer en kritisk sårbarhed og måler svartider.
Mini-konklusion: De fleste CRA-problemer skyldes ikke manglende vilje, men manglende rutiner og ejerskab.
Bedste praksis: sådan kommer du i gang på 30 dage uden at drukne teamet
Hvis du skal gøre det håndterbart, så start med fundamentet og byg ovenpå. Her er en enkel plan, der typisk kan gennemføres uden at stoppe roadmap’et.
- Uge 1: Kortlæg produktets scope og lav en “dokumentationsmappe” med fast struktur (arkitektur, SBOM, processer, test, releases).
- Uge 2: Indfør minimumskrav i CI/CD: dependency scanning, gemte build-artefakter, og en release-checkliste.
- Uge 3: Etabler triage-flow for sårbarheder med roller og SLA’er; opret templates til risikoaccept.
- Uge 4: Lav en let trusselsmodel på top-5 dataflows og koble den til konkrete backlog-items.
Hold det kort og brugbart: en checkliste, der bliver brugt, slår en 40-siders manual, som ingen åbner. Og sørg for at måle noget simpelt, fx “tid fra alert til triage” og “andel releases med komplet SBOM”.
Mini-konklusion: Fokusér på gentagelige minimumsstandarder først—det giver hurtig effekt og stabilitet.
Hvordan du ved, om din dokumentation er “CRA-klar”
Et godt selv-check er at lade en person udenfor teamet “spille auditor” i to timer. Kan de finde svar på: Hvad er produktet, hvordan opdateres det, hvordan håndteres sårbarheder, og hvor er beviserne?
Stil jer selv disse spørgsmål:
- Kan vi på 30 minutter liste alle komponenter og versioner i seneste release?
- Kan vi vise, hvem der godkendte release, og hvilke kontroller der blev kørt?
- Kan vi demonstrere en end-to-end sårbarhedshåndtering fra rapport til patch og kommunikation?
- Kan vi forklare vores vigtigste sikkerhedsbeslutninger og trade-offs uden at gætte?
Hvis svaret er “delvist”, er det et tegn på, at I skal styrke sporbarhed og ejerskab—ikke nødvendigvis skrive mere tekst.
Mini-konklusion: CRA-klar dokumentation er dokumentation, der kan bruges hurtigt, forklares klart og opdateres løbende.
