Revisionsunderlag för Active Directory-härdning inför 2026

Larmet kom in kl. 02.17. Ett privilegierat konto, som hade varit inaktivt i sex månader, hade precis ändrat ett kritiskt grupprincipobjekt (GPO). Nästan samtidigt såg SOC:en flera Kerberos-fel vid förautentisering från ett arbetsstationssubnät. Fem minuter senare utfärdades ett certifikat från Active Directory Certificate Services till ett konto som aldrig borde ha begärt ett.

Maria, CISO på ett medelstort fintechbolag, förstod innebörden. Organisationen hade inte bara upptäckt misstänkt aktivitet. Den hade upptäckt ett möjligt angrepp mot identitetsmiljöns kontrollplan.

Utredningen visade ett välbekant förlopp. En hotaktör komprometterade en äldre applikationsserver, hittade autentiseringsuppgifter i klartext för ett gammalt tjänstekonto och upptäckte att kontot fortfarande hade alltför omfattande privilegier. GPO-ändringen stoppades innan den replikerades vidare, men diskussionen i styrelserummet nästa morgon var rak.

“Hur kunde det här hända?” frågade VD:n. “Kan vi visa våra tillsynsmyndigheter och kunder att våra nycklar till kungariket faktiskt är under kontroll?”

Den frågan definierar Active Directory-härdning 2026. För många organisationer stödjer lokal eller hybrid Active Directory fortfarande filåtkomst, ERP-system, VPN, plattformar för säkerhetskopiering, Windows-servrar, privilegierad administration, äldre applikationer, Kerberos-autentisering och Entra ID-synkronisering. Om AD faller förlorar verksamheten inte bara autentisering. Den förlorar kontroll.

Tillsynsmyndigheter och revisorer förstår nu detta. Enligt NIS2 ska ledningsorgan godkänna åtgärder för hantering av cybersäkerhetsrisker och kan hållas ansvariga vid överträdelser. Enligt DORA ska finansiella entiteter hantera IKT-risk genom dokumenterad styrning och förmågor för skydd, detektering, respons och återställning. Enligt GDPR ska organisationer skydda personuppgifter med lämpliga tekniska och organisatoriska åtgärder och kunna visa ansvarsskyldighet. Enligt ISO/IEC 27001:2022 ska risker kopplade till Active Directory avgränsas, bedömas, behandlas, övervakas och styrkas med underlag.

Svaret är inte ännu en ostyrd checklista. Svaret är en försvarbar underlagsmodell som kopplar domänkontrollanter, Kerberos, Group Policy, AD CS, privilegierad åtkomst, loggning och återställning till ISMS, riskregister, tillämpbarhetsförklaring, policyramverk och revisionsspår.

Varför Active Directory fortfarande är en risk på styrelsenivå

De flesta komprometteringar av Active Directory är inte exotiska. De bygger vanligen på en kombination av alltför omfattande privilegier, inaktuella konton, bristande hantering av tjänstekonton, alltför tillåtande Group Policy, osäker delegering, svag Kerberos-konfiguration, riskfyllda certifikatmallar, opatchade domänkontrollanter, ofullständig övervakning och säkerhetskopior som aldrig har återställningstestats.

Konsekvensen för regelefterlevnad är direkt. Om en angripare får Domain Admin-rättigheter kan denne få åtkomst till personuppgifter, distribuera skadliga GPO:er, inaktivera säkerhetsverktyg, ändra loggar, manipulera säkerhetskopior, utfärda certifikat för persistens, röra sig lateralt in i sökvägar för molnidentitet och störa kritiska tjänster.

ISO/IEC 27001:2022 gör detta till en styrningsfråga innan det blir en teknisk fråga. Klausulerna 4.1 till 4.4 kräver att organisationen definierar kontext, intressenter, krav, omfattning och ISMS-processer. För en hybrid identitetsmiljö bör omfattningen uttryckligen inkludera domänkontrollanter, AD CS, privilegierade administratörsarbetsstationer, säkerhetskopieringssystem, servrar för identitetssynkronisering, hanterade tjänsteleverantörer och beroenden till molnidentitet.

Klausulerna 5.1 till 5.3 gör ledningen ansvarig för policy, resurser, roller och rapportering. Att rensa upp bland Domain Admins är inte bara en infrastrukturuppgift. Det är ett ledningsförankrat beslut om riskbehandling.

