Styrning av Microsoft Entra Conditional Access 2026

Klockan är 09:12 en tisdag när Maria, informationssäkerhetschef på ett snabbväxande europeiskt fintechbolag, öppnar en DORA-beredskapsrapport som borde ha varit rutin. Hennes kontrollpanel för Microsoft Entra Conditional Access ser stark ut. MFA tillämpas för administratörer. Äldre autentisering är blockerad. Högriskinloggningar utmanas eller nekas. Känsliga finansapplikationer kräver kompatibla enheter. Webbläsaråtkomst från ohanterade slutpunkter är begränsad.

Sedan läser hon revisorns iakttagelse.

”Era Conditional Access-regler är tekniskt väl utformade, men de finns i ett vakuum. Visa oss den styrelsegodkända policy som kräver dessa inställningar. Visa oss ändringsposten för regeln som ändrades förra månaden. Visa oss hur policyn för högriskinloggningar var aktiv under den misstänkta credential stuffing-attacken. Visa oss hur detta underlag stödjer ISO 27001, DORA, NIS2 och GDPR.”

Identitetsteamet kan exportera konfigurationen. SOC kan visa inloggningsloggar. Chefen för regelefterlevnad kan hänvisa till en policymapp. Men ingen kan ta fram en sammanhängande, styrd beviskedja som kopplar samman risk, policy, godkännande, konfiguration, undantag, övervakning, incidentrespons, integritetskrav och ledningens genomgång.

Det är styrningsproblemet för Conditional Access 2026.

Microsoft Entra Conditional Access är inte längre bara en identitetsinställning. Det är ett kontrollsystem på styrelsenivå som avgör vem som får åtkomst till molntjänster, under vilka villkor, från vilka enheter, med vilken autentiseringsstyrka och med vilka sessionsbegränsningar. För reglerade organisationer måste dessa beslut kunna förklaras, försvaras och mappas mot skyldigheter enligt ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST och COBIT 2019.

Conditional Access är nu ett verifierbart kontrollsystem

Conditional Access ligger i skärningspunkten mellan identitet, enhetsstatus, applikationens känslighet, plats, inloggningsrisk, användarrisk, sessionsbeteende och loggning. En enda policy kan kräva MFA, kräva en kompatibel enhet, blockera åtkomst från en riskfylld plats, begränsa nedladdningar från ohanterade webbläsare eller framtvinga omautentisering när risken förändras.

Det gör Conditional Access till en av de starkaste kontrollpunkterna för Zero Trust i Microsofts molnmiljöer. Det gör den också mycket granskningsbar.

Enligt ISO/IEC 27001:2022 är en kontroll inte mogen bara för att den finns i en portal. Organisationen måste förstå sitt sammanhang, bedöma informationssäkerhetsrisker, välja riskbehandlingar, dokumentera tillämpbarhetsförklaringen, driva kontroller, övervaka effektivitet och förbättra över tid. Relevanta klausuler omfattar klausul 6.1.2 för riskbedömning, klausul 6.1.3 för riskbehandling, klausul 7.5 för dokumenterad information, klausul 8.1 för operativ planering och styrning, klausul 9.1 för övervakning och klausul 9.3 för ledningens genomgång.

Bilaga A, som är anpassad till ISO/IEC 27002:2022, ger det praktiska kontrollspråk som revisorer känner igen. Conditional Access stödjer ofta:

• 5.15 åtkomstkontroll
• 5.16 identitetshantering
• 5.17 autentiseringsinformation
• 5.18 åtkomsträttigheter
• 8.1 användares slutpunktsenheter
• 8.2 privilegierade åtkomsträttigheter
• 8.3 begränsning av informationsåtkomst
• 8.5 säker autentisering
• 8.15 loggning
• 8.16 övervakningsaktiviteter

För organisationer som omfattas av EU-regelverk är styrningskravet ännu tydligare. NIS2 Article 20 lägger ansvaret på ledningsorgan att godkänna och övervaka riskhanteringsåtgärder för cybersäkerhet. NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive åtkomstkontroll, policy för tillgångshantering, cyberhygien, incidenthantering, säkerhet i leveranskedjan, effektivitetsbedömning och flerfaktorsautentisering eller kontinuerlig autentisering där det är lämpligt. NIS2 Article 23 inför stegvis rapportering av betydande incidenter, inklusive en tidig varning inom 24 timmar, en incidentanmälan inom 72 timmar och en slutrapport inom en månad.

