Gennemgang af firewallregler for ISO 27001, NIS2, DORA og GDPR

Klokken er 07:42 en mandag morgen. CISO’en hos en voksende SaaS- og fintech-udbyder sidder med tre separate beskeder foran sig.

Den første kommer fra SOC. En kompromitteret udviklerarbejdsstation forsøgte i løbet af natten at oprette forbindelse til et internt databaseundernet. Trafikken blev blokeret, men analytikeren ønsker bekræftelse på, at firewallreglen er tilsigtet, aktuel og godkendt.

Den anden kommer fra en stor erhvervskunde. Kunden ønsker bevismateriale for, at produktions-, udviklings-, virksomheds- og supportmiljøer er segmenterede, at firewallregler gennemgås, og at undtagelser udløber.

Den tredje kommer fra den compliance-ansvarlige. Organisationen er omfattet af NIS2 som vigtig digital udbyder, har GDPR-ansvar som databehandler og har kunder i den finansielle sektor, der efterspørger DORA-lignende bevismateriale for IKT-risiko. Bestyrelsen vil vide, om det samme ISO/IEC 27001:2022-bevismateriale kan dække alle tre behov.

Så lander gennemgangen efter hændelsen. En udviklingsserver var tæt på at blive eksponeret mod internettet under en ændring sent om aftenen. Ingen kundedata gik tabt, men det forensiske team fandt noget værre end den oprindelige fejl: En fem år gammel firewallregel markeret som “midlertidig test” tillod stadig bred bevægelse mellem udvikling og produktion. Hvis en angriber havde fået adgang, ville netværket have ydet meget begrænset modstand.

Det er på det tidspunkt, mange organisationer opdager en ubehagelig sandhed. De kan have firewalls, VLAN’er, cloud-sikkerhedsgrupper og diagrammer, men de har ikke styring af segmenteringszoner, regelejerskab, midlertidig adgang, ændringsgodkendelser, recertificering og revisionsbevismateriale.

I 2026 er “vi har en firewall” ikke et forsvarligt svar. Auditorer, tilsynsmyndigheder, kunder og forsikringsselskaber forventer dokumentation for, at netværk er bevidst adskilt, at trafik styres efter forretningsbehov, at risikofyldte undtagelser er under kontrol, og at logfiler viser, at kontrollerne fungerer.

Hvorfor firewallstyring nu er et bestyrelsesanliggende

Netværkssegmentering blev tidligere behandlet som et teknisk ingeniørområde. Infrastrukturteams ejede VLAN’er, firewalladministratorer vedligeholdt regelsæt, cloudteams administrerede sikkerhedsgrupper, og compliance så kun et diagram under revisioner.

Den driftsmodel fungerer ikke længere.

NIS2-direktivet kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger til at styre risici for net- og informationssystemer. Article 21 omfatter politikker for risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikkerhed ved anskaffelse og vedligeholdelse, vurdering af effektivitet, grundlæggende cyberhygiejne, adgangsstyring og styring af aktiver. Ledelsesorganer skal godkende og føre tilsyn med disse foranstaltninger til styring af cybersikkerhedsrisici.

DORA finder anvendelse fra 17. januar 2025 for mange finansielle enheder og gør styring af IKT-risiko til en ledelsesforankret og dokumenteret disciplin. Article 5, 6 og 8 kræver ledelse, en styringsramme for IKT-risiko og identifikation af IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver, afhængigheder, kritiske aktiver og sammenkoblinger. Article 9, 10 og 11 omhandler beskyttelse, forebyggelse, detektion, respons og genopretning. Article 24-27 kræver test af digital operationel robusthed, herunder avanceret test for visse enheder. Det gør segmentering til et robusthedsspørgsmål, ikke kun et firewallspørgsmål.

GDPR tilføjer laget for databeskyttelse og ansvarlighed. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen, herunder fortrolighed, integritet, tilgængelighed og robusthed. Article 5(1)(f) kræver integritet og fortrolighed, og Article 5(2) kræver ansvarlighed. Hvis systemer med personoplysninger kan nås fra kompromitterede endepunkter, gæstenetværk eller ustyrede tredjepartsveje, kan en tilsynsmyndighed spørge, hvorfor disse veje fandtes.