Klausulerna 6.1.1 till 6.1.3 kräver en repeterbar process för riskbedömning och riskbehandling, inklusive tillämpbarhetsförklaringen. Det är där Active Directory-härdning blir granskningsbar.

[ZB] Zenith Blueprint: en revisors färdplan i 30 steg Zenith Blueprint fångar detta i riskhanteringsfasen, steg 13, planering av riskbehandling och tillämpbarhetsförklaring:

SoA fungerar i praktiken som ett bryggdokument: den kopplar din riskbedömning/riskbehandling till de faktiska kontroller du har. Genom att fylla i den dubbelkontrollerar du också om du har missat några kontroller.

För Active Directory är den bryggan kritisk. En risk som “kompromettering av privilegierade AD-konton som leder till ransomware-distribution och obehörig åtkomst till personuppgifter” kan mappas till privilegierad åtkomst, säker autentisering, konfigurationshantering, loggning, övervakning, säkerhetskopiering, incidenthantering och kryptografiska kontroller. SoA kan därefter förklara varför varje kontroll är tillämplig, vilka regulatoriska skyldigheter den stödjer och vilket underlag som visar att den fungerar.

Underlagsstacken för Active Directory som revisorer förväntar sig

En härdad AD-miljö är inte revisionsklar bara för att inställningar finns. Enbart skärmbilder är svagt underlag. Enbart policyer är ofullständigt. En GPO-export utan godkännandehistorik är riskfylld. Starkt underlag visar styrning, genomförande, övervakning och förbättring.

Mognadsgapet är vanligtvis inte att alla kontroller saknas. Det är avsaknaden av ägarskap, granskningsfrekvens, undantagshantering och mappning. En revisor frågar inte bara om en privilegierad grupp finns, utan vem som äger den, vem som godkände medlemskapet, när den senast granskades, vilka loggar som samlas in och hur undantag löper ut.

Privilegierad åtkomst: den första AD-kontrollen att styrka med underlag

Den snabbaste vägen till kompromettering av Active Directory är alltför omfattande privilegier. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, lokala administratörer, delegerade OU-administratörer och administratörer för certifikatutfärdare kräver alla uttrycklig styrning.

[P11] Policy för hantering av användarkonton och privilegier Policy för hantering av användarkonton och privilegier anger organisationens förväntan:

Kontoregister (t.ex. Active Directory (AD), plattformar för identitets- och åtkomsthantering) ska skyddas med lämpliga kontroller för att förhindra obehörig åtkomst eller manipulation.

Från avsnittet “Styrningskrav”, policyklausul 5.6.

[P11S] Policy för hantering av användarkonton och privilegier – SME Policy för hantering av användarkonton och privilegier – SME ger en praktisk godkännanderegel:

Förhöjda eller administrativa privilegier kräver ytterligare godkännande av verkställande chef eller IT-ansvarig och ska dokumenteras, vara tidsbegränsade och omfattas av periodisk granskning.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.2.2.

I [ZC] Zenith Controls: guiden för tvärgående regelefterlevnad Zenith Controls mappas ISO/IEC 27002:2022-kontroll 8.2, privilegierade åtkomsträttigheter, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Guiden kopplar 8.2 till identitetshantering, åtkomsträttigheter, begränsning av informationsåtkomst, säker autentisering, distansarbete, loggning och övervakning. Den mappar även kontrollen till GDPR Articles 5(1)(f), 25 och 32, NIS2 Article 21-förväntningar på riskhantering och DORA:s IKT-riskstyrning för finansiella entiteter.

Zenith Blueprint, fasen Controls in Action, steg 19, förklarar den operativa förväntan:

A.8.2 – Privilegierade åtkomsträttigheter: ”Tilldelning och användning av privilegierade åtkomsträttigheter bör begränsas och hanteras.”

Begränsa superanvändarrättigheter för administratörskonton till endast dem som absolut behöver dem och hantera dem noggrant. Använd till exempel ett separat administratörskonto (använd inte administratörsrättigheter för dagligt arbete), godkänn och följ regelbundet upp vem som får domänadministratörs- eller root-privilegier. Använd även starkare kontroller för dessa konton (t.ex. MFA och loggning av deras åtgärder).

För AD ska en revisor kunna välja en privilegierad användare och följa hela kedjan: begäran, godkännande, verksamhetsmässig motivering, teknisk tilldelning, övervakning, granskning, borttagning och undantagshantering.

