Vägledning för beredskap inför sårbarhetsrapportering enligt EU:s Cyber Resilience Act 2026

Klockan är 08:17 en måndagsmorgon i september 2026. Anna, informationssäkerhetschef på ett snabbväxande europeiskt SaaS-bolag, tänker fortfarande på förra veckans styrelsemöte. Vd:n hade ställt frågan som alla säkerhetsansvariga hör just nu: ”Om vi redan har förberett oss för NIS2 och våra fintech-kunder fortsätter att fråga om DORA, vad förändrar då Cyber Resilience Act?”

Sedan landar svaret i hennes inkorg.

En oberoende forskare rapporterar en fjärrexploaterbar sårbarhet i en komponent för firmwareuppdatering som används av en av bolagets uppkopplade produkter. Meddelandet innehåller ett proof of concept, namnet på ett beroende och en varning om att liknande utnyttjande har observerats i verkliga angrepp.

Inom några minuter vill alla ha olika svar. CTO:n frågar om sårbarheten är verklig. Juridik frågar om rapportering enligt EU Cyber Resilience Act har utlösts. Produktteamet frågar vilka versioner som påverkas. Informationssäkerhetschefen frågar om beroendet förekommer i några SBOM:er. Försäljning frågar om kunder inom finanssektorn behöver DORA-underlag. Chefen för regelefterlevnad öppnar ISO 27001-riskregistret och hittar en process för hantering av sårbarheter, men ingen tydlig beslutsväg för rapportering på produktnivå.

Det är det verkliga problemet med CRA-beredskap. De flesta organisationer börjar inte från noll. De har redan policyer för incidentrespons, rutiner för patchhantering, arbetssätt för säker utveckling, leverantörsgranskningar, sårbarhetsskannrar och ISO 27001-underlag. Men CRA belönar inte isolerade dokument. CRA kräver ett snabbt och försvarbart arbetsflöde som kan besvara fem frågor samtidigt:

1. Är detta en aktivt utnyttjad sårbarhet eller en allvarlig incident som påverkar produktsäkerheten?
2. Vilka produkter, versioner, kunder, beroenden och leverantörer påverkas?
3. Vilken myndighet, kund eller avtalsenlig mottagare måste underrättas, och när?
4. Vilket underlag visar att triage, riskbegränsning och offentliggörande hanterades kontrollerat?
5. Hur överensstämmer detta med ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF och förväntningar vid revision?

Svaret är inte en separat ”CRA-mapp”. Svaret är att koppla sårbarhetsrapportering enligt CRA till det ledningssystem för informationssäkerhet, den process för samordnad sårbarhetsrapportering, den SBOM-disciplin, den leverantörsstyrning och den beviskedja för incidentrespons som ni redan behöver för mogen cybersäkerhetsstyrning.

Varför EU Cyber Resilience Act förändrar rapporteringsmodellen

EU Cyber Resilience Act, Regulation (EU) 2024/2847, för in produktsäkerhet i huvudfåran för regelefterlevnad. Den gäller för produkter med digitala element som släpps ut på EU-marknaden, vilket kan omfatta uppkopplade enheter, programvara, firmware, inbyggda system och programvaruprodukter för företag.

Den operativa förändring som är viktigast för informationssäkerhetschefer, ansvariga för produktsäkerhet och regelefterlevnadsteam börjar den 11 september 2026. CRA Article 14 kräver stegvis rapportering för aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar säkerheten hos produkter med digitala element. I praktiken måste tillverkare vara förberedda för:

Den exakta rättsliga bedömningen ska alltid utföras av kvalificerad juridisk rådgivare, men den operativa lärdomen är tydlig. De första 24 till 72 timmarna blir bara så bra som de förberedelser som slutfördes månader tidigare.

Om era SBOM:er är ofullständiga, om er CVD-inkorg övervakas informellt, om leverantörsavtal inte kräver sårbarhetsanmälan, eller om er policy för incidentrespons inte skiljer produktrapportering av sårbarheter från integritetsincidenter eller operativa incidenter, kommer den rättsliga tidsfristen att löpa snabbare än er process för att ta fram underlag.

Använd ISO/IEC 27001:2022 som ram för CRA-beredskap

ISO/IEC 27001:2022 är inte en ersättning för efterlevnad av rättsliga krav enligt CRA, men den är den bästa ledningssystemsramen för att integrera CRA-skyldigheter i den dagliga styrningen.