ISO/IEC 27001:2022 giver det ledelsessystemmæssige fundament, der forbinder disse forpligtelser. Standarden kræver afgrænsning af omfang, krav fra interessenter, risikovurdering, risikobehandling, en Anvendelseserklæring, operationel planlægning og styring, ledelsesmæssig ansvarlighed, målbare målsætninger, dokumenteret information og løbende forbedring. Annex A, understøttet af vejledning i ISO/IEC 27002:2022, omfatter de kontrolområder, der er nødvendige for leverandørrisiko, cloudtjenester, logning, overvågning, sikker arkitektur, adskillelse af miljøer og ændringsstyring.

Pointen er enkel: Netværkssegmentering og gennemgang af firewallregler er nu bevismateriale for styring.

Clarysecs driftsmodel: 8.20, 8.22 og 8.32

Clarysec behandler segmentering og firewallgennemgang som én samlet driftsmodel på tværs af ISO/IEC 27002:2022-kontroller, ikke som isolerede tekniske opgaver.

De tre primære kontroller er:

I Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] placerer Clarysec netværkssikkerhed i fasen Controls in Action, Step 20: Controls 8.18 to 8.26. Vejledningen formulerer det centrale revisionsspørgsmål klart:

“I sin kerne kræver denne kontrol, at organisationer sikrer, at netværk er sikre gennem arkitekturen, ikke blot ved senere at tilføje firewalls eller antivirus. Det betyder, at man skal tænke strategisk om netværkssegmentering, adgangsstyring, kryptering under overførsel, overvågning og defense in depth. Det begynder med et enkelt spørgsmål: Hvem og hvad kommunikerer, og bør de gøre det?”

Spørgsmålet “hvem og hvad kommunikerer, og bør de gøre det?” er det bedste praktiske udgangspunkt for gennemgang af firewallregler. Det flytter samtalen væk fra tusindvis af kryptiske ACL-poster og hen imod forretningsmæssigt begrundede flows.

Den samme Zenith Blueprint instruerer teams i at vurdere netværksarkitekturen ved at verificere, at firewallregler, IPS/IDS og fjernadgangskonfigurationer er aktuelle og hærdede, og ved at bekræfte, at cloud-sikkerhedsgrupper, routing og VPC- eller undernetregler stemmer overens med den tilsigtede arkitektur. Den fortæller også auditorer, at de skal forvente et netværkssikkerhedsarkitekturdiagram, der viser firewalls, VPN-gateways, DMZ-zoner, VLAN-adskillelse og tillidsgrænser.

For ændringsstyring placerer Zenith Blueprint ISO/IEC 27002:2022-kontrol 8.32 i fasen Controls in Action, Step 21: Controls 8.27 to 8.34, og fremhæver, hvorfor firewallstyring fejler, når ændringskontrollen er svag:

“Denne kontrol anerkender en hård sandhed i IT: Mange hændelser skyldes ikke angreb, men fejlstyrede ændringer. En firewallregel, der er åbnet for bredt. En debugindstilling, der står aktiveret. En glemt afhængighed efter en migrering.”

Det er præcis sådan midlertidige firewallåbninger bliver permanente angrebsveje.

Sådan ser god netværkssegmentering ud

Et modent segmenteringsprogram har fire lag.

For det første har det en zonemodel. Zoner er ikke vilkårlige undernet. De er tillidsgrænser, der er tilpasset forretningsfunktion og datafølsomhed, f.eks. internetvendt DMZ, produktionsapplikationslag, produktionsdatabaselag, virksomhedens brugernetværk, privilegeret administrationsnetværk, udviklingsmiljø, testmiljø, backupnetværk, gæste-Wi‑Fi, OT- eller IoT-zone og zone for tredjepartsadgang.

For det andet har det en flowmatrix. For hvert zonepar dokumenterer organisationen tilladt kilde, destination, protokol, port, applikation, forretningsejer, systemejer, datatype, begrundelse og logningskrav.

For det tredje har det regelejerskab. Hver firewallregel, cloud-sikkerhedsgrupperegel eller softwaredefineret perimeterpolitik har en ejer, udløbs- eller recertificeringsdato, tilknyttet ændringssag og forretningsmæssig begrundelse. “Any-to-any” bør behandles som en konstatering, medmindre det er formelt risikoaccepteret, tidsbegrænset og understøttet af kompenserende kontroller.

