DNS-styring i 2026: revisionsklare kontroller hos registrarer

Kl. 07.42 en mandag morgen modtager CISO’en i en fintech-scaleup den besked, ingen ønsker at se. Kunder kan ikke tilgå betalingsportalen, helpdesken er oversvømmet, e-mail fejler, og SOC’et har hverken fundet malware, firewallnedbrud eller hændelser hos cloududbyderen.

Rodårsagen er mere stille og mere pinlig. En registrarkonto blev tilgået med forældede administratorlegitimationsoplysninger, som flere tidligere IT-medarbejdere havde delt. Angriberen ændrede autoritative navneservere, modificerede MX-records, deaktiverede DNSSEC og omdirigerede trafikken længe nok til at høste legitimationsoplysninger og forstyrre partner-API’er. Betalingsportalen var ikke kompromitteret i traditionel forstand. Virksomhedens tillidsanker, dens domæne, var kompromitteret.

Kl. 09.30 er den driftsmæssige krise blevet en compliance-krise. Bestyrelsen spørger, om registry lock var aktiveret. Juridisk afdeling spørger, om personoplysninger blev eksponeret. DPO’en spørger, om dette er et GDPR-brud på persondatasikkerheden. Tilsynsmyndigheden vil vide, om en kritisk eller vigtig funktion blev påvirket. En kunderevisor beder om den ændringssag, der godkendte DNS-ændringen.

Svaret er i alt for mange organisationer et regneark, en delt postkasse og en registrarkonsol, som ingen har gennemgået i seks måneder.

Styring af DNS og domæneregistrarer i 2026 er ikke længere et snævert infrastrukturemne. Det er en del af robusthed mod ransomware, phishing-forebyggelse, cloudtilgængelighed, risikostyring af leverandører, hændelseshåndtering, forretningskontinuitet og evidensbaseret efterlevelse. Hvis dit domæne kan kapres, kan din SaaS-platform forsvinde. Hvis dine DNS-records kan ændres uden godkendelse, kan din e-mailsikkerhed, SSO, TLS-certifikater, API-endpoints og kundernes tillid undermineres på få minutter.

Hvorfor DNS- og registrarstyring hører hjemme i ISMS

Et domænenavn er ikke kun et brandaktiv. Det er et logisk aktiv, en autentifikationsafhængighed, en routingafhængighed og ofte en leverandøradministreret tjeneste. Det forbinder identitetsudbydere, e-mailautentifikation, TLS-certifikatvalidering, cloudendpoints, kundeportaler, API’er, CDN-tjenester, overvågningsprober og hændelseskommunikation.

Clarysecs Politik for styring af aktiver - SME Politik for styring af aktiver - SME gør dette eksplicit i sit omfang:

Digitale legitimationsoplysninger og tjenester: domænenavne, digitale certifikater, API-nøgler, e-mailkonti, cloudlogins

Fra afsnittet “Omfang”, politikklausul 2.2.4.

Den samme politik kræver mere end blot at opliste domænenavnet:

Ejerskab, formål, adgangsrettigheder og fornyelsesfrister skal dokumenteres.

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

For enterprise-miljøer omfatter Clarysecs Politik for styring af aktiver Politik for styring af aktiver også logiske aktiver:

Logiske aktiver: domænenavne, licenser, brugerkonti, konfigurationsbaselines

Fra afsnittet “Omfang”, politikklausul 2.2.5.

Det er udgangspunktet for styringen. En DNS- og registrarfortegnelse bør dokumentere:

• Domænenavn, registry, registrar, DNS-hostingudbyder og autoritative navneservere
• Forretningsansvarlig, teknisk ansvarlig, sikkerhedsansvarlig og nødgodkender
• Formål, f.eks. produktionsportal, API, e-mail, SSO, marketing, testmiljø eller defensiv registrering
• Kritikalitetsvurdering og kortlægning af afhængigheder til forretningstjenester
• DNSSEC-status, DS-recordstatus, nøgleejerskab og proces for nøglerotation
• Status for registry lock og registrar lock
• MFA og model for privilegeret adgang til konti hos registrarer og DNS-udbydere
• Fornyelsesdato, status for automatisk fornyelse, betalingsansvarlig og alarmering ved udløb
• Krav til ændringsstyring for zoneredigeringer og delegeringsændringer
• Logning, alarmering, overvågning og opbevaring af revisionsbevis