Ett praktiskt underlagspaket för privilegierad åtkomst bör omfatta:

1. Export av privilegierade AD-grupper, inklusive nästlade grupper.
2. Namngiven verksamhetsägare för varje privilegierad grupp.
3. Underlag för kvartalsvis åtkomstgranskning.
4. Separata administratörskonton för privilegierade uppgifter.
5. Ingen daglig e-postanvändning eller webbsurfning från privilegierade konton.
6. MFA eller nätfiskeresistent autentisering för privilegierade åtkomstvägar där det är tillämpligt.
7. Modell med privilegierad arbetsstation eller säker administrativ hoppvärd.
8. Loggning av ändringar i gruppmedlemskap och privilegierade operationer.
9. Förteckning över break-glass-konton med kompenserande kontroller.
10. Riskacceptans för undantag, med utgångsdatum.

Så stängde Maria den omedelbara iakttagelsen om tjänstekontot. Kontot dokumenterades som en högriskpost, Policy för hantering av användarkonton och privilegier – SME användes för att ifrågasätta stående privilegier, applikationsägaren identifierade minsta nödvändiga åtkomst, medlemskapet i Domain Admins togs bort och ändringen dokumenterades genom ändringshantering. SoA-posten för ISO/IEC 27002:2022-kontroll 8.2 uppdaterades för att visa riskreducering och mappning till GDPR Article 32 och NIS2 Article 21.

Kerberos och autentiseringsinformation

Kerberos möjliggör skalbar autentisering i Windows-miljöer, men svag konfiguration eller bristande tjänstekontohygien kan möjliggöra Kerberoasting, missbruk av biljetter, återspelningsattacker och långvarig persistens. Underlag bör omfatta autentiseringsinformation över hela livscykeln: lösenord, nycklar, biljetter, hemligheter för tjänstekonton, certifikat, återställningsprocesser och MFA-faktorer.

I Zenith Controls mappas ISO/IEC 27002:2022-kontroll 5.17, autentiseringsinformation, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den kopplas till identitetshantering, säker autentisering, roller och ansvar, godtagbar användning samt efterlevnad av policyer och standarder. Tvärmappningen kopplar den till GDPR:s riskanpassade skydd mot obehörig åtkomst, NIS2 Article 21(2)(j) om MFA eller kontinuerlig autentisering där det är lämpligt samt DORA-krav på robusta autentiseringsmekanismer inom IKT-riskhantering.

GDPR Article 5(1)(f) kräver att personuppgifter skyddas mot obehörig eller olaglig behandling samt mot oavsiktlig förlust, förstöring eller skada. Article 5(2) lägger till ansvarsskyldighet. Om AD-autentiseringsuppgifter ger åtkomst till HR-register, kundfiler eller postlådor blir Kerberos- och autentiseringskontroller underlag för GDPR.

NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säkert underhåll, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och MFA eller kontinuerlig autentisering där det är lämpligt.

För finansiella entiteter som omfattas av DORA ska autentiseringsberoenden beaktas inom ramverket för IKT-riskhantering. Om AD autentiserar personal till betalnings-, handels-, försäkrings-, kund- eller risksystem stödjer Kerberos-underlag operativ resiliens.

Styrning av Group Policy och konfigurationshantering

Group Policy är en av de mest kraftfulla säkerhetsmekanismerna i Active Directory. Den kan tillämpa brandväggar, begränsningar för lokala administratörer, revisionspolicy, inställningar för endpointskydd, regler för skriptkörning och säkra baslinjer över tusentals system. Den kan också försvaga samma kontroller om den används fel.

I Zenith Controls mappas ISO/IEC 27002:2022-kontroll 8.9, konfigurationshantering, som en förebyggande kontroll för säker konfiguration. Den kopplas till hantering av sårbarheter, ändringshantering, tillgångsförteckning, slutpunkter, privilegierad åtkomst, säker autentisering, loggning och övervakning. Guiden kopplar konfigurationshantering till GDPR Articles 5(1)(f), 25 och 32, NIS2 Article 21-förväntningar på säker konfiguration och riskhantering samt DORA-krav på IKT-systems tillförlitlighet, säkerhet och resiliens.

[P05S] Ändringshanteringspolicy – SME Ändringshanteringspolicy – SME anger:

Om en ändring omfattar känsliga data, systemåtkomsträttigheter eller externa integrationer krävs en granskning av säkerhetspåverkan. Den utsedda säkerhets- eller regelefterlevnadskontakten ska bedöma om ändringen inför ytterligare risker och rekommendera ytterligare skyddsåtgärder.

Från avsnittet “Riskbehandling och undantag”, policyklausul 7.5.1.

[P05] Ändringshanteringspolicy Ändringshanteringspolicy kräver:

Alla ändringsbegäranden, granskningar, godkännanden och stödjande underlag ska registreras i det centraliserade systemet för ändringshantering.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1.

Ett GPO-underlagspaket bör besvara fyra frågor:

1. Vem äger varje säkerhetsrelevant GPO?
2. Vilken baslinje tillämpar den?
3. Vem godkände ändringar i den?
4. Hur detekteras obehörig drift?

Zenith Blueprint, fasen Controls in Action, steg 19, beskriver baslinjearbetet:

Börja med att fastställa checklistor för konfiguration för alla större systemtyper: Windows-servrar, Linux-värdar, nätverksenheter, databaser och molntjänster. Dessa baslinjer bör spegla både bästa branschpraxis (såsom CIS Benchmarks) och ert interna riskläge.

För AD innebär det att GPO:er ska tillämpa dokumenterade baslinjer, inte odokumenterade preferenser. Underlag bör omfatta månatliga GPO-exporter, mappning till baslinjekrav, ändringsärenden för modifieringar, granskningar av delegerade behörigheter, poster över GPO-säkerhetskopior och larm vid ändringar i GPO:er med hög påverkan.

AD CS och PKI: den förbisedda angreppsvägen

Active Directory Certificate Services hamnar ofta utanför efterlevnadsgranskningar eftersom den fungerar tyst i bakgrunden. Angripare uppskattar den av samma skäl. Felkonfigurerade certifikatmallar, alltför omfattande registreringsbehörigheter, svaga utfärdandekontroller eller farliga Extended Key Usage-inställningar kan möjliggöra privilegiehöjning, impersonering och persistens.

AD CS hör hemma i kryptografiska kontroller, identitetshantering, privilegierad åtkomst och ändringshantering. Det räcker inte att säga “vi har PKI”. Organisationen ska veta vilka CA:er som finns, vilka certifikat som kan utfärdas, vem som kan begära dem, vilka mallar som möjliggör klientautentisering, vem som administrerar CA:n och om utfärdande övervakas.

[P18S] Policy för kryptografiska kontroller – SME Policy för kryptografiska kontroller – SME anger:

IT-supportleverantören ska upprätthålla en aktuell förteckning över kryptografiska verktyg och certifikat som används

Från avsnittet “Styrningskrav”, policyklausul 5.1.2.

[P18] Policy för kryptografiska kontroller Policy för kryptografiska kontroller inkluderar uttryckligen:

Public Key Infrastructure (PKI)

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.4.

NIS2 Article 21 omfattar policyer och procedurer för kryptografi och kryptering. GDPR Article 32 kräver säkerhet i behandlingen, inklusive konfidentialitet, riktighet, tillgänglighet och resiliens. DORA kräver att IKT-tillgångar som stödjer finansiella processer skyddas och kan återställas. AD CS kan stödja allt detta – eller undergräva allt detta.

Loggning, säkerhetskopiering och återställning av domänkontrollanter

Domänkontrollanter är inte vanliga servrar. De är autentiseringssystem, katalogrepliker, distributionspunkter för policy och återställningskritiska tillgångar. Om ransomware komprometterar AD beror återställningen på rena säkerhetskopior av domänkontrollanter, återställning av systemtillstånd, bevarade loggar, kända fungerande GPO:er, AD CS-säkerhetskopior, skyddade privata nycklar och dokumenterade återställningsrutiner.

[P22S] Loggnings- och övervakningspolicy – SME Loggnings- och övervakningspolicy – SME definierar förväntningar på autentiseringsloggar:

Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning

Från avsnittet “Styrningskrav”, policyklausul 5.4.2.

[P22] Loggnings- och övervakningspolicy Loggnings- och övervakningspolicy kräver:

Alla omfattade system ska generera loggar som fångar:

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1.

I en AD-beroende miljö bör omfattade system inkludera domänkontrollanter, AD CS-servrar, system för privilegierad åtkomst, administratörsarbetsstationer, servrar för identitetssynkronisering och konsoler för säkerhetskopiering.

