AD and Azure Compliance: NIS2, ISO 27001, CIS Controls

What Is AD and Azure Compliance?

AD and Azure Compliance becomes useful only when framework requirements are translated into production evidence. In estates built on Active Directory and Microsoft Entra ID, that means proving how password policy, privileged access, MFA, audit logging, lifecycle governance, and third-party access controls are actually enforced.

The hard part is translation. Framework text is intentionally high level, while the technical evidence an auditor or security lead actually needs is specific: which password policy is active, which admin accounts still hold standing privilege, which sign-in protections are enforced, which logs are retained, and which guest or cross-tenant paths remain open.

This article maps common compliance requirements to technical identity controls that can be checked in AD and Azure without turning the exercise into a spreadsheet-only audit.

How It Works

Identity-focused compliance reviews usually examine five areas:

• Authentication policy such as password length, complexity, MFA, and legacy protocol exposure
• Privileged access control such as admin role scope, just-in-time access, and break-glass governance
• Audit and monitoring such as Advanced Audit Policy on Domain Controllers, Entra audit logs, and review cadence
• Access lifecycle such as provisioning, stale account cleanup, and deprovisioning
• External and application access such as guest governance, app consent, and cross-tenant trust

Each area can be translated into a set of technical checks and supporting evidence.

AD and Azure Compliance Framework Mapping

NIS2 Directive

NIS2 Article 21(1) requires Member States to ensure that essential and important entities take "appropriate and proportionate technical, operational and organisational measures" to manage their cybersecurity risks. For identity, that usually maps to the following controls:

CIS Controls v8.1

The CIS Controls turn identity hardening into prioritized defensive actions. Numbering follows CIS Controls v8.1, the current release, and is unchanged from v8:

ISO 27001:2022

The ISO 27001 Annex A controls most often mapped to directory security include:

ANSSI-Style Directory Hardening Expectations

For organizations aligning with ANSSI-style guidance, the practical identity themes are consistent — see the ANSSI Active Directory Guide for the full recommendation set:

• reduce legacy authentication and legacy cryptography where application compatibility allows it
• isolate or harden privileged accounts rather than letting daily-use identities keep standing privilege
• document exceptions for legacy systems instead of quietly carrying them forward indefinitely
• validate that monitoring, privileged access, and password controls are enforced in production rather than only declared in policy

The Compliance Gap Assessment

Step 1 - Baseline Your Current State

# Password policy baseline
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Entra Conditional Access baseline
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Audit policy baseline on a domain controller
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Step 2 - Map Gaps to Named Controls

$policy = Get-ADDefaultDomainPasswordPolicy

# Password expiration is deliberately NOT scored as a control. Microsoft dropped the
# password-expiration policies from its Windows security baselines in 2019 and calls periodic
# expiration "an ancient and obsolete mitigation of very low value". Capture MaxPasswordAge as
# evidence, and score it only where a framework or an internal policy still mandates rotation.
$policy.MaxPasswordAge

$checks = @{
    "Min password length >= 14"   = $policy.MinPasswordLength -ge 14
    "Password complexity enabled" = $policy.ComplexityEnabled
    "DS Changes audit enabled"    = (auditpol /get /subcategory:"Directory Service Changes") -match "Success"
    "Kerberos audit enabled"      = (auditpol /get /subcategory:"Kerberos Authentication Service") -match "Success"
}

$checks.GetEnumerator() | ForEach-Object {
    [PSCustomObject]@{
        Control = $_.Key
        Status  = if ($_.Value) { "PASS" } else { "FAIL" }
    }
} | Format-Table -AutoSize

Step 3 - Prioritize by Exposure, Not by Checkbox Count

1. Critical: No MFA for privileged identities, no control over high-risk role assignments, unconstrained delegation, DCSync-capable principals
2. High: Weak password policy, missing audit coverage, too many standing admins, weak guest governance
3. Medium: Stale accounts, missing LAPS, incomplete role review process, missing fine-grained controls where needed
4. Low: Documentation gaps, naming inconsistency, non-material presentation issues

Detection

Compliance evidence is weak if it exists only at audit time. The controls that matter should be continuously reviewable.

Continuous Compliance Checks