Derfor bør domænestyring indgå i ISO/IEC 27001:2022 ISMS-omfanget og risikovurderingen. ISO/IEC 27001:2022 kræver, at organisationer fastlægger kontekst, krav fra interessenter, retlige og kontraktlige forpligtelser samt grænseflader og afhængigheder til eksterne organisationer. DNS afhænger af registrarer, registries, DNS-hostingudbydere, cloududbydere, certifikatudstedere, MSP’er og nogle gange marketingbureauer. Hvis disse grænseflader udelades fra ISMS, bliver revisionssporet ufuldstændigt.

DNS-trusselsmodellen for 2026

De mest skadelige DNS-fejl er ofte enkle:

1. Et domæne udløber, fordi ansvaret for fornyelse er uklart.
2. Et tidligere bureau har stadig adgang til en registrarkonto.
3. DNSSEC er aktiveret, men DS-records er forkerte efter migrering til en ny DNS-udbyder.
4. En wildcard-record peger trafik mod en forladt cloudtjeneste.
5. En TXT-record ændres for at validere en SaaS-tenant eller en certifikatanmodning under angriberens kontrol.
6. MX-records ændres under en phishing- eller e-mailaflytningskampagne.
7. En CNAME til en tredjepartsplatform bliver sårbar over for takeover.
8. Registry lock findes for det primære domæne, men ikke for kundevendte landekodedomæner.
9. SOC’et overvåger endpoints, men ingen overvåger ændringer i zonefiler.

De tekniske sikkerhedsforanstaltninger er velkendte. DNSSEC hjælper med at beskytte DNS-dataenes integritet og oprindelsesautentifikation. Registry lock betyder, at højrisikoændringer på registry-niveau kræver yderligere out-of-band-verifikation. Registrar lock reducerer risikoen for uautoriseret overførsel. MFA og gennemgang af privilegeret adgang reducerer sandsynligheden for kontoovertagelse. Ændringsstyring forebygger utilsigtede driftsforstyrrelser. Overvågning opdager uautoriserede eller uventede ændringer.

Compliance-udfordringen er en anden: Kan I dokumentere, at disse sikkerhedsforanstaltninger findes, har ejerskab, gennemgås og fungerer under en hændelse?

Det er netop dette evidensspørgsmål, mange organisationer fejler på.

Kortlægning af DNS-styring til ISO/IEC 27001:2022 og ISO/IEC 27002:2022

ISO/IEC 27001:2022 leverer ledelsessystemstrukturen til at omsætte DNS-kontroller til gentagelige, revisionsbare processer. ISO/IEC 27001:2022 Bilag A og kontrolvejledningen i ISO/IEC 27002:2022 giver det kontrolsprog, revisorer forventer.

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint behandler netværkstjenester som eksplicitte revisionsobjekter. I fasen Kontroller i praksis, trin 20, instruerer den teams i at validere sikkerheden for netværkstjenester:

Oplist alle interne og eksterne netværkstjenester (DNS, VPN, SMTP, DHCP, API-gateways, osv.).

✓ Bekræft for hver enkelt, at de anvender sikre protokoller (f.eks. DNSSEC, TLS 1.2+, SSH i stedet for Telnet). ✓ Gennemgå, hvordan adgangen til hver tjeneste styres (f.eks. IP-tilladelseslister, autentifikation, certifikater). ✓ Hvis de administreres af tredjeparter (f.eks. DNS, SD-WAN, hosted VPN), skal sikkerhedsklausulerne i SLA’en eller leverandørkontrakten gennemgås. Opdater jeres serviceregister, og angiv, hvor sikkerhedsansvaret ligger, internt eller eksternt.

Fra fasen Kontroller i praksis, trin 20: Kontroller 8.18 til 8.26.

Det giver en praktisk revisionsvej: Behandl DNS som en ekstern netværkstjeneste, dokumentér hvordan den er sikret, og registrér, om ansvaret ligger internt, hos en registrar, hos en DNS-udbyder eller hos en MSP.

