Zero Trust Architecture 2026: revisionsklart bevismateriale

Den mandag morgen, hvor ingen havde planlagt en Zero Trust-revision

Kl. 08.12 en mandag modtager CISO’en i en europæisk SaaS-fintech tre beskeder inden for fem minutter.

Den første er fra en bankkunde: “Send venligst jeres bevispakke for Zero Trust Architecture til vores årlige gennemgang af IKT-tredjeparter.”

Den anden er fra juridisk afdeling: “Vi kan blive klassificeret som en vigtig enhed efter NIS2 i én medlemsstat, og nogle kunder spørger, om DORA videreføres til os som IKT-tjenesteudbyder.”

Den tredje er fra udviklingschefen: “Vi har MFA, SSO, EDR, Kubernetes-netværkspolitikker og SIEM-alarmer. Er det Zero Trust?”

Det er her, mange organisationer går i stå. De har sikkerhedsværktøjer, men ikke en driftsmodel for Zero Trust-efterlevelse. De kan pege på MFA-skærmbilleder, men kan ikke forklare, hvordan identitet, enheders sikkerhedstilstand, mindste privilegium, segmentering, overvågning, hændelsesrapportering, privatlivsbeskyttende foranstaltninger og leverandørafhængigheder hænger sammen. De kan vise kontroller, men ikke sporbarhed.

I 2026 skal Zero Trust Architecture baseret på NIST SP 800-207 være mere end “never trust, always verify”. For CISO’er, complianceansvarlige, revisorer og forretningsansvarlige er det praktiske spørgsmål mere præcist:

Hvordan omsætter vi Zero Trust til bevismateriale, der opfylder ISO/IEC 27001:2022, NIS2-forventninger til cyberhygiejne, DORA-styring af IKT-risiko, GDPR Article 32 om behandlingssikkerhed, kunders due diligence og bestyrelsestilsyn?

Svaret er ikke endnu et værktøj. Det er en risikobaseret bevismodel, der forbinder politikker, kontroller, teknisk implementering, overvågning og ledelsesmæssig ansvarlighed.

Zero Trust i 2026: fra sikkerhedsstrategi til bevismateriale for efterlevelse

NIST SP 800-207 definerer Zero Trust som et sæt principper for design og drift af sikre systemer, hvor tillid aldrig er implicit. Adgang tildeles på grundlag af identitet, kontekst, politik, aktivernes sikkerhedstilstand og løbende evaluering.

De syv NIST Zero Trust-principper er særligt nyttige, fordi de omsætter et uklart sikkerhedsslogan til noget, der kan kortlægges, testes og revideres:

1. Alle datakilder og databehandlingstjenester betragtes som ressourcer.
2. Al kommunikation sikres uanset netværkslokation.
3. Adgang til individuelle virksomhedsressourcer tildeles pr. session.
4. Adgang til ressourcer bestemmes af dynamiske politikker, herunder identitets-, enheds-, applikations- og adfærdsattributter.
5. Virksomheden overvåger og måler integriteten og sikkerhedstilstanden for alle ejede og tilknyttede aktiver.
6. Al autentifikation og autorisation af ressourcer er dynamisk og håndhæves strengt, før adgang tillades.
7. Virksomheden indsamler oplysninger om aktiver, infrastruktur og kommunikation og bruger dem til at forbedre sikkerhedstilstanden.

For en moderne SaaS-udbyder, digital bank, udbyder af administrerede tjenester eller cloud-native-platform omsættes disse principper til praktiske kontroldomæner:

• Identitet verificeres og styres.
• Enheder vurderes, før adgang tildeles.
• Privilegeret adgang minimeres og gennemgås.
• Netværksveje segmenteres og kontrolleres.
• Applikationer, API’er og datalagre håndhæver autorisation.
• Logfiler og telemetri understøtter løbende overvågning.
• Hændelser udløser inddæmning, rapportering og genopretning.
• Bevismateriale dokumenterer, at kontrollerne fungerer i drift og ikke kun er designet.

Det sidste punkt er dér, efterlevelse kommer ind.

ISO/IEC 27001:2022 kræver, at organisationer definerer kontekst, interessenter, relevante lovgivningsmæssige og kontraktlige krav, omfang, grænseflader og afhængigheder. Standarden kræver også risikovurdering, risikobehandling, en anvendelighedserklæring (SoA), ledelsens ansvarlighed, intern revision, ledelsens gennemgang og løbende forbedring.

