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

AD and Azure Compliance should be anchored in production evidence, clear ownership, and a review process that survives the next infrastructure change.

What Is AD Security Compliance?

Security compliance frameworks — NIS2, ISO 27001, SOC 2, CIS Controls, ANSSI — define baseline security requirements for identity infrastructure. For organizations running Active Directory or Azure Entra ID, these frameworks translate into concrete technical controls: password policies, privileged access management, audit logging, MFA enforcement, and vulnerability management.

The challenge is that compliance requirements are often vague while the technical controls needed to meet them are specific. "Implement strong authentication" in a NIS2 requirement maps to a concrete list of AD and Azure settings. This article bridges that gap — mapping the most common compliance requirements to the specific Active Directory and Azure controls that satisfy them.

ℹ️ Note: Compliance is not the same as security. A compliant environment can still be compromised. But the controls required for compliance — when properly implemented — significantly reduce the attack surface covered throughout this blog.

How It Works

Compliance audits evaluate your environment against a defined control set. For identity infrastructure, auditors typically examine:

• Password and authentication policies — minimum length, complexity, MFA enforcement
• Privileged access controls — who has admin rights, how access is granted and reviewed
• Audit and monitoring — what events are logged, how long they are retained, who reviews them
• Vulnerability management — how quickly known vulnerabilities are remediated
• Access lifecycle management — how user access is provisioned, reviewed, and revoked

Each control maps to specific AD and Azure settings — and each setting is something EtcSec audits automatically.

Compliance Framework Mapping

NIS2 Directive (EU, 2024)

NIS2 requires essential and important entities to implement appropriate technical measures for identity security. Key requirements:

CIS Controls v8

The CIS Controls provide prioritized security actions. Identity-related controls:

ISO 27001:2022

ISO 27001 Annex A controls relevant to AD:

ANSSI Recommendations (France)

ANSSI's AD hardening guide defines specific technical requirements:

# ANSSI recommends: AES-only Kerberos encryption
Set-ADDefaultDomainPasswordPolicy -Identity corp.local -KerberosEncryptionType AES128,AES256

# ANSSI recommends: Disable RC4 fallback
Set-ADUser krbtgt -Replace @{msDS-SupportedEncryptionTypes=24}

# ANSSI recommends: Enable Protected Users for all admins
Add-ADGroupMember -Identity "Protected Users" -Members (Get-ADGroupMember "Domain Admins")

The Compliance Gap Assessment

Step 1 - Baseline Your Current State

# Quick compliance baseline — password policy
Get-ADDefaultDomainPasswordPolicy | Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# MFA status (Azure — requires Graph API)
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.State -eq "enabled"} |
    Select-Object DisplayName, State

# Audit policy status
auditpol /get /category:"Account Logon","DS Access","Account Management" | Select-String "Success|Failure"

Step 2 - Map Gaps to Framework Controls

# Generate a compliance gap report
$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 and Remediate

Prioritize by risk impact, not by compliance checkbox:

1. Critical: MFA not enforced, DCSync capable accounts, unconstrained delegation
2. High: Weak password policy, no audit logging, excessive privileged accounts
3. Medium: Stale accounts, missing LAPS, no fine-grained password policies
4. Low: Administrative naming conventions, documentation gaps

Detection

Compliance monitoring requires continuous assessment, not point-in-time audits.

Continuous Compliance Checks

# Schedule weekly: check for new DA members added without approval
$cutoff = (Get-Date).AddDays(-7)
Get-ADGroup "Domain Admins" -Properties Members, whenChanged |
    Where-Object {$_.whenChanged -gt $cutoff} |
    Select-Object Name, whenChanged

# Monthly: accounts with no activity in 90 days
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt (Get-Date).AddDays(-90)} |
    Select-Object SamAccountName, LastLogonDate | Measure-Object | Select-Object Count

Remediation

💡 Quick Win: Run a CIS benchmark self-assessment using the free CIS-CAT Lite tool against your Domain Controllers. It produces a scored report with specific remediation steps.

Priority Remediation Sequence

1. Enable MFA for all privileged accounts (Azure: Conditional Access; AD: use smart cards or FIDO2)
2. Enable audit logging — Advanced Audit Policy on all DCs
3. Fix password policy — minimum 14 chars, complexity, 90-day max age
4. Remove excessive DA members — audit and reduce to minimum
5. Deploy LAPS — eliminate shared local admin passwords
6. Disable stale accounts — automate with a weekly scheduled task
7. Enable AES-only Kerberos — disable RC4 fallback

How EtcSec Detects This

EtcSec maps its 426 vulnerability checks directly to compliance framework requirements. Every finding in an EtcSec report includes:

• The specific misconfiguration detected
• The risk level (Critical/High/Medium/Low)
• The compliance frameworks affected (NIS2, CIS, ISO 27001, ANSSI)
• Step-by-step remediation guidance

The Compliance category in EtcSec reports aggregates findings by framework, allowing you to generate a compliance gap report directly from your AD audit — without a separate assessment tool.

ℹ️ Note: EtcSec maps all findings to compliance frameworks automatically. Run a free audit to see your compliance posture across NIS2, CIS Controls, and ISO 27001.

Review Priorities

AD and Azure Compliance: Mapping NIS2, ISO 27001 and CIS to Real Controls should be handled as a real exposure inside your Active Directory estate, not as a single isolated setting. Start by defining the review perimeter: which privileged groups, service accounts, ACLs, GPO links, trusts, delegation settings, certificate templates, and admin workstations are affected, which business workflows depend on them, which privileges they expose, and which emergency exceptions were added over time. That scoping step prevents shallow remediation, because the technical symptom is often smaller than the operational blast radius. By documenting the full path from configuration to privilege, the team can prioritize changes that reduce risk quickly without breaking production access. This also creates a defensible baseline for later validation and gives leadership a clear explanation of why the issue matters now.