Clarysecs Zenith Controls: Vejledning til tværgående efterlevelse Zenith Controls er nyttig, fordi DNS-styring sjældent kun kortlægges til ét framework. Den samme beslutning om DNSSEC eller registry lock understøtter revisionsbevis for ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

For leverandørovervågning kortlægger Zenith Controls ISO/IEC 27002:2022-kontrol 5.22, Overvågning, gennemgang og ændringsstyring af leverandørtjenester, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. For DNS betyder det, at jeres registrar og DNS-udbyder ikke er leverandører, der kan sættes op og derefter glemmes. Deres sikkerhedstilstand, serviceændringer, nedbrud, underdatabehandlere og underretningspraksis skal gennemgås.

For DNSSEC og kryptografisk integritet kortlægger Zenith Controls ISO/IEC 27002:2022-kontrol 8.24, Brug af kryptografi, som en forebyggende kontrol tilpasset sikker konfiguration. DNSSEC er ikke kryptering af DNS-trafik, men kryptografisk sikring af DNS-dataenes integritet og oprindelsesautentifikation.

For redigeringer af DNS-zoner kortlægger Zenith Controls ISO/IEC 27002:2022-kontrol 8.32, Ændringsstyring, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. En DNS-ændring er en konfigurationsændring. En opdatering af DS-record, ændring af MX-record, CNAME-migrering, SPF- eller DMARC-opdatering, CDN-overgang eller ændring af navneserverdelegering bør have en sag, risikovurdering, godkendelse, testresultat og tilbagerulningsplan.

DNSSEC, registry lock og nøglestyring for kritiske domæner

Ikke alle domæner har samme risiko. Et defensivt domæne, der kun bruges til at forhindre efterligning, kan have behov for overvågning og disciplineret fornyelse. Et primært kundeportaldomæne kræver de stærkeste tilgængelige kontroller.

For kritiske domæner anbefaler Clarysec typisk denne baseline:

• DNSSEC aktiveret og valideret, hvor det understøttes af registry, registrar og DNS-udbyder
• DS-records gennemgået efter enhver migrering af DNS-udbyder
• Dokumenteret proces for KSK- og ZSK-rotation, hvor nøgler administreres af kunden
• Registry lock aktiveret for primære produktions-, identitets-, API-, betalings- og e-maildomæner
• Registrar lock aktiveret for alle domæner, medmindre en midlertidig undtagelse er dokumenteret
• MFA håndhævet for alle brugere hos registrar og DNS-udbyder
• Privilegerede brugere er begrænsede, navngivne, godkendte og gennemgåede
• Break-glass-adgang dokumenteret og testet
• Zonefilovervågning med alarmer på ændringer af NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA og wildcard
• Ekstern overvågning fra flere resolvers og regioner
• Revisionsbevis opbevaret i ISMS-repositoriet

Clarysecs enterprise-Politik for kryptografiske kontroller Politik for kryptografiske kontroller giver styringsankeret for DNSSEC-nøgler:

Et centraliseret register for nøglestyring skal vedligeholdes for at registrere alle kryptografiske nøgler, deres livscyklusstatus, tildelte forvaltere og anvendelseskontekster.

Fra afsnittet “Styringskrav”, politikklausul 5.2.

Hvis jeres organisation administrerer DNSSEC-nøgler direkte eller kontrollerer DS-publicering hos registraren, bør registeret for nøglestyring dokumentere forvaltning, livscyklustilstand, rotationsdatoer og godkendelsesbeføjelse. Hvis DNS-udbyderen administrerer DNSSEC-nøgler, bør leverandørregistreringen forklare dette ansvar og indeholde dokumentation for sikkerhed.

Styring af adgang hos registrarer: MFA, mindst privilegieprincip og nødkontrol

Registrarkonti oprettes ofte tidligt i en virksomheds liv og glemmes derefter, efterhånden som virksomheden modnes. Stiftere, bureauer, udviklere, økonomibrugere og MSP’er kan alle have historisk adgang. Det er en alvorlig kontrolsvaghed.

Clarysecs Politik for styring af brugerkonti og privilegier - SME Politik for styring af brugerkonti og privilegier - SME fastslår:

Forhøjede eller administrative rettigheder kræver yderligere godkendelse fra direktøren eller IT-ansvarlig og skal dokumenteres, tidsbegrænses og underlægges periodisk gennemgang.

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

