Varför styrelser och tillsynsmyndigheter nu kräver resultatinriktade granskningar efter incidenter
I dagens NIS 2-miljö är det en väg till ökad granskning att ”rapportera” hur man hanterar cyberincidenter. Styrelser, revisorer och tillsynsmyndigheter förväntar sig nu att granskningarna efter incidenter ska vara motorer för mätbara förbättringar – inte bara tidslinjer eller tekniska sammanfattningar. NIS 2, förstärkt av ISO 27001:2022 och ENISA-riktlinjer, har raderat den era där det var säkert att kryssa i rutor och generera en PDF. Varje incidentgranskning måste tydligt visa att organisationen inte bara reagerade, utan lärde sig, förbättrade och integrerade förändringar i kontroller och personalbeteende.
Granskningar efter incidenter är antingen påtryckningar för förändring eller problem som urholkar förtroendet över tid.
Varför är denna förändring så betydande? Eftersom en incident som är "dokumenterad" men inte löst i grunden fortfarande är ett hot. Era SIEM-dashboards och efterrapporter räcker inte till. NIS 2 frågar: Ledde denna incident till en varaktig riskminskning? Testades dess åtgärd, godkändes och spårades den tillbaka till er tillämplighetsförklaring (SoA)? Om ert svar bygger på osammanhängande checklistor – eller slutar med "problemet löst" – lämnar ni sårbarheter hos myndigheter och styrelsen oåtgärdade.
Tillsynsmyndigheter analyserar hela er åtgärdslivscykel: från grundorsaken, via kartlagda åtgärder, till synliga bevis på avslutning och insyn på styrelsenivå. Det som tidigare ansågs vara grundligt – som en punktlista över grundorsaker – godkänns nu bara om ni kan visa hur händelsen förändrade er riskprofil, hur kontroller uppgraderades och testades om, och hur verklig motståndskraft byggdes upp och bevisades.
Det här handlar inte om mer pappersarbete – det handlar om att förvandla ditt revisionspaket till ett levande bevis på din förmåga att förbättras. Den obekväma sanningen är att de flesta företag fortfarande hanterar incidentgranskningar som en regelefterlevnadsadministratör. Under NIS 2 räcker det för att misslyckas med nästa stora test.
Scrolla vidare när vi går igenom anatomin bakom en rotorsaksanalys som driver resultat – och hur man integrerar den förbättringen i din organisations operativa verklighet.
Hur rotorsaksanalys ligger till grund för mätbar motståndskraft (inte bara reparationer)
Rotorsaksanalys (RCA) är inte en retroaktiv ursäkt för "vad som gick fel" – det är en mekanism för att avslöja de verkliga drivkrafterna bakom repeterbar motståndskraft. NIS 2 och ISO 27001 :2022 kräver att du går längre än att åtgärda "symptomet" – brandväggsregeln, den missade varningen, den förhastade patchen. Modern RCA kräver att varje "varför" resulterar i en ansvarsfull åtgärd, mappad till en kontroll och korsrefererad i din SoA.
När man gräver bortom ytan med de fem varför-principerna, till exempel, framträder värdet inte i processen, utan i varje lagers handlingsförmåga – bidrog ett resursgap, en dålig överlämning eller en försummad leverantörspolicy? Varje resultat bör peka på en förbättringsansvarig, inte bara den tekniska lösningen.
RCA är inte klar förrän:
- Varje "varför" leder till process- eller kontrollhöjning: -en som är spårbar över tid.
- Ansvarsskyldigheter dokumenteras: -ägare tilldelad, testad och integrerad i nästa onboarding- eller leverantörsgranskningscykel.
- Bevis är synliga och refererade: -i SIEM-loggar, revisionsdashboards, policyrevideringar eller artefakter från omskolning av personal.
En grundorsak som inte är kopplad till en ägare och bevis på förbättring är bara en teori i väntan på att den upprepas.
Integrationspunkter:
- Blanda dina kriminaltekniska analyser: (SIEM/händelseloggar), obduktionsrapporter och inmatning från central/extern CSIRT för att triangulera inte bara "vad" utan "varför".
- Uppdatera din SoA: varje gång en ny grundorsak dokumenteras och åtgärdas.
- Inkludera styrelse- eller revisionsövervakning: på alla åtgärder med omfattande inverkan (policy, tredjeparts-, arkitekturförändringar).
Klausuler överbryggade till operationalisering:
| **Förväntan** | **Operationalisering** | **Bilagareferens** |
|---|---|---|
| Identifiera den/de verkliga orsaken/orsakerna | RCA-logg med tilldelad ägare | ISO 27001:2022 6.1.2, bilaga A.5.25, A.8.8 |
| Undvik symptombaserade åtgärder | Dokument förklaring av skillnaden | 6.1.3, A.5.4, A.8.9, A.5.36 |
| Intressenter i loopen | Kort/CSIRT i RCA-cykel | 5.3, 5.4, A.5.5, A.5.24, A.8.25 |
| Handlingsplan/avslut | SoA-uppdatering, korsreferensåtgärder | 6.1.3, 8.3, A.5.7, A.5.26 |
| Testade och loggade korrigeringar | Omprövning med tillagda bevis | 9.1, 9.3.2, A.5.29, A.8.29 |
När RCA används på detta resultatinriktade sätt blir det en stödpunkt för kontinuerlig förbättring, inte bara åtgärdande. Låt oss se hur man kan integrera dessa åtgärder i en evidensbaserad, ständig granskningscykel.
Bemästra NIS 2 utan kalkylbladskaos
Centralisera risker, incidenter, leverantörer och bevis i en enda ren plattform.
Kartläggning, spårning och åtgärd av felpunkter: Den levande revisionsloggen
Resultatdrivna incidentgranskningar måste skapa en "levande revisionslogg " – en sammanhängande kedja som länkar samman incidentdetektering, RCA, riskuppdatering, åtgärder, omtestning och avslut. Utan denna sammanbindande vävnad kommer revisioner och regulatoriska granskningar alltid att hitta luckor.
En kontroll existerar bara om du kan spåra dess livscykel från fel, via reparation, till varaktig avslutning – och bevisa det för andra.
Hur man bygger den gyllene tråden:
1. Upptäckt och ärendehantering: Incidenten hamnar i SIEM; ärendet öppnas automatiskt i ditt system.
2. RCA tilldelad: Ägarloggar Fem varför; resultaten delas med styrelsen/CSIRT vid behov.
3. Uppdatering av riskregister: Lägg till eller uppdatera riskpost (t.ex. "kritisk" sänkt efter kontrollhöjning).
4. SoA-korsreferens: Berörda kontroller refereras till och flaggas som under granskning i SoA.
5. Korrigerande åtgärder: Process eller kontroll ändras, policy uppdateras och personal omskolas vid behov.
6. Omtest planerat: Bevis på åtgärd (loggar, användartester, leverantörsbekräftelse) kopplad till den ursprungliga incidenten.
7. Avslutning och godkännande: Ägare och chef/TDA/styrelse granskar avslutandet; loggar och bevis arkiveras för efterlevnad och styrelserapportering.
Checklista för inbäddade bevis:
- Före/efter SIEM-bevis
- Dokumenterad uppdatering av riskklassificering
- Uppdaterad SoA med korsreferens till incident
- Utbildnings- eller kommunikationslogg (personalbekräftelse)
- Styrelse eller ledning granskar inlägg för större/kritiska händelser
- Verifiering av automatisk stängning (testkörning visar att kontrollen nu fungerar)
Om den görs på rätt sätt synliggör denna "levande" granskning återkommande problem, stöder ledningens granskning och erbjuder en stabil grund för revisionsteam som är redo att testa er efterlevnad när som helst.
Att göra kontrollhöjning motståndskraftig, synlig och styrelsebeprövad
Styrelser och extern revisionsbyrå tittar i allt högre grad bortom "lappa och stäng"-cykeln. De vill veta: Utsågs rätt ägare? Bestod förbättringen? Kan den lärdomen användas i framtida onboarding, leverantörsavtal eller processdesign?
Motståndskraft är en kedja av handlingar som är synliga för personal och ägare, och som är dokumenterade, bevisade och redo att motstå personalomsättning eller granskning av styrelsen.
Här är hur:
- Koppla varje förbättring till en tydlig ägare.: Inga fler "laginsatser" som skingrar ansvarsskyldigheten.
- Uppdatera SoA och alla processdokument: En åtgärd är inte bara ett ändrat lösenord eller en återaktiverad regel; det är en fullständig processomvalidering, där personalen meddelas, omskolas och bekräftar att de har förstått.
- Testa om efter förbättring, inte bara efter en incident. Kontroller efter incidenter som inte verifieras genom ny data, personal eller extern tillsyn från det röda teamet är ofullständiga.
- Arkivera bevisen och uppdatera kunskapsbaserna.: Kontroller, processdokumentation, onboarding och lärdomsguider måste visa på förbättringen, inte bara incidenten.
Bryggtabell – Operationalisering av kontrollupphöjning:
| **Utlösare** | **Operationalisering** | **ISO 27001/Bilaga A-referens** |
|---|---|---|
| Leverantörsintroduktionsgap | Leverantörsgranskningsprocess reviderad, godkännande tillagt | A.5.19, 5.1.2, 6.2 |
| Översikt över patchhantering | Automatiserad uppdatering, omtestning, RCA- och SoA-korsreferens | 8.8, 8.29, 6.1.3 |
| Bristande efterlevnad av utrikesministeriet | MFA utrullat, testat, personal omskolad | A.5.17, 8.5, 8.18 |
| Autentisering med endast lösenfras | Policy uppdaterad, utbildningsbekräftelse, SIEM-testad | A.8.32, 6.3, 8.24 |
Bevisen som arkiveras i denna uppgradering – skärmdumpar, loggförfrågningar, kvitton, leverantörssignaturer – är bevis för framtida revisioner, onboarding eller leverantörsbedömningar.
Var NIS 2-redo från dag ett
Lansera med en beprövad arbetsyta och mallar – bara skräddarsy, tilldela och kör.
Hur man bevisar lösningen: Testa om bevis som revisioner och styrelser litar på
En åtgärd har ingen vikt om du inte kan verifiera den – helst "i verkligheten". Det som är avgörande är inte intern tillfredsställelse utan granskning av en styrelse eller en extern revisor som letar efter bevis på förbättring ( isms.online ).
En lärdom förtjänar att behållas – utan att bevisen återuppfinns vid varje revision.
Viktigt att veta om bevispaketet:
- Undertecknad avslutning: Ägare, chef och vid större evenemang, styrelse- eller TDA-godkännande.
- Före-och-efter-tillstånd: Skärmdump eller loggdata som visar ändringen, testet godkänt/misslyckat eller policyn före/efter redigeringar.
- Testa loggarna igen: Scenarieuppspelningar, forensisk bekräftelse, penetrationstester eller extern CSIRT-granskning för betydande luckor.
- Personalbekräftelse: Bekräftelse av omskolat arbetsflöde eller procedur (utbildningsinstrumentpanel, läskvitto för policy, quizresultat).
- Loggar för öppna objekt: Synlighet för förbättringar är ännu inte verifierad eller fortfarande under utveckling.
Även negativa bevis – öppna eller försenade ärenden – bör lyftas fram och flaggas. Styrelser och försäkringsbolag värdesätter transparens och bevis på pågående förbättringar lika mycket som slutförda nedläggningar.
Packa din recension med exporterbara eller rapportklara bevis – försök aldrig att rekonstruera historien i efterhand.
Spårbarhet i realtid: Gör varje uppdatering redo för revision
NIS 2-efterlevnad är en kapplöpning mot ogenomskinlighet; varje kontroll, förbättring och granskning måste kunna spåras i realtid från första incidenten till avslut. Om det görs rätt är du inte bara förberedd för revisioner, utan även redo för styrelsetillsyn och försäkringsbedömning.
Spårbarhetsmini-tabell:
| **Utlösare** | **Riskuppdatering** | **Kontroll-/SoA-länk** | **Bevis loggad** |
|---|---|---|---|
| Legitimationsstöld | Kritisk → Måttlig | A.5.17; MFA/SIEM uppdaterad | MFA-loggar, ägarbekräftelse, SIEM efter test |
| Leverantörsintrång | Ny leverantörsrisk | A.5.19; Onboarding via tredje part | Leverantörsrevisionsdokument, policyuppdatering, CISO-godkännande |
| Nolldagsutnyttjande | Stängd postpatch | A.8.8, 8.29; Patchhantering | Bevis på lapp, test efter lapp, stängningsdatum |
| Träningsgap | Medel → Låg | A.6.3; Utbildningsmodul | Träningsloggar, quizpass, personalens ACK |
Dashboards i realtid visar inte bara passivt information: de fungerar som levande bevis som visar vem som äger varje risk, åtgärd eller ärende, och var i cykeln åtgärden befinner sig – från öppen, till under arbete, till slutförd.
Ett motståndskraftigt ISMS låter alla styrelseledamöter eller tillsynsmyndigheter fråga: "Vad hände? Vem godkände? Var finns bevisen?" – och få ett svar direkt.
Alla dina NIS 2, allt på ett ställe
Från artiklarna 20–23 till revisionsplaner – kör och bevisa efterlevnad, från början till slut.
Demonstrera kontinuerlig förbättring: Från revisionsförsvar till mognadsläge
Kontinuerliga förbättringar enligt NIS 2 mäts och bevisas, inte tillkännages. Styrelser och tillsynsmyndigheter förväntar sig kvartalsvisa eller halvårsvisa rapporter som visar minskande riskåterfall, förbättrad time-to-closure och stigande ägarsigneringsgrad. Försäkringsgivare och investerare kopplar i allt högre grad täckning, prissättning och förtroende till detta bevis.
Förbättringstaktik:
- Schemalägg kvartalsvisa granskningar: Riskkartor, incidentloggaroch prestationer inom personalutbildning.
- Rapportera trendlinjer: Visa mätbar minskning av återfall, snabbare avslut, ökning av konsekvent omskolning.
- Integrera lärandet i onboarding: Varje större lärdom eller förbättring blir standard för nya medarbetare, leverantörer eller programvaruimplementeringar.
- Styrelse-/ledningsinstrumentpaneler: Visa i realtid "öppna incidenter", "förbättring pågår" och "avslut validerat" efter risknivå och ägare.
Integrera denna systematiska förbättring i ert ISMS, inte som en bilaga utan som en förstklassig operativ modul. Använd styrelsepaket, granskningscykler och transparenta dashboards för att bevisa, iterera och mogna varje kvartal.
Nästa steg: Förvandla dina incidentgranskningar till kapital för motståndskraft
Momentum byggs när incidentgranskningar driver förbättringar – en förbättring som din styrelse, revisor, försäkringsgivare och så småningom ditt team alla litar på. Med ISMS.online slår dina arbetsflöden samman dokumenterad RCA, synlig kontrollhöjning, loggförd omskolning och exportklara revisionspaket i en enda kontinuerlig förbättringsmotor.
Ni behöver inte brottas med osammanhängande kalkylblad eller föråldrade godkännandekedjor för att komma dit. Börja med en RCA-mall, gå igenom en kartlagd förbättring eller förhandsgranska en realtidsöversikt för styrelser – varje resultat är kopplat till motståndskraft som er organisation kan bevisa och bibehålla.
Nu är det dags att omvandla eftergranskning av incidenter från ansvar till hävstångseffekt. Gör varje incident till ett bevis för din framtid, inte en fotnot till ditt förflutna.
Vanliga frågor om partihandel med mat och dryck
Vilka är de mest effektiva metoderna för rotorsaksanalys i en NIS 2-granskning efter incidenten?
Grundorsaksanalys enligt NIS 2 är mest effektiv när man kombinerar teknisk forensik (SIEM/händelselogggranskning, endpointdata, leverantörs-/processspår) med strukturerade, transparenta resonemangsramverk som Five Whys eller Fishbone (Ishikawa)-diagram – erkända av ENISA och ISACA för sin förmåga att gå bortom symptom till underliggande fel. Detta innebär att man börjar med att rekonstruera tidslinjer från loggar, ärenden och incidentaviseringar, och sedan systematiskt utmanar varje ytlig förklaring tills man avslöjar det "begravda antagandet eller den brutna överlämningen" som gjorde intrånget möjligt. Till exempel kan en ransomware-händelse som spåras till föråldrade VPN-inloggningsuppgifter i slutändan avslöja haverier i inloggningsstyrning, tillsyn av leveranskedjan eller utbildning.
Intervjuer mellan olika funktioner är avgörande för att upptäcka procedurrelaterade, kulturella eller leverantörsrelaterade problem som loggar ensamma inte kan avslöja. Engagera verksamhets-, IT-, juridik- och kritiska leverantörer; var och en kan ha kontext för beslut, överlämningar eller blinda fläckar som andra inte har. NIS 2 förväntar sig också deltagande från kollegor, tredjeparter eller till och med tillsynsmyndigheter i RCA efter incidenter för händelser med stor påverkan.
Beprövat RCA-flöde
- Aggregerade loggar och ärendedata: (SIEM, slutpunkter, leverantörsaviseringar)
- Använd strukturerad frågeställning: (Fem varför, Fishbone, tidslinjekartläggning)
- Intervjua alla parter i eskaleringsprocessen: – inte bara IT
- Loggfynd och bevis: , mappad direkt till riskregister poster och kontroller
- Utlösa oberoende/kollegiella granskning: för betydande incidenter
Varje brott är i slutändan resultatet av obestridda antaganden. Du upptäcker den verkliga orsaken när du frågar bortom det uppenbara.
Hur ska bevis dokumenteras och versionssäkras efter en incident enligt NIS 2?
NIS 2 kräver att organisationer upprätthåller ett versionsbaserat, spårbart och revisionsklart bevispaket för varje betydande incident – ett som inte bara beskriver den tekniska tidslinjen utan också bevisar procedurmässig respons, ägarens ansvar och lärande. Bevisen måste inkludera:
- Råa loggar, aviseringar, varningar: (SIEM, slutpunkt, leveranskedja)
- RCA-artefakter: (ramverksresultat, intervjuloggar, diagram)
- Loggar över korrigerande åtgärder: -länka varje åtgärdssteg till ett incidentfynd
- Direkt mappning: av varje artefakt till relevant NIS 2-klausul/artikel och ISO 27001-kontroll (t.ex. A.5.24, A.5.25, A.8.8)
- Versionsbaserad lagring: (med åtkomst, inloggning och ändringsloggar)
Bästa praxis är att upprätthålla en live-matris för efterlevnadsmappning – där varje artefakt tilldelas roller, tidslinjer för ägande, relaterad policy och risk. ISMS.online, till exempel, automatiserar denna mappning så att du kan hämta fullständiga bevis per incident, kontroll eller ägare när som helst (ISMS.online, 2024). Alla saknade motiveringar, godkännanden eller olänkade artefakter ökar risken för utdragna frågor från tillsynsmyndigheter.
Ögonblicksbild av bevisspårbarhet
| Typ av bevis | Exempel på artefakt | Klausuler / Kontroller | Ägare / Datum |
|---|---|---|---|
| Detektering | SIEM-logg, varningsärende | NIS 2 Artikel 23, A.5.24 | Sek. avledning/X/X |
| RCA | Fishbone, varför-analys | Artikel 27, A.5.25 | CISO/Å/Å |
| sanering | Policyuppdatering, ny konfiguration | Artikel 21, A.8.5 | Operationer/Z/Z |
| Omtest/stängning | Pentest, SoA-uppdatering | Artikel 21, A.8.8 | Revision/V/V |
Vad gör kontrolluppgraderingar och omtester "redo för revision" för NIS 2 och ISO 27001?
En kontrollhöjning blir verkligen "revisionsklar" först när hela förbättringscykeln – från korrigering, omtestning till styrningsgodkännande – är dokumenterad, tidsstämplad och spårbar till den underliggande risken. Det innebär att du måste:
- Fånga en förändringsregister (t.ex. uppdaterad policy, systemkonfiguration eller leverantörsavtal) tillsammans med den utlösare som motiverade det.
- Koppla ändringen direkt till riskregistret och rätt SoA/kontrollreferens (t.ex. A.8.5) Multifaktorautentisering).
- Dokument aggressivt omtestning- vare sig det är via manuell kontroll, automatiserad skanning eller övning med röda teamet - med bifogade resultat.
- Inkludera explicit ägarskap och godkännande från både tekniska och lednings-/styrelselager.
- Se till att bevisen är versionerad, åtkomstkontrollerad och länkad till policy-/utbildningsuppdateringar efter behov.
Styrelser och tillsynsmyndigheter begär i allt högre grad att få se hela "före- och efter"-kedjan, inklusive personalutbildning eller introduktionsregister när rutiner ändras.
Revisionsklar förbättringskedja
| Trigger | Riskuppdatering | SoA-referens | Omprövningsbevis | Styrelse/Ägare |
|---|---|---|---|---|
| Nätfiske upptäckt | Risk 4→2, lägre | A.8.5 | Röda lagets passning | IT-chef, styrelse |
| Leveranskedjans brott | Leverantörsstatus upp | A.5.19 | Tredjepartsrapport | Operationer, styrelse |
Hur säkerställer man att lektioner faktiskt förändrar beteenden efter en incident?
En lärdom "landar" bara om den översätts för olika målgrupper, tilldelas namngivna ägare och förstärks genom riktad kommunikation och regelbunden testning. Detta innebär:
- Sammanfattande resultat: i jargongfria PM och meddelanden till alla anställda (inte bara teknisk dokumentation)
- Uppdatering av onboarding och fortlöpande utbildning: , med spårning så att varje medarbetare eller leverantör med en roll ser och bekräftar nya krav
- Tilldela och spåra åtgärdsägare och deadlines: i riskregister eller instrumentpanel
- Automatisera påminnelser och regelbundna övningar: (t.ex. kvartalsvisa nätfisketester eller åtkomstgranskningar)
- Rapporteringsstatistik: till tavlan som visar inte bara "slutförda" utan "antagna" ändringar (NCES, 2023)
Verklig förbättring sker bara när åtgärder flyttas från sidan – till kalendern, personalens arbetsflöde och styrelserumsdiskussionerna.
Vilka är de största fallgroparna med bevis och granskning efter incidenter att undvika för att NIS 2-efterlevnad ska uppfyllas?
Vanliga misslyckanden kan undergräva ditt försvar och förtroendet hos revisorer:
- Döda vinklar på grund av ofullständig loggning: (särskilt med leverantörer eller molnet).
- Behandlar symptom, inte orsaker: -uppdatering av appar men ignorering av process-/styrnings- eller leveranskedjans risker.
- Hoppa över omprov: eller dokumenterar bara "lösningen" utan bevis för att den fungerar.
- Att lämna riskregister eller tillämplighetsförklaringar inaktuella: efter en granskning.
- Spårbarhetsbrister: -ingen bindväv från upptäckt till avslut, särskilt mellan flera team eller leverantörer.
- Silobevis eller godkännande: -saknad tvärfunktionell validering, t.ex. styrning, styrelse eller deltagande från oberoende testare.
- Försummar förnyad personal- eller leverantörsutbildning: efter att kontrollerna ändrats.
- Oklart ägarskap eller saknade versionshistoriker: för bevispaket.
Alla dessa leder till upprepade frågor från tillsynsmyndigheter, förlängda revisionscykler eller i slutändan förlorat kundförtroende.
Hur effektiviserar ISMS.online incidentgranskning, kontrollförbättring och bevisrevision för NIS 2?
ISMS.online länkar samman varje steg i NIS 2-incidentlivscykeln – detektering, RCA, förbättring, omtestning, bevis och utbildning – i en enda, versionsstyrd revisionskedja . Plattformen låter ditt team:
- Tilldela och logga varje incidentärende till en rotorsaksanalys (Varför, Fishbone), korrigerande åtgärder och omtestning
- Koppla bevis till specifika NIS 2-klausuler, ISO 27001-kontroller och policyartefakter (”Länkat arbete”)
- Uppdatera tillämplighetsförklaringar, riskregister och personal-/kommunikationsregister automatiskt när kontrollerna ändras
- Kräv, spåra och rapportera bekräftelser på utbildning av personal/leverantörerstänger slingan för styrning och tillsynsmyndigheter
- Exportera tillsynsklara bevispaket – med inbäddade ändrings- och åtkomstloggar och fullständig spårbarhet ((https://sv.isms.online/platform/features/linked-work/))
Med en live-instrumentpanel och automatiserade påminnelser är varje förbättring synlig, från incidentrapport via riskuppdatering till styrelsepresentation – utan att något går förlorat mellan stegen.
Vägen från incident till förbättring är bara ett klick bort, och din nästa revision är klar innan frågan ens har ställts.
ISO 27001 / NIS 2 Operativ bryggtabell
| Förväntan | Hur levererat | Artikel/Klausul |
|---|---|---|
| Röda orsaksanalys | Tidslinje, Varför/Fishbone, teamintervjuer | NIS 2 Art.23/27, A.5.25 |
| Versionsbaserat bevispaket | Kedja: loggar→RCA→fix→test+godkännande, mappad | NIS 2 Art.27/35, A.5.35 |
| Kontrollförbättring | Åtgärda med omtest, SoA/riskuppdatering, signering | NIS 2 Artikel 21, A.8.8 |
| Spårbarhet | ISMS.online-instrumentpanelen ”Länkat arbete” | NIS 2, ISO 27001 |
Exempel på spårbarhetstabell
| Trigger | Riskuppdatering | Kontroll / Referens | Bevis |
|---|---|---|---|
| Intrång i autentiseringsuppgifter | Risk 3→2 lägre | A.8.5 | Pentest, utbildningskvitto |
| Leverantörens driftstopp | Leverantör flaggad | A.5.19, NIS2 Artikel 21 | Leverantörsrevision, instrumentpanel |
Genom att integrera bevis, processer och ansvarsskyldighet i ett system omvandlar ISMS.online ert NIS 2-svar från efterlevnadspappersarbete till en levande motståndskraftsstrategi – mätbar, repeterbar och redo för alla utmaningar.