Zenith Blueprint, fasen Controls in Action, steg 19, är tydlig:

Säkerställ att alla kritiska system (servrar, domänkontrollanter, brandväggar) vidarebefordrar loggar till ert SIEM eller er logginsamlare. Validera att logglagringen överensstämmer med er loggningspolicy (t.ex. 90 dagar online, 1 år i arkiv). Välj en nylig incident eller händelse och visa hur ni spårade den med hjälp av era loggar.

Den lyfter också klocksynkronisering, som mappas till ISO/IEC 27002:2022-kontroll 8.17, klocksynkronisering. Utan tillförlitlig tid blir loggkorrelation under en incident bräcklig.

[P15S] Policy för säkerhetskopiering och återställning – SME Policy för säkerhetskopiering och återställning – SME anger ett minimikrav på underlag:

Återställningstester genomförs minst kvartalsvis, och resultaten dokumenteras för att verifiera återställningsförmåga

Från avsnittet “Styrningskrav”, policyklausul 5.3.3.

Relevanta ISO/IEC 27002:2022-kontroller omfattar 8.13 Säkerhetskopiering av information, 8.15 Loggning, 8.16 Övervakningsaktiviteter, 8.17 Klocksynkronisering, 5.24 Planering och förberedelse för hantering av informationssäkerhetsincidenter, 5.29 Informationssäkerhet vid störning och 5.30 IKT-beredskap för verksamhetskontinuitet.

Ett praktiskt återställningsunderlag bör omfatta:

1. Förteckning över domänkontrollanter och ägarskap för FSMO-roller.
2. Underlag för omfattning, frekvens och oföränderlighet för säkerhetskopiering.
3. Validering av säkerhetskopiering av systemtillstånd.
4. Resultat från kvartalsvisa återställningstester.
5. Rutin för säkerhetskopiering och återställning av GPO:er.
6. Underlag för AD CS-säkerhetskopiering och skydd av privata nycklar.
7. Rutin för break-glass-autentisering.
8. Konfiguration för klocksynkronisering.
9. Åtgärdsplan för AD-kompromettering.
10. Erfarenhetsåterföring från skrivbordsövningar eller tekniska återställningsövningar.

NIS2 Article 23 är också relevant. Betydande incidenter kan kräva tidig varning inom 24 timmar från kännedom, incidentanmälan inom 72 timmar och en slutrapport senast en månad efter incidentanmälan. Om ett AD-avbrott stör väsentliga eller viktiga tjänster blir återställningsunderlag och incidenttidslinjer regulatoriskt underlag.

Tvärgående efterlevnadskarta för Active Directory-härdning

Active Directory-härdning är ett tydligt exempel på hur en kontrolluppsättning stödjer många skyldigheter.

För NIS2 är detta inte längre teoretiskt. Nationella åtgärder gäller för många medelstora och stora väsentliga eller viktiga entiteter i sektorer enligt bilaga I och bilaga II, och även för vissa entiteter oavsett storlek, inklusive betrodda tjänsteleverantörer, TLD-register, DNS-tjänsteleverantörer och utvalda kritiska tjänster.

För DORA är tidslinjen också reell. DORA tillämpas från den 17 januari 2025 och omfattar direkt många finansiella entiteter. Om en outsourcad MSP hanterar AD blir DORA:s krav på IKT-tredjepartsrisk relevanta, inklusive avtalsregister, leverantörsgranskning, revisionsrätt, incidentstöd, säkerhetsförväntningar och exitstrategier enligt Articles 28 och 30.

För GDPR är bryggan ansvarsskyldighet. Om AD styr åtkomst till personuppgifter bidrar granskningar av privilegierad åtkomst, autentiseringsunderlag, loggning, konfigurationsbaslinjer, certifikatkontroller och återställningstester till att visa lämpliga tekniska och organisatoriska åtgärder.

Bygg ett underlagspaket för AD-härdning under en sprint

En praktisk tvåveckorssprint kan omvandla fragmenterad AD-härdning till ett revisionsklart underlagspaket.

