Er din DNS-tjeneste virkelig uden for rækkevidde - eller er du et af tilsynsmyndighedernes næste mål?
NIS 2-direktivet har omstruktureret DNS fra teknisk baggrund til en central søjle for digital robusthed og regulatorisk tilsyn. Hvis din virksomhed driver nogen del af DNS-stakken – primær administration, sekundære spejle, rekursive resolvere, "bare" SaaS-integration eller et administreret servicetilbud – påtager du dig automatisk et nyt lag af compliance- og revisionsrisiko. Den velkendte komfort "vi videresælger eller videresender bare DNS" opløses under NIS 2's regime: du bliver en "essentiel enhed", der er synlig ikke kun for dine kunder og tekniske teams, men også for regulatorer og sikkerhedsråd i hele Europa (ENISA).
Der er intet skjold i uvidenhed - kun den klarhed, du skaber.
Virksomheder, der engang betragtede DNS som intet andet end digital VVS, står nu over for direkte, juridisk bindende forpligtelser. Det er ikke længere nok at delegere tekniske operationer andre steder eller stole på punktløsninger med "SaaS som middleware". Ansvaret – juridisk, operationelt og omdømmemæssigt – ligger direkte hos dig, medmindre du proaktivt og forsvarligt kan bevise dit sande omfang. Hvis dine logfiler, kontrakter og Bestyrelsesreferat Hvis du ikke demonstrerer med granularitet, "hvor DNS stopper ved vores kant", betragtes du som medfølgende, indtil det modsatte er bevist.
Hvad ændrer sig under NIS 2?
- Hver DNS-zone, du driver eller administrerer for kunder, bringer dig øjeblikkeligt til status som essentiel enhed.
- Multi-cloud-, hybrid- og delegerede opsætninger er ikke udskilt som undtagelser – ansvar for tilsyn, kortlægning og hændelsesgennemgang kan ikke outsources via kontrakt.
- Enhver DNS-hændelse, ikke blot dramatisk nedetid, medfører eksponering for bestyrelsen og regulatorisk risiko (se Hændelsesgrænser nedenfor).
- Jeres bestyrelse, ikke kun jeres sikkerhedsledere, er nu ansvarlige i forbindelse med beslutningstagning og gennemgang af beviser.
Uanset om du er CISO, databeskyttelsesrådgiver, compliance-leder eller IT-medarbejder, der administrerer den daglige kø af supportsager: Din DNS-risiko er nu et spørgsmål om offentlig tillid og lovgivningsmæssig kontrol. Det eneste skjold er aktiv dokumentation og bestyrelsesklar bevismateriale.
Book en demoHvad tæller som en "væsentlig hændelse" for DNS under NIS 2, og hvorfor er det vigtigt?
De dage er forbi, hvor kun regionale DNS-fejl eller berømte DDoS-hændelser krævede anmeldelse. I henhold til NIS 2 - som er forfinet gennem implementeringsforordningen fra 2024 (Kommissionens implementeringsforordning (EU) 2024/653) - er hændelsestærsklen lav, præcis og giver ingen plads til fortolkning eller forsinkelse.
Hvad udløser formel DNS-hændelsesrapportering?
- Enhver tjenesteutilgængelighed i mere end 30 sammenhængende minutter: , uanset årsag - angreb, hardwarefejl, fejlkonfiguration, menneskelige fejl.
- Et databrud, der påvirker over 1,000 administrerede domæner: , uanset om opdagelsen var øjeblikkelig eller ej.
- Vedvarende DNS-svar med høj latenstid eller forsinkede DNS-svar i spidsbelastningsperioder: , selv uden fuldstændigt udfald.
Intet behov for presseoverskrifter eller offentlig forstyrrelse: et internt afhjulpet uheld, der overstiger disse tærskler, eller ethvert næsten-uheld, der registreres uden en klar begrundelse fra anmelderen, kræver rapportering og dokumentation.
| Hændelsestype | Rapporteringsudløser | Reguleringsreference |
|---|---|---|
| Tjenestens utilgængelighed | >30 minutters kontinuerlig DNS-afbrydelse | Artikel 23, 2024/653 |
| Dataovertrædelse | Over 1,000 kundedomæner kompromitteret | Artikel 23, 2024/653 |
| Vedvarende forsinkelse | Fejl med høj latenstid/respons i spidsbelastningsperioden | Artikel 23, 2024/653 |
| Tæt på | Ikke rapporteringspligtig, men skal registrere begrundelse | ENISA DNS-retningslinjer 2024 |
Hurtig gendannelse efter hændelser er værdiløs uden det spor, der beviser din proces.
Eksempel (under tærsklen "næsten uheld"):
"[2024-06-19 21:15 UTC] – DNS-afbrydelse (27 min); gennemgået af hændelsesejer – under rapporteringstærsklen i henhold til artikel 23." Hovedårsagen: fiber skåret. Overvåget og genvundet, begrundelse dokumenteret. Ingen myndighedsmeddelelse kræves.
Hvert sådant fragment bliver essentielt både for at demonstrere løbende compliance - og for at coache dit team til stærkere eskaleringsprotokoller og fremtidsberedskab.
Mestre NIS 2 uden regnearkkaos
Centraliser risici, hændelser, leverandører og bevismateriale på én ren platform.
Har "lokal proces" stadig betydning med NIS 2 - eller er mine DNS-pligter harmoniseret overalt?
NIS 2 erstatter lokale lappeløsninger med en enkelt, EU-dækkende ordningUanset om du opererer i Lissabon, Berlin, Riga eller på tværs af de cloud-regulatoriske udløsere, er rapporteringsvinduer og dokumentationskrav synkroniseret (Shoosmiths). Der er ingen fravalg, ingen "lokale tilpasninger" og ingen tilgivelse for uoverensstemmende regionale logfiler under lovgivningsmæssig gennemgang.
Det, du går glip af i Berlin, kan nu koste dig dyrt i Dublin - og i Bruxelles.
Vigtige harmoniseringsrealiteter
- Ensartede udløsere og tærskler: betyder, at dine detektions- og eskaleringspolitikker skal opfylde de strengeste standarder, uanset hvor din infrastruktur eller dit team befinder sig.
- Overskredne grænser i Paris vil dukke op i Bruxelles, efterhånden som fagfællebedømmelser eskalerer, især hvor der eksisterer kontraktlige krydsafhængigheder.
- ENISA og medlemsstaternes agenturer udfører nu fælles evalueringer og kræver eksportklare, harmoniserede registre på tværs af din DNS-ejendom.
- Peer benchmarking – via OARC- og ENISA-arbejdsgrupper – betyder, at uoverensstemmelser vil tiltrække ekstern opmærksomhed og potentielt kritik af lovgivningen (OARC).
Et 34-minutters strømafbrydelse i Paris forbliver ikke længere i en lokal kø. NIS 2 kræver synkroniserede meddelelser, identiske bevisregistre og lukningslogge, der er synlige for alle kompetente myndigheder i hele EU. Enhver forsinkelse eller uoverensstemmelse kan trække CISO'en, den ansvarlige for databeskyttelse eller bestyrelsen op i forreste række på den regulatoriske række.
Praktiske næste trin
- Centraliser alt eskalering af hændelsen og gennemgang ved hjælp af harmoniserede skabeloner.
- Standardiser dokumentation og rapportering – selv interne logfiler – i henhold til EU-standarder, ikke national lovgivning.
- Gennemgå regelmæssigt hændelsestilgange i forhold til ENISA's seneste vejledning og opdateringer fra peer-arbejdsgrupper.
Harmonisering afslutter æraen med overholdelse af tilbudsfrister for DNS. Den nye standard gælder for hele EU.
DNS-hændelsesrespons, der kan modstå bestyrelses- og tilsynsrevisioner: Hvad betyder "revisionsklar" nu?
Revisionssucces er ikke en funktion af teknisk oppetid; det er hastigheden og fuldstændigheden af sporbarhed - fra gnist til hændelsesafslutning. NIS 2-håndhævelse tester i stigende grad din end-to-end beviskæde.
Sådan opbygger du revisionssikre DNS-hændelsesregistre
- Udpeg navngivne compliance- og hændelseskontrollører.: Det er ikke nok at stole på anonyme "operationsteams".
- Automatiser harmoniserede skabeloner på EU-niveau: for både interne og lovgivningsmæssige meddelelser.
- Registrer alle stigninger, eskaleringer og dokumentationsprocesser: med utvetydige tidsstempler, anmelderidentitet og begrundelse.
- Linklogfiler, SoA/aktivregistreringer og bestyrelseskommunikation: i et centralt, eksportklart arbejdsområde.
- Vedligehold en sporbarhedsmatrix: kortlægning af udløste hændelser, risikoregister opdateringer og konkrete ISO 27001 bilag A eller SoA-referencer for hver begivenhed.
Compliance er kun så stærk som dit svageste revisionsbevis.
| Udløser | Risikoopdatering | Kontrol-/SoA-link | Beviser registreret |
|---|---|---|---|
| 31 minutters strømafbrydelse (10:22) | "Tilgængelighedskløft, Europa" | A.5.25–A.5.28, A.8.15, A.8.16 | SIEM-advarsel, SoA-opdatering |
| 1,200 Domænebrud | "Datatab, .eu-klienter" | A.5.26, A.5.27, A.8.13 | Overtrædelsesrapport, ticketlog |
| 24-timers forsinket meddelelse | "Mistede vindue" | A.6.3.3, A.8.15, A.8.16 | E-mail, handlingslog for bestyrelsen |
Bestyrelses- og tilsynsmyndigheds-KPI'er: MTTR er ikke nok
I dag er "gennemsnitlig tid til bevisførelse" (MTTE) lige så vigtig som den gennemsnitlige tid til løsning. Kan du hurtigt og fuldstændigt udarbejde en "vugge-til-grav" hændelsesrapport, der er knyttet til politikker, logfiler og navngivet ansvarlighed? Hvis ikke, stiger risikoen for bestyrelsen og myndighederne.
Vær NIS 2-klar fra dag ét
Start med et gennemprøvet arbejdsområde og skabeloner – bare skræddersy, tildel og gå i gang.
Registrerer du næsten-uheld – eller venter du på, at en tilsynsmyndighed spørger?
Overholdelse af afkrydsningsfelter overlever ikke NIS 2-kontrollen. Både "væsentlige" og "nærved-uheld" DNS-hændelser kræver nu sporbare, handlingsrettede gennemgange, der dokumenteres, tidsstemples og underskrives af udpegede kontrollører.
Du bliver ikke kun bedømt ud fra rapporterede hændelser; du bliver bedømt ud fra, hvad du logger, og hvem der gennemgår det.
Eksempel på bedste praksis for registrering i registeret
"[2024-06-15 14:34 UTC] – DNS-latens (26 min); under tærskelværdi i henhold til artikel 23. Rod: udbyderroutingfejl; overvåget, fuldt løst. Hændelsesejer: Jane Q. - ikke rapporterbar, men fuldt logget."
Anvend denne regel:
- Log altid kontekst, anmelder og begrundelse for hændelser – større som mindre.
- Dokumentanmelderens identitet, tidsstempel og årsager til ikke at eskalere.
- Eksporter og link disse poster til både bestyrelsens gennemgangspakke og det formelle SoA/risikovurderingsspor.
Sundhedstjek:
- Kan du gentage alle hændelser – større eller næsten-uheld – for bestyrelsen, revisoren, tilsynsmyndigheden?
- Har dine logfiler naturlige krydsforbindelser mellem registre, politikker, kontroller og aktivposter?
- Hvis ikke, stiger din risiko for eksponering efter hændelsen.
ISO 27001 Bridge Tabeller: Det manglende led, der binder DNS-compliance til revisionsbevis
Med 2 NIS og ISO 27001 fungerer sideløbende for de fleste DNS-enheder, kan du kun bestå revisioner og gennemgange ved at vedligeholde eksplicitte tilpasningerEnhver forventning – intern eller ekstern – skal knyttes til både kontroller og reel evidens.
Reguleringsmæssig dokumentation er kun klar til revision, når den er afstemt, eksplicit og kan eksporteres.
Eksempel på ISO 27001-brotabel
| Forventning | Operationalisering | ISO 27001 / Bilag A Reference |
|---|---|---|
| Registrer hændelser <30 min | SIEM/overvågning, tærskelværdianmelder tildelt | A.5.25, A.8.16 |
| Eskaler ved >30 minutters udfald | Politik for eskalering af hændelser, bevislog, rapportering | A.5.26, A.8.15, A.6.3 |
| Dokumenteret begrundelse for "ingen rapport" | Registrer indtastning med godkendelse, tidsstempel, korrekturlæseridentitet | A.8.15, A.5.27 |
| Underret myndighed <24 timer | Formel meddelelse, brug ENISA-skabelon, beviskæde | A.5.26, A.8.15 |
| Dokumentér fuld svarcyklus | Vugge-til-grav-log, bestyrelses-/lukningsrapporter, SoA/aktivtilknytning | A.5.27, A.6.3, A.8.13 |
Sporbarheds-minibord
| Udløser | Risikoopdatering | Kontrol-/SoA-link | Beviser registreret |
|---|---|---|---|
| 34 minutters DNS-forsinkelse | Tilgængelighedsgennemgang | A.5.25, A.8.16 | SIEM, SoA, bestyrelsesopdatering |
| <1,000 Domænebrud | Ikke rapporteringspligtig (logget) | A.8.15, Register | Hændelseslog, anmelderens begrundelse |
| 45 minutters strømafbrydelse | Notifikation sendt | A.5.26 | ENISA-meddelelse, e-mailspor |
Det er, hvad eksterne revisorer, bestyrelsen og tilsynsmyndigheder nu alle forventer. Hver hændelse, næsten-uheld eller politikopdatering skal kortlægges og eksporteres i dette eksplicitte, revisionsklare format.
Alle dine NIS 2, samlet ét sted
Fra artikel 20-23 til revisionsplaner – kør og bevis overholdelse af regler fra ende til anden.
DNS overlever bestyrelseslokalet og revisionen - men kun hvis bevistrådene er ubrydelige
I dag er kontrol standarden. Regulatoriske revisioner og bestyrelsesgennemgange kræver i stigende grad "just-in-time"-produktion af komplette hændelseskæder - fra detektion, gennemgang og anmeldelse, til afslutning og erfaringer.
Kendetegnende for operationelt lederskab er ikke hændelsesfri drift; det er transparent, reviderbar læring.
Protokol for bestyrelsens/regulatorens overlevelse
- Juster alle skabeloner og revisionsspor: med ENISA's og ISO's bedste praksis.
- Peer review: hændelseslogfiler i forhold til OARC-benchmarks og ENISA-feedback; erfaringer og tværfaglig træning skal gennemsyre compliance-registreringer.
- Grundig nærvedfangst: -det mest lærerige regulatoriske skjold.
- Samlet, øjeblikkelig eksport: Dine hændelseslogge, ændringsregistreringer, SoA og bestyrelseskommunikation skal være eksportklar til ethvert publikum.
Hvor bevismateriale bryder sammen – fragmenterede logfiler, ikke-sammenkædede politikker, manglende navne på anmeldere – revner compliance, troværdighed og konkurrencepræget tillid på vid gab.
ISMS.online – DNS-compliance for drifts-, revisions- og bestyrelsesstyring
Reguleringspligter inden for DNS belønner ikke længere regnearksgymnasten eller den, der "finder og retter" i sidste øjeblik. ISMS.online udnytter NIS 2 og ISO 27001 til at skabe en fremtidssikret compliance-rygrad, der overvinder revisionsangst og pres på bestyrelsen.
- Live-dashboards: -enhver DNS-hændelse, -gab eller -log, direkte knyttet til NIS 2-, ENISA- og ISO 27001-krav, altid klar til eksport.
- Indbygget sporbarhed: -hændelser tildelt, gennemgået og eskaleret af rigtige navne. Ikke mere "team" som et skjold, når tilsynsmyndighederne ringer.
- Hurtig eksport: -fra SIEM til bestyrelsen til ENISA kan alle hændelses-, log- og politikrelaterede optegnelser eksporteres på sekunder, ikke timer.
- Integration af arbejdsgange: -hver politikopdatering udløser automatisk bevismateriale og logændringer på tværs af hændelser og SoA for ægte revisionskontinuitet.
- API/syslog-forbindelse: -for driftsteams, sikring af at alle anomalier, politikændringer og løsninger forbliver fuldt synlige indtil gennemgang og afslutning.
Beviser tæller kun, når de er klar i det øjeblik, du har brug for at bevise dem.
Hvis compliance stadig føles som at jonglere med regneark, eller hvis din næste revision gør dig bekymret for manglende tråde, så skift til et system designet til live, auditerbar tillid - fra hændelse til bestyrelseslokale.
Få overblik over din DNS-compliance. Oplev live sporbarhedseksport, verificer logs mod ENISA og ISO 27001, og luk revisionskløften, før mindre fejl bliver til rapporteringspligtige problemer.
Ofte stillede spørgsmål
Hvilke typer hændelser skal DNS-udbydere rapportere i henhold til NIS 2?
Enhver hændelse, der påvirker tilgængelighed, integritet, fortrolighed eller autenticitet af DNS-tjenester kan udløse obligatorisk rapportering i henhold til NIS 2. Specifikt skal du rapportere afbrydelser, hvor DNS-opløsningen går tabt for længere end 30 minutteruautoriseret manipulation eller ændring af DNS-poster; vellykkede cacheforgiftning, omdirigering eller autenticitetsangreb; og ethvert databrud, der afslører mindst 1,000 domæner eller mere end 1% af administrerede posterServiceforringelse skal også anmeldes, hvis f.eks. gennemsnitlige DNS-svartider overstiger 10 sekunder i mere end en time. Reglerne fanger både direkte cyberangreb og ulykker, hvis de overskrider disse kvantitative tærskler. Selv mistænkte, koordinerede trusler eller anomalier, der lige akkurat ikke overskrider grænserne (et 22-minutters afbrydelse eller en uafklaret trafikstigning), skal dokumenteres, tidsstemples og gennemgås for... revisionsberedskab- selvom formel rapportering kun er obligatorisk over de fastsatte tærskler.
DNS-hændelsesrapporteringsgrænser (NIS 2-øjebliksbillede)
| Hændelsestype | NIS 2-tærskel | Skal man rapportere? |
|---|---|---|
| Afbrydelse (Tilgængelighed) | >30 minutters DNS-opløsningstab | Ja, til CSIRT |
| Integritetsbrud | Uautoriserede ændringer af DNS-poster | Ja |
| Brud på fortrolighed | ≥1,000 domæner eller 1% af de berørte poster | Ja |
| Serviceforringelse | >10 sekunders gennemsnitlig respons i >1 time | Ja |
| Nærved-uheld/anomali | Under tærsklen (f.eks. <30 min) | Log og intern gennemgang |
NIS 2 omformulerer enhver væsentlig DNS-anomali til en regulatorisk begivenhed – det handler ikke kun om de angreb, du stopper, men hvordan du dokumenterer dem, der næsten ramte.
Reference:,
Hvor hurtigt skal DNS-udbydere rapportere NIS 2-hændelser, og hvem underrettes?
I henhold til NIS 2 skal DNS-operatører følge en tretrins rapporteringstidsplanFørst inden for 24 timer efter at have opdaget en kvalificerende hændelse, skal dit team udstede en "tidlig advarsel" til den nationale CSIRT (Computer Security Hændelsesrespons (Team) eller udpeget tilsynsmyndighed, med en kort beskrivelse, systempåvirkning og om hændelsen har grænseoverskridende eller kriminelle elementer. Inden for en yderligere 72 timer (72 timer fra den første opdagelse) skal du give en detaljeret meddelelse, der forklarer forretnings-/brugerpåvirkningen, tekniske undersøgelser og iværksatte eller planlagte skridt. Endelig skal der indsendes en rodårsagsanalyse og erfaringer. inden for en måned af detektion. Hvis hændelsen påvirker mere end ét EU-land, skal ENISA og muligvis CyCLONe-krisenetværket straks involveres. Kontroller altid dit hjemlands udpegede myndighed; nogle bruger deres CSIRT, andre en dedikeret sektorregulator.
Tidslinje for hændelsesmeddelelser
| Rapporteringstrin | Deadline | Hvad der kræves |
|---|---|---|
| Tidlig advarsel | 24 timer | Resumé, effekt, grænseoverskridende kontekst |
| Detaljeret meddelelse | 72 timer | Tekniske detaljer, skader, afbødende foranstaltninger |
| Endelig roden | 1 måneder | Dybdegående analyse, opdeling, forebyggelsestrin |
Rettidig og klar rapportering – især de første 72 timer – er vigtigere end perfektion. Forsinkede eller ufuldstændige anmeldelser udløser næsten altid opfølgning fra tilsynsmyndighederne.
Se: NIS2, artikel 23,
Hvad er konsekvenserne, hvis DNS-udbydere ikke rapporterer eller overholder NIS 2-reglerne?
Manglende, forsinket eller forkert håndtering af NIS 2-rapportering kan udsætte DNS-operatører for store straffeBøderne kan nå op på 10 millioner euro eller 2 % af den årlige globale omsætning for essentielle DNS-udbydere (alt efter hvad der er højest), og 7 millioner euro eller 1.4 % for vigtige. Udover bøder kan vedvarende eller alvorlige overtrædelser resultere i midlertidige forbud mod ansvarlige ledere, suspendering af DNS-drift eller offentliggørelse af fejl (hvor tilsynsmyndigheden tvinger dine compliance-udløb frem i lyset). Revisioner - både planlagte og tilfældige - kontrollerer nu rutinemæssigt dine hændelsesregistre, logfiler og behandling af næsten-uheld; manglende eller dårligt vedligeholdte registre er almindelige årsager til fund, forbedringsordrer eller eskaleret kontrol fra både myndigheder og bestyrelser. Compliance er ikke bare en offentlig tillid, der skal afkrydses, og kontraktfornyelser er i fare, hvis din DNS-rapportering viser sig at være upålidelig.
NIS 2 DNS-håndhævelsesmatrix
| Compliance-mangel | Regulatorhandling | Bestyrelses-/offentlig eksponering |
|---|---|---|
| Sen/ikke-rapporteret hændelse | Bøder: op til €10 mio./2% (min.) | Offentlig hvis alvorlig |
| Manglende dokumentation | Revisionsresultat, ordrer | Intern/offentlig |
| Multiplicer tilbagevendende gab | Drifts-/lederudelukkelser | Videregivet til klienter |
| Alvorlige fejltrin | Suspension, store bøder | Høj |
Dit bedste forsvar er en levende, revisionsklar log – tilsynsmyndigheder fokuserer lige så meget på, hvordan du håndterer næsten-uheld, som på, hvad der officielt rapporteres.
Referencer:,
Hvordan skal DNS-teams registrere eller håndtere hændelser, der næsten – men ikke – kræver NIS 2-anmeldelse?
Dokumentér alle hændelser under tærsklen eller "nærved-uheld" med samme omhu som dem, der udløser formel rapportering. Hver anomali - hvad enten det er en 22 minutters afbrydelse, en række mistænkelige DNS-forespørgsler eller et mistænkt phishing-forsøg - kræver et unikt sags-ID, en navngiven korrekturlæser, fulde hændelsesdetaljer og en begrundelse for ikke at eskalere. Registrer ikke kun dine handlinger, men også den risikobaserede begrundelse, der førte til at holde svaret internt. Brug et SIEM- eller DNS-bevidst overvågningssystem, og følg ENISA-vejledningen til felt-for-felt-logning (se. Når det anmodes om det, demonstrerer præsentation af et robust nærved-uheldsregister troværdigt tilsyn, forbedrer revisionsresultaterne og kan reducere den samlede regulatoriske risiko.
Skabelon: DNS-hændelsesregister for næsten-uheld
| Begivenhed | Anmelder | Handling | Timestamp | Dokumenteret årsag |
|---|---|---|---|---|
| 22 minutters strømafbrydelse | T. Novak | logget | 2025-04-21 12:33 | Under 30 minutters tærskel |
| Trafikstigning | P. Ehrlich | Lukket | 2025-05-03 18:05 | Ingen kompromittering fundet |
En grundig intern gennemgang af næsten-uheld er dit mest værdifulde skjold i forbindelse med compliance-revisioner og kontrol efter hændelser.
Se:,
Kræver NIS 2, at alle DNS-udbydere i EU følger de samme grænser og regler?
Fra april 2024 kræver ja-EU-lovgivningen harmoniserede hændelsestærskler og rapporteringskriterier for DNS-udbydere i henhold til NIS 2 og gennemførelsesforordning 2024/653/EU. Det betyder, at de fleste udbydere endelig kan bruge en ensartet strategi til rapportering af hændelser, svartider (24 timer/72 timer/1 måned) og dokumentationsindhold på tværs af grænser. Imidlertid... nationale tilsynsmyndigheder som f.eks. Tysklands BSI eller Luxembourgs ILR kan og gør det på "lokale nuancer" - ofte hyppigere kundemeddelelser, strengere opbevaringsperioder eller let justerede formularer. Tjek altid den seneste vejledning fra din kompetente myndighed, da lokale regler kan forme både din rapporteringskø og hvad revisorer forventer at se.
Øjebliksbillede: Harmoniseret - men med lokale præg
| Parameter | EU NIS 2 Standard (2024/653/EU) | Eksempel på national variation |
|---|---|---|
| Hændelsestærskel | >30 min, 1%/1000 domæner | DE: Underret slutkunder |
| Tidslinjer | 24 timer / 72 timer / 1 måned | EE: 12 timers varsel muligt |
| Bevisopbevaring | ENISA-minimumkrav | LU: 2-5 års opbevaring |
Ensartet regulering er værdifuld, men lokal årvågenhed sikrer, at du undgår dyre overraskelser i forbindelse med revisioner.
Gennemse:,
Hvordan hjælper ISMS.online DNS-teams med at opnå NIS 2-overholdelse – og bygge bro over til ISO 27001?
ISMS.online operationaliserer alle rapporterings- og dokumentationskrav for DNS-udbydere under NIS 2 - og knytter hver hændelse og beslutning direkte til de relevante ISO 27001-kontroller. Dets hændelsesdashboard fremhæver alle nærgående eller overskredne tærskler og automatiserer påmindelser for 24-timers, 72-timers og en-måneders rapporteringsvinduer til CSIRT'er og myndigheder, så intet slipper igennem. Integrerede skabeloner dækker alle typer DNS-hændelser og -registre og tidsstempler både formelle hændelser og interne næsten-uheld. Anmelderarbejdsgange forbinder hver hændelse til ansvarlige teammedlemmer med eksportklare logfiler til revisioner eller lovgivningsmæssige indsendelser. Hver handling er i overensstemmelse med ISO 27001-klausuler-A.5.25 (hændelsesoptegnelser), A.5.26 (respons), A.5.27 (gennemgang efter hændelsen), A.8.15/8.16 (logning og overvågning), A.5.35 (uafhængig gennemgang). Når ENISA eller lokale regulatorer opdaterer kravene, sikrer ISMS.online, at dit system forbliver på niveau, så din overholdelse altid er forsvarlig - både på teknisk og bestyrelsesniveau.
Sporingstabel: NIS 2/ISO 27001 Fodgængerovergang
| NIS 2-handling | ISMS.online-funktion | ISO 27001 klausul |
|---|---|---|
| Registrer/advarsler | Alarmdashboard, SIEM | A.5.25, A.8.16 |
| Gennemgå/Tildel | Arbejdsgang, adgangslog | A.5.26, A.8.15 |
| Optag hændelse | Bevisregister | ENISA, A.5.25 |
| Underret/Revision | Rollebaseret eksport | A.5.27, A.5.35 |
Med ISMS.online er NIS 2-compliance ikke et kæmpe besvær på vurderingstidspunktet – det er en levende, revisorklar historie, der kan bevises over for bestyrelsen, tilsynsmyndigheden eller kunden med en enkelt eksport.
*Se:, *
