EU CRA 2026: guide til parathed for sårbarhedsrapportering

Klokken er 08:17 en mandag morgen i september 2026. Anna, CISO i en hurtigt voksende europæisk SaaS-virksomhed, tænker stadig på sidste uges bestyrelsesmøde. Den administrerende direktør havde stillet det spørgsmål, som alle sikkerhedsledere hører nu: “Hvis vi allerede har forberedt os på NIS2, og vores fintech-kunder bliver ved med at spørge ind til DORA, hvad ændrer Cyber Resilience Act så?”

Så lander svaret i hendes indbakke.

En uafhængig sikkerhedsresearcher rapporterer en sårbarhed, der kan udnyttes eksternt, i en firmwareopdateringskomponent, som bruges af et af virksomhedens forbundne produkter. Meddelelsen indeholder et proof of concept, navnet på en afhængighed og en advarsel om, at tilsvarende udnyttelse er observeret i praksis.

Inden for få minutter ønsker alle et forskelligt svar. CTO’en spørger, om sårbarheden er reel. Juridisk afdeling spørger, om rapportering efter EU Cyber Resilience Act er udløst. Produktteamet spørger, hvilke versioner der er berørt. CISO’en spørger, om afhængigheden fremgår af nogen SBOMs. Salg spørger, om kunder i den finansielle sektor har brug for DORA-bevismateriale. Den complianceansvarlige åbner ISO 27001-risikoregisteret og finder en sårbarhedsstyringsproces, men ingen klar beslutningsvej for produktrapportering.

Det er det reelle CRA-parathedsproblem. De fleste organisationer starter ikke fra nul. De har allerede politikker for hændelseshåndtering, rutiner for patchstyring, praksis for sikker udvikling, leverandørgennemgange, sårbarhedsscannere og ISO 27001-bevismateriale. Men CRA belønner ikke isolerede dokumenter. Den kræver en hurtig og forsvarlig arbejdsgang, der kan besvare fem spørgsmål samtidig:

1. Er dette en aktivt udnyttet sårbarhed eller en alvorlig hændelse, der påvirker produktsikkerheden?
2. Hvilke produkter, versioner, kunder, afhængigheder og leverandører er berørt?
3. Hvilken myndighed, kunde eller kontraktlig modtager skal underrettes, og hvornår?
4. Hvilket bevismateriale dokumenterer, at triage, afbødning og offentliggørelse blev styret kontrolleret?
5. Hvordan stemmer dette overens med ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF og revisionsforventninger?

Svaret er ikke en særskilt “CRA-mappe”. Svaret er at indarbejde CRA-sårbarhedsrapportering i ISMS’et, processen for koordineret offentliggørelse af sårbarheder, SBOM-disciplinen, leverandørstyringen og beviskæden for hændelseshåndtering, som I allerede har brug for til moden cybersikkerhedsstyring.

Hvorfor EU Cyber Resilience Act ændrer rapporteringsmodellen

EU Cyber Resilience Act, Regulation (EU) 2024/2847, bringer produktsikkerhed ind i den almindelige compliance-dagsorden. Den gælder for produkter med digitale elementer, der bringes i omsætning på EU-markedet, hvilket kan omfatte forbundne enheder, software, firmware, indlejrede systemer og enterprise-softwareprodukter.

Den driftsmæssige ændring, der betyder mest for CISO’er, produktsikkerhedsledere og compliance-teams, begynder den 11. september 2026. CRA Article 14 kræver trinvis rapportering for aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker sikkerheden i produkter med digitale elementer. I praksis skal producenter være klar til:

Den præcise juridiske vurdering bør altid foretages af kvalificeret juridisk rådgiver, men den driftsmæssige læring er klar. De første 24 til 72 timer er kun så gode som den forberedelse, der er gennemført måneder tidligere.

Hvis jeres SBOMs er ufuldstændige, hvis jeres CVD-indbakke overvåges uformelt, hvis leverandørkontrakter ikke kræver sårbarhedsunderretning, eller hvis jeres politik for hændelseshåndtering ikke skelner mellem rapportering af produktsårbarheder og privatlivs- eller driftsmæssige hændelser, vil det juridiske ur løbe hurtigere end jeres proces for bevismateriale.

Brug ISO/IEC 27001:2022 som styringsramme for CRA-parathed