Anvend dette direkte på adgang hos registrarer og DNS-udbydere:

• Ingen delte administratorbrugere hos registrarer
• MFA for alle brugere, helst phishing-resistent hvor det understøttes
• Navngivne nødkontakter med dokumenteret bemyndigelse
• Adskillelse af faktureringsbrugere fra tekniske administratorer, hvor det er muligt
• Øjeblikkelig fjernelse af tidligere medarbejdere, bureauer og leverandører
• Kvartalsvis gennemgang af privilegeret adgang for kritiske domæner
• Undtagelser registreret med udløbsdatoer
• Testede nødprocedurer for oplåsning og genopretning, som ikke skaber usikre ændringer i produktionsmiljøet

Revisionsbevis for registry lock bør omfatte skærmbilleder eller registrarattester, der viser aktiveret status, autoriserede kontaktpersoner, unlock-proces og dato for seneste gennemgang.

Styring af zoneændringer: Små DNS-redigeringer, stor forretningspåvirkning

DNS-ændringer er tilsyneladende små. En TXT-record kan validere ejerskab af en SaaS-platform. En CNAME kan omdirigere kunder til et nyt miljø. En MX-record kan omdirigere e-mail. En CAA-record kan påvirke certifikatudstedelse. En forkert DS-record kan få et signeret domæne til at fejle validering.

Clarysecs P05 Ændringsstyringspolitik - SME P05 Ændringsstyringspolitik - SME fastslår:

Alle ændringer skal indsendes som en Change Request (e-mail, formular eller helpdesk-sag).

Fra afsnittet “Styringskrav”, politikklausul 5.1.1.

For enterprise-kunder hæver Clarysecs P05 Ændringsstyringspolitik P05 Ændringsstyringspolitik forventningen til revisionsbevis:

Alle ændringsanmodninger, gennemgange, godkendelser og understøttende bevismateriale skal registreres i det centraliserede ændringsstyringssystem.

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

Zenith Blueprint understøtter dette i fasen Kontroller i praksis, trin 21:

Vælg 2-3 nylige system- eller konfigurationsændringer, og kontrollér, om de blev behandlet via jeres formelle ændringsstyringsarbejdsgang.

✓ Blev risici vurderet? ✓ Blev godkendelser dokumenteret? ✓ Var der inkluderet en tilbagerulningsplan?

Validér, at ændringerne blev implementeret som planlagt, og at eventuelle hændelser eller uventede påvirkninger blev registreret. Gennemgå logfiler, versionsstyringsdiffs eller revisionsspor fra værktøjer som ServiceNow, Jira eller Git. Indfang denne proces i en oversigtslog for ændringsregistreringer som revisionsreference.

Fra fasen Kontroller i praksis, trin 21: Kontroller 8.27 til 8.34.

En DNS-specifik ændringssag bør omfatte berørt domæne og zone, recordtype, før- og efterværdier, forretningsmæssig begrundelse, risikovurdering, implementeringsvindue, godkender, implementeringsansvarlig, verifikationsansvarlig, kontroller af DNS-propagation, DNSSEC-validering, tilbagerulningsplan, overvågning efter ændringen og eksporteret revisionsbevis.

Revisionsprincippet er enkelt: DNS-ændringer skal kunne spores fra anmodning til godkendelse, implementering og verifikation.

Overvågning og logning: Opdag DNS-ændringen før kunderne gør

Et stærkt DNS-styringsprogram forudsætter, at forebyggelse kan fejle. Overvågning skal opdage uventede ændringer hurtigt nok til at understøtte hændelseshåndtering.

Clarysecs Politik for netværkssikkerhed - SME Politik for netværkssikkerhed - SME er eksplicit:

DNS-logning skal være aktiveret for at understøtte trusselsjagt og hændelseshåndtering

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

Enterprise-Lognings- og overvågningspolitik Lognings- og overvågningspolitik tager udgangspunkt i samme driftsmæssige forventning:

Alle omfattede systemer skal generere logfiler, der registrerer:

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

For DNS- og registrarstyring bør omfattede systemer omfatte registrarportaler, DNS-hostingkonsoller, API-baseret DNS-styring, CI/CD-pipelines, der udruller DNS som kode, SIEM-alarmer og eksterne overvågningsværktøjer.