Zero Trust passer naturligt ind i denne struktur, når det behandles som et kontrolsystem. Det bør ikke ligge uden for ISMS som et teknisk initiativ. Det bør indgå i risikovurdering, kontroludvælgelse, politikstyring, leverandørstyring, privatlivsbeskyttelse, hændelseshåndtering og rapportering til bestyrelsen.

Det regulatoriske pres bag Zero Trust-bevismateriale

Presset for Zero Trust-bevismateriale kommer normalt fra overlappende forpligtelser snarere end én enkelt standard.

NIS2 kan finde anvendelse på offentlige eller private enheder i Annex I- eller Annex II-sektorer, som opfylder tærskler for størrelse og aktivitet, og kan også gælde for visse mindre, men kritiske enheder. Annex I omfatter udbydere af cloud computing-tjenester, datacenterudbydere, udbydere af indholdsleveringsnetværk, udbydere af tillidstjenester, managed service providers, managed security service providers, banker og enheder inden for finansiel markedsinfrastruktur. Annex II omfatter digitale udbydere som onlinemarkedspladser, søgemaskiner og sociale netværksplatforme.

NIS2 Article 20 gør cybersikkerhed til et ansvar for ledelsesorganet. Bestyrelsen skal godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og modtage cybersikkerhedsuddannelse. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, der dækker risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, sårbarhedshåndtering, vurdering af effektivitet, cyberhygiejne, uddannelse, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og, hvor det er relevant, MFA eller løbende autentifikation. Article 23 indfører trinvis rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer, underretning inden for 72 timer og endelig rapportering.

DORA finder anvendelse fra 17. januar 2025 og etablerer en ensartet ordning for digital operationel robusthed for finansielle enheder. Den dækker styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af operationel robusthed, deling af trusselsinformation og IKT-tredjepartsrisiko. DORA Articles 5 og 6 kræver governance og en dokumenteret styringsramme for IKT-risikostyring. Article 9 omhandler beskyttelse og forebyggelse, herunder politikker, procedurer, protokoller og værktøjer til beskyttelse af IKT-systemer. Article 17 kræver en proces for styring af IKT-relaterede hændelser.

GDPR gælder for behandling i forbindelse med en etablering i EU og også for dataansvarlige eller databehandlere uden for EU, der udbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. GDPR Article 5 kræver ansvarlighed. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen. Article 33 kræver underretning om brud på persondatasikkerheden til tilsynsmyndigheden uden unødig forsinkelse og, hvor det er muligt, inden for 72 timer efter, at man er blevet bekendt med bruddet.

En Zero Trust-bevismodel hjælper, fordi den samme kontrol kan understøtte flere rammeværker. MFA kan understøtte ISO/IEC 27001:2022 adgangsstyring, NIS2-autentifikationsforanstaltninger, DORA-beskyttelseskrav og GDPR-behandlingssikkerhed. Men kun hvis organisationen kan dokumentere omfang, ejerskab, implementering, overvågning og gennemgang.

Kortlægning af NIST Zero Trust-principper til ISO/IEC 27001:2022-kontroller

ISO/IEC 27001:2022 Annex A-kontroller, understøttet af implementeringsvejledningen i ISO/IEC 27002:2022, giver det revisionssprog, som de fleste organisationer har brug for. Tabellen nedenfor oversætter NIST Zero Trust-principper til ISO-kontrolområder, som revisorer genkender.

Denne kortlægning er ikke kun en teknisk designøvelse. Den bliver strukturen for risikoregisteret, anvendelighedserklæringen (SoA), bevispakken og dagsordenen for ledelsens gennemgang.

Et risikoscenarie som “kompromitteret udviklerkonto ændrer produktionskode og tilgår kundedata” bør f.eks. kortlægges til identitetsstyring, MFA, privilegeret adgang, netværksadskillelse, logning, overvågning, sikker udvikling, ændringsstyring og hændelseshåndtering. Det ene scenarie kan understøtte ISO/IEC 27001:2022, NIS2 Article 21, DORA-styring af IKT-risiko og GDPR Article 32.

Clarysecs Zero Trust-kontrolstack

Clarysec bygger Zero Trust op omkring fem bevisdomæner: identitet, enhed, netværk, applikation og data, med overvågning og styring på tværs af alle fem.