ISO/IEC 27001:2022 er ikke en erstatning for juridisk efterlevelse af CRA, men den er den bedste ledelsessystemramme til at integrere CRA-forpligtelser i den daglige styring.

Punkterne 4.1 til 4.4 kræver, at organisationen forstår intern og ekstern kontekst, interessenter, krav, grænseflader med andre organisationer og ISMS-omfang ISO/IEC 27001:2022. For CRA-parathed betyder det, at jeres ISMS-omfang bør identificere produkter med digitale elementer, ansvar i produktlivscyklussen, hostede komponenter, buildpipelines, open source-afhængigheder, leverandører, brugere, importører, distributører, regulerede kunder og relevante myndigheder.

Punkterne 6.1.1 til 6.1.3 kræver risikovurdering og risikobehandling, herunder risikoejere, konsekvenser, sandsynlighed, behandlingsbeslutninger, anvendelseserklæring og accept af restrisiko. CRA-rapportering bør behandles som et risikoscenarie for produktsikkerhed i denne proces, ikke som en akut juridisk fortolkningsøvelse.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 giver derefter den praktiske kontrolstruktur. De vigtigste kontroller for CRA-sårbarhedsrapportering er:

I Zenith Controls: vejledning til tværgående efterlevelse kortlægger Clarysec ISO/IEC 27002:2022-kontrol 8.8, styring af tekniske sårbarheder, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens attributter er tilpasset Identify- og Protect-begreberne inden for cybersikkerhed med trussels- og sårbarhedsstyring som den operationelle kapacitet.

Denne rammesætning er vigtig. CRA-rapportering handler ikke kun om at underrette myndigheder. Den handler om at dokumentere, at en forebyggende sårbarhedsstyringskapacitet fandtes, før rapporten kom ind.

Byg driftsmodellen op omkring CVD, SBOM og rapporteringsfristerne

En troværdig CRA-arbejdsgang for sårbarheder starter, før en researcher nogensinde kontakter jer. Den starter med evnen til at modtage sårbarhedsrapporter, validere dem, identificere berørte komponenter, vurdere udnyttelse, koordinere afbødning, kommunikere med brugere og bevare bevismateriale.

Den første byggesten er en offentlig kanal til rapportering af sårbarheder. Clarysecs politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, punkt 6.1, fastslår:

Offentlige kanaler for offentliggørelse: Organisationen skal opretholde en klar kanal til rapportering af sårbarheder, f.eks. en særskilt e-mailadresse til sikkerhedskontakt (for eksempel security@company.com) eller en webformular. Disse oplysninger skal offentliggøres på virksomhedens sikkerhedsside sammen med organisationens offentlige PGP-nøgle for at muliggøre krypterede indsendelser.

Det løser en almindelig revisionsmangel. Mange virksomheder siger, at de accepterer sårbarhedsrapporter, men rapporteringsvejen er skjult, ustyret eller dirigeret gennem en generel supportkø. Under CRA-forhold bliver rapporteringskanalen udløsningspunktet for juridisk kendskab, alvorlighedsvurdering og indsamling af bevismateriale.

Den anden byggesten er triage. Politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, punkt 6.4, fastslår:

Triage og bekræftelse: Ved modtagelse af en rapport skal VRT registrere den og sende en bekræftelse til rapportøren inden for 2 arbejdsdage med en tildelt sporingsreference. VRT skal foretage en indledende alvorlighedsvurdering, f.eks. ved hjælp af CVSS-scoring, og validere forholdet, herunder med støtte fra IT- og udviklingsteams, hvor det er nødvendigt, inden for en målfrist på 5 arbejdsdage. Kritiske sårbarheder, f.eks. sårbarheder der muliggør fjernudførelse af kode eller et større brud på persondatasikkerheden, skal behandles fremskyndet.

For CRA-parathed bør denne triageregistrering udvides med felter, der understøtter den juridiske rapporteringsbeslutning:

Den tredje byggesten er SBOM-disciplin. Clarysecs politik for sikker udvikling, styringskrav, punkt 5.4, fastslår:

Brug af open source-kode eller kode fra tredjeparter skal godkendes, spores og valideres gennem: 5.4.1 Software Composition Analysis (SCA) 5.4.2 Licensgennemgang (GPL, MIT, BSD osv.) 5.4.3 Scanning for kendte sårbarheder (CVEs, OSS Index osv.)

