Cyber Resilience Act · 2026/2027

CRA-incidentrespons: ägare, deadlines och rapporteringsbevis

Författare: Piotr AdamskiOperativ granskning och säkerhetsgranskning: Brillnet C-Team

Information. Ersätter inte individuell juridisk rådgivning eller bedömning av överensstämmelse.

Kontrollera CRA:s tillämpning och ladda ned din bedömning

Sedan den 11 september 2026 måste tillverkare som omfattas av CRA rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar säkerheten hos produkter med digitala element. Den tidiga varningen ska lämnas inom 24 timmar från att tillverkaren fått kännedom, och den fullständiga anmälan inom 72 timmar.

Den största operativa risken är inte att ett formulär saknas. Den är att det saknas ett överenskommet T0, en beslutsansvarig, ersättare, tillförlitliga informationskällor och dokumentation av varför en händelse klassificerades på ett visst sätt.

Rapporteringsförloppet

Steg Tidsfrist Vad som ska kontrolleras
Kännedom T0 tidsstämpel, informationskälla och mottagande person
Tidig varning inom 24 h uppgifterna som CRA/SRP kräver i detta steg
Fullständig anmälan inom 72 h ytterligare uppgifter om händelsen och påverkan
Slutrapport – aktivt utnyttjad sårbarhet senast 14 dagar efter att en korrigerande åtgärd finns tillgänglig avhjälpande och hanteringens resultat
Slutrapport – allvarlig incident inom 1 månad från anmälan inom 72 timmar incidentförlopp, påverkan, åtgärder och resultat

Kontrollera alltid de aktuella instruktionerna för CRA:s gemensamma rapporteringsplattform. Operativ vägledning och portalen kan förändras snabbare än själva förordningen.

Alla sårbarheter utlöser inte rapportering enligt artikel 14

CRA avser en aktivt utnyttjad sårbarhet, inte varje fynd från en skanner. På samma sätt är ”allvarlig incident” ett rättsligt begrepp och inte en synonym till varje säkerhetsärende med hög prioritet.

Ett bra arbetsflöde skiljer mellan:

  1. upptäckt eller mottagande av information;
  2. teknisk triage;
  3. bedömning av rättsliga kriterier;
  4. beslut av en ansvarig person;
  5. förberedelse av anmälan;
  6. inlämning genom rätt kanal;
  7. avhjälpande, uppföljning och slutrapport.

Att automatiskt märka ett fynd som ”rapporteringspliktigt enligt CRA” utan mänskligt godkännande skapar risk för både felaktiga anmälningar och utebliven rapportering.

Definiera ansvaret innan tiden börjar löpa

En roll som heter ”Säkerhetsteam” räcker inte. Identifiera för varje produkt:

  • vem som tar emot information om sårbarheter eller incidenter;
  • vem som utför teknisk triage;
  • produktansvarig;
  • vem som godkänner den rättsliga klassificeringen;
  • vem som lämnar in via SRP;
  • en ersättare för varje tidskritisk roll;
  • eventuell eskalering utanför arbetstid som produkten och arbetssättet kräver.

Om en person har flera roller ska det dokumenteras uttryckligen. Små team kan fungera; oklart ansvar gör det inte.

Vad som ska registreras vid T0

Skapa den första posten innan diskussionen övergår till om händelsen är ”verkligt allvarlig”. Bevara åtminstone:

  • exakt tidpunkt för kännedom;
  • informationskälla;
  • produkt och version;
  • rapportör eller detekteringssystem;
  • en kort beskrivning av vad som observerades;
  • personen som tog emot informationen;
  • länk till källmaterial eller underlag.

Utan denna post kan organisationen några timmar senare sakna möjlighet att fastställa när den lagstadgade tiden faktiskt började löpa.

En praktisk arbetsföljd

1. Registrera

Öppna ett ärende och bevara den ursprungliga rapporten. Skriv inte över källan när förståelsen utvecklas.

2. Gör triage

Bekräfta berörd produkt, version, teknisk omfattning, kända effekter och tillgängligt underlag. Skilj bekräftade fakta från hypoteser.

