ISO 27001-evidens for logning til NIS2, DORA og GDPR

Alarmen landede i SOC-kanalen kl. 2:17 en tirsdag morgen: flere mislykkede loginforsøg for den privilegerede bruger admin fra en ny IP-adresse. Forsøgene stoppede efter få minutter. En junioranalytiker noterede alarmen, antog at den skyldtes et fejlkonfigureret script eller en systemadministrator, der arbejdede sent, og gik videre.

To dage senere sad Maria, informationssikkerhedschef (CISO) i en hurtigt voksende fintechvirksomhed, i et ledelsesmøde, da hendes telefon vibrerede. Engineering havde konstateret usædvanligt høj CPU-belastning på en produktionsdatabaseinstans. En ny uautoriseret brugerkonto var blevet oprettet. Alarmen kl. 2:17 var ikke en falsk positiv. Den var det første synlige tegn på et indtrængningsforsøg.

Hændelsen blev inddæmmet, men undersøgelsen afdækkede et større problem. Firewalllogfiler lå i ét system. Kubernetes-logfiler lå i et andet. Databasens revisionslogfiler blev opbevaret særskilt. Flere tidsstempler var ude af synkronisering med flere minutter. Teamet havde data, men kunne ikke hurtigt levere en forsvarlig redegørelse for detektion, gennemgang, eskalering, inddæmning og vurdering af brud.

Marias ISO/IEC 27001:2022-overvågningsrevision var afsluttet uden afvigelser, men revisoren efterlod én advarsel: Organisationen havde kontroller for logning og overvågning, men ville få svært ved rettidigt at fremlægge korreleret evidens til rapporteringsbeslutninger efter NIS2, DORA og GDPR.

Det er den virkelighed, mange organisationer står i i 2026. De har ikke et logningsproblem. De har et evidensproblem.

En SIEM, EDR-platform, cloudbaseret auditlog eller firewalllog er ikke i sig selv revisionsklar evidens. Evidens bliver først forsvarlig, når den er underlagt politik, beskyttet mod manipulation, gennemgået med en fast kadence, knyttet til hændelsesbeslutninger og opbevaret længe nok til at rekonstruere hændelsesforløb.

For ISO/IEC 27001:2022, NIS2, DORA og GDPR er nøglespørgsmålet ikke længere: “Indsamler vi logfiler?” Spørgsmålet er: “Kan vi dokumentere, hvad der skete, hvem der gennemgik det, hvordan det blev klassificeret, om rapportering var påkrævet, og om ledelsen førte tilsyn?”

Hvorfor logning og overvågning er blevet et spørgsmål om compliance-evidens

NIS2, DORA og GDPR har ændret sikkerhedslogfilers forretningsmæssige betydning.

Efter NIS2 skal væsentlige og vigtige enheder implementere passende og proportionale foranstaltninger til styring af cybersikkerhedsrisici. Article 21 omfatter hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, effektivitetsvurdering, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver, MFA og sikker kommunikation. Article 23 etablerer en trinvis rapporteringsmodel, herunder en tidlig advarsel inden for 24 timer, hændelsesunderretning inden for 72 timer, mellemliggende opdateringer hvor relevant og en slutrapport senest én måned efter hændelsesunderretningen.

Den model afhænger af logning og overvågning. Man kan ikke sende en troværdig tidlig advarsel, hvis man ikke kan dokumentere, hvornår hændelsen blev detekteret. Man kan ikke klassificere en væsentlig hændelse, hvis man ikke kan rekonstruere berørte systemer, brugeraktivitet, påvirkning af tjenester og inddæmningshandlinger.

DORA lægger et tilsvarende pres på finansielle enheder. Articles 5 to 14 fastlægger forventninger til governance og styring af IKT-risiko, herunder ledelsesorganets ansvar, identifikation af IKT-aktiver, beskyttelse og forebyggelse, detektion, respons og genopretning, backup, gendannelse, læring og kommunikation. Articles 17 to 23 kræver en proces for håndtering af IKT-relaterede hændelser, der omfatter detektion, registrering, klassificering, eskalering, underretning og opfølgning. Articles 24 to 27 omhandler test af digital operationel robusthed. Articles 28 to 31 etablerer forpligtelser vedrørende styring af IKT-tredjepartsrisici.