For mindre organisationer fastsætter Clarysecs politik for krav til applikationssikkerhed - SME, krav til implementering af politikken, punkt 6.4.2, den samme forventning i praktisk form:

Der skal vedligeholdes en registrering af hver anvendt ekstern komponent af udvikleren eller IT-leverandøren, herunder:

Denne komponentregistrering bliver det minimale bevismateriale til SBOM-drevet sårbarhedshåndtering. Den bør forbinde komponentnavn, version, kilde, leverandør eller repository, licens, produktversion, build-dato og status for sårbarhedsscanning. Når en CVE, researcher-rapport eller leverandørmeddelelse ankommer, bør jeres team kunne svare inden for få timer: “Hvilke frigivne produkter indeholder denne komponent?”

Kortlæg CRA, NIS2, DORA og GDPR i én beslutningsmatrix for underretning

Cyber Resilience Act kommer ikke til at fungere isoleret. En enkelt produktsårbarhed kan udløse CRA-rapportering, NIS2-hændelsesvurdering, DORA-relaterede dokumentationsforpligtelser over for kunder, vurdering af brud efter GDPR og kontraktlige underretningsforpligtelser.

NIS2 Article 21 kræver, at væsentlige og vigtige enheder implementerer passende tekniske, driftsmæssige og organisatoriske foranstaltninger. Disse foranstaltninger omfatter risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, udvikling og vedligeholdelse, sårbarhedshåndtering og offentliggørelse, effektivitetsvurdering, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver, MFA og sikker kommunikation.

NIS2 Article 23 fastlægger en trinvis model for hændelsesrapportering: tidlig advarsel senest 24 timer efter at være blevet bekendt med hændelsen, hændelsesunderretning senest 72 timer efter, foreløbige opdateringer efter anmodning og en endelig rapport senest én måned efter hændelsesunderretningen. NIS2 Article 20 etablerer også ledelsesorganets ansvar for at godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici.

DORA gælder fra den 17. januar 2025 og skaber en ensartet EU-ramme for digital operationel robusthed for finansielle enheder. For SaaS-udbydere, softwareleverandører og IKT-leverandører viser DORA sig ofte gennem kundekontrakter. Jeres kunde i den finansielle sektor kan være den regulerede DORA-enhed, men jeres sårbarhedshåndtering, SBOM-bevismateriale, hændelsessupport, revisionsrettigheder og underretningsforpligtelser kan være nødvendige for, at kunden kan opfylde sine egne forpligtelser.

GDPR tilføjer endnu en gren. Hvis sårbarheden eller hændelsen medfører hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger, kræves en vurdering af brud på persondatasikkerheden. GDPR Article 5 omfatter også integritet, fortrolighed og ansvarlighed, hvilket betyder, at organisationen skal kunne dokumentere sin beslutningstagning.

Clarysecs politik for hændelseshåndtering, krav til implementering af politikken, punkt 6.4.1, understøtter allerede denne vurdering på tværs af regelsæt:

Hvis en hændelse medfører bekræftet eller sandsynlig eksponering af personoplysninger eller andre regulerede data, skal juridisk afdeling og DPO vurdere anvendeligheden af: 6.4.1.1 GDPR Article 33 (72-timers underretning til tilsynsmyndigheden) 6.4.1.2 GDPR Article 34 (underretning til registrerede, hvor høj risiko foreligger) 6.4.1.3 NIS2 Article 23 (underretning inden for 24 timer efter at være blevet bekendt med hændelsen) 6.4.1.4 DORA Article 17 (rapportering af alvorlige IKT-relaterede hændelser)

For CRA-parathed skal denne drejebog udvides med vurdering af rapportering efter CRA Article 14 for aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker produktsikkerheden.

En samlet beslutningsmatrix forhindrer teams i at køre adskilte og inkonsistente rapporteringsdrejebøger:

For SMEs angiver Clarysecs politik for hændelseshåndtering - SME, styringskrav, punkt 5.3.2, det samme princip i enklere form:

Responstider, herunder datagendannelse og underretningsforpligtelser, skal dokumenteres og tilpasses juridiske krav, såsom GDPR-kravet om underretning om brud på persondatasikkerheden inden for 72 timer.

CRA-parathed udvider ganske enkelt dette princip fra underretning om brud på persondatasikkerheden til rapportering af produktsårbarheder og produktsikkerhedshændelser.

