ENS & ISO 27001 Checklist in Microsoft 365 and Azure (2025) — Complete Guide

Executive summary and overview

The client needs to demonstrate that its information is protected and that such protection is sustainable. ENS sets measures for the Public Administration and providers; ISO 27001 structures the management system (ISMS) with policies, risks, controls, metrics, and review. The Microsoft platform provides native capabilities to materialize those controls and generate repeatable evidence.

The conceptual flow is straightforward: strong identity (Entra ID) → classified and protected data (Purview) → governed configuration (Azure Policy) → assessed posture (Defender for Cloud, MDE) → logging and detection (Log Analytics, Sentinel) → response and continuity (playbooks, backup/DR). Each block adds technical barriers and creates an auditable footprint.

ENS & ISO 27001: what they are, who they apply to, and how they fit together

ENS (Royal Decree 311/2022) structures security measures by categories (Basic/Medium/High) and relies on CCN-STIC guides that translate requirements by technology (for example, profiles for Azure and secure configurations for Microsoft 365). It applies to public-sector bodies and providers that deliver services to them, with a special focus on proportionality and traceability.

ISO/IEC 27001:2022 defines ISMS requirements and Annex A with 93 controls. It integrates risk management, scope, the Statement of Applicability (SoA), and continuous improvement (PDCA). It is certifiable by third parties, which brings external recognition and internal discipline.

Both frameworks are compatible: ISO provides the system and ENS provides the national catalogue of measures. In Microsoft, equivalence is supported by official mappings (for example, Azure Policy initiatives for ISO 27001 and ENS-specific documentation for Azure/M365) that facilitate verification.

Operating model in Microsoft: governance and responsibilities

The operating structure prevents controls from depending on specific people and facilitates auditing. Separation of duties and documented delegation are key: who designs, who approves, who deploys, and who monitors.

A practical cadence: monthly (privileges, access policies, anomalies), quarterly (DLP/retention, Policy exceptions, posture), semiannual (restore tests), annual (full internal audit and updated risk analysis).

Prerequisites, licensing, and functional scope

Before deploying, confirm which components are available in the tenant and subscriptions. This avoids coverage gaps and ensures visibility.

• Entra ID: multifactor authentication, Conditional Access, Privileged Identity Management, auditing, and access reviews.
• Microsoft Purview: classification and labels, label-based encryption, DLP for Email/SharePoint/OneDrive/Teams/endpoints, retention policies, eDiscovery.
• Defender: Microsoft Defender for Endpoint (EDR, vulnerabilities, isolation), Defender for Office/Apps/Identity, and Defender for Cloud for Azure.
• Azure: Management Groups, Azure Policy, Log Analytics, Microsoft Sentinel, Key Vault (CMEK), Backup, storage with immutability.
• Compliance portals: provider catalogs and documentation to append as reference in the client’s audits.

Step-by-step methodology: from requirement to evidence

The sequence turns requirements into controls and controls into repeatable evidence:

1. Define scope: services, processed data, ENS category, and risk appetite. Determine zones (DEV/TEST/PROD) and internal/external dependencies.
2. Map controls: relate ENS/ISO requirements to Microsoft capabilities: identity, data, network, configuration, logging, detection, response, and continuity.
3. Identify gaps: assess impact and likelihood; estimate remediation effort; prioritize quick wins that reduce the most risk.
4. Apply remediation: policy-as-code, Policy initiatives, scoped assignments, tags, documented exceptions with expiry date.
5. Consolidate evidence: time-bound signed exports, reports with clear filters and periods, screenshots with context, custody location, and owners.
6. Review and improve: internal audit, corrective actions, lessons learned, and incorporation into procedures.

Identity and access (Entra ID)

Most modern incidents rely on credentials. Access control in Entra ID drastically reduces that attack surface.

Objectives

• Universal strong authentication: MFA for all identities (including supported service accounts).
• Conditional Access: require conditions by context (user and session risk, platform, device compliance, location).
• Ephemeral privileges: PIM to grant just-in-time admin with approval, logging, and expiry.
• Resilience: controlled break-glass accounts, monitored and for exceptional use only.
• Continuous review: Access Reviews campaigns for critical roles and groups.

Suggested implementation