GDPR tilføjer ansvarlighedslaget inden for databeskyttelse. Article 32 kræver passende behandlingssikkerhed. Article 33 kræver underretning om brud på persondatasikkerheden til tilsynsmyndigheden uden unødig forsinkelse og, hvor det er muligt, senest 72 timer efter at være blevet bekendt med bruddet, medmindre bruddet sandsynligvis ikke indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Article 34 kan kræve underretning af berørte registrerede, når risikoen er høj. Logfiler bidrager til at fastslå, om personoplysninger er blevet tilgået, ændret, eksfiltreret eller eksponeret, men logfiler kan også selv indeholde personoplysninger og skal derfor styres tilsvarende.

ISO/IEC 27001:2022 leverer rygraden i ledelsessystemet. Clauses 4.1 to 4.4 kræver, at organisationen forstår sin kontekst, interessenter, krav og ISMS-omfang. Clauses 5.1 to 5.3 kræver lederskab, sammenhæng med politikker, roller, ansvar og beføjelser. Clauses 6.1.1 to 6.1.3 kræver en gentagelig proces for risikovurdering og risikobehandling, herunder risikokriterier, risikoejere, behandlingsmuligheder, sammenligning med Annex A-kontroller, anvendelseserklæring og accept af restrisiko. Clause 6.2 kræver målbare informationssikkerhedsmål.

Derfor kan evidens for logning og overvågning ikke kun ligge i SOC. Den hører hjemme i ISMS, risikoregisteret, anvendelseserklæringen, hændelseshåndteringsprocessen, arbejdsgangen for brud på persondatasikkerheden, leverandørstyringen og ledelsesrapporteringen.

De ISO 27001-logningskontroller, revisorer først kobler sammen

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandler fasen Controls in Action, Step 19: Technological Controls I, logning, overvågning og synkronisering af systemtid som én evidenskæde.

A.8.15 – Logning: “Logfiler, der registrerer aktiviteter, undtagelser, fejl og andre relevante hændelser,
bør produceres, opbevares, beskyttes og analyseres.”

A.8.16 – Overvågningsaktiviteter: “Netværk, systemer og applikationer bør overvåges for
anomal adfærd, og passende handlinger bør iværksættes for at evaluere potentielle informationssikkerhedshændelser”

A.8.17 – Synkronisering af systemtid: “Urene i informationsbehandlingssystemer, som anvendes af
organisationen, bør synkroniseres til godkendte tidskilder.”

Disse kontroller besvarer tre revisionsspørgsmål:

Zenith Controls: The Cross-Compliance Guide Zenith Controls gør sammenhængen eksplicit:

“Logning fungerer som det grundlæggende datalag for overvågning. Control 8.16 afhænger af de logfiler, der genereres under 8.15, for at analysere sikkerhedshændelser, detektere anomalier og identificere potentielle brud. Uden omfattende logning er overvågningssystemer ineffektive.”

Zenith Controls klassificerer ISO/IEC 27002:2022-kontrol 8.15, Logning, som en detekterende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den kortlægges til cybersikkerhedskonceptet Detect og styring af informationssikkerhedshændelser. Den forbinder også Logning med Overvågningsaktiviteter, Vurdering og beslutning om informationssikkerhedshændelser samt Synkronisering af systemtid.

For kontrol 8.16, Overvågningsaktiviteter, klassificerer Zenith Controls den som detekterende og korrigerende, kortlagt til Detect og Respond. Den forbinder overvågning med overvågning af leverandørtjenester og hændelsesvurdering, hvilket er afgørende for cloud-, SaaS-, managed service- og outsourcingmiljøer.

Det praktiske budskab er enkelt. Logfiler leverer fakta. Overvågning identificerer anomalier. Synkronisering af systemtid gør fakta pålidelige på tværs af systemer. Hændelsesvurdering omsætter alarmer til beslutninger.

Hvordan revisionsklar logningsevidens faktisk ser ud

Revisionsklar evidens er ikke en mappe med skærmbilleder. Det er et sammenhængende revisionsspor, der dokumenterer kontroldesign, kontroludførelse og beslutningstagning.