# Privileged group drift in the last 7 days, checked on every domain controller.
# whenChanged is NOT replicated - each DC maintains its own value - so querying a single DC silently
# misses a change that was written elsewhere.
$cutoff = (Get-Date).AddDays(-7)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-ADGroup "Domain Admins" -Properties whenChanged -Server $dc |
      Where-Object {$_.whenChanged -gt $cutoff} |
      Select-Object @{Name="DC";Expression={$dc}}, Name, whenChanged
}

# Enabled accounts inactive for 90+ days.
# -Filter is not a PowerShell script block: it only accepts <attr> <operator> <value>, so the cutoff
# has to be computed first. LastLogonDate is not in the default property set either, so it must be
# requested explicitly or the column comes back empty.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remediation

Priority Remediation Sequence

1. Enforce MFA for privileged accounts and sensitive cloud access
2. Reduce standing privilege by reviewing role assignments and using just-in-time elevation where available
3. Enable audit coverage on Domain Controllers and in Entra so control failures are reviewable
4. Fix password hygiene including length, complexity, banned-password lists, and exception sprawl
5. Clean stale and orphaned identities in AD and Azure
6. Review guest and cross-tenant access so third-party access is governed
7. Document justified exceptions with owner, reason, and review date

How EtcSec Detects This

EtcSec maps technical findings to the control families most often referenced in compliance work.

Each relevant finding helps answer three practical questions:

• which identity control is missing or weak
• which accounts, roles, or objects are affected
• what evidence the security team should collect to prove the gap is closed

The Compliance category is useful when you want to turn raw technical findings into an actionable remediation backlog rather than a generic framework spreadsheet.

AD and Azure Compliance Evidence Package

A strong compliance review usually fails for two reasons: the control was never implemented in production, or the team cannot prove that it was. Build an evidence package that survives both an internal challenge and an external audit:

• current password-policy output and any approved fine-grained exceptions
• privileged role and privileged group membership exports, including permanent assignments
• Conditional Access or Security Defaults state for the tenant in scope
• Domain Controller audit-policy output for the subcategories you rely on for detection
• guest, cross-tenant, and application access settings for the populations covered by the review
• owner, exception reason, and review date for anything that still cannot meet the target state

That evidence package is what turns AD and Azure Compliance from a presentation exercise into a repeatable control review.

Running One Review Instead of Three

Organizations facing NIS2, ISO 27001, and CIS Controls at the same time rarely need three separate review cycles. The three frameworks converge on the same handful of identity primitives — MFA, privileged access governance, password hygiene, and audit coverage — so a single technical review can produce evidence that satisfies all three mappings at once.

A practical sequencing approach:

1. Build one control baseline first. Capture password policy, Conditional Access state, audit-policy output, and privileged group membership once. Every framework mapping above draws from the same handful of data points.
2. Tag findings against every framework they satisfy, not just one. A single MFA gap on a Global Administrator account is simultaneously an NIS2 Article 21(2)(j) gap, a CIS Control 6 gap, and an ISO 27001 A.8.5 gap. Recording it once with multiple tags avoids re-collecting the same evidence three times.
3. Prioritize by attacker value, then backfill the paperwork. Fixing the highest-exposure gaps first — unconstrained delegation, DCSync-capable accounts, standing Global Admin access without MFA — closes findings across all three frameworks before a single compliance checkbox is filled in.
4. Keep exception documentation in one place. A legacy application that cannot support MFA is one exception record with one owner and one review date, not three separate justifications filed against three different frameworks.

This sequencing matters most for teams that inherited compliance work as a side effect of a security review, rather than teams starting from a blank framework document. The underlying technical evidence — password policy, audit coverage, privileged access state — does not change depending on which framework is asking for it.

Common Gaps That Reappear Every Quarter

Even mature teams tend to reopen the same identity compliance gaps:

• legacy application exceptions that quietly preserve weak authentication
• stale privileged identities that were never removed after a project or staff change
• Conditional Access exclusions added during an incident and never reviewed
• guest access paths that remain broader than the written policy allows
• monitoring controls that were documented once but are no longer validated on current Domain Controllers or current tenant scope

If those gaps are not tracked as operational debt with ownership, the framework mapping will look healthy while the attack surface remains largely unchanged.

Related Reading

For the technical side of the same control families, review Azure Privileged Access: Too Many Global Admins, Azure Identity Protection: Blocking Leaked Credentials, How to Audit Active Directory Security: Practical Checklist for Internal Teams, and Azure App Registrations: Over-Privileged Tenant Apps. Those articles help turn framework language into concrete hardening and validation steps.