Leverandørbevismateriale er nu produktsikkerhedsbevismateriale

Mange CRA-relevante sårbarheder vil opstå uden for jeres egen kodebase. De kan komme fra open source-pakker, firmwaremoduler, SDK’er, hostede API’er, build-værktøjer, cloudtjenester, underleverede komponenter eller upstream-biblioteker. Det gør leverandørstyring central for CRA-parathed.

ISO 27001:2022 punkt 8.1 kræver, at organisationer styrer eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS’et. ISO/IEC 27002:2022-kontrol 5.21, styring af informationssikkerhed i IKT-forsyningskæden, giver kontrolankeret.

I Zenith Controls kortlægger Clarysec kontrol 5.21 som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens operationelle kapacitet er sikkerhed i leverandørrelationer, og dens domæner omfatter styring, økosystem og beskyttelse. Pointen er enkel: Leverandørkontroller er ikke indkøbspapirarbejde. De er kontroller til beskyttelse af økosystemet.

Clarysecs politik for tredjeparts- og leverandørsikkerhed - SME, styringskrav, punkt 5.3, fastlægger det kontraktlige grundlag:

Kontrakter skal indeholde obligatoriske klausuler, der dækker:

For enterprise-programmer forklarer Zenith Blueprint: revisors 30-trins køreplan, Controls in Action-fasen, Step 23, organisatoriske kontroller 5.19 to 5.37, ISO/IEC 27002:2022-kontrol 5.20, håndtering af informationssikkerhed i leverandøraftaler:

Tillid kan, når det gælder leverandører, ikke hvile på antagelser. Den skal kodificeres.

For CRA-parathed bør leverandøraftaler indeholde produktsikkerhedsklausuler, der understøtter hurtig sårbarhedshåndtering:

DORA forstærker samme retning. Finansielle enheder skal styre IKT-tredjepartsrisiko, vedligeholde registre over IKT-servicekontrakter, vurdere kritikalitet, udføre due diligence, styre koncentrationsrisiko, definere kontraktlige sikkerhedsforanstaltninger, sikre revisionsrettigheder og planlægge exit. Hvis I sælger software eller IKT-tjenester til finansielle enheder, må I forvente, at kunderne spørger, om jeres sårbarhedsrapportering og SBOM-proces kan understøtte deres behov for DORA-bevismateriale om hændelser, robusthed og tredjeparter.

Clarysecs arbejdsgang for CRA-parathed

Clarysec hjælper kunder med at operationalisere CRA-rapportering i et ISO 27001:2022-tilpasset ISMS gennem en praktisk arbejdsgang.

1. Tilføj CRA-forpligtelser til ISMS-kravregisteret

Start med ISO 27001:2022 punkterne 4.1 til 4.4. Opdater organisationens kontekst, interessenter og omfang, så de omfatter produkter med digitale elementer, eksponering mod EU-markedet, brugere, importører, distributører, regulatorer, CSIRTs, leverandører og regulerede kunder.

Opret poster i kravregisteret for CRA-sårbarhedsrapportering, CRA-rapportering af alvorlige produktsikkerhedshændelser, NIS2-hændelsesunderretning, DORA-kundesupportforpligtelser, GDPR-vurdering af brud på persondatasikkerheden, kontraktlig hændelsesunderretning, CVD-forpligtelser og kommunikation med researchere.

Det giver revisorer en sporbar vej fra ekstern forpligtelse til intern kontrol.

2. Opret en indrapporteringsformular for produktsårbarheder

Basér formularen på politik for koordineret offentliggørelse af sårbarheder. Den bør registrere rapportørens identitet, sikre kontaktoplysninger, produktversion, modul, miljø, proof of concept, reproduktionstrin, udnyttelsesstatus, potentiel dataeksponering, servicepåvirkning, SBOM-komponentmatch, CVSS eller tilsvarende alvorlighed, ejer, sporingsreference og regulatorisk kontrolpunkt.

Formularen bør automatisk oprette en sag i køen for sårbarhedshåndtering. Den bør også starte en timer for underretningsbeslutning, selv hvis det endelige svar er “ikke rapporteringspligtigt”.

3. Kobl SBOM-data til releases

For hver frigivet produktversion skal der vedligeholdes en SBOM eller tilsvarende komponentfortegnelse. Det mindst anvendelige bevismateriale omfatter komponentnavn, version, kilde, licens, leverandør eller repository, produktversion, build-dato og status for sårbarhedsscanning.