En moden evidensfil for logning og overvågning indeholder typisk følgende:

Clarysecs Enterprise Lognings- og overvågningspolitik Lognings- og overvågningspolitik rammesætter dette direkte:

“Denne politik er afgørende for at understøtte ISO/IEC 27001 Clause 8.1 og Annex A Controls 8.15 (Logging), 8.16 (Monitoring) og 8.17 (Clock Synchronization) og er direkte kortlagt til regulatoriske forpligtelser under GDPR, NIS2, DORA og COBIT 2019.”

Fra afsnittet “Formål”, politikklausul 1.3.

Den samme politik fastsætter den operationelle forventning:

“Etabler centraliserede lognings- og alarmeringssystemer (f.eks. SIEM) til at aggregere, korrelere og eskalere mistænkelig aktivitet nær realtid.”

Fra afsnittet “Mål”, politikklausul 3.4.

For mindre organisationer omsætter Clarysecs SME Logging and Monitoring Policy-sme Lognings- og overvågningspolitik - SME det samme princip til proportionale krav:

“IT-supportleverandøren skal definere og følge en fast plan for gennemgang af logfiler:”

Fra afsnittet “Styringskrav”, politikklausul 5.1.1.

Den definerer også opbevaring og beskyttelse:

“Logfiler skal opbevares i mindst 12 måneder, medmindre en længere opbevaringsperiode kræves efter lov eller kontrakt eller er begrundet som led i en aktiv hændelse eller retlig tvist.”

Fra afsnittet “Styringskrav”, politikklausul 5.2.1.

“Logfiler skal opbevares på skrivebeskyttede placeringer, og adgang skal begrænses til godkendt personale alene”

Fra afsnittet “Styringskrav”, politikklausul 5.3.1.

For NIS2 og DORA kan en 12-måneders baseline for evidens være forskellen mellem troværdig rekonstruktion og en mislykket undersøgelse. For GDPR understøtter den ansvarlighed, samtidig med at den fortsat kræver dataminimering, adgangsstyring og disciplineret opbevaring.

Den manglende bro: hændelsesvurdering og rapporteringstærskler

Mange organisationer indsamler logfiler og alarmerer på anomalier, men fejler i beslutningspunktet.

Var alarmen kun en sikkerhedshændelse, eller blev den til en informationssikkerhedshændelse? Var den væsentlig efter NIS2? Var den en større IKT-relateret hændelse efter DORA? Var personoplysninger involveret? Kræves der analyse af underretningspligt ved brud efter GDPR?

Dette beslutningspunkt kortlægges til ISO/IEC 27002:2022-kontrol 5.25, Vurdering og beslutning om informationssikkerhedshændelser. Zenith Controls beskriver 5.25 som triagefunktionen mellem rå overvågningsalarmer og formel hændelseshåndtering. Den forbinder 5.25 med planlægning af hændelsesstyring, overvågningsaktiviteter, respons på informationssikkerhedshændelser og logning. Den kortlægger også 5.25 til GDPR Articles 33 and 34 for underretning om brud og risikoevaluering, NIS2-hændelsesunderretning og klassificeringskriterier samt DORA-klassificering af større IKT-relaterede hændelser.

Clarysecs Politik for hændelseshåndtering Politik for hændelseshåndtering understøtter dette eskaleringspunkt:

“Hvis en hændelse medfører bekræftet eller sandsynlig eksponering af personoplysninger eller andre regulerede data, skal juridisk afdeling og DPO vurdere anvendeligheden af:”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

For SMV’er fastsætter Incident Response Policy-sme Politik for hændelseshåndtering - SME det tekniske evidenskrav:

“Logningssystemer skal konfigureres til at registrere tilstrækkelige detaljer til at understøtte undersøgelsen.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

Det er her, GDPR Article 33 bliver operationel. Spørgsmålet er ikke kun, om personoplysninger blev tilgået. Spørgsmålet er, om logfiler, overvågningsalarmer og hændelsesregistreringer gør det muligt for DPO’en at foretage en rettidig og forsvarlig brudvurdering.