1. Inventory current roles and admins; remove direct assignments and delegate via groups.
2. Create baseline Conditional Access policies: require MFA, block unused high-risk countries, require compliant device for sensitive apps.
3. Enable PIM for global and service roles; define approval flows and minimum viable durations.
4. Configure two emergency accounts with usage controls and alerts; out-of-band custody.
5. Plan quarterly access reviews and remove inactive members.

Useful evidence

• Export of Conditional Access policies with list of exclusions and rationale.
• PIM activity reports (activations, reasons, durations, approvals).
• Minutes from access reviews with decisions and owners.

Data protection and privacy (Microsoft Purview)

The goal is for information sensitivity to travel with the data and for improper exits to be prevented or clearly recorded.

Objectives

• Classification and labeling: simple, understandable taxonomy; labels with encryption where truly required.
• Channel-based DLP: coherent rules for email, sites, and endpoints; start in audit mode to understand impact and tune.
• Retention: keep what is necessary for legal or business obligations; avoid holding data without purpose.
• Investigation: eDiscovery and unified audit to reconstruct events when needed.
• Cryptographic control: Customer Key when an extra layer of key control is required.

Suggested implementation

1. Define taxonomy with business and legal: concrete examples per label and responsible owners.
2. Publish labels in informative mode and measure adoption; enable encryption only where essential.
3. Deploy DLP in audit mode (Email and SharePoint/OneDrive), review false positives/negatives, and move to gradual blocking.
4. Configure retention policies by document type (contracts, HR, tax, etc.) with justified exceptions.
5. Establish a quarterly review process for DLP incidents and rule adjustments.

Useful evidence

• List of labels and scopes; screenshots of application and authorized decryption.
• DLP reports by period, with trends and corrective actions.
• Retention policies with regulatory justification and results from deletion audits.

Conceptual DLP example

Condition: Document labeled "Confidential" + external recipient Action: Block send and notify Exception: Designated owners with justification and logging

Technical governance in Azure (Management Groups, Policy, Key Vault)

Technical governance reduces configuration drift and makes exceptions visible. Management Group inheritance allows controlling by default what can and cannot be deployed.

Objectives

• Clear inheritance: Management Group structure by environment and/or region.
• Policy as guardrail: initiatives that assess and, where appropriate, prevent noncompliant deployments.
• Central logging: send diagnostics to a common workspace with adequate retention.
• Keys under control: Key Vault and CMEK for resources that support it.
• Minimal exposed network: Private Endpoints, modern TLS, and closure of legacy protocols.

Suggested implementation

1. Define the Management Group structure (org → region/business unit → environment) and associate subscriptions.
2. Assign the ISO 27001 initiative and other relevant ones (CIS/NIST/sector benchmarks) at the root group.
3. Enable Diagnostic settings per subscription for Activity/Resource logs to Log Analytics.
4. Set network standards: NSG/ASG, private subnets, Private DNS, secure gateways.
5. Manage keys in Key Vault with rotation and access via RBAC/PIM and audit logs.
6. Manage Policy exceptions with expiration date, reason, and owner.

Useful evidence

• List of Policy assignments and their compliance by subscription.
• Lists of active exceptions with expiry date and closure plan.
• Key states, rotation, and Key Vault access logs.

Posture and risk (Defender for Cloud and Microsoft Defender for Endpoint)

Posture synthesizes hardening and exposure status. Prioritizing by risk avoids dispersion of efforts and accelerates real attack surface reduction.

Objectives

• Impact-based priority: recommendations that most increase Secure Score and close critical gaps.
• Vulnerability visibility on endpoints and servers, with patching and remediation plans.
• Signals that block: device risk (MDE) integrated with compliance and Conditional Access.

Suggested implementation

1. Enable Defender for Cloud on subscriptions and review Regulatory Compliance and service-specific recommendations.
2. Deploy MDE to endpoints and servers, enable attack surface reduction, and test isolation.
3. Set remediation workflow in sprints with owners and due dates.
4. Use MDE device risk to mark noncompliant devices and condition access.

Useful evidence

• Secure Score trend and details of closed recommendations.
• Exposure/vulnerability reports and reduction metrics.
• MDE cases with action timeline and outcomes.

Logging, detection, and response (Log Analytics, Sentinel, KQL)

Without logs there is no forensics or defensible compliance. Centralizing, detecting consistently, and responding automatically shortens timelines and leaves traceability.