Adjacent Controls to Review

When attackers reach your Active Directory estate, they rarely stop at the first weak point. Around AD and Azure Compliance: Mapping NIS2, ISO 27001 and CIS to Real Controls, they normally test whether the exposed path can be chained with stale privileged accounts, unsafe group nesting, excessive delegation, weak password settings, writable GPO paths, and inherited ACL abuse. That means defenders should review not just the headline weakness but every nearby dependency that turns access into persistence or privilege escalation. Confirm which identities, roles, permissions, and trust assumptions can be reused by a motivated operator. If a fix closes only one object while leaving adjacent privilege paths untouched, the effective risk barely changes. A disciplined review of chaining opportunities is what turns this article topic into a practical hardening exercise rather than a one-time checkbox.

Evidence and Telemetry to Pull

A strong response to AD and Azure Compliance: Mapping NIS2, ISO 27001 and CIS to Real Controls needs evidence that can be reviewed by both engineering and detection teams. Pull Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, SYSVOL changes, and certificate or CA activity, compare recent changes with known maintenance windows, and isolate accounts or systems that changed behavior without a clear business reason. Use that evidence to answer three questions: when the risky path appeared, who can still use it, and whether similar exposure exists elsewhere in your Active Directory estate. Good telemetry review also helps you separate inherited technical debt from active misuse. That distinction matters, because the remediation plan for stale misconfiguration is different from the plan for a path that already shows attacker-like activity or repeated policy exceptions.

Adjacent Weaknesses Worth Reviewing

Very few environments contain AD and Azure Compliance: Mapping NIS2, ISO 27001 and CIS to Real Controls alone. In practice, the same tenant or directory segment often contains stale privileged accounts, unsafe group nesting, excessive delegation, weak password settings, writable GPO paths, and inherited ACL abuse, and those neighboring weaknesses decide whether the issue is merely noisy or truly critical. Review shared owners, inherited permissions, duplicated exceptions, and long-lived administrative shortcuts. Check whether the same team approved similar risky patterns in multiple places, because repeated decisions usually point to a process gap rather than a single technical bug. This broader review prevents partial cleanup and gives you a better chance of removing the entire attack path. It also improves audit readiness, because the final state is easier to explain and easier to monitor over time.

AD and Azure Compliance: Validation Before Sign-Off

A strong review of AD and Azure Compliance should end with production evidence, not with an assumption that the risky path disappeared. Before you close the finding, recheck the control mapping and the technical implementation behind it, the evidence retained for auditors and control owners, and the review cadence and ownership that keep the control alive. Confirm that the safer state applies to the scope that actually matters: the production OU, the effective role assignment, the application path, or the trust and delegation path an attacker would really abuse. Record the technical owner, the business dependency, and the rollback condition so the next review can tell whether the safer state was maintained.

Use a short sign-off checklist:

• verify the risky state is gone from the attacker's point of view, not only from an admin screenshot
• keep one before/after export or log sample that proves the affected scope changed
• document the owner and the exception decision if the control could not be fully enforced

For adjacent exposure, cross-check the result with Azure Privileged Access: Too Many Global Admins, How to Audit Active Directory Security: Practical Checklist for Internal Teams, Active Directory Security Audit Tools: What to Compare Before You Choose, and Azure App Registrations: Over-Privileged Tenant Apps. The same control gap often reappears in nearby identity paths, logging gaps, or delegated permissions, which is why the final validation step matters as much as the initial finding.

AD and Azure Compliance: Evidence to Keep for the Next Review Cycle

The next reviewer should not have to rebuild the case from memory. Keep the evidence that originally justified the finding, the proof that the change was applied, and the note that explains why the final state is acceptable. For this topic, the most useful evidence usually combines the mapping that links each control to a concrete technical safeguard, the proof that the safeguard is enabled and periodically reviewed, and the owner, review date, and exception note for residual risk. That compact pack makes quarterly or post-change reviews much faster and helps explain whether the issue was removed, reduced, or formally accepted.

If a later admin, policy, or application change reopens the path, this historical evidence also makes it easier to prove what drifted. That is what turns AD and Azure Compliance from a one-time check into a repeatable assurance process.

Related Reading

Review this topic together with Active Directory Monitoring: Security Event IDs That Matter, Azure Tenant Hardening: Fix Insecure Default Settings, Azure Identity Protection: Blocking Leaked Credentials, Active Directory Password Security: Misconfigurations That Matter, and Azure Conditional Access: MFA Bypass With Stolen Passwords. Those adjacent posts show how the same identity weaknesses usually chain together in a real assessment instead of appearing as isolated findings.

• Active Directory Monitoring: Security Event IDs That Matter
• Azure Tenant Hardening: Fix Insecure Default Settings
• Azure Identity Protection: Blocking Leaked Credentials
• Active Directory Password Security: Misconfigurations That Matter
• Azure Conditional Access: MFA Bypass With Stolen Passwords

Using those references keeps the remediation discussion focused on the full attack path rather than a single control gap.

Evidence to Preserve Between Reviews

Compliance-oriented identity reviews create the most value when the evidence survives beyond a single reporting cycle. Teams should retain the privileged access inventory, the owner for each exception, the technical proof behind every compensating control, and the audit trail showing when risky configurations were removed or accepted. That evidence is what lets a framework mapping support real governance instead of becoming a static spreadsheet exercise.