Dag 1 till 2: Avgränsa AD inom ISMS. Använd ISO/IEC 27001:2022-klausulerna 4.1 till 4.4 för att bekräfta om AD, Entra Connect, domänkontrollanter, AD CS, privilegierade administratörsarbetsstationer, säkerhetskopieringssystem och hanterade tjänsteleverantörer ingår i omfattningen. Dokumentera intressenter, inklusive tillsynsmyndigheter, kunder, revisorer, registrerade, verksamhetsägare och IT-drift.

Dag 3 till 4: Lägg till AD-risker i riskregistret. Inkludera kompromettering av domänkontrollanter, alltför omfattande privilegierad åtkomst, Kerberos-missbruk, GPO-manipulation, AD CS-felkonfiguration, kompromettering av identitetssynkronisering, fel i säkerhetskopiering och otillräcklig loggning. Tilldela ägare, sannolikhet, konsekvens och riskbehandlingsbeslut.

Dag 5 till 6: Uppdatera SoA. Följ Zenith Blueprint steg 13 och markera kontroller såsom privilegierade åtkomsträttigheter, autentiseringsinformation, konfigurationshantering, loggning, övervakning, säkerhetskopiering av information, incidenthantering, kryptografiska kontroller och ändringshantering som tillämpliga. Lägg till noter som kopplar dem till GDPR Article 32, NIS2 Article 21 och DORA:s IKT-riskhantering där det är relevant.

Dag 7 till 9: Samla in tekniskt underlag. Exportera privilegierade grupper, Kerberos-inställningar, GPO-förteckning, baslinjer för domänkontrollanter, CA-mallar, loggar över certifikatutfärdande, status för säkerhetskopieringsjobb och status för SIEM-inmatning. Lägg till ägare, datum, granskare, iakttagelse och åtgärdsstatus.

Dag 10 till 11: Genomför en workshop för kontrollgranskning. IT, säkerhet, regelefterlevnad och verksamhetsägare granskar undantag. Varför behöver detta tjänstekonto ett SPN? Varför kan den här gruppen redigera GPO:er? Varför kan den här mallen utfärda klientautentiseringscertifikat? Varför saknar den här domänkontrollanten loggvidarebefordran?

Dag 12 till 14: Paketera revisionsberättelsen. Skapa ett underlagspaket för AD-härdning med sammanfattning för ledningen, omfattning, risker, SoA-mappning, kontrollunderlag, öppna iakttagelser, åtgärdsplan och testschema.

Resultatet är en försvarbar berättelse: vi känner till risken, vi valde kontroller, vi införde dem, vi övervakar dem, vi testar återställning och ledningen har insyn.

Vanliga revisionsiakttagelser för Active Directory och stängningsåtgärder

Stängningsmönstret är konsekvent: policykrav, tekniskt genomförande, insamling av underlag, granskningsfrekvens, undantagshantering och rapportering till ledningen.

Omvandla Active Directory-härdning till revisionsklart underlag

Active Directory-härdning 2026 är inte en engångsstädning. Det är ett levande kontrollsystem som ska styras, styrkas med underlag och förbättras. Domänkontrollanter, Kerberos, Group Policy, AD CS, privilegierad åtkomst, loggning och återställning finns alla i skärningspunkten mellan säkerhetsdrift och regulatorisk ansvarsskyldighet.

Clarysec hjälper CISO:er, IT-ledare och regelefterlevnadsteam att bygga den bryggan. Använd Zenith Blueprint för att mappa AD-risker till ISMS, riskregister och tillämpbarhetsförklaring. Använd Zenith Controls för att korsreferera ISO/IEC 27002:2022-kontroller mot GDPR, NIS2, DORA, NIST CSF 2.0 och revisionsförväntningar. Använd Clarysecs policymallar, inklusive Policy för hantering av användarkonton och privilegier, Ändringshanteringspolicy, Policy för kryptografiska kontroller, Loggnings- och övervakningspolicy och Policy för säkerhetskopiering och återställning – SME, för att omvandla teknisk härdning till repeterbart underlag.

Om nästa revision, tillsynsbegäran eller kundens säkerhetsfrågeformulär frågar hur Active Directory kontrolleras, svara inte enbart med skärmbilder. Bygg underlagspaketet, koppla det till risk och visa att ledningen kan lita på identitetsmiljöns kontrollplan.

Börja med en sprint: privilegierad åtkomst, GPO-styrning, AD CS-granskning, loggning av domänkontrollanter och återställningstestning. Clarysec kan hjälpa er att strukturera det, styrka det med underlag och försvara det.