Klausulerna 4.1 till 4.4 kräver att organisationen förstår internt och externt sammanhang, intressenter, krav, gränssnitt mot andra organisationer och omfattningen för ledningssystemet för informationssäkerhet ISO/IEC 27001:2022. För CRA-beredskap innebär det att omfattningen bör identifiera produkter med digitala element, ansvar i produktlivscykeln, driftade komponenter, byggpipelines, beroenden med öppen källkod, leverantörer, användare, importörer, distributörer, reglerade kunder och relevanta myndigheter.

Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning och riskbehandling, inklusive riskägare, konsekvenser, sannolikhet, behandlingsbeslut, Statement of Applicability och acceptans av kvarstående risk. CRA-rapportering bör behandlas som ett riskscenario för produktsäkerhet i den processen, inte som en akut övning i rättslig tolkning.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 ger därefter den praktiska kontrollstrukturen. De viktigaste kontrollerna för sårbarhetsrapportering enligt CRA är:

I Zenith Controls: The Cross-Compliance Guide mappar Clarysec ISO/IEC 27002:2022-kontroll 8.8, hantering av tekniska sårbarheter, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Dess attribut överensstämmer med cybersäkerhetsbegreppen Identify och Protect, med hot- och sårbarhetshantering som operativ förmåga.

Den inramningen är viktig. CRA-rapportering handlar inte bara om att underrätta myndigheter. Den handlar om att visa att en förebyggande förmåga för sårbarhetshantering fanns innan rapporten kom in.

Bygg den operativa modellen kring CVD, SBOM och rapporteringsklockan

Ett trovärdigt arbetsflöde för CRA-sårbarheter börjar innan en forskare någonsin kontaktar er. Det börjar med förmågan att ta emot sårbarhetsrapporter, validera dem, identifiera påverkade komponenter, bedöma utnyttjande, samordna riskbegränsning, kommunicera med användare och bevara underlag.

Den första byggstenen är en publik rapporteringskanal för sårbarheter. Clarysecs Policy för samordnad sårbarhetsrapportering, krav för genomförande 6.1, anger:

Publika kanaler för offentliggörande: Organisationen ska upprätthålla en tydlig kanal för sårbarhetsrapportering, till exempel en dedikerad e-postadress för säkerhetskontakt (exempelvis security@company.com) eller ett webbformulär. Denna information ska publiceras på företagets säkerhetssida tillsammans med organisationens publika PGP-nyckel för att möjliggöra krypterade inlämningar.

Detta löser en vanlig revisionsbrist. Många företag säger att de tar emot sårbarhetsrapporter, men rapporteringsvägen är dold, ohanterad eller dirigeras via en allmän supportkö. Under CRA-förhållanden blir rapporteringskanalen startpunkten för rättslig kännedom, bedömning av allvarlighetsgrad och insamling av underlag.

Den andra byggstenen är triage. Policy för samordnad sårbarhetsrapportering, krav för genomförande 6.4, anger:

Triage och bekräftelse: Vid mottagande av en rapport ska VRT registrera den och skicka en bekräftelse till rapportören inom 2 arbetsdagar, med en tilldelad spårningsreferens. VRT ska genomföra en preliminär bedömning av allvarlighetsgrad, exempelvis med CVSS-poängsättning, och validera problemet, vid behov med stöd från IT- och utvecklingsteam, inom ett målvärde på 5 arbetsdagar. Kritiska sårbarheter, exempelvis sådana som möjliggör fjärrkörning av kod eller en större personuppgiftsincident, ska hanteras skyndsamt.

För CRA-beredskap bör denna triagepost utökas med fält som stödjer beslutet om rättslig rapportering:

Den tredje byggstenen är SBOM-disciplin. Clarysecs Policy för säker utveckling, styrningskrav 5.4, anger:

Användning av kod med öppen källkod eller tredjepartskod måste godkännas, följas upp och valideras genom: 5.4.1 Analys av programvarusammansättning (SCA) 5.4.2 Licensgranskning (GPL, MIT, BSD osv.) 5.4.3 Skanning efter kända sårbarheter (CVEs, OSS Index osv.)