Objectives

• Comprehensive ingestion from Entra ID, Microsoft 365, Azure (Activity/Resource), MDE/MDO/MDA into a central workspace.
• Relevant detections in Sentinel, with well-designed severities and suppressions.
• Orchestrated response with Logic Apps: isolate devices, revoke tokens, open ITSM incidents.

Suggested implementation

1. Enable data connectors in Sentinel and validate volumes and retentions.
2. Activate baseline rules (identity, privileges, exfiltration) and tune thresholds to reduce noise.
3. Design playbooks for common cases (phishing, stolen token, compromised device) and test them.
4. Version KQL queries and dashboards; document parameters and assumptions.

KQL example (admin sign-ins outside business hours)

SigninLogs | where ResultType == 0 | where Identity matches regex ".*(admin|adm).*" | where hour_of_day(TimeGenerated) < 7 or hour_of_day(TimeGenerated) > 20 | summarize attempts=count() by Identity, bin(TimeGenerated, 1h)

Useful evidence

• List of active rules and their justification.
• Screenshots of playbook runs with timestamps.
• Dashboards with defined time range and exported results.

Continuity and resilience (BCP/DR, RTO/RPO, immutability)

Controlled exercises are the only solid evidence that the organization can resume operations after an incident. Resilience is not a one-off habit; it is a continuous process.

Objectives

• Realistic RTO/RPO by service and data, agreed with the business.
• Immutable backups and offline copies or retention that can withstand insider fraud or ransomware.
• Resilient architectures: availability zones, paired regions, private traffic, and plane separation.
• Drills with minutes, measured times, and improvement actions.

Suggested implementation

1. Catalogue services and dependencies; document RTO/RPO and criticality metrics.
2. Configure backup policies with immutability and periodic restore tests.
3. Define runbooks (what, who, how) for typical disruptions.
4. Run semiannual drills and close derived actions.

Useful evidence

• Signed BCP/DR plan, topologies, and owners.
• Backup reports and logs from real restorations.
• Drill minutes with results and improvements.

ENS checklist by domains with examples

Indicative list of ENS measures and their technical reflection in Microsoft. Final priority depends on the risk analysis and the ENS category of the system.

Applied ISO 27001 (Annex A 2022) checklist

Selection of high-impact controls in Microsoft. The client’s SoA must reflect applicable controls, exclusions, and reasons.

Traceability, evidence, and “smoke tests” templates

Traceability matrix (summary)

Quick checklist (smoke tests)

Short examples

Conceptual policy — “Block access without MFA”

Condition: User without MFA method

Action: Require MFA; deny if not passed
Exception: Documented emergency accounts, with review

KQL — unusual administrative activity

SigninLogs

| where ResultType == 0
| where Identity matches regex ".(admin|adm)."
| where hour_of_day(TimeGenerated) < 7 or hour_of_day(TimeGenerated) > 20
| summarize attempts=count() by Identity, bin(TimeGenerated, 1h)

Common mistakes and how to avoid them

• Confusing provider compliance with client compliance. Provider certificates are a reference, not a substitute for the client’s controls.
• Uncontrolled Policy exceptions. Every exception needs a reason, scope, and end date; without this, they become permanent.
• No change log. Lack of traceability slows audits and makes forensics more expensive.
• DR not tested. Valid evidence is the executed, measured restoration—not the written plan.
• Unmaintained Sentinel rules. Without threshold review and tuning, noise hides relevant alerts.

Frequently asked questions

Official resources

• Royal Decree 311/2022 (ENS) — BOE
• ENS regulations — CCN
• CCN-STIC Guides (800/1000 series for Microsoft technologies)
• ENS at Microsoft (Azure/Microsoft 365)
• Compliance in Azure
• Azure Policy — ISO 27001 initiative
• Azure — ISO/IEC 27001
• Microsoft Compliance offerings
• ISO/IEC 27001 — official page
• CCN-STIC-884 — ENS profile in Azure
• CCN-STIC-885A — Secure configuration for Office 365

Conclusion

Treating ENS and ISO 27001 as an ongoing program—with default controls, periodic reviews, and clear evidence—reduces risk and simplifies audits. With Entra ID, Purview, Azure Policy, Defender for Cloud, MDE, and Sentinel, the client has a solid, traceable technical foundation.