Grundlaget er adgangsstyring og identitetsstyring. I Zenith Controls: den tværgående compliance-vejledning klassificeres ISO/IEC 27002:2022-kontrol 5.15, adgangsstyring, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedskonceptet Protect og er knyttet til kapabiliteten identitets- og adgangsstyring (IAM). Kontrol 5.16, identitetsstyring, er også forebyggende og knyttet til de samme CIA-egenskaber og IAM-kapabiliteten. Kontrol 8.16, overvågningsaktiviteter, klassificeres som opdagende og korrigerende og understøtter Detect og Respond gennem styring af informationssikkerhedshændelser.

Den kombination er afgørende. Zero Trust er ikke adgangsstyring alene. Det er adgangsstyring plus identitetslivscyklus plus enheders sikkerhedstilstand plus netværksadskillelse plus overvågning plus respons.

Clarysecs politikklausuler omsætter modellen til håndhævelig styring.

Fra Virksomhedspolitik for adgangsstyring, afsnittet Mål, klausul 3.4:

At understøtte zero trust-principper ved som udgangspunkt at afvise adgang, medmindre den er eksplicit godkendt og begrundet.

Fra Virksomhedspolitik for styring af brugerkonti og privilegier, afsnittet Krav til implementering af politikken, klausul 6.2.1:

Alle brugere skal tildeles det laveste adgangsniveau, der er nødvendigt for at udføre deres arbejdsfunktioner.

Fra Virksomhedspolitik for netværkssikkerhed, afsnittet Styringskrav, klausul 5.2:

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

Fra Virksomhedens lognings- og overvågningspolitik, afsnittet Mål, klausul 3.4:

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

Fra Virksomhedens informationssikkerhedspolitik, afsnittet Krav til implementering af politikken, klausul 6.6.1:

Alle implementerede kontroller skal kunne revideres, understøttes af dokumenterede procedurer og have opbevaret bevismateriale for drift.

For SMV’er kan den samme styringsintention implementeres med lettere politikdokumentation. Politik for styring af brugerkonti og privilegier - SMV, afsnittet Mål, klausul 3.2 angiver:

Håndhæv princippet om mindste privilegium, så brugere kun tildeles det laveste adgangsniveau, der er nødvendigt for at udføre deres opgaver.

Politik for adgangsstyring - SMV, afsnittet Styringskrav, klausul 5.4.3 tilføjer:

Privilegerede konti skal bruge multifaktorgodkendelse (MFA), hvor det understøttes.

Netværkssikkerhedspolitik - SMV, afsnittet Krav til implementering af politikken, klausul 6.2.3 angiver:

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

Lognings- og overvågningspolitik - SMV, afsnittet Formål, klausul 1.3 forklarer:

Logning og overvågning understøtter trusselsdetektion, regulatorisk efterlevelse, hændelsesrapportering og -håndtering samt forensisk analyse.

For privatlivsdrevet Zero Trust angiver Databeskyttelses- og privatlivspolitik - SMV, afsnittet Styringskrav, klausul 5.3.2:

Brugeradgang til personoplysninger skal begrænses til roller med et dokumenteret forretningsmæssigt behov.

Disse klausuler skaber revisionsankre. En revisor kan teste, om adgang som udgangspunkt afvises, privilegier minimeres, trafik mellem zoner kontrolleres, logfiler centraliseres, og bevismateriale opbevares.

Tværgående Zero Trust-kort over bevismateriale

En stærk Zero Trust-bevismodel bør undgå fragmenterede skærmbilleder. Bevismateriale bør vise styring, design, implementering, overvågning og gennemgang.

Denne tabel er kernen i et bestyrelsesklart Zero Trust-program. Den viser, hvordan ét kontrolmiljø kan understøtte flere assurance-krav uden at oprette separate bevispakker for hvert rammeværk.

Brug Zenith Blueprint til at skabe sporbarhed

Clarysecs Zenith Blueprint: en revisors 30-trins køreplan er designet til at forhindre, at Zero Trust bliver en udokumenteret teknisk filosofi. I fasen Risikostyring, trin 13, Planlægning af risikobehandling og anvendelighedserklæring, forklares det:

SoA er i praksis et brodokument: det forbinder din risikovurdering/-behandling med de
faktiske kontroller, du har. Når du udfylder det, kontrollerer du samtidig, om du har overset kontroller.

Det samme trin anbefaler at kortlægge kontroller til risici, tilføje Annex A-kontrolreferencer til poster i risikobehandlingen og krydshenvise til reguleringer som GDPR, NIS2 eller DORA, hvor kontroller implementeres for at opfylde disse forpligtelser.

