Cyberresiliensförordningen: produktberedskap

Arbetet med cyberresiliensförordningen (CRA) är inte klart när ett krav har lagts till i ett kalkylblad. Produktteamet behöver veta vilken produkt kravet gäller, vem som ansvarar för arbetet, när det ska vara klart, varför ett beslut fattades och var underlaget finns.

CRA:s rapporteringsskyldigheter gäller sedan den 11 september 2026. Förordningens huvudsakliga bestämmelser börjar tillämpas den 11 december 2027. En del av arbetssättet måste därför fungera nu, medan resten bör byggas upp så tidigt att den tekniska dokumentationen inte behöver återskapas i slutet.

Viktiga CRA-datum

Datum	Vad förändras
11 september 2026	Rapporteringsskyldigheterna enligt artikel 14 börjar tillämpas
11 december 2027	De huvudsakliga CRA-skyldigheterna börjar tillämpas

För rapporteringspliktiga händelser börjar tiden räknas när tillverkaren får kännedom om dem. Kommissionen beskriver en tidig varning inom 24 timmar och en fullständig anmälan inom 72 timmar. Tidsfristen för slutrapporten skiljer sig mellan en aktivt utnyttjad sårbarhet och en allvarlig incident.

Se det praktiska arbetsflödet för CRA-rapportering inom 24/72 timmar

CRA gäller en produkt, inte ett abstrakt efterlevnadspoäng för hela företaget

Den första användbara frågan är: vilken specifik produkt med digitala element bedömer vi?

Förordningen omfattar programvaru- och hårdvaruprodukter och, under angivna förutsättningar, deras lösningar för fjärrbehandling av data. Organisationens roll spelar också roll: tillverkare, representant, importör, distributör eller en aktör som gör en väsentlig ändring.

Börja med en post för en produkt:

produktnamn och unik identifierare;
version eller utgåvefamilj;
tillverkare och det varumärke under vilket produkten tillhandahålls;
hur produkten tillhandahålls på EU-marknaden;
avsett ändamål och huvudfunktioner;
komponenter och beroenden;
fjärrtjänster som krävs för produktens funktioner;
stödperiod;
personer som ansvarar för produktsäkerhet, sårbarheter och utgåvor.

Kontrollera hur CRA:s tillämpningsområde bedöms för en produkt

Sju områden som behöver hänga ihop

1. Tillämpningsområde

Avgör om produkten och organisationens roll omfattas av CRA. En etikett som ”SaaS”, ”IoT” eller ”programvara” är ingen bedömning av tillämpningsområdet.

2. Produktrisk

CRA-kraven är kopplade till en cybersäkerhetsriskbedömning för produkten. Bedömningen bör vara knuten till en produktversion och granskas när arkitekturen, det avsedda ändamålet eller risken förändras.

3. Inbyggd säkerhet och säkerhet som standard

Ett krav behöver bli utvecklingsarbete: ett konstruktionsbeslut, en åtgärd, en ansvarig, ett test, en granskning och underlag.

Läs om inbyggd säkerhet enligt CRA

4. Sårbarheter och SBOM

CRA kräver att tillverkare identifierar och dokumenterar sårbarheter och produktkomponenter, bland annat genom att upprätta en programvaruförteckning (SBOM) i ett vanligt, maskinläsbart format som omfattar åtminstone beroendena på den översta nivån.

Se varför en SBOM är ett underlag till processen och inte slutresultatet

5. Rapportering

CRA:s gemensamma rapporteringsplattform (SRP) är i drift sedan den 11 september 2026. I praktiken behöver tillverkaren mer än portalåtkomst: ett tydligt T0, eskaleringskriterier, en ansvarig, ersättare och de uppgifter som krävs för att lämna en anmälan.

6. Teknisk dokumentation

Den tekniska dokumentationen ska inte vara ett arkiv av fristående filer. Den behöver göra produkt, version, arkitektur, riskbedömning, sårbarhetshantering, tester, beslut och grunden för stödperioden spårbara.

Se en praktisk struktur för CRA:s tekniska dokumentation

7. Stödperiod

Tillverkaren fastställer en stödperiod utifrån förväntad användning och kriterierna i CRA. Huvudregeln är minst fem år, om produkten inte förväntas användas under kortare tid.

Se hur stödperioden dokumenteras

Var mindre organisationer får svårigheter