Overvågning bør integreres i hændelseshåndtering. En DNS-alarm uden ejer, alvorlighedsvurdering eller runbook er kun støj.

NIS2, DORA og GDPR: DNS-styring som regulatorisk revisionsbevis

NIS2 Article 21 kræver passende og proportionale tekniske, driftsmæssige og organisatoriske foranstaltninger til at styre risici for net- og informationssystemer og minimere hændelsers påvirkning. DNS-styring kortlægges naturligt til aktivstyring, adgangsstyring, kryptografi, forsyningskædesikkerhed, hændelseshåndtering, forretningskontinuitet og vurdering af effektivitet.

NIS2 Article 20 gør også cybersikkerhed til et ansvar for ledelsesorganet. Bestyrelser behøver ikke at godkende hver TXT-record, men de bør forstå, om kritiske domæner er beskyttet med DNSSEC, registry lock, MFA, overvågning og testet genopretning. For væsentlige hændelser indfører NIS2 Article 23 trinvis rapportering, herunder tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer og en endelig rapport senest én måned efter hændelsesunderretningen.

For regulerede finansielle enheder gælder DORA fra 17. januar 2025 og fungerer som den sektorspecifikke ramme for IKT-robusthed, hvor den overlapper med NIS2. DNS understøtter ofte kritiske eller vigtige funktioner såsom betalingsapplikationer, mobilbank, handelsportaler, kundeidentitet, svigsystemer, API-gateways og tredjepartsintegrationer. DORA-bevis bør vise kortlægning af IKT-aktivafhængigheder, klassificering af hændelser, robusthedstest, tredjepartsrisikostyring og genopretningsplanlægning for scenarier med DNS- og registrarsvigt.

En DNS-hændelse er ikke automatisk et GDPR-brud på persondatasikkerheden. Den kan blive det, hvis brugere omdirigeres til et phishing-site, legitimationsoplysninger høstes, e-mail med personoplysninger omdirigeres, trafik til systemer, der behandler personoplysninger, aflyttes, eller tilgængeligheden af personoplysninger påvirkes væsentligt. GDPR Article 5 kræver integritet, fortrolighed og ansvarlighed. Article 32 kræver passende sikkerhedsforanstaltninger for behandling. DNS-styring giver revisionsbevis for, at domænerouting og DNS-afhængige tjenester er beskyttet med proportionale tekniske og organisatoriske foranstaltninger.

Opbyg en DNS-dokumentationspakke på én uge

En praktisk afhjælpningsplan for DNS-styring kan gennemføres hurtigt, hvis den er evidensdrevet.

Dag 1: Opret registeret over domæner og DNS-tjenester

Tag udgangspunkt i kravet i Politik for styring af aktiver - SME om at dokumentere ejerskab, formål, adgangsrettigheder og fornyelsesfrister.

Dag 2: Gennemgå adgang og rettigheder

Eksportér brugere hos registrar og DNS-udbyder. Fjern forældede konti. Håndhæv MFA. Identificér administratorer. Registrér godkendelsesbevis for privilegerede brugere, og dokumentér nødadgang.

Dag 3: Validér DNSSEC og låsning

For hvert kritisk domæne verificeres DNSSEC-kædevalidering, DS-recordnøjagtighed, DNSKEY-synlighed, registrar lock og registry lock. Hvis DNSSEC administreres af udbyderen, dokumenteres udbyderens ansvar. Hvis det administreres af kunden, tilføjes DNSSEC-nøgler og nøgleforvaltere til registeret for nøglestyring.

Dag 4: Omsæt DNS-ændringer til formelle ændringsregistreringer

Vælg de seneste tre DNS-ændringer, og test dem mod kriterierne i Zenith Blueprint trin 21: risiko vurderet, godkendelse dokumenteret, tilbagerulningsplan inkluderet, implementeret som planlagt og uventet påvirkning registreret. Opret en oversigtslog for ændringsregistreringer.

Dag 5: Knyt overvågning til hændelseshåndtering

Bekræft logfiler og alarmer for registrarlogin, zoneændringer, DNSSEC-ændringer, NS-ændringer, MX-ændringer, TXT-ændringer, CAA-ændringer og udbydernotifikationer. Send testalarmer til SOC eller IT-ansvarlig. Vedhæft revisionsbevis til ISMS-repositoriet.