För mindre organisationer anger Clarysecs Policy för applikationssäkerhetskrav – SME, krav för genomförande av policyn 6.4.2, samma förväntan i praktisk form:

En post över varje extern komponent som används måste upprätthållas av utvecklaren eller IT-leverantören, inklusive:

Den komponentposten blir den minsta uppsättningen underlag för SBOM-driven sårbarhetsrespons. Den bör koppla samman komponentnamn, version, källa, leverantör eller kodförråd, licens, produktversion, byggdatum och status för sårbarhetsskanning. När en CVE, forskarrapport eller leverantörsavisering kommer in bör ert team inom några timmar kunna svara på: ”Vilka släppta produkter innehåller denna komponent?”

Mappa CRA, NIS2, DORA och GDPR till en gemensam beslutsmatris för anmälan

Cyber Resilience Act kommer inte att verka isolerat. En enda produktsårbarhet kan utlösa CRA-rapportering, incidentbedömning enligt NIS2, kundrelaterade underlagskrav enligt DORA, bedömning av personuppgiftsincident enligt GDPR och avtalsenliga underrättelseskyldigheter.

NIS2 Article 21 kräver att väsentliga och viktiga entiteter genomför lämpliga tekniska, operativa och organisatoriska åtgärder. Dessa åtgärder omfattar riskanalys, incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, säker anskaffning, utveckling och underhåll, sårbarhetshantering och sårbarhetsrapportering, bedömning av effektivitet, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, MFA och säker kommunikation.

NIS2 Article 23 fastställer en stegvis modell för incidentrapportering: tidig varning inom 24 timmar från kännedom, incidentanmälan inom 72 timmar, mellanliggande uppdateringar om så begärs och en slutrapport senast en månad efter incidentanmälan. NIS2 Article 20 skapar även ansvarsskyldighet för ledningsorganet att godkänna och utöva tillsyn över åtgärder för hantering av cybersäkerhetsrisker.

DORA gäller från den 17 januari 2025 och skapar ett enhetligt EU-ramverk för digital operativ resiliens för finansiella entiteter. För SaaS-leverantörer, programvaruleverantörer och IKT-leverantörer framträder DORA ofta genom kundavtal. Er kund inom finanssektorn kan vara den reglerade DORA-entiteten, men er sårbarhetshantering, ert SBOM-underlag, ert incidentstöd, era revisionsrättigheter och era underrättelseåtaganden kan vara nödvändiga för att kunden ska kunna uppfylla sina egna skyldigheter.

GDPR lägger till ytterligare en gren. Om sårbarheten eller incidenten orsakar oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter krävs en bedömning av personuppgiftsincident. GDPR Article 5 omfattar även riktighet, konfidentialitet och ansvarsskyldighet, vilket innebär att organisationen måste kunna visa sitt beslutsfattande.

Clarysecs Policy för incidenthantering, krav för genomförande av policyn 6.4.1, stödjer redan denna bedömning över flera regelverk:

Om en incident leder till bekräftad eller sannolik exponering av personuppgifter eller andra reglerade data måste Juridik och DPO bedöma tillämpligheten av: 6.4.1.1 GDPR Article 33 (72-timmarsanmälan till tillsynsmyndigheten) 6.4.1.2 GDPR Article 34 (underrättelse till registrerade, när hög risk föreligger) 6.4.1.3 NIS2 Article 23 (anmälan inom 24 timmar från kännedom om incidenten) 6.4.1.4 DORA Article 17 (rapportering av allvarliga IKT-relaterade incidenter)

För CRA-beredskap ska denna åtgärdsplan utökas med bedömning av rapportering enligt CRA Article 14 för aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar produktsäkerheten.

En gemensam beslutsmatris förhindrar att team använder separata och inkonsekventa rapporteringsrutiner:

För små och medelstora företag ger Clarysecs Policy för incidenthantering – SME, styrningskrav 5.3.2, samma princip i enklare form:

Tidslinjer för respons, inklusive dataåterställning och underrättelseskyldigheter, måste dokumenteras och anpassas till rättsliga krav, till exempel GDPR:s krav på anmälan av personuppgiftsincident inom 72 timmar.

CRA-beredskap utvidgar helt enkelt den principen från incidentanmälan vid personuppgiftsincident till rapportering av produktsårbarheter och produktsäkerhetsincidenter.

Leverantörsunderlag är numera produktsäkerhetsunderlag