DORA ställer liknande förväntningar på finansiella entiteter. Article 5 kräver ett internt styrnings- och kontrollramverk. Article 6 kräver ett ramverk för IKT-riskhantering. Article 9 omfattar skydd och förebyggande, inklusive åtkomstbegränsningar och praxis för identitetshantering. Articles 10, 11, 17, 18 och 19 kopplar samman detektering, respons, återställning, IKT-incidenthantering, klassificering och rapportering. Eftersom DORA gäller från den 17 januari 2025 bör finansiella entiteter behandla Conditional Access som en del av underlaget för operativ resiliens, inte bara som identitetshärdning.

GDPR tillför integritetsperspektivet. Om Conditional Access skyddar system som behandlar personuppgifter stödjer det Article 5 ansvarsskyldighetsprinciper, Article 24 personuppgiftsansvarigs ansvar, Article 25 inbyggt dataskydd och Article 32 säkerhet i behandlingen. Om obehörig åtkomst misstänks kan Conditional Access-loggar bli en del av underlaget för bedömning och anmälan av personuppgiftsincident.

Misstaget är att behandla detta som separata revisionsförfrågningar. Det mogna arbetssättet är en styrningsmodell för Conditional Access som kan brytas ned per ramverk, tillsynsmyndighet, kund eller styrelsepublik.

Konfiguration är inte styrning

De flesta organisationer kan svara på frågan: ”Vad är konfigurerat?” Färre kan svara på de svårare frågorna:

• Varför är denna Conditional Access-policy konfigurerad på det här sättet?
• Vilket riskscenario behandlar den?
• Vilken policyklausul kräver den?
• Vem godkände ändringen?
• Vilka användare, applikationer och enheter är undantagna?
• Hur testas den?
• Vilka loggar visar att den fungerade?
• Hur ofta granskas den?
• Vad händer när den fallerar?

Det är här revisionsiakttagelserna vanligtvis uppstår. Policyer finns men är inte kopplade till Microsoft Entra-inställningar. Enhetsefterlevnad ägs av IT-drift men är inte mappad mot åtkomstkontrollrisk. Policyer för inloggningsrisk är aktiverade utan dokumenterade tröskelvärden eller eskaleringsregler. Sessionsbegränsningar är konfigurerade men testas aldrig från ohanterade enheter. Loggar bevaras men sammanställs inte till revisionsbevis.

Clarysec behandlar detta som ett spårbarhetsproblem. Varje Conditional Access-beslut ska koppla samman policy, risk, kontroll, konfiguration, underlag och granskning.

SME Cloud Usage Policy-sme Cloud Usage Policy-sme - SME anger:

Flerfaktorsautentisering (MFA) för administrativa konton och användarkonton

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

Den klausulen är mandatet. Conditional Access-regeln är tillämpningen. Inloggningsloggen är underlaget. Granskningsposten visar tillsynen.

SME Network Security Policy-sme Network Security Policy-sme - SME lägger till kravet på enhetsstatus:

System utan uppdaterat antivirus, patchar eller en godtagbar enhetsstatus måste blockeras eller sättas i karantän

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

I Microsoft Entra kan detta omsättas till ”kräv kompatibel enhet”, ”blockera plattformar som inte stöds”, ”begränsa ohanterade webbläsarsessioner” eller ”neka åtkomst till högriskapplikationer från okända enheter”. Men kontrollen är inte komplett förrän organisationen kan visa omfattning, godkännande, testning, undantag och övervakning.

Bygg styrningsgrunden före regeluppsättningen

Ett starkt Conditional Access-program börjar utanför Entra-portalen. Det börjar med ISMS, riskregister, åtkomstkontrollpolicy, policy för användning av molntjänster, SoA och underlagsmodell.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ger en praktisk ordningsföljd. I riskhanteringsfasen, steg 13, Risk Treatment Planning and Statement of Applicability, instruerar den organisationer att koppla kontroller till risker och regulatoriska drivkrafter:

Korsreferera regelverk: Om vissa kontroller införs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i riskregistret (som en del av motiveringen av riskkonsekvens) eller i SoA-anteckningarna.

För Conditional Access förändrar det beviskedjan. I stället för att säga ”Vi aktiverade MFA” kan organisationen säga:

• Riskscenario: Komprometterade autentiseringsuppgifter möjliggör obehörig åtkomst till kunddata i Microsoft 365 och finansiella SaaS-applikationer.
• Riskägare: Chef för IT-säkerhet.
• Behandling: Entra Conditional Access kräver stark MFA för privilegierade roller, MFA för användare, blockering baserad på inloggningsrisk, kompatibla enheter för känsliga applikationer och sessionsbegränsningar för ohanterade slutpunkter.
• ISO/IEC 27002:2022-mappning: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 och 8.16.
• Regulatorisk mappning: NIS2 Articles 20, 21 och 23, DORA Articles 5, 6, 9, 10, 17 och 18, GDPR Articles 24, 25, 32 och 33.
• Underlag: Policygodkännande, Conditional Access-export, ändringsärende, testresultat, inloggningsloggar, rapporter om enhetsefterlevnad, undantagsregister, SOC-ärenden och protokoll från ledningens genomgång.

Zenith Blueprint förklarar också i fasen Controls in Action, steg 19, varför enhetsstatus hör hemma i åtkomstbeslutet:

Åtkomst till information via slutpunkter måste vara kontextmedveten. Uppfyller till exempel enheten minimikraven för säkerhet innan den får åtkomst till organisationens resurser? Har den nyligen genomgått en skanning efter skadlig kod? Ansluter den från en ovanlig plats eller ett ovanligt nätverk? Genom integrering med Zero trust-principer kan slutpunktens status matas in i villkorsstyrd åtkomst, så att åtkomst nekas tills enheten visar att den är säker.

Det är den centrala styrningsprincipen. Conditional Access ska vara riskbaserad, kontextmedveten och producera revisionsunderlag.

Mappa Conditional Access-beslut mot kontrollmål

Ett moget program definierar standardiserade åtkomstbeslut och mappar därefter varje beslut mot styrningssyfte och underlag. Det förebygger policyspretighet och förenklar revisionsdialoger.

Enterprise Cloud Usage Policy Cloud Usage Policy stödjer central identitetsintegration:

Single Sign-On (SSO)-integration med organisationens IdP krävs för att säkerställa konsekvent autentisering.

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

Enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy gör övervakningen uttrycklig:

Användning av Single Sign-On (SSO)-system måste integreras med centrala identitetsleverantörer (t.ex. Active Directory (AD), Azure AD) och övervakas för avvikande inloggningsaktivitet.

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

Tillsammans kräver dessa klausuler mer än SSO. De kräver central identitetsarkitektur, konsekvent autentisering, övervakning av avvikande inloggningar och underlag som visar att åtkomstbeslut granskas.

Enhetsefterlevnad: kontrollen som revisorer kan testa

Enhetsefterlevnad är ett av de områden som är lättast att överskatta. En kontrollpanel kan visa 92 procent kompatibla enheter, men en revisor kommer att fråga om regeln gäller för de applikationer som är viktiga, om personliga enheter är tillåtna, om plattformar som inte stöds blockeras och om undantag är godkända.

Enterprise Remote Work Policy Remote Work Policy sätter baslinjen för godkännande:

BYOD-enheter måste uttryckligen godkännas och:

Från avsnittet ”Styrningskrav”, policyklausul 5.2.2.

Den korta meningen är viktig. BYOD är inte bara ett tekniskt tillstånd. Det är ett styrningsbeslut. I Conditional Access bör det omsättas i regler för enhetsägarskap, miniminivåer för efterlevnad, krypteringskrav, kontroller av patchning och skydd mot skadlig kod, mobilappskydd, hantering av uppdragstagare och granskning av undantag.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls mappar ISO/IEC 27002:2022 kontroll 5.15 åtkomstkontroll som förebyggande, med skydd av konfidentialitet, riktighet och tillgänglighet inom den operativa förmågan för identitets- och åtkomsthantering. Den kopplar också åtkomstkontroll till användares slutpunktsenheter eftersom ohanterade bärbara datorer, mobiler och stationära datorer kan undergräva centraliserad tillämpning av åtkomstkontroller.

Ett praktiskt kvartalsvis underlagspaket för Conditional Access-enheter bör omfatta:

• Godkänd baslinje för enhetsefterlevnad.
• Conditional Access-policyer som kräver kompatibla enheter.
• Applikationer som skyddas av dessa policyer.
• Export över undantagna användare, grupper, applikationer och plattformar.
• Trendrapport över icke-kompatibla enheter.
• Exempel på blockerade inloggningsloggar för icke-kompatibla enheter.
• Undantagsregister med ägare, skäl, utgångsdatum och riskacceptans.
• Protokoll från ledningens genomgång.

Detta underlagspaket stödjer operativ styrning enligt ISO/IEC 27001:2022, NIS2-cyberhygien, DORA-skydd och förebyggande samt ansvarsskyldighet enligt GDPR.

Inloggningsrisk: detektering måste bli beslutsunderlag

Riskbaserad Conditional Access är punkten där identitetsdetektering blir åtkomststyrning. Microsoft Entra kan utvärdera signaler som ovanliga inloggningsegenskaper, anonyma IP-adresser, omöjliga resor och läckta autentiseringsuppgifter. Men revisorer accepterar inte ”riskpolicy aktiverad” som slutligt svar. De kommer att fråga varför tröskelvärdena valdes, vem som granskar riskhändelser och när en högriskinloggning blir en incident.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME definierar ett minimikrav för loggning:

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

Från avsnittet ”Styrningskrav”, policyklausul 5.4.2.

Enterprise Logging and Monitoring Policy Logging and Monitoring Policy breddar den förväntade händelseuppsättningen:

Händelsetyper som ska samlas in (t.ex. inloggningar, åtkomstfel, konfigurationsändringar, administrativa kommandon, detektering av skadlig kod)

Från avsnittet ”Styrningskrav”, policyklausul 5.1.1.

För Conditional Access bör användbart underlag omfatta lyckade inloggningar, misslyckade inloggningar, resultat av Conditional Access-policy, MFA-metod, inloggningsrisk, användarrisk, enhetens efterlevnadsstatus, åtkommen applikation, plats, klientapplikation, resultat av sessionskontroll, historik över policyändringar och administrativa åtgärder.

Zenith Controls mappar ISO/IEC 27002:2022 kontroll 8.16 övervakningsaktiviteter som upptäckande och korrigerande, kopplad till begreppen Detect och Respond. Den kopplar övervakning till loggning, händelsebedömning, hotinformation, leverantörsövervakning och incidenthantering. Den mappar även övervakningsaktiviteter mot GDPR Articles 32 och 33, NIS2-incidentövervakning och rapportering, DORA-spårning av IKT-incidenter, NIST kontinuerlig övervakning och COBIT-säkerhetsövervakning.

En högriskinloggning som blockeras av Conditional Access är därför inte bara en säkerhetsvinst. Den är underlag för att förebyggande, upptäckande och responsbaserade processer är sammankopplade.

Sessionskontroller: kopplingen mellan åtkomst och dataskydd

Beslut före åtkomst räcker inte. När en användare väl är autentiserad avgör sessionskontroller hur stor exponering som kvarstår. Detta är särskilt viktigt för ohanterade enheter, uppdragstagare, distansarbete, delade terminaler, riskfyllda platser och applikationer som behandlar personuppgifter.

SME Application Security Requirements Policy-sme Application Security Requirements Policy-sme - SME anger:

Sessionshantering: Sessionsdata måste upphöra efter 15 minuters inaktivitet och innehålla varningar om tidsgräns där det är tillämpligt.

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

I Microsoft Entra-styrning kan detta mappas till inloggningsfrekvens, begränsningar av beständiga webbläsarsessioner, Conditional Access App Control, appstyrda begränsningar, blockerad nedladdning, omautentisering efter riskförändringar och känslighetsbaserade sessionsbegränsningar.

Sessionskontroller stödjer ISO/IEC 27002:2022 kontroll 8.3 begränsning av informationsåtkomst och 8.5 säker autentisering. De stödjer också GDPR Article 32 genom att minska obehörig visning, nedladdning eller beständig åtkomst till personuppgifter. För DORA bidrar sessionsbegränsningar till att begränsa exponering i IKT-system och stödjer detektering och respons. För NIS2 är de proportionerliga åtgärder för åtkomstkontroll och cyberhygien.