Politik for sikker udvikling og politik for krav til applikationssikkerhed - SME giver det politiske grundlag for SCA, komponentgennemgang og registreringer af eksterne komponenter.

4. Bevar bevismateriale fra dag ét

Enhver CRA-relevant sårbarhedssag bør opbevare:

• Oprindelig rapport
• Tidsstempel for bekræftelse
• Triagenotater
• Begrundelse for CVSS eller tilsvarende alvorlighed
• SBOM-matchresultater
• Vurdering af udnyttelse
• Logfiler, indikatorer og forensiske snapshots
• Leverandørkommunikation
• Risikoaccept, hvis afbødning forsinkes
• Patchplan, patchnoter og testbevismateriale
• Beslutninger om kunde- og myndighedsunderretning
• Input til endelig rapport og læringspunkter

Dette er i overensstemmelse med ISO 27001:2022 punkt 8.1, som kræver dokumenterede oplysninger, der er tilstrækkelige til at dokumentere, at processerne fungerede som planlagt, og punkterne 8.2 og 8.3, som kræver dokumenterede resultater af risikovurdering og risikobehandling.

5. Test med et realistisk afhængighedsscenarie

Gennemfør en tabletop-øvelse med en simuleret aktivt udnyttet afhængighedssårbarhed. Inkludér engineering, sikkerhed, juridisk afdeling, databeskyttelse, produkt, kommunikation, leverandørstyring og kundevendte teams. Testen bør dokumentere, at organisationen kan identificere berørte versioner, vurdere udnyttelse, træffe en underretningsbeslutning, kontakte leverandører, udarbejde brugervejledning og bevare bevismateriale.

Hvordan revisorer vil teste parathed til CRA-sårbarhedsrapportering

En CRA-parathedsgennemgang vil sjældent være begrænset til en CRA-tjekliste. Forskellige revisorer vil teste det samme bevismateriale gennem forskellige frameworks.

I Zenith Controls kortlægger Clarysec ISO/IEC 27002:2022-kontrol 5.24, planlægning og forberedelse af styring af informationssikkerhedshændelser, som en korrigerende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den er tilpasset Respond og Recover med styring og håndtering af informationssikkerhedshændelser som operationelle kapaciteter.

Denne kontrol er broen mellem sårbarhedsopdagelse og regulatorisk rapportering.

NIST CSF 2.0 er særligt nyttig som kommunikationslag til bestyrelsesniveau. Funktionerne GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER hjælper med at forklare, hvordan rapportering af produktsårbarheder passer ind i organisationens samlede cybersikkerhedsstyring i stedet for at ligge som en engineering-undtagelse.

Almindelige CRA-parathedsmangler, der skal rettes før 2026

Clarysec ser de samme mangler igen og igen.

Den første er CVD uden rapportering. En virksomhed har en sikkerheds-e-mailadresse eller en security.txt-fil, men ingen intern vej fra researcher-rapport til juridisk vurdering af underretning.

Den anden er SBOM uden ejerskab. Engineering kan generere en SBOM under build, men ingen ejer nøjagtigheden for frigivne produkter eller kan forklare, hvordan SBOM-konstateringer indgår i sårbarhedshåndtering.

Den tredje er et ISO-certifikat uden produktomfang. ISMS’et dækker virksomhedens IT og SaaS-drift, men ikke indlejret software, firmware, infrastruktur til produktopdateringer, buildpipelines eller offentliggørelse af sårbarheder.

Den fjerde er leverandørkontrakter uden sårbarhedsklausuler. Indkøb kræver fortrolighed og databeskyttelse, men ikke sårbarhedsunderretning, komponenttransparens, hændelsesassistance, koordineret offentliggørelse eller revisionsbevismateriale.

Den femte er hændelseshåndtering uden logik for produktsårbarheder. Hændelsesplanen dækker ransomware, phishing og brud på persondatasikkerheden, men ikke aktivt udnyttede produktsårbarheder, hvor kundesystemer kan være i risiko, før producentens eget miljø er kompromitteret.

Den sjette er DORA-kundebevismateriale, der håndteres manuelt. Salg eller Customer Success besvarer spørgeskemaer fra finansielle kunder fra sag til sag, mens sikkerhed mangler en standardiseret dokumentationspakke, der viser sårbarhedshåndtering, SBOM-styring, hændelsessupport og leverandørkontroller.

