DORA Article 9 Compliance: The Protection Controls Financial Entities Must Evidence Now

DORA Article 9: What 'Protection and Prevention' Means in M365

The Digital Operational Resilience Act (DORA) entered into application on 17 January 2025, and in the year since, financial entities across the UK and EU have been translating its requirements into operational controls. Article 9 - "Protection and prevention" - is the most technically demanding article in the regulation, and the one where the most confusion occurs between compliance teams and engineering teams.

This section breaks down what Article 9 actually requires, and shows how to satisfy each requirement with native Microsoft 365 and Azure controls.

Understanding the Article 9 Structure

Article 9 sits within Chapter II (ICT Risk Management Framework) and focuses specifically on protection and prevention measures. It requires financial entities to:

1. Continuously monitor and control the security and functioning of ICT systems
2. Implement ICT security policies, procedures, protocols and tools for network and infrastructure management
3. Design network connection mechanisms that are encrypted and resistant to tampering
4. Minimise the impact of ICT risk through resilient systems, protocols, and tools

The European Supervisory Authorities (ESAs) published Regulatory Technical Standards (RTS) under Commission Delegated Regulation (EU) 2024/1774 that provide granular detail. The RTS is where the engineering requirements actually live - Article 9 alone is too abstract to build controls from.

Article 9(2): ICT Security Policies

The regulation requires documented ICT security policies covering network security, encryption, cryptographic controls, and access management. These aren't just Word documents, the RTS requires demonstrable implementation.

M365 Implementation:

The starting point is Entra ID Conditional Access as the policy enforcement engine. Every ICT security policy decision should have a corresponding CA policy:

# Export all Conditional Access policies for DORA evidence
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy
$policies | ForEach-Object {
    [PSCustomObject]@{
        Name        = $_.DisplayName
        State       = $_.State
        Conditions  = ($_.Conditions | ConvertTo-Json -Depth 5 -Compress)
        Grant       = ($_.GrantControls | ConvertTo-Json -Depth 3 -Compress)
        Session     = ($_.SessionControls | ConvertTo-Json -Depth 3 -Compress)
        Created     = $_.CreatedDateTime
        Modified    = $_.ModifiedDateTime
    }
} | Export-Csv -Path "./dora-ca-policies-$(Get-Date -Format yyyy-MM-dd).csv" -NoTypeInformation

Article 9(3): Network Security Management

The RTS under Article 9(3) requires that network connections are secured, segmented, and monitored. For M365 tenants, this translates to:

Encryption in Transit:

• All M365 services enforce TLS 1.2 minimum by default. Verify this hasn't been downgraded: Exchange Admin Center > Mail Flow > Connectors - check that no partner connectors allow opportunistic TLS fallback
• For SharePoint and OneDrive, data in transit is encrypted via HTTPS with TLS 1.2/1.3. This is platform-managed, but you must document it in your DORA evidence pack

Encryption at Rest:

• M365 uses service-level encryption (BitLocker for disk, per-file encryption for SharePoint/OneDrive). For DORA, Customer Key is recommended for additional sovereignty:

# Verify Customer Key DEP (Data Encryption Policy) status
Get-M365DataAtRestEncryptionPolicy | Select Name, State, AzureKeyIDs, Enabled

Network Segmentation:

• Implement Entra Private Access or Azure VPN for access to on-premises resources - never expose RDP or SMB directly
• Use Conditional Access named locations to restrict admin portal access to known corporate IPs:

Navigate to Entra ID > Security > Conditional Access > Named locations and create IP-range-based trusted locations. Then create a CA policy targeting Directory Roles (Global Admin, Security Admin, etc.) with a grant condition of "Require one of the selected controls" including the trusted location.

Article 9(4): Access Management and Least Privilege

DORA Article 9(4) explicitly requires "strong authentication mechanisms" and "the principle of least privilege." The RTS elaborates: entities must implement role-based access, enforce MFA for all critical systems, and maintain access inventories.

Privileged Identity Management Configuration:

These are the recommended PIM settings for DORA-regulated clients:

• Global Administrator: Maximum 1-hour activation, require approval from Security team, require justification, require MFA at activation
• Security Administrator: Maximum 4-hour activation, require justification, require MFA
• Exchange Administrator, SharePoint Administrator: Maximum 8-hour activation, require justification

# Audit current permanent role assignments - any permanent admin is a DORA finding
$permanentAssignments = Get-MgRoleManagementDirectoryRoleAssignment -Filter "assignmentType eq 'Assigned'"
$permanentAssignments | ForEach-Object {
    $role = Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId
    $user = Get-MgUser -UserId $_.PrincipalId -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Role      = $role.DisplayName
        Principal = $user.UserPrincipalName
        Type      = "Permanent"
    }
} | Where-Object { $_.Role -match "Admin" } | Format-Table -AutoSize

Any permanent admin assignment outside break-glass accounts is a finding. DORA assessments commonly flag this as a material gap.

Authentication Strength:

The RTS requires "strong authentication" which in practice means phishing-resistant MFA. Configure an Authentication Strength policy in Entra ID:

Navigate to Entra ID > Security > Authentication methods > Authentication strengths and create a custom strength requiring FIDO2 security keys or Windows Hello for Business. Then reference this strength in your Conditional Access policies targeting admin roles and sensitive applications.

Article 9(4)(c): Data Integrity

DORA requires mechanisms to ensure data integrity and confidentiality. In M365, this means:

Purview Sensitivity Labels:

• Deploy auto-labelling policies that classify financial data, PII, and confidential ICT documentation
• Enforce encryption on "Highly Confidential" labels so data cannot be accessed outside the tenant
• Enable co-authoring for encrypted documents (now GA) to avoid workflow friction

Purview DLP:

• Create DLP policies for financial instruments data, customer PII, and ICT configuration exports
• Block external sharing of anything labelled "Confidential" or above
• Monitor Teams channels for accidental credential sharing using custom sensitive information types

# Create a custom SIT for detecting API keys and credentials in Teams/Exchange
New-DlpSensitiveInformationType -Name "DORA ICT Credentials" -Description "Detects API keys, connection strings, and credentials" -SensitiveInformationTypeRulePackage @{
    Rules = @(
        @{
            Name = "API Key Pattern"
            Pattern = @{
                Match = @(
                    @{ Type = "Regex"; Value = "(?i)(api[_-]?key|apikey|api[_-]?secret)s*[:=]s*['"]?[A-Za-z0-9-_]{20,}" }
                )
            }
            Confidence = 85
        }
    )
}

Article 9(4)(d): Threat Protection

The protection and prevention requirements demand active threat detection and response. This maps directly to the Defender XDR stack:

Defender for Endpoint:

• Attack Surface Reduction (ASR) rules enabled in block mode - not audit mode
• Automated investigation and response (AIR) enabled
• Network protection enabled to block C2 connections

Defender for Office 365:

• Safe Attachments in dynamic delivery mode (detonates attachments in sandbox, delivers email body immediately)
• Safe Links with URL detonation at time of click
• Zero-hour auto purge (ZAP) for retroactive removal of weaponised emails

Defender for Identity:

• Deployed on all domain controllers for lateral movement detection
• Honeytoken accounts configured and monitored

Generating DORA Evidence Packs

Regulators expect a structured evidence pack. This should be produced monthly using an Azure Automation runbook:

# DORA Article 9 Evidence Pack - Monthly Generation
$evidencePath = "./DORA-Evidence-Pack-$(Get-Date -Format yyyy-MM)"
New-Item -ItemType Directory -Path $evidencePath -Force

# 1. CA Policies (Article 9(4) - Access Management)
Get-MgIdentityConditionalAccessPolicy | ConvertTo-Json -Depth 10 | Out-File "$evidencePath/conditional-access-policies.json"

# 2. PIM Role Settings (Article 9(4) - Least Privilege)
Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/'" | ConvertTo-Json -Depth 5 | Out-File "$evidencePath/pim-settings.json"

# 3. DLP Policy Status (Article 9(4)(c) - Data Integrity)
Get-DlpCompliancePolicy | Select Name, Mode, Enabled, Priority | ConvertTo-Json | Out-File "$evidencePath/dlp-policies.json"

# 4. Defender Configuration (Article 9(4)(d) - Threat Protection)
Get-MgSecurityAlert -Top 100 -OrderBy "createdDateTime desc" | ConvertTo-Json -Depth 5 | Out-File "$evidencePath/recent-alerts.json"

# 5. Encryption Status (Article 9(3) - Network Security)
Get-MgOrganization | Select -ExpandProperty AssignedPlans | Where { $_.Service -like "*encrypt*" } | ConvertTo-Json | Out-File "$evidencePath/encryption-plans.json"

Write-Host "DORA Article 9 evidence pack generated at $evidencePath"

The RTS Gap Most People Miss

The RTS under DORA Article 9 requires that protection and prevention measures be tested. It's not enough to deploy Conditional Access and call it done. You must demonstrate:

1. Penetration testing of ICT systems (Article 26 - TLPT for systemically important entities)
2. Regular review of access rights - quarterly at minimum
3. Change management records showing that ICT system changes go through a controlled process

The access review requirement is satisfied with Entra ID Access Reviews configured to run quarterly for all privileged roles, with auto-removal of access if the reviewer doesn't respond within 14 days.

For change management, Azure DevOps or ServiceNow integrated with the M365 admin audit log. Every change to Conditional Access, DLP policies, or security configuration must have a corresponding change ticket. This is enforced by restricting admin access through PIM with mandatory justification that must include a ticket number.

Final Thoughts

DORA Article 9 is dense, but it maps cleanly to the M365 security stack when you approach it systematically. The key insight is that DORA doesn't just require controls - it requires evidence of operational effectiveness. Every control must be monitored, tested, and documented continuously. Build automation from day one, or you'll drown in manual evidence gathering by the time the regulator asks.