Underlaget bör förklara varför sessionskontrollen finns. Till exempel bör ”blockera nedladdning från ohanterade enheter för HR- och finansapplikationer” mappas mot läckage av personuppgifter, kompromettering av slutpunkter och förlust av konfidentialitet. Underlaget bör omfatta konfiguration, applikationsomfattning, testinloggningar från hanterade och ohanterade enheter, loggar som visar begränsningar och godkännandeposter.

Skapa ett kontrollregister för Conditional Access

Ett kontrollregister för Conditional Access är den operativa bryggan mellan riskregistret, tillämpbarhetsförklaringen och Microsoft Entra-konfigurationen. Det ersätter inte dessa dokument. Det gör dem användbara.

Använd en granskningscykel i fem steg:

1. Bekräfta omfattning: Identifiera molnapplikationer som behandlar reglerade, finansiella, operativa eller personliga data.
2. Mappa policyer mot risker: Koppla varje Conditional Access-policy till minst ett riskscenario och en riskägare.
3. Validera undantag: Exportera undantagna användare, roller, appar, grupper, platser och enheter. Varje undantag behöver ägare, skäl, godkännande och utgångsdatum.
4. Testa tillämpningen: Använd testkonton för att verifiera MFA, enhetsefterlevnad, riskblockering, blockering av äldre autentisering och sessionsbegränsningar.
5. Paketera underlag: Lagra exporter, skärmdumpar, loggar och godkännanden med metadata.

SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME är avgörande för underlagets integritet:

Metadata (t.ex. vem som samlade in det, när och från vilket system) måste dokumenteras.

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

Skärmdumpar utan källa, datum, insamlare och systemkontext är svagt underlag. Conditional Access-exporter, inloggningsloggar och granskningsrapporter bör behandlas som kontrollerade revisionsunderlag.

Tvärgående efterlevnadsmappning för Conditional Access-underlag

Värdet med Conditional Access är att en och samma kontrolluppsättning kan uppfylla flera revisionsperspektiv när den styrs korrekt.

Zenith Controls mappar också 5.15 åtkomstkontroll till GDPR Article 32, NIS2 Article 21(2)(i), DORA-begrepp för åtkomststyrning, NIST SP 800-53-familjer för åtkomstkontroll och COBIT 2019 DSS06.04. Den mappar 8.5 säker autentisering till GDPR Articles 5, 24, 25 och 32, NIS2-riskhantering för cybersäkerhet, DORA IKT-riskhantering, NIST identifiering och autentisering samt COBIT identitet och logisk åtkomst.

Lärdomen är enkel. Ramverk använder olika språk, men de förväntar sig samma mönster för säkerhetsförsäkran: rätt användare, från godtagbara kontexter, med stark autentisering, genom styrda sessioner och med loggar som visar vad som hände.

Hur revisorer granskar Conditional Access

En ISO/IEC 27001:2022-revisor börjar med ISMS. Revisorn frågar om Conditional Access ingår i omfattningen, vilka risker den behandlar, hur den framgår av SoA, hur policyer godkänns, hur ändringar styrs och om underlaget visar operativ effektivitet. Förvänta dig stickprov på privilegierade användare, känsliga applikationer, undantag och nyliga policyändringar.

En DORA- eller NIS2-revisor fokuserar på operativ resiliens, ledningsansvar och risk. De kan fråga hur åtkomstkontroller skyddar kritiska eller viktiga funktioner, hur styrelsen övervakar identitetsrisk, hur högriskinloggningar triageras och om åtkomstfel matas in i beslut om incidentklassificering eller rapportering.

En GDPR-inriktad revisor bryr sig om personuppgifter. De kan fråga hur HR-, finans- eller kunddata skyddas från ohanterade enheter, hur sessionskontroller minskar obehörig visning, hur åtkomst begränsas till behöriga användare och hur loggar stödjer incidentbedömning.

En COBIT 2019-granskare söker efter styrningspraxis, ägarskap, mätetal, repeterbarhet, prestationsövervakning och förbättring. En NIST-orienterad bedömare jämför resultat för identitet, autentisering, auktorisering, övervakning och respons mot tekniskt underlag.

Enterprise Access Control Policy Access Control Policy sätter nivån för privilegierad åtkomst:

Administrativ åtkomst måste styras strikt genom:

Från avsnittet ”Styrningskrav”, policyklausul 5.4.1.