Dag 6: Gennemgå leverandørforpligtelser

Brug vejledningen i Zenith Blueprint trin 23 for procedurer for leverandørændringer og overvågning:

Etabler en enkel, skalerbar procedure til vurdering af ændringer i leverandørtjenester (5.21), såsom migrering til cloud, nye underdatabehandlere eller redesign af infrastruktur. Definér udløsende forhold, der kræver fornyet sikkerhedsvurdering. Implementér derefter en tilbagevendende kadence for leverandørovervågning (5.22), tildel ejere til kritiske leverandører, og sørg for, at performance, efterlevelse og risici gennemgås mindst årligt.

Fra fasen Kontroller i praksis, trin 23: Organisatoriske kontroller 5.19 til 5.37.

Clarysecs enterprise-Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed giver det kontraktlige anker:

Kontrakter med leverandører skal indeholde:

Fra afsnittet “Styringskrav”, politikklausul 5.3.

Dag 7: Gennemfør en tabletop-øvelse

Simulér en uautoriseret ændring af en NS-record. Teamet skal opdage den, klassificere den, eskalere den, kontakte registraren, iværksætte registry lock-procedurer om nødvendigt, gendanne korrekt delegering, validere DNSSEC, underrette interessenter, vurdere GDPR-påvirkning og beslutte, om rapporteringstærskler efter NIS2 eller DORA er opfyldt. Indfang læringspunkter, og opdater procedurer.

Revisionsspørgsmål, almindelige konstateringer og bestyrelsesmetrikker

En DNS-styringsrevision udføres sjældent gennem kun ét perspektiv.

De mest almindelige konstateringer er forudsigelige.

Bestyrelser og ledelsesteams har behov for DNS-metrikker udtrykt i robusthedssprog. Nyttige målepunkter omfatter procentdel af kritiske domæner med DNSSEC aktiveret og valideret, procentdel med registry lock, antal registraradministratorer, procentdel af privilegerede brugere gennemgået i seneste kvartal, antal DNS-ændringer implementeret uden formelle sager, gennemsnitlig detektionstid for uautoriseret DNS-ændring, gennemsnitlig genopretningstid for korrekt DNS-konfiguration, domæner der udløber inden for 90 dage, gennemførte leverandørgennemgange og uafklarede DNS-overvågningsalarmer.

Gør DNS fra skjult risiko til revisionsklart bevis

Hvis jeres organisation ikke har gennemgået domæne- og DNS-styring inden for de seneste seks måneder, bør I antage, at der er sket afvigelser. Start med kritiske produktionsdomæner, og udvid derefter til regionale domæner, defensive domæner, testdomæner, opkøbsdomæner og domæner, der administreres af bureauer eller datterselskaber.

Clarysec kan hjælpe jer med at gå fra spredte registrarskærmbilleder til en struktureret dokumentationspakke ved hjælp af:

• Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint til trinvis validering af netværkstjenester, ændringsstyring, logning, overvågning og leverandørkontroller
• Zenith Controls: Vejledning til tværgående efterlevelse Zenith Controls til kortlægning af DNSSEC, registry lock, leverandørovervågning og styring af zoneændringer på tværs af ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST- og COBIT 2019-perspektiver
• Clarysec-politikskabeloner, herunder Politik for styring af aktiver - SME, P05 Ændringsstyringspolitik - SME, Politik for styring af brugerkonti og privilegier - SME, Politik for netværkssikkerhed - SME, Politik for styring af aktiver, P05 Ændringsstyringspolitik, Lognings- og overvågningspolitik, Politik for kryptografiske kontroller og Politik for tredjeparts- og leverandørsikkerhed

Jeres domæne er hoveddøren til jeres digitale forretning. I 2026 vil revisorer, tilsynsmyndigheder, kunder og bestyrelser forvente, at I kan dokumentere, at hoveddøren er låst, overvåget, genoprettelig og styret.

Download Clarysec-værktøjssættet, gennemfør én-uges-øvelsen med DNS-dokumentationspakken, eller book en Clarysec-vurdering for at omsætte DNS- og registrarstyring til revisionsklart bevis, før jeres egen mandag morgen-krise rammer.