3. Klassificera

Dokumentera skälen för och emot rapporteringsplikt. Beslutet ska ange godkännare och tidpunkt för godkännandet.

4. Lämna varningen inom 24 timmar

Förbered den tidiga varningen med den information som finns då. Vänta inte på en färdig grundorsaksanalys när den lagstadgade tidsfristen redan löper.

5. Lämna anmälan inom 72 timmar

Färdigställ uppgifterna som den aktuella SRP-processen kräver.

6. Avhjälp och kommunicera

Koppla utvecklingsarbete, utgåvor, säkerhetsuppdateringar och kundkommunikation till samma ärende.

7. Färdigställ slutrapporten

Avsluta arbetsflödet först när resultatet, åtgärderna, verifieringsunderlaget och den nödvändiga slutrapporten har dokumenterats.

Öva processen före en verklig händelse

Använd ett realistiskt men hypotetiskt scenario och kontrollera att:

  • teamet vet var posten ska skapas;
  • T0 går att identifiera;
  • den godkännande personen är känd;
  • det finns ersättare;
  • produkt- och logguppgifter kan samlas snabbt;
  • personen som lämnar in har fungerande SRP-åtkomst;
  • övningen lämnar ett dokumenterat beslut och förbättringsåtgärder.

Pulsar GRC:s roll

Pulsar kan koppla incidenten eller sårbarheten till risker, åtgärder, ansvariga, dokument, underlag, rapporter och beslutshistorik. Risker, uppgifter, dokument, underlag och rapporter bevarar kontexten för hantering och beslut.

Organisationen bedömer om artikel 14 gäller, godkänner anmälan och lämnar in den till SRP genom rätt kanal. Att förbereda dokumentation i Pulsar ersätter inte inlämningen av en anmälan.

Se Pulsar GRC i ett arbetsflöde

Ett scenario som prövar hela överlämningen

Anta att en extern rapportör skickar information om ett aktivt utnyttjande i en produktkomponent. Meddelandet når supporten en fredag kväll och innehåller en teknisk beskrivning men ingen säker lista över berörda versioner. Registrera det ursprungliga meddelandet, mottagningstid och den person som tog emot det. Skapa därefter en tydlig överlämning till teknisk triage och den ansvariga för rättslig klassificering. Osäkerhet om versionerna är en uppgift att utreda, inte ett skäl att låta ärendet försvinna.

I övningen ska varje överlämning kunna följas. Vem hade uppgifterna, vilka fakta var bekräftade och när fick nästa person tillgång? Behåll skillnaden mellan mottagningssystemets tidsstämpel och ett senare internt möte. T0 behöver en dokumenterad bedömning av när relevant kännedom uppstod. Organisationen bör inte flytta startpunkten genom att byta ärendesystem eller vänta på en bekväm beslutsdag.

Triage och anmälan arbetar med olika frågor

Den tekniska gruppen undersöker komponent, version, möjlig exploatering och påverkan. Den som bedömer rapporteringsskyldigheten jämför de kända förhållandena med de tillämpliga kriterierna. Koppla arbetena men gör inte det ena beroende av att det andra är slutligt. En fullständig grundorsaksanalys kan ta längre tid än den första tidsfristen. Registrera därför vilka uppgifter som finns och vilka som ännu utreds.

En skannerrapport med hög allvarlighetsgrad innebär inte automatiskt ett aktivt utnyttjande. Ett meddelande om verklig exploatering kan däremot kräva snabbare handling än en vanlig åtgärdsplan. Den bedömningen behöver en behörig person och en kort motivering. När ny information kommer ska teamet kunna ompröva beslutet utan att radera den tidigare bedömningen eller dess grund.

En kvittens är ett eget underlag

Att utkastet är godkänt internt betyder inte att anmälan har lämnats in. Bevara tidpunkt, kanal och den kvittens eller identifierare som rapporteringsplattformen ger. Koppla den till rätt händelse och produkt. Om ett tekniskt problem uppstår behöver organisationen dokumentera det och följa de aktuella instruktionerna för rätt rapporteringskanal. En skärmbild av en färdig text är inte samma sak som ett inlämningsbevis.