Ditt Microsoft Entra-underlag måste operationalisera den meningen. Vilka roller är privilegierade? Vilka kräver phishingresistent eller stark MFA? Vilka är berättigade genom privilegierad identitetshantering? Vilka konton är nödkonton? Vilka är undantagna från policyer? Vem granskar dem? Vart skickas larm?

Styrelsemätetal för styrning av Conditional Access

Eftersom NIS2 och DORA betonar ledningsansvar bör rapportering av Conditional Access vara läsbar för styrelsen. Rapportera inte bara policynamn. Rapportera riskläge och kontrollprestanda.

Användbara mätetal omfattar:

• Andel privilegierade konton som skyddas av stark MFA.
• Antal Conditional Access-undantag per risknivå.
• Antal högriskinloggningar som blockerats, utmanats eller tillåtits.
• Andel åtkomst till känsliga applikationer som kräver kompatibla enheter.
• Antal sessioner från ohanterade enheter till reglerade applikationer.
• Tid till triagering av högriskinloggningar.
• Antal ändringar av Conditional Access-policyer under kvartalet.
• Antal utgångna, förnyade och försenade undantag.
• Täckning för loggning av autentisering, sessioner och policyändringar.
• Underkända testfall från kvartalsvis validering av Conditional Access.

Dessa mätetal omvandlar identitetskonfiguration till underlag för tillsyn. De hjälper också ledningsorgan att visa godkännande, granskning, resurssättning och ständig förbättring.

Vanliga iakttagelser att eliminera före revisionen

Iakttagelser avseende Conditional Access beror vanligtvis på svag styrning, inte tekniska fel. De vanligaste problemen omfattar:

• Nödkonton är undantagna men övervakas inte.
• Policyer namnges inkonsekvent och saknar ägare.
• Känsliga applikationer saknas i regler för enhetsefterlevnad.
• Gästanvändare och externa samarbetspartner kringgår standardkontroller.
• Tjänstekonton och arbetslastidentiteter styrs inte separat.
• Detekteringar av inloggningsrisk triageras inte eller kopplas inte till incidenter.
• Sessionskontroller testas aldrig från ohanterade enheter.
• Policyändringar görs direkt i produktionsmiljö utan ändringsposter.
• Undantag är permanenta, odokumenterade eller muntligt godkända.
• Loggar bevaras men granskas inte.
• Underlag saknar metadata, källkontext eller beviskedja.

Ett målbildsläge för 2026 har ledningsgodkänd åtkomststyrning, riskbaserad utformning av Conditional Access, uttrycklig mappning mot ISO/IEC 27001:2022 och ISO/IEC 27002:2022, dokumenterat stöd för NIS2, DORA och GDPR, stark MFA efter roll och risk, enhetsefterlevnad för känslig åtkomst, sessionsbegränsningar för ohanterade kontexter, övervakad autentisering och övervakade policyändringar, en livscykel för undantag, kvartalsvis testning och ledningsrapportering.

Gör Microsoft Entra till revisionsklart underlag

Dina Conditional Access-policyer fattar redan säkerhetsbeslut varje minut. Frågan är om dessa beslut är styrda, riskbaserade, övervakade och mappade mot de skyldigheter som dina revisorer och tillsynsmyndigheter bryr sig om.

Börja med Zenith Blueprint Zenith Blueprint, särskilt steg 13, för att koppla Conditional Access-policyer till risker, behandlingar, tillämpbarhetsförklaringen och regulatoriska anteckningar. Använd Zenith Controls Zenith Controls för att mappa åtkomstkontroll, säker autentisering, slutpunktsstatus, loggning och övervakning över ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST och COBIT 2019.

Anpassa därefter dina interna krav till Clarysec-policyer, inklusive Cloud Usage Policy-sme, Network Security Policy-sme, Logging and Monitoring Policy-sme, Audit and Compliance Monitoring Policy-sme, Application Security Requirements Policy-sme, Cloud Usage Policy, User Account and Privilege Management Policy, Remote Work Policy, Access Control Policy och Logging and Monitoring Policy.

Clarysec hjälper dig att omvandla Microsoft Entra Conditional Access från en samling inställningar till ett bindande, mätbart kontrollsystem med beredskap för revision. Ladda ner relevanta Clarysec-verktygspaket, begär en granskning av policymappning eller boka en bedömning för att se om ditt Conditional Access-underlag håller för granskning enligt ISO 27001, NIS2, DORA och GDPR.