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.

ℹ️ Note: Compliance is not the same thing as security. A compliant tenant can still be compromised. The value of the mapping is that it forces teams to review a baseline of controls that materially changes attacker effort.

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 requires essential and important entities to implement appropriate technical and organizational measures. For identity, that usually maps to the following controls:

CIS Controls v8

The CIS Controls turn identity hardening into prioritized defensive actions:

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:

• 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 |
  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

$checks = @{
    "Min password length >= 12"   = (Get-ADDefaultDomainPasswordPolicy).MinPasswordLength -ge 12
    "Password complexity enabled" = (Get-ADDefaultDomainPasswordPolicy).ComplexityEnabled
    "Max password age <= 90 days" = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge.Days -le 90
    "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
$cutoff = (Get-Date).AddDays(-7)
Get-ADGroup "Domain Admins" -Properties Members, whenChanged |
  Where-Object {$_.whenChanged -gt $cutoff} |
  Select-Object Name, whenChanged

# Enabled accounts inactive for 90+ days
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt (Get-Date).AddDays(-90)} |
  Select-Object SamAccountName, LastLogonDate

Remediation

💡 Quick Win: Pick one control family at a time and gather production evidence for it. Password policy, privileged access, and audit coverage usually produce the fastest compliance uplift.

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, age, 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.

ℹ️ Note: The value is in the mapping plus the evidence. A framework label is not a substitute for proving the tenant or domain was actually corrected.

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.

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.