For Zero Trust er dette den manglende bro. Hvis en revisor spørger, hvorfor I har implementeret betinget adgang, bør svaret ikke være “fordi Zero Trust siger det”. Et bedre svar er:

• Risikoscenariet er uautoriseret adgang til kundedata via kompromitterede legitimationsoplysninger.
• Risikoejeren er CTO’en eller udviklingschefen.
• Behandlingen omfatter SSO, MFA, betinget adgang, validering af endpoints sikkerhedstilstand, mindste privilegium, segmentering og overvågning.
• SoA kortlægger behandlingen til adgangsstyring, identitetsstyring, logning, overvågning, kryptografi, sårbarhedsstyring og styring af cloudtjenester.
• Den samme behandling understøtter NIS2 Article 21, DORA-styring af IKT-risiko og GDPR Article 32.
• Bevismateriale omfatter politikklausuler, gennemgang af adgangsrettigheder, SIEM-alarmer, EDR-rapporter om sikkerhedstilstand, firewallregler, IAM-eksporter, hændelsesøvelser og referater fra ledelsens gennemgang.

Det er sådan, Zero Trust Architecture bliver revisionsklar.

Endpoint-tillid, API’er og netværksadskillelse i praksis

Zero Trust fejler ofte, fordi organisationer fokuserer på identitet og overser enheds-, workload-, data- og netværkskontekst.

Zenith Blueprint trin 19, Teknologiske kontroller I, forklarer kravet til endpoints sikkerhedstilstand tydeligt:

Adgang til information via endpoints skal være kontekstbaseret. Opfylder enheden f.eks.
minimumskrav til sikkerhed, før den tilgår virksomhedens ressourcer? Har den for nylig bestået
en malware-scanning? Opretter den forbindelse fra en usædvanlig lokation eller et usædvanligt netværk? Integreret med Zero
Trust-principper kan endpoints sikkerhedstilstand indgå i betinget adgang, så adgang nægtes, indtil
enheden dokumenterer, at den er sikker.

Dette gør enheden til en del af autorisationsbeslutningen. En gyldig adgangskode fra en ikke-administreret bærbar computer bør ikke behandles på samme måde som et gyldigt login fra et compliant, krypteret og overvåget virksomhedsendpoint.

Det samme trin fremhæver, at adgangsbegrænsninger gælder for applikationer, tjenester og API’er, ikke kun brugere:

Adgangsbegrænsninger bør også anvendes på applikationer, tjenester og API’er, ikke kun personer.
En mikrotjeneste kan f.eks. kun have brug for læseadgang til en databasetabel, ikke fulde CRUD-
rettigheder. Et backupværktøj kan kun have brug for adgang til specifikke storage buckets, ikke alle tenant-ressourcer.

Den vejledning er kritisk for cloud-native-miljøer. API-scopes, servicekonti, workload-identiteter, Kubernetes-roller og cloud-IAM-politikker skal alle følge mindste privilegium. Menneskelig adgang er kun én del af kontrolfladen.

Trin 20 i Zenith Blueprint behandler netværksadskillelse:

Adskillelse er et af de ældste og mest effektive principper i cybersikkerhed: begræns
spredningen, reducer risikoen og inddæm skaden. Kontrol 8.22 fokuserer på netværks-
adskillelse, dvs. praksissen med at adskille systemer, tjenester og brugere på tværs af forskellige logiske eller
fysiske zoner for at forhindre uautoriseret adgang og begrænse lateral bevægelse ved
kompromittering.

Dette er kritisk for DORA- og NIS2-robusthed. Et Zero Trust-netværk bør antage, at én konto, workload eller endpoint kan blive kompromitteret. Segmentering forhindrer, at en lokal hændelse udvikler sig til en systemisk hændelse.

En 10-dages Zero Trust-bevispakke

Forestil dig en SaaS-fintech, der leverer sviganalyse til banker. Den behandler personoplysninger, bruger cloudinfrastruktur, er afhængig af administreret Kubernetes, integrerer med kunders API’er og bruger en tredjeparts identitetsudbyder. En kunde beder om Zero Trust-bevismateriale, og virksomheden har ti arbejdsdage.

En praktisk Clarysec-bevissprint vil se sådan ud.

Målet er ikke at foregive, at organisationen har opnået perfekt Zero Trust på ti dage. Målet er at skabe en forsvarlig beviskæde for de vigtigste risici og dokumentere, at programmet er styret, målbart og under forbedring.

Hvordan forskellige revisorer vil teste Zero Trust