NIS2 Article 23 og DORA Articles 17 to 23 skaber et tilsvarende pres. Rapporteringsfrister afhænger af kendskab, klassificering og væsentlighedsvurdering. Organisationen skal kunne dokumentere, hvornår alarmen blev genereret, hvornår den blev gennemgået, hvem der vurderede den, hvilken beslutning der blev truffet, og hvornår eskalering fandt sted.

En 60-minutters evidensøvelse for undersøgelse af privilegeret login

En nyttig måde at teste evidensberedskab på er at gennemspille et realistisk scenarie før revisionen eller hændelsen.

Scenarie: En privilegeret administratorkonto logger ind fra et usædvanligt land kl. 02:13 UTC. Fem minutter senere forsøger kontoen at tilgå en eksportfunktion for kundedata. Betinget adgang blokerer sessionen, og der genereres en alarm.

Mål: På 60 minutter skal der udarbejdes en evidenspakke, der dokumenterer detektion, gennemgang, eskalering, vurdering og lukning.

Trin 1: Bekræft, at hændelsen findes i logfiler

Brug Lognings- og overvågningspolitik til at identificere krævede logkilder: logfiler fra identitetsudbydere, cloud-adminlogfiler, applikationslogfiler, databaselogfiler, endpoint-logfiler og firewall- eller sikre adgangslogfiler.

Eksportér hændelsesregistreringen med tidsstempel, bruger-ID, kilde-IP, enhed, handling, resultat og korrelations-ID. Hvis hændelsen kun findes i én konsol og ikke i SIEM eller logindsamleren, skal det registreres som en kontrolmangel.

Zenith Blueprint Step 19 anbefaler at sikre, at kritiske systemer videresender logfiler til SIEM eller en central logindsamler, og at validere, at opbevaringen er i overensstemmelse med politikken.

Trin 2: Dokumentér, at overvågningen detekterede den

Vis SIEM-alarmen, EDR-alarmen eller alarmen fra identitetsbeskyttelse. Medtag regelnavn, alvorlighed, tidsstempel, udløsende betingelse og underretningskanal. Hvis organisationen anvender manuel gennemgang, skal den daglige rapport og godkendelsen af gennemgangen vises.

Enterprise Lognings- og overvågningspolitik gør dette til et rolleansvar:

“Gennemgår daglige rapporter og sikrer, at anomalier analyseres, dokumenteres og eskaleres efter behov.”

Fra afsnittet “Roller og ansvar”, politikklausul 4.2.3.

Trin 3: Dokumentér, at eskalering skete inden for politikken

For SMV’er er eskaleringskravet eksplicit:

“Højprioritetsalarmer skal eskaleres til direktøren (GM) og databeskyttelseskoordinatoren inden for 24 timer”

Fra afsnittet “Håndhævelse og efterlevelse”, politikklausul 8.1.2.

For enterprise-teams kan evidensen omfatte en hændelsesticket, Teams- eller Slack-eskaleringsregistrering, paginglog, e-mailunderretning, SOC-overdragelsesnote eller sagsstyringsregistrering.

Trin 4: Klassificér hændelsen

Brug hændelsesvurderingslogikken for 5.25 fra Zenith Controls. Registrér, om alarmen er en sikkerhedshændelse, en informationssikkerhedshændelse, et brud på persondatasikkerheden, en væsentlig NIS2-hændelse eller en større IKT-relateret DORA-hændelse.

Klassificeringsnotatet bør besvare:

• Var autentifikation vellykket eller blokeret?
• Blev privilegeret adgang anvendt?
• Blev kundedata tilgået, ændret eller eksfiltreret?
• Blev regulerede tjenester forstyrret?
• Blev kritiske IKT-aktiver påvirket?
• Er leverandører eller databehandlere involveret?
• Opfylder hændelsen interne rapporteringstærskler?
• Kræves der underretning af DPO, juridisk afdeling, tilsynsmyndighed eller kunde?

Trin 5: Opbyg en betroet tidslinje

Synkronisering af systemtid ignoreres ofte, indtil en undersøgelse fejler. Zenith Blueprint Step 19 fastslår, at synkroniseret tid er afgørende for hændelseskorrelation, fordi logfiler fra forskellige systemer skal kunne sammenstilles under hændelsesanalyse.