ENISA:s CRA-enkät för små och medelstora företag 2026 visar gapet mellan kännedom och genomförande. I ett frivilligt urval med 194 svar kände 66 % till CRA, medan 54 % uppgav begränsad eller ingen kunskap om bedömning av överensstämmelse och 42 % begränsad eller ingen kunskap om nödvändig dokumentation. Stöd för teknisk dokumentation valdes av 73 % av de svarande.

Små team behöver ofta samla produktkunskap från flera funktioner. Bedöm det egna nuläget genom ett avgränsat underlagstest i stället för att använda ett allmänt branschprocenttal.

Enkäten ska inte behandlas som en representativ uppskattning av hela EU-marknaden: urvalet är litet och frivilligt. Den är ändå användbar som signal om att problemet handlar om mer än att ”veta att CRA finns”. Team behöver upprepbara arbetsprocesser.

Var Pulsar GRC passar in

Pulsar GRC kopplar ihop arbete som ofta är utspritt mellan dokument, kalkylblad, ärenden och e-post:

krav → risk → kontroll eller åtgärd → ansvarig → tidsfrist → dokument eller underlag → granskning → beslutshistorik.

Pulsar kopplar samman revisioner, kontroller, risker, dokument, underlag, rapporter, CAPA, leverantörer och uppgifter. Det hjälper till att driva och styrka en process utan att låtsas att programvaran gör den rättsliga bedömningen åt kunden.

Pulsar certifierar inte CRA-efterlevnad, ersätter inte rättslig bedömning och avgör inte självständigt om en händelse måste rapporteras. Beslut om tillämpningsområde, regelklassificering och inlämning ligger hos ansvariga personer.

Börja med en produkt

Börja inte med ett program kallat ”inför CRA i hela företaget”. Välj en verklig produkt. Definiera dess omfattning, ansvariga, aktuella risker, sårbarhetsflöde, dokumentation och stödperiod. Där blir de gap som går att åtgärda synliga.

Se Pulsar GRC i ett konkret arbetsflöde

Bygg en produktakt innan ni bygger ett program

Anta att ett litet team säljer en uppkopplad mätare med en mobilapp och en egen backend. Börja med en produktakt som identifierar de delar kunden faktiskt använder. Beskriv huvudfunktioner, programvaruversioner, distribution och vem som ansvarar för varje del. Ange även vilka funktioner som försvinner om nätverket eller backend inte fungerar. Den kartan gör det lättare att ställa rätt frågor om CRA. Den avgör inte på egen hand den rättsliga klassificeringen.

Produktakten behöver också ett avsett användningsområde. En komponent som används i ett kontrollerat nät kan få andra riskförutsättningar när den senare erbjuds för direkt anslutning från internet. Behåll därför det tidigare beslutet och dokumentera när användningen ändras. Ett produktnamn som förblir detsamma är inte bevis på att omfattningen fortfarande är oförändrad. Produktansvarig och tekniskt ansvarig bör godkänna samma beskrivning.

Ge varje viktig fråga en mottagare

En arbetslista med ”säkerhet”, ”dokumentation” och ”CRA” blir snabbt ett register över vad alla hoppas att någon annan gör. Dela i stället upp frågorna efter beslut. Vem bedömer produktens omfattning? Vem avgör om ett fynd påverkar produkten? Vem godkänner stödperiodens grund? Vem kan genomföra tester och vem får acceptera kvarstående risk? En person kan ha flera roller, men det ska framgå vilka beslut personen fattar.

Definiera även vad som händer när den ansvariga är borta. För en tidskritisk händelse är det avgörande att ersättaren kan öppna underlag och få kontakt med rätt teknisk funktion. För långsiktiga frågor räcker ofta ett tydligt överlämningsförfarande. Dokumentera bara den detaljnivå teamet behöver för att handeln ska fungera. Ett stort schema utan praktiska befogenheter löser inte personberoendet.

Håll isär juridisk bedömning och teknisk verifiering

Ett tekniskt test kan visa att en uppdateringsmekanism avvisar ett felaktigt paket. Det visar inte ensamt att alla tillämpliga CRA-krav är uppfyllda. En rättslig bedömning kan fastställa vilka krav som gäller, men den visar inte att produkten beter sig som avsett. Länka därför de två bedömningarna och ange deras skilda syften. Underlag för genomförande, test och godkännande behöver vara kopplat till rätt produktversion.

Om någon del av bedömningen saknas ska statusen beskriva luckan. Exempelvis kan ett krav vara tolkat och en ändring genomförd medan verifieringen återstår. Ett enda sammanslaget ”klart” döljer den skillnaden. Det är särskilt viktigt när flera versioner finns på marknaden och bara den senaste har fått en ny kontroll. Teamet behöver veta vilka användare och utgåvor som fortfarande påverkas.