En almindelig fejl er at forberede én teknisk fortælling og antage, at alle revisorer vil stille de samme spørgsmål. Det vil de ikke.

En ISO/IEC 27001:2022-revisor vil lede efter ledelsessystemet. Revisoren vil spørge, om Zero Trust-risici indgår i risikovurderingen, om behandlinger er godkendt, om SoA er fuldstændig, om politikker er styrede dokumenter, om gennemgang af adgangsrettigheder finder sted, om interne revisioner tester kontrollerne, og om ledelsens gennemgang følger op på performance.

En DORA-gennemgang vil spørge, om Zero Trust-kontroller er en del af den dokumenterede styringsramme for IKT-risikostyring. Der forventes aktiv- og afhængighedsfortegnelser, kortlægning af kritiske eller vigtige funktioner, hændelsesklassificering, eskalering til bestyrelsen, test, kontraktkrav til tredjeparter, revisionsrettigheder, exitstrategier og sporing af afhjælpning.

En NIS2-vurdering vil fokusere på ledelsesorganets ansvarlighed, cybersikkerhedsrisikostyringsforanstaltninger efter Article 21 og beredskab til hændelsesrapportering efter Article 23. Der forventes også bevismateriale for, at sikkerhed i forsyningskæden, forretningskontinuitet, sårbarhedshåndtering, adgangsstyring og cyberhygiejne er styret.

En GDPR-gennemgang eller privatlivsrevision vil spørge, om adgang til personoplysninger er nødvendig, dokumenteret, begrænset, overvåget og tilpasset behandlingsformål. Den vil undersøge roller som dataansvarlig og databehandler, detektion af brud på persondatasikkerheden, rollebaseret adgang, kryptering, pseudonymisering hvor relevant, opbevaring og ansvarlighed.

Den samme kontrol kan besvare flere spørgsmål, men kun hvis bevismaterialet er organiseret.

Leverandør-, cloud- og IKT-tredjepartsrisiko

Zero Trust stopper ikke ved firewallen, og i cloudmiljøer findes der måske slet ikke en traditionel firewallgrænse. Identitetsudbydere, cloudplatforme, CI/CD-værktøjer, udbydere af administreret detektion, betalingsformidlere, API-gateways og teams for outsourcet udvikling bliver alle en del af tillidsstrukturen.

NIS2 Article 21 omfatter udtrykkeligt sikkerhed i forsyningskæden for direkte leverandører og tjenesteudbydere, herunder leverandørsårbarheder, produkt- og tjenesters robusthed, leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling.

DORA kræver, at IKT-tredjepartsrisiko styres som en del af styringsrammen for IKT-risikostyring, med et register over IKT-tjenestekontrakter, due diligence før kontraktindgåelse, vurdering af kritikalitet, koncentrationsrisiko, kontraktlige sikkerhedskrav, assistance ved hændelser, samarbejde med myndigheder, revisionsrettigheder, opsigelsesrettigheder, exitstrategier og overgangsplaner.

For Zero Trust er den praktiske regel enkel: Stol ikke på en leverandørforbindelse, blot fordi den er kontraktlig. Kræv tekniske kontroller og bevismateriale.

En kunde-API-integration bør have afgrænsede tokens, hastighedsbegrænsninger, overvågning, rotation, ejerskab og tilbagekaldelse. En managed service provider bør bruge MFA, navngivne brugerkonti, mindste privilegium, sessionslogning og tidsbegrænset adgang. Et cloududbyderforhold bør have kortlægning af delt ansvar, krypteringskonfiguration, opbevaring af logfiler, backuptest og exitplanlægning.

Derfor hører leverandør- og cloudbevismateriale hjemme i Zero Trust-modellen og ikke i en separat indkøbsmappe.

Metrikker, der dokumenterer, at Zero Trust fungerer i drift

Bestyrelser og revisorer vil ikke kun have arkitekturdiagrammer. De vil have driftsbevismateriale og forbedringstendenser.

Nyttige Zero Trust-metrikker omfatter:

• Procentdel af privilegerede konti, der er beskyttet med MFA.
• Procentdel af brugere, der er omfattet af betinget adgang.
• Antal permanente privilegerede konti sammenlignet med just-in-time-konti.
• Antal forsinkede gennemgange af adgangsrettigheder.
• Procentdel af endpoints, der overholder krav til sikkerhedstilstand.
• EDR-dækning på tværs af kritiske aktiver.
• Antal afviste adgangsforsøg på grund af enheds- eller lokationsrisiko.
• Gennemsnitlig detektionstid (MTTD) for mistænkelig privilegeret aktivitet.
• Gennemsnitlig tid til at tilbagekalde adgang efter fratrædelse.
• Procentdel af firewallregler mellem zoner, der er gennemgået i det seneste kvartal.
• Antal kritiske leverandører med aktuelt sikkerhedsbevismateriale.
• Antal Zero Trust-undtagelser efter afhjælpningsdato.
• Procentdel af kritiske applikationer, der sender logfiler til SIEM.
• Resultater af hændelsessimulering for kompromitterede legitimationsoplysninger.

Disse metrikker understøtter ISO/IEC 27001:2022 løbende forbedring, NIS2-vurdering af effektivitet, DORA-forventninger til test og afhjælpning samt GDPR-ansvarlighed.

Almindelige fejl i Zero Trust-bevismateriale

De hyppigste fejl skyldes ikke manglende værktøjer. De skyldes svag sporbarhed.

For det første implementerer organisationer MFA, men kan ikke dokumentere, at privilegerede konti er fuldt dækket. Servicekonti, nødadgangskonti (break glass) og lokale administratorkonti ligger ofte uden for kontrollen.

For det andet udføres gennemgang af adgangsrettigheder manuelt, men uden kobling til forretningsroller, datafølsomhed eller risikoejere. Bevismaterialet viser, at nogen har klikket “gennemgået”, ikke at unødvendig adgang er fjernet.

For det tredje findes netværkssegmentering i diagrammer, men ikke i testede regler. Revisorer vil spørge, om adgang mellem segmenter som udgangspunkt afvises, og om undtagelser er godkendt.

For det fjerde indsamles logfiler, men de kan ikke omsættes til handling. En SIEM uden definerede brugsscenarier, alarmtriage og responsprocedurer dokumenterer ikke løbende overvågning.

For det femte er leverandøradgang ikke styret. Leverandører kan bruge delte konti, vedvarende VPN-adgang eller brede cloudroller uden sessionsovervågning.

For det sjette er privatlivsbevismateriale adskilt fra sikkerhedsbevismateriale. GDPR kræver dokumenterbar beskyttelse af personoplysninger, så identitets- og adgangskontroller skal kobles til datakategorier og behandlingsformål.

Endelig er undtagelser udokumenterede. Zero Trust kan tolerere undtagelser, hvis de er risikovurderede, godkendte, tidsbegrænsede og overvågede. Det kan ikke tolerere usynlige undtagelser.

Opbyg din Zero Trust-bevispakke med Clarysec

Zero Trust Architecture i 2026 er ikke et slogan. Det er en driftsmodel for efterlevelse, der forbinder identitet, enheder, applikationer, netværkssegmentering, mindste privilegium, løbende overvågning, leverandørkontrol og privatlivsbeskyttende foranstaltninger i ét system, der kan revideres.

Hvis du forbereder ISO/IEC 27001:2022-certificering, besvarer NIS2-kundeforespørgsler, tilpasser dig DORA-styring af IKT-risiko eller dokumenterer GDPR Article 32 om behandlingssikkerhed, så begynd med sporbarhed.

Brug Zenith Blueprint: en revisors 30-trins køreplan til at kortlægge Zero Trust-risici i dit risikoregister, din behandlingsplan og din SoA. Brug Zenith Controls: den tværgående compliance-vejledning til at tilpasse adgangsstyring, identitetsstyring og overvågning til tværgående rammeværksforventninger. Brug Clarysecs politikbibliotek, herunder Virksomhedspolitik for adgangsstyring, Virksomhedspolitik for styring af brugerkonti og privilegier, Virksomhedspolitik for netværkssikkerhed, Virksomhedens lognings- og overvågningspolitik, Virksomhedens informationssikkerhedspolitik og Databeskyttelses- og privatlivspolitik - SMV, til at omsætte arkitektur til håndhævelig styring.

Dit næste praktiske skridt er at vælge ét højrisikoscenarie, f.eks. kompromitteret privilegeret adgang til kundedata, og opbygge en komplet Zero Trust-beviskæde omkring det. Hvis du kan dokumentere scenariet fra ende til ende, har du fundamentet for et skalerbart, revisionsklart og regulatorisk robust Zero Trust-program.

Download Clarysecs politikpakker, eller book en strategisamtale for at se, hvordan Zenith Blueprint og Zenith Controls kan omdanne Zero Trust fra en revisionsrisiko til en efterlevelsesmæssig fordel.