Hver mangel kan rettes. Hver mangel bliver dyr, hvis den opdages under en aktiv sårbarhed.

En 90-dages tjekliste for parathed til CRA-sårbarhedsrapportering

Brug de næste 90 dage på at etablere et forsvarligt grundlag:

• Identificér produkter med digitale elementer, der bringes i omsætning eller gøres tilgængelige på EU-markedet.
• Opdater ISMS-omfang og interessentanalyse, så CRA-interessenter indgår.
• Tilføj vurdering af rapportering efter CRA Article 14 til registeret over juridiske og regulatoriske krav.
• Offentliggør og overvåg en sikker kanal til rapportering af sårbarheder.
• Opret et sårbarhedsresponsteam med roller inden for juridisk afdeling, produkt, engineering, sikkerhed og kommunikation.
• Vedligehold SBOMs eller komponentfortegnelser for frigivne produktversioner.
• Kobl SCA-resultater til sårbarhedssager og produktreleases.
• Tilføj kriterier for aktiv udnyttelse og alvorlige produkthændelser til triageformularer.
• Opret en samlet beslutningsmatrix for underretning efter CRA, NIS2, DORA, GDPR og kontrakter.
• Opdater leverandørkontrakter med klausuler om sårbarhedsunderretning, SBOM, hændelsesassistance og koordinering af offentliggørelse.
• Vedligehold patchlogfiler og afhjælpningsbevismateriale.
• Test arbejdsgangen med en simuleret aktivt udnyttet afhængighedssårbarhed.
• Præsenter resultater for ledelsen med mangler, restrisici og afhjælpningsansvarlige.
• Tilføj dokumentationspakken til intern revision og ledelsens gennemgang.

Clarysecs politik for sårbarheds- og patchstyring - SME, krav til implementering af politikken, punkt 6.2.1, understøtter overvågningsgrundlaget:

IT-funktionen skal overvåge sårbarheder ved hjælp af:

Den samme politik, styringskrav, punkt 5.4.1, tilføjer revisionssporet:

En patchlog skal vedligeholdes og gennemgås under revisioner og hændelseshåndteringsaktiviteter

Denne patchlog kan blive et af de vigtigste artefakter i en endelig CRA-rapport. Den dokumenterer opdagelse, prioritering, afhjælpning, test og lukning.

Gør september 2026 kedelig

Den bedste CRA-rapporteringshændelse er ikke nem, fordi sårbarheden er simpel. Den er nem, fordi organisationen allerede har øvet arbejdsgangen.

Inden september 2026 kan Clarysec hjælpe jer med at gøre sårbarhedsrapportering til et revisionsklart system ved at kortlægge jeres nuværende ISO 27001:2022 ISMS, CVD-proces, SBOM-kapacitet, leverandørklausuler og hændelseshåndteringsdrejebøger mod forventningerne i CRA, NIS2, DORA, GDPR og NIST CSF.

Start med en fokuseret vurdering af parathed til CRA-sårbarhedsrapportering. Clarysec gennemgår jeres politikker, SBOM-bevismateriale, leverandørkontrakter, sårbarhedssager, hændelsesdrejebøger og revisionsspor. Derefter bruger vi Zenith Blueprint og Zenith Controls til at opbygge en praktisk afhjælpningskøreplan, ikke en teoretisk compliance-mappe.

Hvis I allerede bruger Clarysec-politikker, tilpasser vi dem til CRA-rapportering. Hvis I ikke gør, kan vi hjælpe med at implementere det rette politiksæt, herunder politik for koordineret offentliggørelse af sårbarheder, politik for sikker udvikling, politik for hændelseshåndtering, politik for sårbarheds- og patchstyring - SME, politik for krav til applikationssikkerhed - SME og politik for tredjeparts- og leverandørsikkerhed - SME, hvor det er relevant.

September 2026 er tæt nok på til planlægning og langt nok væk til disciplineret forberedelse. De organisationer, der handler nu, kommer ikke til at spørge: “Hvem ejer denne sårbarhed?” i de første 24 timer. De vil allerede have svaret, bevismaterialet og rapporteringsvejen.

Kontakt Clarysec for at planlægge en vurdering af parathed til CRA-sårbarhedsrapportering og omsætte regulatorisk kompleksitet til en forsvarlig produktsikkerhedsfordel.