Hvorfor styrer og regulatorer nå krever resultatorienterte evalueringer etter hendelser
I dagens NIS 2-miljø er det å «rapportere» seg gjennom cyberhendelser en billett til økt gransking. Styrer, revisorer og regulatorer forventer nå at evalueringene etter hendelser skal være motorer for målbar forbedring – ikke bare tidslinjer eller tekniske sammendrag. NIS 2, forsterket av ISO 27001:2022 og ENISA-veiledning, har visket ut tiden der det å krysse av i bokser og generere en PDF betydde at man var trygg. Hver hendelsesgjennomgang må tydelig vise at organisasjonen ikke bare reagerte, men lærte, forbedret og implementerte endringer i kontroller og ansattes atferd.
Ettervurderinger er enten pådrivere for endring, eller ulemper som svekker tilliten over tid.
Hvorfor er dette skiftet så viktig? Fordi en hendelse som er «dokumentert», men ikke løst ved roten, fortsatt er en trussel. SIEM-dashboardene og etterrapportene dine er ikke nok. NIS 2 spør: Førte denne hendelsen til en varig risikoreduksjon? Ble løsningen testet, signert og sporet tilbake til din erklæring om anvendelighet (SoA)? Hvis svaret ditt er basert på frakoblede sjekklister – eller stopper med «problem løst» – lar du regulatoriske og styrelsesmessige sårbarheter være uadressert.
Regulatorer analyserer hele utbedringssyklusen din: fra rotårsaken, via kartlagte tiltak, til synlige bevis på avslutning og synlighet på styrenivå. Det som tidligere ble ansett som grundig – som en punktliste over rotårsaker – består nå bare hvis du kan vise hvordan hendelsen endret risikoprofilen din, hvordan kontroller ble oppgradert og testet på nytt, og hvordan reell motstandskraft ble bygget og dokumentert.
Dette handler ikke om mer papirarbeid – det handler om å forvandle revisjonspakken din til et levende bevis på din evne til forbedring. Den ubehagelige sannheten er at de fleste selskaper fortsatt behandler hendelsesgjennomganger som samsvarsadministrasjon. Under NIS 2 er det nok til å stryke på den neste store testen.
Bla videre mens vi bryter ned anatomien til en rotårsaksanalyse som driver resultater – og hvordan du kan integrere denne forbedringen i organisasjonens operative virkelighet.
Hvordan rotårsaksanalyse underbygger målbar motstandskraft (ikke bare reparasjoner)
Rotårsaksanalyse (RCA) er ikke en tilbakevirkende unnskyldning for «hva som gikk galt» – det er en mekanisme for å avdekke de sanne driverne bak repeterbar robusthet. NIS 2 og ISO 27001 :2022 krever at du går lenger enn å fikse «symptomet» – brannmurregelen, det tapte varselet, den forhastede oppdateringen. Moderne RCA krever at hver «hvorfor» resulterer i en ansvarlig handling, tilordnet en kontroll og kryssreferert i SoA-en din.
Når man for eksempel graver under overflaten med de fem hvorfor-prinsippene, kommer verdien ikke frem i prosessen, men i hvor praktisk mulig hvert lag er – bidro et ressursgap, en dårlig overlevering eller en forsømt leverandørpolicy? Hvert funn bør peke på en forbedringseier, ikke bare den tekniske løsningen.
RCA er ikke ferdig før:
- Hvert «hvorfor» fører til prosess- eller kontrollløft: -en som er sporbar over tid.
- Ansvarsoppgaver er dokumentert: -eier tildelt, testet og integrert i neste onboarding-syklus eller leverandørgjennomgang.
- Bevis er synlige og refererte: -i SIEM-logger, revisjonsdashbord, policyrevisjoner eller artefakter fra omskolering av ansatte.
En underliggende årsak som ikke er knyttet til en eier og bevis på forbedring, er bare en teori i påvente av at den gjentar seg.
Integrasjonspunkter:
- Bland rettsmedisinske analyser: (SIEM/hendelseslogger), obduksjonsrapporter og inndata fra styret/ekstern CSIRT for å triangulere ikke bare «hva», men også «hvorfor».
- Oppdater SoA-en din: hver gang en ny rotårsak dokumenteres og lukkes.
- Inkluder styre- eller revisjonstilsyn: på enhver handling med omfattende innvirkning (policy, tredjepart, arkitekturendringer).
Klausuler knyttet til operasjonalisering:
| **Forventning** | **Operasjonalisering** | **Vedleggreferanse** |
|---|---|---|
| Identifiser den/de virkelige årsaken(e) | RCA-logg med tilordnet eier | ISO 27001:2022 6.1.2, tillegg A.5.25, A.8.8 |
| Unngå symptombaserte løsninger | Document gap analyse | 6.1.3, A.5.4, A.8.9, A.5.36 |
| Interessenter i løkken | Kort/CSIRT i RCA-syklus | 5.3, 5.4, A.5.5, A.5.24, A.8.25 |
| Handlingsplan/avslutning | SoA-oppdatering, kryssreferansetiltak | 6.1.3, 8.3, A.5.7, A.5.26 |
| Rettelser testet og loggført | Test på nytt med bevis lagt til | 9.1, 9.3.2, A.5.29, A.8.29 |
Når RCA brukes på denne resultatorienterte måten, blir det et omdreiningspunkt for kontinuerlig forbedring, ikke bare utbedring. La oss se hvordan vi kan flette disse handlingene inn i en evidensbasert, kontinuerlig evalueringssyklus.
Mestre NIS 2 uten regnearkkaos
Sentraliser risiko, hendelser, leverandører og bevis på én ren plattform.
Kartlegging, sporing og lukking av feilpunkter: Den levende revisjonssporingen
Resultatdrevne hendelsesgjennomganger må skape et «levende revisjonsspor » – en sammenføyet kjede som knytter sammen hendelsesdeteksjon, revisjonsspor, risikooppdatering, tiltak, ny testing og avslutning. Uten dette bindevevet vil revisjoner og regulatoriske gjennomganger alltid finne hull.
En kontroll eksisterer bare hvis du kan spore livssyklusen fra feil, via reparasjon til varig avslutning – og bevise det for andre.
Slik bygger du den gylne tråden:
1. Deteksjon og billettering: Hendelsen havner i SIEM; saken åpnes automatisk i systemet ditt.
2. RCA tilordnet: Eierloggfører de fem grunnprinsippene; funn deles med styret/CSIRT der det er nødvendig.
3. Oppdatering av risikoregister: Legg til eller oppdater risikooppføring (f.eks. «kritisk» senket etter kontrolløkning).
4. SoA-kryssreferanse: Det refereres til og flagges til kontroller som er involvert i SoA som under vurdering.
5. Korrigerende tiltak: Prosess eller kontroll endres, policy oppdateres, og ansatte omskoleres etter behov.
6. Planlagt ny test: Bevis på retting (logger, brukertester, leverandørbekreftelse) knyttet til opprinnelig hendelse.
7. Avslutning og godkjenning: Eier og leder/TDA/styre gjennomgår avslutning; logger og bevis arkiveres for samsvar og styrerapportering.
Sjekkliste for innebygd bevis:
- Før/etter SIEM-bevis
- Dokumentert oppdatering av risikovurdering
- Oppdatert SoA med kryssreferanse til hendelse
- Opplærings- eller kommunikasjonslogg (ansattbekreftelse)
- Styre- eller ledelsesgjennomgang av oppføringer for store/kritiske hendelser
- Verifisering av automatisk lukking (testkjøring viser at kontrollen nå fungerer)
Gjør du det riktig, vil denne «levende» gjennomgangen synliggjøre tilbakevendende problemer, støtte ledelsens gjennomgang og gi et robust grunnlag for revisjonsteam som er klare til å teste samsvar når som helst.
Gjør kontrollløft robust, synlig og styrtgodkjent
Styrer og ekstern revisor ser i økende grad forbi «oppdater og lukk»-syklusen. De vil vite: Ble riktig eier tildelt? Vedvarte forbedringen? Gjenbrukes denne lærdommen i fremtidig onboarding, leverandørkontrakter eller prosessdesign?
Motstandskraft er en kjede av handlinger som er synlige for ansatte og eiere, og som er styrtdokumenterte, dokumenterte og klare til å tåle utskiftning eller gransking.
Slik gjør du det:
- Knytt enhver forbedring til en tydelig eier.: Ikke mer «laginnsats» som fjerner ansvaret.
- Oppdater SoA og all prosessdokumentasjon: En løsning er ikke bare et endret passord eller en ny aktivert regel; det er en fullstendig prosessvalidering, der ansatte blir varslet, opplært på nytt og bekrefter forståelse.
- Test på nytt etter forbedring, ikke bare etter hendelsen. Etterkontroller som ikke er verifisert gjennom nye data, ansatte eller ekstern tilsyn fra det røde teamet, er ufullstendige.
- Arkiver bevisene – og oppdater kunnskapsbasene.: Kontroller, prosessdokumentasjon, onboarding og veiledninger for lærdommer må inneholde forbedringen, ikke bare hendelsen.
Brotabell – Operasjonalisering av kontrollløft:
| **Avtrekker** | **Operasjonalisering** | **ISO 27001/Vedlegg A-referanse** |
|---|---|---|
| Gap i onboarding av leverandører | Leverandørgjennomgangsprosess revidert, godkjenning lagt til | A.5.19, 5.1.2, 6.2 |
| Oversikt over oppdateringshåndtering | Automatisert oppdatering, ny testing, RCA og SoA-kryssreferanse | 8.8, 8.29, 6.1.3 |
| Manglende overholdelse av UD-regler | MFA rullet ut, testet, ansatte omskolert | A.5.17, 8.5, 8.18 |
| Kun passordfrase-autentisering | Retningslinjer oppdatert, opplæring bekreftet, SIEM-testet | A.8.32, 6.3, 8.24 |
Bevisene som er arkivert i denne oppdateringen – skjermbilder, loggforespørsler, kvitteringer for mottak, leverandørsignaturer – er bevis for fremtidige revisjoner, onboarding eller leverandørvurderinger.
Vær NIS 2-klar fra dag én
Lanser med et velprøvd arbeidsområde og maler – bare skreddersy, tildel og gå.
Slik beviser du løsningen: Test bevis som revisjoner og styrer stoler på på nytt
En løsning har ingen vekt hvis du ikke kan bekrefte den – helst «i praksis». Kriteriet er ikke intern tilfredshet, men gransking av et styre eller en ekstern revisor som sjekker for bevis på forbedring ( isms.online ).
En lærdom fortjener å bli husket – uten å måtte oppfinne bevisene på nytt ved hver revisjon.
Viktig informasjon om bevispakken:
- Signert avslutning: Eier, leder, og for større arrangementer, styre- eller TDA-godkjenning.
- Før-og-etter-tilstand: Skjermbilde eller loggdata som viser endringen, bestått/ikke bestått test eller policyen før/etter redigeringer.
- Test loggene på nytt: Scenariegjennomganger, rettsmedisinsk bekreftelse, penetrasjonstesting eller ekstern CSIRT-gjennomgang for betydelige hull.
- Bekreftelse av ansatte: Bekreftelse på omtrent arbeidsflyt eller prosedyre (opplæringsdashbord, lesekvittering for policy, quizresultater).
- Logger for åpne elementer: Synlighet i forbedringer er ikke bekreftet ennå eller fortsatt underveis.
Selv negative bevis – åpne eller forsinkede saker – bør avdekkes og flagges. Styrer og forsikringsselskaper verdsetter åpenhet og bevis på forbedringer som er i gang like mye som fullførte nedleggelser.
Pakk opp anmeldelsen din med eksporterbare eller rapportklare bevis – aldri stress med å rekonstruere historien i etterkant.
Sporbarhet i sanntid: Gjør hver oppdatering revisjonsklar
NIS 2-samsvar er et kappløp mot ugjennomsiktighet; hver kontroll, forbedring og gjennomgang må kunne spores i sanntid fra den første hendelsen til avslutningen. Gjør du det riktig, er du ikke bare forberedt på revisjoner, men også klar for styretilsyn og forsikringsvurdering.
Sporbarhetsminibord:
| **Avtrekker** | **Risikooppdatering** | **Kontroll-/SoA-kobling** | **Bevis registrert** |
|---|---|---|---|
| Legitimasjonstyveri | Kritisk → Moderat | A.5.17; MFA/SIEM oppdatert | MFA-logger, eierbekreftelse, SIEM etter testing |
| Leverandørbrudd | Ny leverandørrisiko | A.5.19; Onboarding av tredjepart | Leverandørrevisjonsdokumenter, policyoppdatering, CISO-godkjenning |
| Nulldagsutnyttelse | Lukket innleggspatch | A.8.8, 8.29; Oppdateringshåndtering | Bevis for lapp, test etter lapp, lukkingsdato |
| Treningsgap | Middels → Lav | A.6.3; Opplæringsmodul | Treningslogger, quiz-pass, bekreftelse fra ansatte |
Sanntidsdashboards viser ikke bare passivt informasjon: de fungerer som levende bevis som viser hvem som eier hver risiko, løsning eller sak, og hvor i syklusen handlingen befinner seg – fra åpen, til under behandling, til fullført.
Et robust ISMS lar ethvert styremedlem eller regulator spørre: «Hva skjedde? Hvem godkjente det? Hvor er beviset?» – og få et svar umiddelbart.
Alle dine NIS 2, alt på ett sted
Fra artikkel 20–23 til revisjonsplaner – kjør og bevis samsvar, fra ende til ende.
Demonstrere kontinuerlig forbedring: Fra revisjonsforsvar til modenhetsmodus
Kontinuerlig forbedring under NIS 2 måles og bevises, ikke kunngjøres. Styrer og regulatorer forventer kvartalsvise eller halvårlige pakker som viser synkende risikogjentakelse, forbedret tid til avslutning og økende eierskapssigneringsgrad. Forsikringsleverandører og investorer knytter i økende grad dekning, prising og tillit til dette beviset.
Forbedringstaktikker:
- Planlegg kvartalsvise evalueringer: Risikokart, hendelsesloggerog prestasjoner innen opplæring av ansatte.
- Rapporter trendlinjer: Vis målbar reduksjon av tilbakefall, raskere avslutning, økning i konsekvent omskolering.
- Integrer læring i onboarding: Enhver større lærdom eller oppgradering blir standard for nye ansatte, leverandører eller programvareutrullinger.
- Styre-/ledelse-dashbord: Vis live «åpne hendelser», «forbedring pågår» og «avslutning validert» etter risikonivå og eier.
Integrer denne systematiske forbedringen i ISMS-systemet ditt, ikke som et tillegg, men som en førsteklasses driftsmodul. Bruk styrepakker, gjennomgangssykluser og transparente dashbord for å bevise, iterere og modne hvert kvartal.
Ditt neste steg: Gjør hendelsesgjennomgangene dine om til kapital for robusthet
Momentum bygger seg opp når hendelsesgjennomganger fremmer forbedringer – en forbedring som styret, revisoren, forsikringsselskapet og til slutt teamet ditt alle stoler på. Med ISMS.online slår arbeidsflytene dine sammen dokumentert RCA, synlig kontrolløkning, loggført omskolering og eksportklare revisjonspakker i én kontinuerlig forbedringsmotor.
Du trenger ikke å slite med usammenhengende regneark eller utdaterte godkjenningskjeder for å komme dit. Start med en RCA-mal, gå gjennom en kartlagt forbedring, eller forhåndsvis et sanntidsdashbord – hvert resultat er knyttet tilbake til robusthet organisasjonen din kan bevise og opprettholde.
Nå er det på tide å forvandle evaluering etter hendelser fra ansvar til påvirkningskraft. Gjør hver hendelse til et bevispunkt for fremtiden, ikke en fotnote til fortiden.
Ofte Stilte Spørsmål
Hva er de mest effektive metodene for rotårsaksanalyse i en NIS 2-gjennomgang etter hendelser?
Rotårsaksanalyse under NIS 2 er mest effektiv når du blander teknisk etterforskning (SIEM/gjennomgang av hendelseslogg, endepunktdata, leverandør-/veispor) med strukturerte, transparente resonnementsrammeverk som Five Whys eller Fishbone (Ishikawa)-diagrammer – anerkjent av ENISA og ISACA for sin evne til å bevege seg utover symptomer til underliggende feil. Dette betyr å starte med å rekonstruere tidslinjer fra logger, billetter og hendelsesvarsler, og deretter systematisk utfordre hver overfladiske forklaring til du avslører den «begravde antagelsen eller den ødelagte overleveringen» som gjorde bruddet mulig. For eksempel kan en ransomware-hendelse sporet til utdaterte VPN-legitimasjon til slutt avsløre brudd i legitimasjonsstyring, tilsyn med forsyningskjeden eller opplæring.
Tverrfaglige intervjuer er avgjørende for å avdekke prosedyremessige, kulturelle eller leverandørproblemer som logger alene ikke vil avsløre. Involver drift, IT, juridiske og kritiske leverandører; hver av dem kan ha kontekst for beslutninger, overleveringer eller blindsoner som andre ikke har. NIS 2 forventer også deltakelse fra kolleger, tredjeparter eller til og med regulatorer i RCA etter hendelser for hendelser med stor innvirkning.
Bevist RCA-flyt
- Samlede logger og billettdata: (SIEM, endepunkter, leverandørvarsler)
- Bruk strukturert spørsmålsstilling: (Fem hvorfor, Fishbone, tidslinjekartlegging)
- Intervju alle parter i eskaleringsprosessen: – ikke bare IT
- Loggfunn og bevis: , kartlagt direkte til risikoregister oppføringer og kontroller
- Utløs uavhengig/fagfellevurdering: for betydelige hendelser
Ethvert brudd er til syvende og sist et resultat av ubestridte antagelser. Du oppdager den virkelige årsaken når du spør utover det åpenbare.
Hvordan skal bevis dokumenteres og versjoneres etter en hendelse i henhold til NIS 2?
NIS 2 krever at organisasjoner opprettholder en versjonert, sporbar og revisjonsklar dokumentpakke for hver betydelig hendelse – en pakke som ikke bare beskriver den tekniske tidslinjen, men også beviser prosedyremessig respons, eieransvar og læring. Dokumentasjonen må inkludere:
- Rå logger, varsler, varsler: (SIEM, endepunkt, forsyningskjede)
- RCA-artefakter: (rammeverksresultater, intervjulogger, diagrammer)
- Logger for korrigerende tiltak: -kobling av hvert utbedringstrinn til et hendelsesfunn
- Direkte kartlegging: av hver artefakt til den relevante NIS 2-klausulen/artikkelen og ISO 27001-kontrollen (f.eks. A.5.24, A.5.25, A.8.8)
- Versjonsbasert lagring: (med tilgang, avlogging og endringslogger)
Beste praksis er å opprettholde en live samsvarskartleggingsmatrise – som tilordner hver artefakt til roller, tidslinjer for eierskap, relatert policy og risiko. ISMS.online automatiserer for eksempel denne kartleggingen, slik at du kan hente fullstendig bevis per hendelse, kontroll eller eier når som helst (ISMS.online, 2024). Enhver manglende begrunnelse, godkjenning eller ukoblet artefakt øker risikoen for langvarige regulatorforespørsler.
Øyeblikksbilde av sporbarhet av bevis
| Bevistype | Eksempel på gjenstand | Klausuler / Kontroller | Eier / Dato |
|---|---|---|---|
| Gjenkjenning | SIEM-logg, varselbillett | NIS 2 Art. 23, A.5.24 | Sek. avledning/X/X |
| RCA | Fishbone, hvorfor-analyse | Art. 27, A.5.25 | CISO/Å/Å |
| Utbedring | Oppdatering av retningslinjer, ny konfigurasjon | Art. 21, A.8.5 | Operasjoner/Z/Z |
| Ny testing/avslutning | Pentest, SoA-oppdatering | Art. 21, A.8.8 | Revisjon/V/V |
Hva gjør kontrolloppgraderinger og nye tester «revisjonsklare» for NIS 2 og ISO 27001?
En kontrolløkning blir virkelig «revisjonsklar» bare når hele forbedringssyklusen – fra reparasjon til ny testing og godkjenning av styring – er dokumentert, tidsstemplet og sporbar til den underliggende risikoen. Dette betyr at du må:
- Fang en registrering av endringer (f.eks. oppdaterte retningslinjer, systemkonfigurasjon eller leverandørkontrakt) sammen med utløseren som rettferdiggjorde det.
- Koble endringen direkte til risikoregisteret og riktig SoA/kontrollreferanse (f.eks. A.8.5 Multifaktorautentisering).
- Dokument aggressiv ny testing– enten via manuell sjekk, automatisk skanning eller øvelse med rødt lag – med resultater vedlagt.
- Inkluder eksplisitt eierskap og godkjenning fra både teknisk og styrings-/styrelag.
- Sørg for at bevis er versjonert, tilgangskontrollert og koblet til policy-/opplæringsoppdateringer etter behov.
Styrer og regulatorer ber i økende grad om å se hele «før og etter»-kjeden, inkludert opplæring av ansatte eller onboarding-journaler når prosedyrer endres.
Revisjonsklar forbedringskjede
| Avtrekker | Risikooppdatering | SoA-referanse | Testbevis på nytt | Styre/eier |
|---|---|---|---|---|
| Phishing oppdaget | Risiko 4→2, lavere | A.8.5 | Rødt lags pasning | IT-sjef, styret |
| Brudd på forsyningskjeden | Leverandørstatus opp | A.5.19 | Tredjepartsrapport | Ops, styre |
Hvordan sikrer du at lærdommene faktisk endrer atferd etter en hendelse?
En lærdom «lander» bare hvis den oversettes for forskjellige målgrupper, tildeles navngitte eiere og forsterkes gjennom målrettet kommunikasjon og regelmessig testing. Dette betyr:
- Oppsummerende funn: i sjargongfrie notater fra ledere og nyhetsbrev til alle ansatte (ikke bare teknisk dokumentasjon)
- Oppdatering av onboarding og kontinuerlig opplæring: , med sporing slik at alle ansatte eller leverandører med en rolle ser og bekrefter nye krav
- Tildeling og sporing av handlingseiere og tidsfrister: i risikoregister eller dashbord
- Automatisere påminnelser og periodiske øvelser: (f.eks. kvartalsvise phishing-tester eller tilgangsgjennomganger)
- Rapporteringsmålinger: til tavlen som viser ikke bare «fullførte», men «vedtatte» endringer (NCES, 2023)
Ekte forbedringer skjer bare når handlinger flyttes fra arket – til kalenderen, arbeidsflyten for de ansatte og samtalene i styrerommet.
Hva er de største fallgruvene etter bevis og gjennomgang av hendelser som bør unngås for å overholde NIS 2-kravene?
Vanlige feilpunkter kan undergrave forsvaret ditt og tilliten til revisorer:
- Blindsoner på grunn av ufullstendig hogst: (spesielt med leverandører eller skyen).
- Behandling av symptomer, ikke årsaker: -oppdatering av apper, men ignorering av prosess-/styrings- eller forsyningskjederisiko.
- Hoppe over nye tester: eller bare dokumentere «løsningen» uten bevis for at den fungerer.
- La risikoregistre eller erklæringer om anvendelighet være foreldet: etter en gjennomgang.
- Sporbarhetshull: -ingen bindevev fra deteksjon til avslutning, spesielt på tvers av flere team eller leverandører.
- Silobasert bevis eller godkjenning: -manglende tverrfunksjonell validering, f.eks. styring, styre eller deltakelse fra uavhengige testere.
- Forsømmelse av oppdatert opplæring av ansatte eller leverandører: etter at kontrollene endres.
- Uklart eierskap eller manglende versjonshistorikk: for bevispakker.
Enhver av disse fører til gjentatte henvendelser fra regulatorer, lengre revisjonssykluser eller til slutt tap av kundetillit.
Hvordan effektiviserer ISMS.online hendelsesgjennomgang, kontrollforbedring og bevisrevisjon for NIS 2?
ISMS.online kobler sammen hvert trinn i NIS 2-hendelsens livssyklus – deteksjon, RCA, forbedring, retesting, bevis og opplæring – i én enkelt, versjonert revisjonskjede . Plattformen lar teamet ditt:
- Tilordne og loggføre hver hendelsessak til en rotårsaksanalyse (Hvorfor, Fishbone), korrigerende tiltak og ny testing
- Knytt bevis til spesifikke NIS 2-klausuler, ISO 27001-kontroller og policyartefakter («tilknyttet arbeid»)
- Oppdater erklæringer om anvendelighet, risikoregistre og personal-/kommunikasjonsregistre automatisk etter hvert som kontrollene endres
- Krev, spor og rapporter bekreftelser på opplæring av ansatte/leverandørerlukker sløyfen for styring og regulatorer
- Eksporter regulatorklare bevispakker – med innebygde endrings- og tilgangslogger og full sporbarhet ((https://no.isms.online/platform/features/linked-work/))
Med et live-dashbord og automatiserte påminnelser er alle forbedringer synlige, fra hendelsesrapport via risikooppdatering til styrepresentasjon – uten at noe går tapt mellom trinnene.
Veien fra hendelse til forbedring er bare ett klikk unna, og din neste revisjon er klar før spørsmålet i det hele tatt er stilt.
ISO 27001 / NIS 2 operasjonell brotabell
| Forventning | Hvordan levert | Artikkel/Klausul |
|---|---|---|
| Årsaksanalyse | Tidslinje, hvorfor/fiskebein, teamintervjuer | NIS 2 Art.23/27, A.5.25 |
| Versjonsbasert bevispakke | Kjede: logger→RCA→fiks→test+godkjenning, kartlagt | NIS 2 Art.27/35, A.5.35 |
| Kontrollforbedring | Retting med ny testing, SoA/risikooppdatering, signering | NIS 2 Art.21, A.8.8 |
| Sporbarhet | ISMS.online «Tilknyttet arbeid»-dashbord | NIS 2, ISO 27001 |
Eksempel på sporbarhetstabell
| Avtrekker | Risikooppdatering | Kontroll / Referanse | bevis |
|---|---|---|---|
| Brudd på legitimasjon | Risiko 3→2 lavere | A.8.5 | Penntest, opplæringskvittering |
| Leverandørens nedetid | Leverandør flagget | A.5.19, NIS2 Art21 | Leverandørrevisjon, dashbord |
Ved å integrere bevis, prosesser og ansvarlighet i ett system, forvandler ISMS.online din NIS 2-respons fra compliance-papirarbeid til en levende robusthetsstrategi – målbar, repeterbar og klar for enhver utfordring.