Medtag NTP-konfigurationsevidens for identitetsplatforme, cloudtjenester, servere, endpoints, databaser, firewalls og SIEM. Normalisér tidsstempler til UTC, hvor det er muligt.

Trin 6: Luk eller eskalér

Hvis hændelsen er inddæmmet, og der ikke blev tilgået data, skal lukning, erfaringer og forebyggende handling dokumenteres. Hvis den bliver til en hændelse, skal den knyttes til hændelseshåndtering, juridisk gennemgang og eventuelle rapporteringsarbejdsgange efter NIS2, DORA eller GDPR.

Til sidst skal evidensen beskyttes. Clarysecs Audit and Compliance Monitoring Policy Politik for revisions- og efterlevelsesovervågning fastslår:

“Alle revisionslogfiler, konstateringer og afhjælpningsrapporter skal opbevares, krypteres og beskyttes mod manipulation.”

Fra afsnittet “Håndhævelse og efterlevelse”, politikklausul 8.5.1.

Denne ene øvelse giver evidens for Annex A.8.15, A.8.16, A.8.17, ISO/IEC 27002:2022-kontrol 5.25, GDPR-ansvarlighed ved brud, NIS2-hændelseshåndtering og DORA-klassificering af IKT-hændelser.

Evidenskort på tværs af ISO 27001, NIS2, DORA og GDPR

De stærkeste complianceprogrammer opbygger ikke separate evidenssæt for hvert framework. De opbygger ét evidenssystem, som kan ses gennem flere revisionslinser.

NIST Cybersecurity Framework 2.0 kan hjælpe med at operationalisere dette som et kommunikationslag. Dets seks Functions, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER, viser, at logning og overvågning primært ligger i DETECT og RESPOND, men afhænger af styring, forståelse af aktiver og risikoprioriteter.

NIST CSF 2.0 Profiles kan også understøtte en køreplan for 2026. En Current Profile kan vise den aktuelle logningsdækning og alarmmodenhed. En Target Profile kan definere krævet dækning for regulerede systemer, privilegeret aktivitet, leverandørplatforme og miljøer med personoplysninger. Gabet mellem dem bliver afhjælpningsplanen.

Leverandør- og cloudlogfiler: evidenshullet, som revisorer i stigende grad tester

I moderne revisioner vedrører de vanskeligste logningsspørgsmål ofte outsourcede platforme.

Kan I få adgang til autentifikationslogfiler fra jeres cloududbyder? Logges SaaS-administrationshandlinger? Er databaserevisionslogfiler aktiveret i administrerede tjenester? Opbevarer jeres MSSP alarmer længe nok? Kræver kontrakter samarbejde ved hændelser? Kan leverandører levere logfiler hurtigt nok til NIS2- eller DORA-rapporteringsfrister? Er databehandlerlogfiler tilgængelige til vurdering af brud efter GDPR?

Zenith Controls forbinder Overvågningsaktiviteter, kontrol 8.16, med Overvågning af leverandørtjenester, kontrol 5.22. Den kortlægger også overvågning til ISO/IEC 27005:2024 clause 10.5, som fremhæver overvågning og gennemgang af risikobehandlingsplaner og kontroller, samt ISO/IEC 27035-2:2023 clause 7.3, hvor mekanismer til løbende overvågning detekterer informationssikkerhedshændelser og udløser hændelsesstyring.

DORA gør leverandørlogning særligt vigtig for finansielle enheder, fordi styring af IKT-tredjepartsrisici omfatter leverandørregistre, kontraktlige aftaler, underleverandørrisiko, koncentrationsrisiko og exitstrategier. NIS2 Article 21 placerer sikkerhed i forsyningskæden blandt foranstaltninger til styring af cybersikkerhedsrisici. GDPR kan gøre leverandørlogfiler afgørende, når en databehandlerhændelse kan blive til et brud på persondatasikkerheden, som den dataansvarlige skal underrette om.

En praktisk leverandørklausul om logning bør kræve:

• Sikkerhedsrelevante revisionslogfiler for autentifikation, ændringer i rettigheder, administrative handlinger, API-adgang, dataeksport og konfigurationsændringer.
• Logopbevaring i overensstemmelse med politik, regulatoriske forpligtelser og kontraktrisiko.
• Tidssynkronisering og normalisering af tidszoner.
• Manipulationsbeskyttelse og begrænset adgang til logfiler.
• Samarbejde ved hændelser inden for definerede tidsfrister.
• Levering af evidens til revisioner, undersøgelser og regulatoriske forespørgsler.
• Underretningsudløsere ved mistænkelig adgang, kompromittering af tjenester eller dataeksponering.
• Lognings- og eskaleringsforpligtelser for underdatabehandlere, hvor relevant.

Leverandørlogning bør håndteres før en hændelse, ikke forhandles under en.

Hvordan forskellige revisorer tester den samme logningskontrol

En god evidenspakke skal kunne modstå forskellige faglige perspektiver. En ISO-revisor, NIS2-gennemgangsansvarlig, DORA-tilsynsførende, GDPR-gennemgangsansvarlig og en COBIT 2019- eller ISACA-orienteret revisor kan se på det samme SIEM-dashboard, men de vil stille forskellige spørgsmål.

Zenith Blueprint Step 19 forbereder organisationer på disse spørgsmål. For Logning fokuserer revisorer på, om centrale sikkerhedshændelser logges, og om logfiler opbevares, beskyttes og er anvendelige. For Overvågningsaktiviteter spørger de, hvordan usædvanlig eller uautoriseret aktivitet detekteres, evalueres og eskaleres. For Synkronisering af systemtid kan de sammenligne tidsstempler på tværs af systemer og påpege uoverensstemmelser.

Step 16: People Controls II, kontrol 6.8, er også vigtig, fordi mekanismer til hændelsesrapportering forbinder menneskelig rapportering med teknisk detektion. GDPR Article 33, NIS2 Article 23 og DORA-forpligtelser om hændelsesrapportering afhænger alle af rettidig intern eskalering.

Almindelige revisionskonstateringer og praktiske løsninger

De fleste konstateringer om logning og overvågning er forudsigelige. Problemet er, at organisationer ofte opdager dem under revisionen i stedet for under intern test.

For organisationer med begrænsede ressourcer er SME-politiktilgangen realistisk. Den kræver ikke et fuldt SOC fra dag ét. Den kræver definerede gennemgangsplaner, 12 måneders opbevaring medmindre længere opbevaring er nødvendig, skrivebeskyttet lagring, begrænset adgang og eskalering af højprioritetsalarmer. Det skaber en forsvarlig baseline, mens organisationen modnes mod centraliseret SIEM, automatiseret korrelation og managed detection.

Metrikker, der gør logning troværdig for ledelsen

Bestyrelser og topledere har ikke behov for rå SIEM-hændelser. De har behov for risikorelevant sikkerhedsinformation. Fordi NIS2 Article 20 og DORA-governancekrav placerer ansvar hos ledelsesorganer, bør metrikker for logning og overvågning indgå i rapportering om sikkerhedsstyring.

Nyttige metrikker omfatter:

• Procentdel af kritiske aktiver, der videresender logfiler til SIEM eller logindsamler.
• Procentdel af privilegerede adgangshændelser, der er dækket af alarmering.
• Antal højprioritetsalarmer gennemgået inden for SLA.
• Gennemsnitlig tid fra alarmgenerering til analytikergennemgang.
• Gennemsnitlig tid fra detektion til eskalering.
• Antal hændelser klassificeret under hændelseshåndteringsprocessen.
• Antal hændelser, der kræver DPO- eller juridisk gennemgang.
• Efterlevelse af logopbevaring efter systemkategori.
• Antal leverandørplatforme med kontraktlig adgang til logfiler.
• Antal systemer, der fejler kontroller af synkronisering af systemtid.
• Åbne afhjælpende foranstaltninger for logning og overvågning efter risikoniveau.

Disse metrikker understøtter ISO/IEC 27001:2022 clause 6.2 om målbare informationssikkerhedsmål. De styrker også ledelsestilsynet efter NIS2 og DORA samt ansvarlighed efter GDPR.

Opbygning af din evidenspakke for logning og overvågning i 2026