Många CRA-relevanta sårbarheter kommer att ha sitt ursprung utanför er kodbas. De kan komma från paket med öppen källkod, firmwaremoduler, SDK:er, driftade API:er, byggverktyg, molntjänster, underlevererade komponenter eller uppströmsbibliotek. Det gör leverantörsstyrning central för CRA-beredskap.

ISO 27001:2022 klausul 8.1 kräver att organisationer styr externt tillhandahållna processer, produkter eller tjänster som är relevanta för ledningssystemet för informationssäkerhet. ISO/IEC 27002:2022-kontroll 5.21, hantering av informationssäkerhet i IKT-leveranskedjan, ger kontrollankaret.

I Zenith Controls mappar Clarysec kontroll 5.21 som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Dess operativa förmåga är säkerhet i leverantörsrelationer och dess domäner omfattar styrning, ekosystem och skydd. Poängen är enkel: leverantörskontroller är inte upphandlingsadministration. De är kontroller för ekosystemskydd.

Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet – SME, styrningskrav 5.3, anger den avtalsmässiga grunden:

Avtal måste innehålla obligatoriska klausuler som omfattar:

För program på företagsnivå förklarar Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen Controls in Action, steg 23, organisatoriska kontroller 5.19 till 5.37, ISO/IEC 27002:2022-kontroll 5.20, hantering av informationssäkerhet i leverantörsavtal:

När det gäller leverantörer kan förtroende inte vila på antaganden. Det måste kodifieras.

För CRA-beredskap bör leverantörsavtal innehålla produktsäkerhetsklausuler som stödjer snabb sårbarhetsrespons:

DORA förstärker samma inriktning. Finansiella entiteter måste hantera IKT-tredjepartsrisk, upprätthålla register över IKT-tjänsteavtal, bedöma kritikalitet, genomföra leverantörsgranskning, hantera koncentrationsrisk, definiera avtalsmässiga skyddsåtgärder, säkra revisionsrätt och planera exit. Om ni säljer programvara eller IKT-tjänster till finansiella entiteter bör ni räkna med att kunder frågar om er sårbarhetsrapportering och SBOM-process kan stödja deras behov av DORA-underlag för incidenter, resiliens och tredje part.

Clarysecs arbetsflöde för CRA-beredskap

Clarysec hjälper kunder att operativt införa CRA-rapportering i ett ledningssystem för informationssäkerhet som är anpassat till ISO 27001:2022 genom ett praktiskt arbetsflöde.

1. Lägg till CRA-skyldigheter i registret över krav i ledningssystemet

Börja med ISO 27001:2022 klausulerna 4.1 till 4.4. Uppdatera organisationens sammanhang, intressenter och omfattning så att de omfattar produkter med digitala element, exponering mot EU-marknaden, användare, importörer, distributörer, tillsynsmyndigheter, CSIRT:er, leverantörer och reglerade kunder.

Skapa poster i kravregistret för CRA-sårbarhetsrapportering, CRA-rapportering av allvarlig produktsäkerhetsincident, incidentanmälan enligt NIS2, DORA-relaterade kundstödsåtaganden, bedömning av personuppgiftsincident enligt GDPR, avtalsenlig incidentunderrättelse, CVD-åtaganden och forskarkommunikation.

Detta ger revisorer en spårbar väg från extern skyldighet till intern kontroll.

2. Skapa ett mottagningsformulär för produktsårbarheter

Basera mottagningsformuläret på Policy för samordnad sårbarhetsrapportering. Det bör fånga rapportörens identitet, säkra kontaktuppgifter, produktversion, modul, miljö, proof of concept, reproduktionssteg, status för utnyttjande, potentiell dataexponering, tjänstepåverkan, SBOM-komponentträff, CVSS eller motsvarande allvarlighetsgrad, ägare, spårningsreferens och regulatorisk kontrollpunkt.

Formuläret bör automatiskt skapa ett ärende i kön för sårbarhetsrespons. Det bör också starta en beslutstimer för anmälan, även om det slutliga svaret är ”inte rapporteringspliktigt”.

3. Koppla SBOM-data till releaser

För varje släppt produktversion ska en SBOM eller motsvarande komponentförteckning upprätthållas. Minsta användbara underlag omfattar komponentnamn, version, källa, licens, leverantör eller kodförråd, produktversion, byggdatum och status för sårbarhetsskanning.