Prioritera med produktens verkliga konsekvenser

Börja med funktioner vars missbruk eller bortfall kan ge en tydlig skada. Beskriv vägen från teknisk svaghet till följd: vilket gränssnitt kan användas, vilka befogenheter behövs, vilken funktion påverkas och vilket skydd finns redan? Orden ”kritisk risk” bör följas av den beskrivningen. Då kan produktteamet avgöra om arbetet ska ändra arkitekturen, begränsa en funktion eller förbättra verifieringen.

Separera en bekräftad brist från ett osäkert antagande. Ett osäkert scenario kan motivera ett test innan en större lösning väljs. Om samma risk förekommer i flera utgåvor behöver åtgärden omfatta rätt versioner eller innehålla ett tydligt beslut om vad som ännu återstår. En prioritering som bara följer det senaste säljprojektet riskerar att lämna äldre produkter utan ägare.

Ett realistiskt första underlagspaket

Välj en produktutgåva och samla ett litet, komplett urval: produktbeskrivning, arkitekturskiss, aktuella riskbedömningar, componentförteckning, testresultat och beslut om öppna frågor. Länka varje del till sin ursprungliga källa. Förklara vad som ingår och vad som ännu inte ingår. Ett index är ofta mer användbart än att kopiera allt till en stor PDF där källor och versioner blandas.

Be en granskare utanför projektets kärnteam följa en risk genom materialet. Personen ska hitta skälet till ett designbeslut, genomförandet, testet och resultatbedömningen. Om det kräver muntliga förklaringar ska de saknade sambanden dokumenteras. Den interna övningen visar om paketet är användbart. Den ersätter inte den tillämpliga bedömningen av överensstämmelse eller en myndighets begäran om ytterligare information.

Rapportering behöver en egen övning

Använd ett hypotetiskt meddelande om ett aktivt utnyttjande och starta en övning med den normala bemanningen. Dokumentera mottagning, första tekniska bedömning, rättslig klassificering och överlämning till den som kan lämna anmälan. Kontrollera att osäkerhet kan anges utan att källan skrivs över. Behåll skillnaden mellan den första uppgiften och vad som senare har bekräftats.

Övningen ska även omfatta portalåtkomst och kvittenshantering på ett tillåtet sätt. Skicka inte en verklig myndighetsanmälan som test om det inte finns en avsedd testkanal. Bedöm om den som hanterar rapporteringen kan få fram de uppgifter som behövs och vad som händer om en huvudperson inte är tillgänglig. Skapa uppföljningar för konkreta gap, med ansvarig och datum.

Kontrollera att ändringsarbete uppdaterar rätt handlingar

En säkerhetsrättelse kan påverka flera dokument samtidigt: komponentförteckning, arkitektur, testplan, användarinformation och riskbedömning. Ange vilka följdändringar som behövs redan när utvecklingsuppgiften skapas. Vid utgåvan kontrollerar teamet vilka som faktiskt är genomförda. Utan det steget kan programvaran vara rättad medan produktakten fortfarande beskriver en äldre lösning.

Bevara också vilka utgåvor som har fått ändringen och hur den verifierats där. Ett lyckat test i utvecklingsmiljön är inte alltid tillräckligt underlag för alla stödda installationssätt. Dokumentera avgränsningen och skapa en öppen fråga när täckningen är ofullständig. Då blir dokumentationen en del av produktförvaltningen och inte en efterhandsbeskrivning av en idealisk process.

Följ framsteg utan ett påhittat efterlevnadspoäng

Mät avgränsade arbetsresultat: produkter med granskad omfattning, risker med aktuellt underlag, versioner med identifierad SBOM och åtgärder som väntar på verifiering. Definiera vad varje mått betyder. Ett stort antal uppladdade dokument säger lite om innehållet är relevant eller granskat. Ett procenttal som blandar juridiska och tekniska frågor kan bli svårt att använda i beslut.

Läs särskilt de ärenden som saknar godkännare eller ligger stilla mellan funktioner. De visar ofta var kapacitet eller befogenheter saknas. Ledningen behöver då fatta ett resursbeslut, ändra prioritering eller tydligt acceptera ett avgränsat nästa steg. Pulsar kan synliggöra sambanden och arbetet; organisationen behöver fortfarande genomföra kontroller, granska slutsatser och följa de officiella regler som gäller produkten.

Källor

Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.