Cyber Resilience Act er ikke en forordning, du kan delegere til compliance-afdelingen og glemme alt om. Den stiller nemlig konkrete krav til, hvordan dine produkter er bygget, hvem i organisationen der ejer ansvaret, og hvad du kan dokumentere, hvis det går galt.
CRA skal dermed tænkes ind i produkterne fra starten og fungerer ikke som en eftertanke.
Forordningen træder fuldt i kraft i december 2027, men allerede nu stiller CRA krav – bl.a. til indberetning af sårbarheder. Det kan du læse mere om i vores artikel om “Alt, du skal vide om CRA”.
Derudover kræver forordningen, at sikkerhed er bygget ind fra allerførste linje i produktudviklingen, og for mange virksomheder er det et fundamentalt skifte, der tager tid.
Det lyder måske abstrakt, men konsekvenserne er meget konkrete: produkter, der ikke lever op til forordningen, kan ikke lovligt sælges i EU. Og CRA gælder ikke kun de store. Forordningen rammer de fleste virksomheder, der udvikler, importerer eller distribuerer produkter med softwarekomponenter.
Vi har talt med Raja Hamza Ali, GRC Advisor hos NorthGRC, om de fire udfordringer, han igen og igen ser virksomheder støde ind i, når de begynder at tage CRA alvorligt.
Her er de – og hvad du gør ved dem:
Det første spørgsmål er også det mest grundlæggende: Hvilke af jeres produkter er faktisk omfattet af CRA?
Forordningen gælder for produkter med digitale elementer – det vil sige produkter, der indeholder software eller firmware, og som er forbundet til netværk eller andre enheder. Det dækker alt fra industrielle styresystemer og IoT-enheder til B2B-software og applikationer.
Men scope-spørgsmålet stopper ikke ved produktlisten. Det handler mindst ligeså meget om, hvilken regulatorisk rolle din virksomhed har.
CRA opererer med tre centrale roller. Manufactureren er den virksomhed, der udvikler og fremstiller produkter og markedsfører dem under eget navn eller varemærke. Importøren bringer produkter fra producenter uden for EU til EU-markedet. Distributøren markedsfører produkter uden selv at have produceret eller importeret dem.
Én virksomhed kan sagtens have flere roller på tværs af forskellige produkter – og det er netop det, der gør scope-arbejdet vigtigt.
"Før man overhovedet kan snakke om CRA, skal man finde ud af, hvilke produkter der er i scope, og afdække virksomhedens regulatoriske roller – fordi det afgør, hvilke CRA-forpligtelser der gælder," siger Raja Hamza Ali.
Rollen bestemmer forpligtelserne. En manufacturer har de tungeste krav – herunder fuld dokumentation, sårbarhedshåndtering og CE-mærkning. En importør har pligt til at sikre sig, at de produkter, de bringer til EU-markedet, allerede lever op til kravene.
En distributør har et begrænset, men stadig reelt ansvar for, at produkterne er compliant, inden de sættes til salg.
Hvad kan du gøre? Lav en struktureret kortlægning af jeres produktportefølje. For hvert produkt: Indeholder det digitale elementer? Hvilken rolle har virksomheden? Svaret på de to spørgsmål er udgangspunktet for alt det, der kommer efter.
Med CRA er cybersikkerhed en integreret del af hele produktlivscyklussen. Den kræver, at sikkerhed er integreret fra første linje – i kravspecifikationen, i designet, i koden, i testen, i lanceringen og i vedligeholdelsen af produktet. Det er det, der menes med security by design.
For mange virksomheder er det et paradigmeskifte. Og det har én meget direkte konsekvens, for du vil nemlig ikke have mulighed for at sælge produktet i EU, før sikkerhed er tænkt ind i produktet fra start til slut:
"Hvis du kommer i gang med CRA senere i produktudviklingen, skal du faktisk starte forfra – tilbage til tegnebrættet – og få integreret CRA fra begyndelsen. Det betyder mærkbare omkostninger for organisationen i tid, penge og ressourcer – og det kan påvirke kundernes opfattelse af og tillid til virksomheden," forklarer Raja Hamza Ali.
Det kan således få meget konkrete forretningsmæssige konsekvenser, hvis en virksomhed håber at kunne lancere produkter på EU-markedet efter december 2027 uden at have gjort det nødvendige forarbejde.
Security by design betyder i praksis, at sikkerhedskrav skal indgå i requirements-fasen, at der skal laves threat modeling i designfasen, at udviklerne skal arbejde efter sikre kodningsstandarder, at sikkerhedstest skal være en del af QA-processen, og at release og vedligeholdelse af produktet skal inkludere håndtering af sårbarheder og opdateringer.
Hvad kan du gøre? Gennemgå jeres nuværende produktudviklingsproces og identificér, hvor CRA-kravene mangler. Integrér security-gates i jeres eksisterende workflow. Jo tidligere I starter, jo lavere er omkostningerne.
Et af de mest undervurderede elementer i CRA-forberedelsen er den interne ansvarsfordeling. Mange virksomheder har en naturlig tilbøjelighed til at placere compliance-ansvaret hos én funktion – compliance-afdelingen, IT-sikkerhed, eller måske den person, der er mest begejstret for GDPR.
Det er ikke nok.
CRA-forpligtelserne spænder over hele organisationen. Engineering skal bygge sikkert. Security skal definere krav og teste. Legal skal håndtere kontraktuelle og regulatoriske forpligtelser. Governance skal sikre overblik og sporbarhed. Ingen af disse funktioner kan stå alene.
"Pointen er ikke, at virksomheden har alle titler med – men det skal være tydeligt, hvem der har ansvar for hvad, og man kan se, hvor man kan hente den nødvendige ekspertise. Ansvaret kan ikke ligge hos compliance alene. Det skal i stedet fordeles på tværs i organisationen," vurderer Raja Hamza Ali.
Det handler med andre ord ikke om at oprette nye stillingsbetegnelser. Det handler om at gøre ansvaret eksplicit og handlekraftigt. Hvem godkender security requirements? Hvem er ansvarlig for sårbarhedshåndtering? Hvem eskalerer til ledelsen, hvis et produkt ikke kan leve op til kravene?
Hvad kan du gøre? Lav et klart RACI (Responsible, Accountable, Consulted, Informed) for CRA-forpligtelserne på tværs af engineering, security, legal og governance. Kortlæg også, hvor I mangler intern ekspertise – og om I skal hente den udefra.
Det fjerde og afsluttende element er det, der binder det hele sammen: dokumentation. CRA kræver ikke bare, at produktet er sikkert. Det kræver, at du kan bevise det.
Det er ikke en administrativ formalitet. Det er fundamentet for den tillid, som EU-lovgivningen forsøger at skabe – og som dine kunder med rette forventer.
Den tekniske dokumentation, der skal følge et produkt, dækker blandt andet cybersecurity assessments, dokumenterede security requirements, sårbarhedshåndtering og -log, sikkerhedstest, afklaring af software-afhængigheder (dependencies) samt den tekniske dokumentation, der ledsager produktet til markedet.
"Det er selvfølgelig ikke nok blot at sige 'produktet er sikkert'. Nej, det skal dokumenteres – og det på en måde, så hvis der opstår en sårbarhed, skal man kunne pege præcist på, hvor den er, og hvor ansvaret ligger. Så kan man nemlig også gøre noget ved det," siger Raja Hamza Ali.
Det perspektiv er værd at holde fast i. God CRA-dokumentation handler ikke kun om at bestå et tilsyn. Det handler om, at din organisation faktisk kan reagere hurtigt og præcist, når noget går galt. Og noget vil på et tidspunkt gå galt – det er ikke et spørgsmål om hvis, men om hvornår.
Hvad kan du gøre? Byg dokumentationsstrukturen op som en løbende del af produktprocessen – ikke som en opgave, der løses i dagene op til audit. Sørg for, at dokumentationen er levende og opdateret med hvert release og hver opdatering af produktet.
De fire udfordringer hænger tæt sammen. Scope afgør, hvilke roller virksomheden har. Rollerne afgør, hvad der skal designes og bygges. Det, der designes og bygges, afgør, hvad der skal dokumenteres. Og dokumentationen er det eneste, der kan bevise, at I har gjort det rigtigt.
Det er grunden til, at CRA ikke kan løses af én afdeling alene. Det kræver et tværorganisatorisk løft – og det kræver, at I tænker det ind fra starten, ikke kort før deadline.
Er I i gang med at kortlægge jeres CRA-ståsted? NorthGRC hjælper virksomheder med at navigere i forordningen fra scope-afdækning til klar dokumentation. Kontakt os for en uforpligtende snak om, hvor I står, og hvad næste skridt er.