Policy för säker utveckling och Policy för applikationssäkerhetskrav – SME ger policygrunden för SCA, komponentgranskning och poster över externa komponenter.

4. Bevara underlag från dag ett

Varje CRA-relevant sårbarhetsärende bör bevara:

• Ursprunglig rapport
• Tidsstämpel för bekräftelse
• Triageanteckningar
• Motivering av CVSS eller motsvarande allvarlighetsgrad
• Resultat av SBOM-matchning
• Bedömning av utnyttjande
• Loggar, indikatorer och forensiska ögonblicksbilder
• Leverantörskommunikation
• Riskacceptans, om riskbegränsning försenas
• Patchplan, versionsinformation och testunderlag
• Beslut om kund- och myndighetsunderrättelse
• Indata till slutrapport och erfarenhetsåterföring

Detta överensstämmer med ISO 27001:2022 klausul 8.1, som kräver dokumenterad information som är tillräcklig för att visa att processer fungerade som planerat, samt klausulerna 8.2 och 8.3, som kräver dokumenterade resultat från riskbedömning och riskbehandling.

5. Testa med ett realistiskt beroendescenario

Genomför en skrivbordsövning med en simulerad aktivt utnyttjad beroendesårbarhet. Inkludera utveckling, säkerhet, juridik, integritet, produkt, kommunikation, leverantörshantering och kundnära team. Testet ska visa att organisationen kan identifiera påverkade versioner, bedöma utnyttjande, fatta ett underrättelsebeslut, kontakta leverantörer, ta fram användarvägledning och bevara underlag.

Hur revisorer kommer att testa beredskap för CRA-sårbarhetsrapportering

En CRA-beredskapsgranskning kommer sällan att vara begränsad till en CRA-checklista. Olika revisorer kommer att testa samma underlag genom olika ramverk.

I Zenith Controls mappar Clarysec ISO/IEC 27002:2022-kontroll 5.24, planering och förberedelse för hantering av informationssäkerhetsincidenter, som en korrigerande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den överensstämmer med Respond och Recover, med styrning och hantering av informationssäkerhetshändelser som operativa förmågor.

Den kontrollen är bryggan mellan sårbarhetsupptäckt och regulatorisk rapportering.

NIST CSF 2.0 är särskilt användbart som kommunikationslager på styrelsenivå. Funktionerna GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER hjälper till att förklara hur produktrapportering av sårbarheter passar in i organisationens cybersäkerhetsstyrning i stället för att ligga som ett utvecklingsundantag.

Vanliga brister i CRA-beredskap att åtgärda före 2026

Clarysec ser samma luckor återkommande.

Den första är CVD utan rapportering. Ett företag har en e-postadress för säkerhet eller en security.txt-fil, men ingen intern väg från forskarrapport till rättslig bedömning av underrättelseskyldighet.

Den andra är SBOM utan ägarskap. Utveckling kan generera en SBOM under byggprocessen, men ingen äger riktigheten för släppta produkter eller kan förklara hur SBOM-iakttagelser matas in i sårbarhetsresponsen.

Den tredje är ett ISO-certifikat utan produktomfattning. Ledningssystemet för informationssäkerhet omfattar organisationens IT och SaaS-drift, men inte inbyggd programvara, firmware, infrastruktur för produktuppdateringar, byggpipelines eller sårbarhetsrapportering.

Den fjärde är leverantörsavtal utan sårbarhetsklausuler. Upphandling kräver sekretess och dataskydd, men inte sårbarhetsanmälan, komponenttransparens, incidentstöd, samordnat offentliggörande eller revisionsunderlag.

Den femte är incidentrespons utan logik för produktsårbarheter. Incidentplanen omfattar ransomware, nätfiske och personuppgiftsincidenter, men inte aktivt utnyttjade produktsårbarheter där kundsystem kan vara utsatta innan tillverkarens egen miljö har komprometterats.

Den sjätte är manuellt hanterat DORA-kundunderlag. Försäljning eller kundansvariga besvarar frågeformulär från finanssektorn från fall till fall, medan säkerhetsfunktionen saknar ett standardiserat underlagspaket som visar sårbarhetshantering, SBOM-styrning, incidentstöd och leverantörskontroller.