For det fjerde har det tilbagevendende gennemgang. Gennemgang betyder mere end at eksportere en firewallregelbase én gang om året. Den omfatter recertificering ved ejeren, sammenligning med observeret trafik, detektion af ubrugte regler, validering af midlertidige undtagelser, gennemgang af interneteksponering, segmenteringstest og afstemning mod aktivfortegnelsen.

Clarysecs Politik for netværkssikkerhed [P-NS] fastsætter organisationens forventning klart:

“Al trafik mellem zoner skal kontrolleres af firewalls eller softwaredefinerede perimeterløsninger med eksplicitte deny-by-default-konfigurationer.”

Fra Enterprise Policy, Politik for netværkssikkerhed, afsnittet “Styringskrav”, klausul 5.2.

Den samme politik forbinder firewallændringer direkte med ændringsstyring:

“Enhver ændring af firewallregelsæt, routingtabeller eller security group-konfigurationer skal følge organisationens Politik for ændringsstyring (P5), herunder tilbagerulningsplaner og revisionslogning.”

Fra Enterprise Policy, Politik for netværkssikkerhed, afsnittet “Styringskrav”, klausul 5.4.

For SMV’er giver Clarysecs Network Security Policy-sme [P-NS-SME] det samme princip i operationelle termer:

“Default-deny-regler skal håndhæves for alle indgående forbindelser, medmindre de udtrykkeligt er påkrævet og godkendt”

Fra SME Policy, Network Security Policy-sme, afsnittet “Krav til implementering af politikken”, klausul 6.1.2.

Og specifikt for segmentering:

“Trafik mellem segmenter skal filtreres, og adgang mellem segmenter skal følge princippet om mindste privilegium”

Fra SME Policy, Network Security Policy-sme, afsnittet “Krav til implementering af politikken”, klausul 6.2.3.

Disse politikklausuler gør det muligt for en auditor at spore fra risiko til kontrol, fra kontrol til regel, fra regel til godkendelse og fra godkendelse til logfiler.

Én bevispakke for ISO 27001, NIS2, DORA og GDPR

Den fejl, mange teams begår, er at opbygge separate bevispakker: én til ISO/IEC 27001:2022, én til NIS2, én til GDPR, én til DORA-kunder og én til cyberforsikring.

En bedre tilgang er at opbygge én samlet bevispakke for segmenterings- og firewallstyring, der kortlægger på tværs af rammeværker.

Zenith Controls: The Cross-Compliance Guide [ZC] kortlægger ISO/IEC 27002:2022-kontrol 8.22 Adskillelse af netværk som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedskonceptet Protect og den operationelle kapabilitet for system- og netværkssikkerhed. Vejledningen knytter 8.22 til 8.20 Netværkssikkerhed, 8.21 Sikkerhed i netværkstjenester, 8.7 Beskyttelse mod malware, 8.27 Sikker systemarkitektur og tekniske principper samt 8.31 Adskillelse af udviklings-, test- og produktionsmiljøer.

Vejledningen forklarer segmenteringens relevans for NIS2 sådan:

“Adskillelse af netværk er et direkte svar på disse forpligtelser, fordi den reducerer angrebsflader og forhindrer lateral bevægelse på tværs af netværksforbundne systemer.”

Den sætning beskriver, hvorfor NIS2-cyberhygiejneprogrammer ikke bør behandle segmentering som valgfrit. Inddæmning af ransomware handler ikke kun om beskyttelse af endepunkter. Det handler om at begrænse lateral bevægelse, når forebyggelsen svigter.

For GDPR kortlægger Zenith Controls 8.22 til Article 32 og Recital 49 og bemærker, at netværksdiagrammer og zonepolitikker bliver centralt bevismateriale for efterlevelse. For DORA kortlægger Zenith Controls netværkssikkerhed og adskillelse til styring af IKT-risiko og inddæmning af hændelser. Segmenteringstest kan understøtte bevismateriale for IKT-robusthed, især når de dokumenterer, at en kompromittering i én zone ikke frit kan bevæge sig ind i kritiske finansielle tjenester, repositories med personoplysninger eller privilegerede administrationssystemer.

Denne tabel er ikke kun en compliance-kortlægning. Den er en køreplan for indsamling af bevismateriale.

Den firewallregelgennemgang, der faktisk virker

En gennemgang af firewallregler fejler, når den kun spørger: “Er denne regel stadig nødvendig?” Regelejere svarer ofte ja, fordi de er bange for at bryde noget.