En stærk evidenspakke for 2026 bør samles før revisionen eller hændelsen. Clarysec anbefaler typisk en struktureret mappe eller et GRC-evidensobjekt med disse afsnit:

1. Styring og omfang: ISMS-omfang, interessenter, regulatorisk anvendelighed, ledelsesgodkendelse og rolletildelinger.
2. Politik: Lognings- og overvågningspolitik, Politik for hændelseshåndtering, Politik for revisions- og efterlevelsesovervågning, opbevaringskrav og eskaleringskrav.
3. Risiko og SoA: Risikovurdering, behandlingsplan, begrundelse i anvendelseserklæringen for A.8.15, A.8.16, A.8.17 og relaterede kontroller.
4. Arkitektur: SIEM- eller logindsamlerdiagram, fortegnelse over logkilder, indstillinger for cloudlogning og leverandørafhængigheder for logfiler.
5. Kontroldrift: Gennemgangsregistreringer, alarmer, tickets, eskaleringslogfiler, lukningsevidens og undtagelser.
6. Hændelseskobling: Arbejdsark for hændelsesklassificering, hændelsesregister, DPO-vurderingsregistrering og beslutningslog for rapportering.
7. Integritet og opbevaring: Adgangsstyring, kryptering, skrivebeskyttelse, arkivindstillinger, sletningskontroller og dokumentation for opbevaring.
8. Tidssynkronisering: NTP-konfiguration, sikker baseline, overvågning af urafvigelse og tilgang til UTC-normalisering.
9. Leverandørevidens: Kontraktklausuler, leverandørattester, tilgængelighed af cloud audit-logfiler og procedurer for samarbejde ved hændelser.
10. Forbedring: Konstateringer fra intern revision, afhjælpningstracker, resultater fra tabletop-øvelser, registreringer af alarmtuning og ledelsesrapporter.

Formålet er ikke at overvælde revisorer med volumen. Formålet er at dokumentere, at logning og overvågning fungerer som en kontrolleret proces fra styring til detektion, vurdering, eskalering, rapportering og forbedring.

Gør logfiler til forsvarlig compliance-evidens

Marias team løste ikke problemet ved at købe endnu et dashboard. Det løste problemet ved at gøre logning og overvågning til en evidensmotor. Politikker definerede kravene. SIEM-regler og cloudlogfiler leverede signaler. Hændelsesarbejdsgange registrerede beslutninger. Synkronisering af systemtid gjorde tidslinjen troværdig. Ledelsesrapportering gjorde risikoen synlig.

Det er den standard, organisationer har brug for til ISO/IEC 27001:2022, NIS2, DORA og GDPR i 2026.

Start med én praktisk test: Tag en reel alarm fra de sidste 30 dage, og dokumentér fra start til slut, hvordan den blev logget, detekteret, gennemgået, eskaleret, klassificeret, opbevaret og rapporteret.

Hvis svaret ikke er sikkert, kan Clarysec hjælpe jer med at lukke hullet.

Brug Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til at implementere Step 19 for logning, overvågning og synkronisering af systemtid samt Step 16 for mekanismer til hændelsesrapportering. Brug Zenith Controls: The Cross-Compliance Guide Zenith Controls til at kortlægge Annex A.8.15, A.8.16, A.8.17 og ISO/IEC 27002:2022-kontrol 5.25 på tværs af NIS2-, DORA-, GDPR-, NIST CSF 2.0- og COBIT 2019-perspektiver.

Operationalisér derefter kravene gennem Clarysecs Lognings- og overvågningspolitik Lognings- og overvågningspolitik, Logging and Monitoring Policy-sme Lognings- og overvågningspolitik - SME, Politik for hændelseshåndtering Politik for hændelseshåndtering, Incident Response Policy-sme Politik for hændelseshåndtering - SME og Audit and Compliance Monitoring Policy Politik for revisions- og efterlevelsesovervågning.

Logfiler er ikke evidens, før de er styret, beskyttet, gennemgået og knyttet til beslutninger. De organisationer, der kan dokumentere den kæde, vil gennemføre revisioner hurtigere, reagere bedre på hændelser og give ledelsen sikkerhed, når den næste alarm kl. 2:17 ankommer.