Varje lucka kan åtgärdas. Varje lucka blir kostsam om den upptäcks under en pågående sårbarhet.

En 90-dagars checklista för beredskap inför CRA-sårbarhetsrapportering

Använd de kommande 90 dagarna för att etablera en försvarbar grund:

• Identifiera produkter med digitala element som släpps ut på eller tillhandahålls på EU-marknaden.
• Uppdatera omfattningen för ledningssystemet för informationssäkerhet och intressentanalysen så att de omfattar CRA-intressenter.
• Lägg till bedömning av rapportering enligt CRA Article 14 i registret över rättsliga och regulatoriska krav.
• Publicera och övervaka en säker rapporteringskanal för sårbarheter.
• Skapa en sårbarhetsresponsgrupp med roller för juridik, produkt, utveckling, säkerhet och kommunikation.
• Upprätthåll SBOM:er eller komponentförteckningar för släppta produktversioner.
• Koppla SCA-resultat till sårbarhetsärenden och produktreleaser.
• Lägg till kriterier för aktivt utnyttjande och allvarlig produktincident i triageformulär.
• Skapa en gemensam beslutsmatris för CRA-, NIS2-, DORA-, GDPR- och avtalsenliga underrättelser.
• Uppdatera leverantörsavtal med klausuler om sårbarhetsavisering, SBOM, incidentstöd och samordning av offentliggörande.
• Upprätthåll patchloggar och underlag för avhjälpande.
• Testa arbetsflödet med en simulerad aktivt utnyttjad beroendesårbarhet.
• Presentera resultaten för ledningen med luckor, kvarstående risker och ansvariga för åtgärder.
• Lägg till underlagspaketet i internrevision och ledningens genomgång.

Clarysecs Policy för sårbarhets- och patchhantering – SME, krav för genomförande av policyn 6.2.1, stödjer övervakningsgrunden:

IT-funktionen måste övervaka sårbarheter med hjälp av:

Samma policy, styrningskrav 5.4.1, lägger till revisionsspåret:

En patchlogg måste upprätthållas och granskas vid revisioner och incidenthanteringsaktiviteter

Den patchloggen kan bli en av de viktigaste artefakterna i en slutrapport enligt CRA. Den visar upptäckt, prioritering, avhjälpande, testning och stängning.

Gör september 2026 odramatiskt

Den bästa CRA-rapporteringshändelsen är inte enkel för att sårbarheten är enkel. Den är enkel för att organisationen redan har övat arbetsflödet.

Före september 2026 kan Clarysec hjälpa er att omvandla sårbarhetsrapportering till ett revisionsklart system genom att mappa ert nuvarande ISO 27001:2022-anpassade ledningssystem för informationssäkerhet, er CVD-process, er SBOM-förmåga, era leverantörsklausuler och era åtgärdsplaner för incidentrespons mot förväntningarna enligt CRA, NIS2, DORA, GDPR och NIST CSF.

Börja med en fokuserad beredskapsbedömning för CRA-sårbarhetsrapportering. Clarysec granskar era policyer, ert SBOM-underlag, era leverantörsavtal, era sårbarhetsärenden, era incidentåtgärdsplaner och ert revisionsspår. Därefter använder vi Zenith Blueprint och Zenith Controls för att bygga en praktisk åtgärdsfärdplan, inte en teoretisk regelefterlevnadspärm.

Om ni redan använder Clarysec-policyer anpassar vi dem för CRA-rapportering. Om ni inte gör det kan vi hjälpa till att införa rätt policyuppsättning, inklusive Policy för samordnad sårbarhetsrapportering, Policy för säker utveckling, Policy för incidenthantering, Policy för sårbarhets- och patchhantering – SME, Policy för applikationssäkerhetskrav – SME och policy för leverantörssäkerhet och tredjepartssäkerhet – SME där det är lämpligt.

September 2026 är tillräckligt nära för planering och tillräckligt långt bort för disciplinerad förberedelse. De organisationer som agerar nu kommer inte att fråga ”Vem äger den här sårbarheten?” under de första 24 timmarna. De kommer redan att ha svaret, underlaget och rapporteringsvägen.

Kontakta Clarysec för att boka en beredskapsbedömning för CRA-sårbarhetsrapportering och omvandla regulatorisk komplexitet till en försvarbar fördel inom produktsäkerhet.