Kontrollera åtkomst och behörigheter före en verklig händelse. Personen som ska lämna in behöver veta hur kontot används, var vägledningen finns och hur ersättaren får tillgång genom godkänd procedur. Dela inte personliga lösenord för att lösa bemanningsfrågan. Öva det praktiska förfarandet utan att skapa felaktiga verkliga myndighetsanmälningar. Bevara resultaten och följ upp det som hindrade en fullständig överlämning.

Fakta, hypoteser och externa budskap ska kunna skiljas åt

När flera personer arbetar parallellt blir en tidig hypotes lätt en uppgift som senare ser bekräftad ut. Märk därför uppgiftens status och hänvisa till källan. Bevara versionshistorik för den text som används i anmälan. Ange vilken intern bedömning som godkände uppgifterna och vilka frågor som fortfarande var öppna. Detta hjälper teamet att korrigera information när förståelsen förändras.

Samordna även användarkommunikation med teknisk åtgärd och relevant bedömning. Beskriv vad mottagaren behöver göra och vilka versioner informationen gäller. Undvik absoluta säkerhetsbesked när testerna har begränsad omfattning. Kontrollera samtidigt att kommunikationen inte röjer hemligheter, personuppgifter eller tekniska detaljer i större omfattning än det aktuella syftet kräver. Rapportering och kundinformation är relaterade men har olika mottagare och former.

Flera skyldigheter kan gälla samma händelse

CRA-rapportering ska hållas tydlig även när organisationen bedömer andra regelverk. En händelse kan kräva separat prövning av exempelvis dataskydd eller nationella cybersäkerhetsregler. Skapa länkar mellan bedömningarna och bevara deras olika kriterier, ansvariga och kanaler. Anta inte att en inlämning i ett arbetsflöde automatiskt uppfyller ett annat. Kontrollera de aktuella reglerna för varje tillämplig skyldighet.

Registrera också vem som samordnar budskap mellan funktionerna. Tekniskt innehåll kan vara gemensamt medan omfattning och tidsfrister skiljer sig. Ett gemensamt händelseärende kan minska dubbelarbete, men rapporteringsbesluten behöver fortfarande vara urskiljbara. Om två funktioner gör olika bedömningar ska skillnaden synas så att den kan lösas, inte gömmas bakom en sammanslagen status.

Slutrapporten börjar med den första posten

Spara det som senare behövs för att förklara hanteringen: tidslinje, påverkan, beslut, rättelser, testresultat och kvarstående frågor. Koppla utvecklingsuppgiften till den utgåva där ändringen faktiskt levererades. Dokumentera också hur berörda användare kunde få åtgärden. Om materialet samlas först när slutrapporten ska skrivas behöver teamet rekonstruera viktiga detaljer under tidspress.

Skilj publicering av en rättelse från verifiering av dess effekt. Testresultatet ska identifiera produktversion, relevanta förhållanden och vad som undersöktes. Om en äldre utgåva ännu inte är åtgärdad måste den begränsningen framgå. Den ansvariga ska kunna avgöra vilket slutrapporteringsflöde som gäller för den aktuella typen av händelse och kontrollera tidsfristen i de officiella källorna.

Ett mottagningstest med en frånvarande nyckelperson

Genomför en skrivbordsövning där ordinarie produktansvarig inte är tillgänglig. Ersättaren ska hitta produktbeskrivning, komponentuppgifter, beslutsväg och rätt rapporteringskanal. Övningen kan använda fiktiva tider så att gruppen ser var väntan uppstår. Markera tydligt att det är ett test. Mät inte bara hur snabbt ett dokument skapas; kontrollera också om rätt frågor besvaras och om underlagen går att följa.

Lägg in en motsägande uppgift, exempelvis att den första versionslistan senare visar sig vara fel. Teamet ska kunna ändra bedömningen, bevara den tidigare källan och uppdatera rätt mottagare. Ett arbetsflöde som bara fungerar med perfekt första information är för skört för en verklig incident. Följ upp bristerna som konkreta uppgifter med ansvarig och verifieringskriterium.