En bedre gennemgang stiller seks spørgsmål:

1. Hvilken forretningstjeneste understøtter denne regel?
2. Hvilken aktivejer og dataejer har godkendt flowet?
3. Ligger destinationen i den korrekte zone i forhold til data og funktion?
4. Er reglen mere permissiv, end den observerede trafik kræver?
5. Er logning aktiveret for højrisikoflows?
6. Har reglen en gennemgangsdato, udløbsdato eller registreret undtagelse?

Network Security Policy-sme kræver periodisk gennemgang:

“IT-supportleverandøren skal gennemføre en årlig gennemgang af firewallregler, netværksarkitektur og trådløse konfigurationer”

Fra SME Policy, Network Security Policy-sme, afsnittet “Styringskrav”, klausul 5.6.1.

Årlig gennemgang er baseline, ikke loftet. Højrisikoregler kræver hyppigere recertificering.

Politik for netværkssikkerhed er eksplicit om undtagelser:

“Anmodningen skal gennemgås og godkendes af ISMS-ansvarlig eller CISO og registreres i ISMS-undtagelsesregisteret med en maksimal godkendelsesperiode på 90 dage, som kan fornyes efter en ny vurdering.”

Fra Enterprise Policy, Politik for netværkssikkerhed, afsnittet “Risikobehandling og undtagelser”, klausul 7.3.

For SMV’er kræver Network Security Policy-sme, at undtagelsesanmodninger indeholder de rigtige minimumsoplysninger:

“Anmodningen skal indeholde begrundelse, omfang, varighed og kompenserende kontroller (f.eks. IP-tilladelsesliste, logning)”

Fra SME Policy, Network Security Policy-sme, afsnittet “Risikobehandling og undtagelser”, klausul 7.3.3.

Den klausul gør undtagelseshåndtering til revisionsbar risikobehandling i stedet for uformel chat.

Praktisk eksempel: fjernelse af en risikofyldt produktionsdatabaseregel

Antag, at en virksomhed finder følgende regel under gennemgangen:

Dette er en klassisk revisionskonstatering. Den overtræder princippet om mindste privilegium, har ingen klar ejer, ingen udløbsdato, ingen aktuel begrundelse og ingen logning. Den skaber også en eksponering efter GDPR Article 32, hvis produktionsdatabasen indeholder kunders personoplysninger.

Afhjælpningsprocessen bør skabe bevismateriale, ikke kun fjerne en dårlig regel.

Clarysecs Lognings- og overvågningspolitik [P-LM] omfatter ekstern kommunikation og udløsere fra firewallregler som logrelevante hændelser:

“Ekstern kommunikation og udløsere fra firewallregler”

Fra Enterprise Policy, Lognings- og overvågningspolitik, afsnittet “Krav til implementering af politikken”, klausul 6.1.1.6.

For højrisikoregler mellem zoner bør firewalludløsere sendes til SIEM- eller overvågningsplatformen med alarmer for usædvanlige kildehosts, volumener eller tidsvinduer.

SMV-politikken kræver også ændringsdisciplin:

“Alle ændringer af netværkskonfigurationer (firewallregler, switch-ACL’er, routingtabeller) skal følge en dokumenteret ændringsstyringsproces”

Fra SME Policy, Network Security Policy-sme, afsnittet “Krav til implementering af politikken”, klausul 6.9.1.

En enkelt oprydning i denne regel skaber bevismateriale for ISO/IEC 27001:2022 operationel kontrol, ISO/IEC 27002:2022 8.20, 8.22 og 8.32, NIS2-cyberhygiejne, GDPR Article 32 og DORA-lignende styring af IKT-risiko.

Cloud, SaaS og hybride netværk skal medtages

Moderne segmentering handler ikke kun om VLAN’er og fysiske firewalls. Den omfatter AWS security groups, Azure network security groups, Kubernetes-netværkspolitikker, cloud-routingtabeller, SaaS-admin-tilladelseslister, private endpoints, VPN’er, SD-WAN, identitetsbevidste proxies og softwaredefinerede perimeterkontroller.

For en SaaS-udbyder eller reguleret digital tjeneste bør gennemgangen af firewallregler som minimum omfatte:

• Internetvendte load balancere og applikationsgateways
• Cloud-sikkerhedsgrupper og netværks-ACL’er
• Routingtabeller for private undernet
• Peering- og transitgatewayveje
• VPN- og fjernadministrationsveje
• Administrationsgrænseflader og management planes
• Kubernetes ingress- og netværkspolitikker
• CI/CD-runneradgang til produktion
• Logningsdækning for afviste og tilladte højrisikoflows
• Tredjepartssupportadgang og nødadgangsveje

Hvis en cloud-sikkerhedsgruppe tillader indgående databasetrafik fra et bredt virksomheds-IP-interval, skal den behandles som en firewallregel. Den skal have ejerskab, begrundelse, godkendelse, gennemgang, logning og udløb.

Det er også her, understøttende ISO-standarder styrker fortællingen. ISO/IEC 27017 understøtter klarhed over cloud-sikkerhedsansvar. ISO/IEC 27033 giver dybere vejledning om netværkssikkerhedsarkitektur, DMZ’er, segmenteringszoner, trafikfiltrering og sikker kommunikation mellem netværk. ISO/IEC 27701 styrker databeskyttelsesstyring, hvor personhenførbare oplysninger bevæger sig på tværs af netværk. ISO/IEC 27035 understøtter inddæmning af hændelser, og ISO/IEC 27005 understøtter valg af segmentering som risikobehandling for uautoriseret adgang, spredning af malware og lateral bevægelse.

Hvordan auditorer tester den samme kontrol forskelligt

En af styrkerne ved Zenith Controls er, at den forklarer, hvordan forskellige revisionsmetodikker undersøger den samme kontrol. Bevismaterialet kan genbruges, men spørgsmålene er forskellige.

En DORA-fokuseret assessor kan spørge, om en kompromittering i en betalingsgateway kan pivotere ind i kundedatabaser. En kompetent NIS2-myndighed kan spørge, om ransomware på en administrativ arbejdsstation kan nå systemer til levering af kernetjenester. En GDPR-myndighed kan spørge, hvilke netværksbegrænsninger der beskyttede systemer, som behandler personoplysninger. En ISO-auditor kan blot bede om risikovurderingen, SoA, politikken, proceduren og bevismateriale for, at gennemgangene fandt sted.

De bedste programmer besvarer alle disse spørgsmål med de samme artefakter.

Metrikker, der gør segmentering synlig for ledelsen

NIS2 og DORA presser begge på for ledelsens ansvarlighed. ISO/IEC 27001:2022 kræver lederskab, mål, roller, ressourcer, rapportering og løbende forbedring. Det betyder, at segmentering kræver metrikker, som ledelsen kan forstå.

Nyttige ledelsesmetrikker omfatter:

• Andel firewallregler med tildelt ejer
• Andel regler med dokumenteret forretningsmæssig begrundelse
• Antal udløbne midlertidige regler
• Antal regler med “any” som kilde, destination eller tjeneste
• Antal interneteksponerede tjenester efter kritikalitet
• Andel højrisikoflows mellem zoner med logning aktiveret
• Antal nødændringer i firewalls pr. kvartal
• Andel stikprøveudvalgte regler, der matcher godkendte ændringssager
• Antal fejl i segmenteringstest
• Gennemsnitlig tid til afhjælpning af risikofyldte eller ubrugte regler
• Antal undtagelser ældre end 90 dage
• Antal regler for tredjepartsadgang, der er gennemgået og recertificeret

Politik for netværkssikkerhed identificerer “Firewallreglers effektivitet” som et hensyn ved efterlevelse og håndhævelse i afsnittet “Håndhævelse og efterlevelse”, klausul 8.2.2. Den formulering er vigtig, fordi det ikke er nok, at regler eksisterer. Regler skal være effektive, gennemgåede og tilpasset den aktuelle risiko.

Opbyg bevispakken for segmentering i 2026

En praktisk bevispakke for segmentering og gennemgang af firewallregler bør være klar, før auditoren beder om den.

Som minimum skal følgende vedligeholdes:

1. Aktuelt netværksarkitekturdiagram, herunder cloud- og hybridzoner
2. Standard for zoneklassificering, herunder følsomhed og tillidsniveau
3. Flowmatrix for kritiske tjenester og systemer med personoplysninger
4. Eksport af firewallregler og cloud-sikkerhedsgrupperegler
5. Register over regelejere og recertificering
6. Procedure for firewallgennemgang og gennemgangskalender
7. Ændringsregistreringer for stikprøveudvalgte firewallændringer
8. Undtagelsesregister med godkendelser, udløb og kompenserende kontroller
9. Resultater af segmenteringstest og afhjælpningsregistreringer
10. Bevismateriale for logning og overvågning af højrisikoflows
11. Hændelsesplaybooks, der viser inddæmning efter zone
12. Metrikker til ledelsesrapportering og mødereferater

Kortlæg dette bevismateriale til ISO/IEC 27001:2022-klausuler og Annex A-kontrolområder. Krydsreferér det derefter til NIS2 Article 21, GDPR Article 32, DORA-krav til styring og test af IKT-risiko, NIST CSF 2.0-resultater såsom GOVERN, PROTECT, DETECT og RESPOND samt COBIT-styringspraksisser.

NIST CSF 2.0 er særligt nyttig som kommunikationslag til bestyrelsen. GOVERN-funktionen fokuserer på juridiske, regulatoriske og kontraktlige krav, risikovillighed, roller, politikker og tilsyn. De operationelle resultater omhandler konfigurationsstyring, logning, overvågning, databeskyttelse, hændelseshåndtering og genopretning. Det hjælper ledelsen med at forstå risiko uden at læse firewall-ACL’er.

Almindelige konstateringer, Clarysec ser i segmenteringsrevisioner

På tværs af SaaS, fintech, managed service providers og regulerede SMV’er går de samme konstateringer igen:

• Fladt netværk mellem brugerendepunkter og produktionstjenester
• Produktionsdatabaser, der kan nås fra udviklings- eller virksomhedsnetværk
• Brede cloud-sikkerhedsgrupper kopieret fra gamle skabeloner
• Midlertidige leverandørregler uden udløb
• Firewallændringer foretaget uden for ændringsprocessen
• Regler uden ejer eller forretningsmæssig begrundelse
• Logning deaktiveret på højrisiko-tilladelsesregler
• Gæste-Wi‑Fi ikke fuldt isoleret
• Administrationsgrænseflader, der kan nås fra generelle netværk
• Diagrammer, der ikke stemmer overens med faktisk routing
• Intet bevismateriale for, at regelgennemgange er gennemført
• Ingen segmenteringstest efter større arkitekturændringer
• Ingen kortlægning mellem systemer med personoplysninger og netværkszoner
• Ingen ledelsesrapportering om netværkseksponering

Disse konstateringer er ikke kun tekniske svagheder. De underminerer organisationens evne til at dokumentere NIS2-cyberhygiejne, DORA-operationel robusthed og ansvarlighed efter GDPR Article 32.

Fra reaktiv oprydning til forsvarlig kontrol

Netværkssegmentering og gennemgang af firewallregler er dér, hvor sikkerhedsarkitektur møder revisionsvirkelighed. Hvis du kan vise en risikobaseret zonemodel, kontrollerede flows mellem zoner, godkendte firewallændringer, tidsbegrænsede undtagelser, logningsbevismateriale og periodisk validering, kan du besvare en bred vifte af spørgsmål fra ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST og COBIT med én sammenhængende fortælling.

Clarysec kan hjælpe dig med at opbygge den fortælling.

Brug Zenith Blueprint: An Auditor’s 30-Step Roadmap til at strukturere implementeringsrejsen, især Controls in Action Step 20 for netværkssikkerhed og segmentering samt Step 21 for ændringsstyring. Brug Zenith Controls: The Cross-Compliance Guide til at kortlægge ISO/IEC 27002:2022-kontrollerne 8.20, 8.22 og 8.32 på tværs af revisionsforventninger for NIS2, DORA, GDPR, NIST og COBIT. Forankr dine operationelle regler i Clarysecs Politik for netværkssikkerhed, Network Security Policy-sme og Lognings- og overvågningspolitik.

Dit næste skridt er enkelt og har høj værdi: Vælg én kritisk tjeneste, f.eks. kundeproduktion, betalingsbehandling eller identitetsstyring, og gennemfør en stikprøvegennemgang af 10 regler i denne uge. For hver regel skal du bekræfte ejer, begrundelse, kilde, destination, port, logning, ændringssag og udløb. Hvis du ikke kan dokumentere disse syv forhold, har du begyndelsen på din forbedringsplan for segmentering i 2026.