Verktygets gräns och organisationens ansvar

Pulsar kan hålla ihop tidslinje, uppgifter, risker, dokument och beslutshistorik. Organisationen behöver göra teknisk triage, bedöma rättslig tillämplighet, godkänna budskap och lämna anmälan genom den avsedda plattformen. Det finns inget automatiskt myndighetsgodkännande i ett internt ärende. En förberedd mall och tydligt ansvar kan underlätta arbetet, men de garanterar inte att en anmälan är korrekt eller fullständig.

Granska processen efter varje övning eller verklig händelse. Fråga vad som blev känt för sent, vilken information som behövde samlas om och vilken överlämning som saknade mottagare. Anpassa arbetsflödet efter dessa observationer och kontrollera portalens aktuella instruktioner när processen ändras. På så sätt utvecklas rapporteringsberedskapen från dokumenterade erfarenheter i stället för antaganden om att nästa incident ska vara enklare.

Kontrollera vad som hände mellan två tidsstämplar

En tidslinje kan visa när ärendet skapades utan att visa när relevant information togs emot. Jämför därför ursprungsmeddelandet, mottagningssystemet och den första bedömningen. Om uppgifterna skiljer sig ska teamet utreda varför. Ett automatiskt tidsfält ersätter inte bedömningen av relevant kännedom. Bevara skälet och ansvarig person så att beslutet går att följa senare.

Kontrollera också om en överlämning gjorde att information väntade utan mottagare. Det kan kräva ändrad bemanning eller en tydligare eskaleringsväg. En påminnelse i samma kö löser inte alltid problemet. Efter övningen bör ansvarig kunna visa vilken konkret ändring som gjordes och hur den ska prövas nästa gång.

Relaterad vägledning

Repetera en incident utan att göra en riktig arkivering

Välj en fiktiv produkt som din träning förutsätter ligger inom CRA:s räckvidd. Om exemplet inkluderar SaaS eller en backend, dokumentera varför det är relevant för den produkten; anta inte att alla webbläsartjänster faller under CRA. Använd ett syntetiskt meddelande som tagits emot utanför kontorstid, ett tekniskt fynd och ett beslut som kräver en auktoriserad granskare.

Anteckna när övningsdeltagarna blir medvetna om fakta och särskilj den punkten från att öppna en biljett. Tilldela utredare, beslutsägare och ersättare. Spåra vilka fakta som fastställs och vilka som fortfarande är under granskning. Tidslinjerna enligt artikel 14 avser tillämpliga medvetenhets- och rapporteringsvillkor, inte bara till den tid då en chef råkar öppna applikationen.

Håll den aktivt utnyttjade sårbarhetsgrenen åtskild från grenen för allvarliga incidenter. Deras slutrapportvillkor skiljer sig åt: sårbarhetsrapporten innehåller en deadline kopplad till tillgängligheten av en korrigerande eller mildrande åtgärd, medan grenen för allvarliga incidenter har sin egen slutrapporttidslinje. Använd den aktuella lagtexten och officiella rapporteringsvägledning för den filial du har kvalificerat dig för.

I Pulsar, förbered övningsåtgärder, ägare, deadlines och syntetiska bevis. Anteckna ett granskarens beslut och all information som saknas. Kontrollera det slutliga tillståndet efter att du har sparat. Det användbara resultatet är en dokumenterad repetition som avslöjar ett saknat substitut eller beviskrav innan en verklig händelse inträffar.

Skicka inte in en övning till ENISA, en CSIRT eller en riktig kund. Pulsars register är inte ett officiellt kvitto och den offentliga testperioden lovar inte automatisk rapportering till myndigheterna. Behåll en faktisk inlämning, dess officiella kanal och kvitto som separata åtgärder vid en verklig incident. Granska 14-dagars provperiodens betalningsmetod och avbokningsvillkor innan du registrerar dig.

Källor

CRA för SaaS: omfattning, åtgärder med ansvarig och bevis

Sårbarheter i IoT-komponenter: leverantörer, beslut och korrigeringar

Polska KSC/NIS2 för IT-leverantörer: bedömning och ett åtgärdsregister