DORA Compliance as Code: Automating Resilience

02 The Engineering Paradigm Shift for Digital Operational Resilience

03 Executive Summary

The entry into force of Regulation (EU) 2022/2554, known as the Digital Operational Resilience Act (DORA), marks a fundamental inflection point for the European financial sector. Historically, financial regulation has focused on capital adequacy, liquidity buffers, and market conduct. DORA, however, codified the premise that the financial system is now indistinguishable from the Information and Communication Technology (ICT) infrastructure that underpins it. For financial entities (FEs)—from global investment banks in Frankfurt to payment processors in Dublin—compliance is no longer exclusively a function of legal governance; it has become a primary engineering constraint.¹

The regulation introduces a rigorous, harmonized framework for ICT risk management, incident reporting, and resilience testing. The latency of traditional compliance mechanisms—manual spreadsheets, retrospective audits, and quarterly risk committees—is incompatible with DORA’s operational tempo, which mandates incident classification and initial reporting within four hours of detection.³ Furthermore, the requirements for data sovereignty, encryption key management, and backup frequency require a level of granular control that can only be achieved through automation.

This whitepaper advocates for a "Compliance as Code" methodology. By embedding regulatory requirements directly into the Infrastructure as Code (IaC) layer using declarative frameworks like Terraform and policy engines such as HashiCorp Sentinel or Open Policy Agent (OPA), financial entities can enforce DORA standards at the provisioning stage. This approach shifts compliance "left," transforming it from a detective bureaucracy into a preventative architectural capability.

The following sections provide a comprehensive technical roadmap for engineering leaders. We deconstruct the Regulatory Technical Standards (RTS) into actionable engineering requirements, detail the implementation of Policy-as-Code for critical controls, propose a "Resilience Dashboard" architecture that bridges the gap between DevOps metrics and regulatory impact tolerances, and present a detailed case study of a Frankfurt-based Significant Institution automating its regulatory reporting obligations to the European Central Bank (ECB) and BaFin.

1 The Regulatory Technical Standards (RTS): An Engineering Specifications Document

The European Supervisory Authorities (ESAs)—EBA, EIOPA, and ESMA—have developed detailed Regulatory Technical Standards (RTS) that translate the high-level legislative text of DORA into specific technical obligations. For infrastructure architects and platform engineers, these RTS documents function effectively as a non-negotiable requirements specification for the cloud platform.

1.1 The ICT Risk Management Framework (Article 6 – Article 16)

DORA mandates a comprehensive ICT Risk Management Framework (RMF). While the RMF includes governance and strategy, its execution relies on specific technical capabilities that must be engineered into the platform.

1.1.1 Protection and Prevention (Article 9)

Article 9 requires financial entities to design ICT security strategies that ensure the resilience, continuity, and availability of systems. The RTS expands this to require "sound, resilient and updated ICT systems".⁵

Immutable Infrastructure as a Compliance Necessity: The requirement for "updated" and "resilient" systems effectively deprecates the "pet" server model of long-lived, manually patched instances. To comply with Article 9 at scale, engineering teams must adopt immutable infrastructure patterns (e.g., replacing rather than patching instances) to eliminate configuration drift. Security patches must be applied upstream in the image build process, ensuring that the deployed infrastructure always matches the compliant "desired state" defined in the code repository.

Capacity Management and Autoscaling: The RTS explicitly mandates procedures for capacity and performance management.⁵ In a cloud-native context, this translates to automated autoscaling policies. A static infrastructure that fails under unforeseen load is no longer just a service quality issue; it represents a regulatory violation of the availability mandate. Engineers must implement predictive scaling or robust reactive scaling policies that are tested against the defined impact tolerances of the service.

1.1.2 Cryptography and Key Sovereignty (Article 9(4)(d) & RTS Art. 6, 7, 14)

The regulatory standards place immense weight on the encryption of data at rest, in transit, and in use. The RTS specifies that encryption protocols must be based on state-of-the-art standards and that cryptographic keys must be managed securely.⁵

Sovereignty and EKM: For critical or important functions (CIFs), reliance on default Cloud Service Provider (CSP)-managed keys (e.g., SSE-S3 with AWS-managed keys) may be insufficient depending on the data classification and sovereignty requirements. DORA implicitly pushes FEs toward greater control over their cryptographic material. This implies the adoption of Customer Managed Keys (CMK) or, for higher sovereignty requirements, External Key Management (EKM) where the key material is held outside the CSP’s infrastructure (e.g., in a dedicated Hardware Security Module or a third-party service like Thales CipherTrust).⁸

Cryptographic Agility: The requirement to "update" systems extends to cryptographic standards. Hard-coded encryption protocols are a liability. Infrastructure code must be parameterized to allow for the rapid rotation of cipher suites and keys in response to emerging threats (e.g., the potential future threat of quantum decryption).

1.1.3 ICT Operations Security: Backup and Recovery (Article 12)

Article 12 is highly prescriptive regarding data protection. It requires backup policies that specify the scope of data and the minimum frequency of backups, based on the criticality of the information.⁵

Risk-Based Backup Frequency: The RTS rejects a "one-size-fits-all" backup strategy. The frequency of backup must be aligned with the recovery point objective (RPO) dictated by the business impact analysis. For a core ledger, a daily backup is non-compliant; continuous replication with point-in-time recovery (PITR) is required. For an archival system, daily or weekly snapshots may suffice. Policy-as-Code must enforce these distinct profiles based on resource tagging.

Segregation and Air Gapping: The RTS requires the physical and logical segregation of backup systems from production systems to prevent simultaneous compromise.¹⁰ In a cloud architecture, this mandates specific engineering patterns:

Cross-Region Replication: Storing backups in a geographically distant region to mitigate physical disaster risk.

Cross-Account Vaults: Utilizing separate AWS Accounts or Azure Subscriptions for backup vaults, with distinct Identity and Access Management (IAM) roles, to prevent a compromised production administrator from deleting backups (e.g., leveraging AWS Backup Vault Lock or Azure Backup's soft delete and immutable storage features).

1.2 Incident Reporting Timelines (Article 19)

DORA harmonizes the reporting of major ICT-related incidents with aggressive timelines that challenge manual reporting processes 3:

Initial Notification: Must be submitted within 4 hours of classifying the incident as "major," and no later than 24 hours after detection.

Intermediate Report: Required within 72 hours of the initial notification, providing updates on the impact and root cause.

Final Report: Due within 1 month of the incident resolution.

These timelines imply that the "Time to Understand" (TTU) an incident must be radically compressed. If an engineering team spends three hours just gathering logs to determine the number of affected users, they have likely already breached the reporting window. The infrastructure must emit the necessary telemetry—impacted user count, data loss estimation, geographical spread—in real-time to the incident command center.

1.3 Digital Operational Resilience Testing (Articles 24-27)

DORA mandates a proportional testing program, including vulnerability assessments, open source analyses, and Threat-Led Penetration Testing (TLPT) for significant entities.¹³ This reinforces the need for "Continuous Verification." Security testing cannot be a quarterly manual exercise. Vulnerability scanning (e.g., utilizing tools like Trivy, Snyk, or Tenable) must be integrated into the CI/CD pipeline. A build artifact containing a critical Common Vulnerabilities and Exposures (CVE) identifier must be blocked by the pipeline before it can be deployed, ensuring that the "current state" remains compliant with the vulnerability management procedures required by the RTS.

2 Implementation: Governing the Cloud with Policy-as-Code

To navigate the complex web of DORA requirements without stalling the velocity of software delivery, financial entities must transition from manual "gatekeeping" to automated "guardrails." Policy-as-Code (PaC) allows organizations to codify DORA’s regulatory text into executable logic that intercepts infrastructure changes during the provisioning phase (e.g., terraform plan), preventing non-compliant resources from ever being created.

This section details two technical implementations: utilizing HashiCorp Sentinel for Azure environments and Open Policy Agent (OPA) with Rego for AWS environments.

2.1 Scenario A: Enforcing Backup Frequency Compliance on Azure

The Regulatory Requirement: Under Article 12 of DORA, and the associated RTS on ICT Operations Security, the financial entity has defined a policy that all Virtual Machines (VMs) supporting "Critical Functions" must have a Recovery Point Objective (RPO) of 24 hours or less. Consequently, any Azure Backup Policy applied to these VMs must have a backup frequency of "Daily." A "Weekly" frequency is insufficient and constitutes a compliance violation.¹⁰

The Technical Constraint: Azure's azurerm_backup_policy_vm resource supports both "Daily" and "Weekly" frequencies. A developer might inadvertently select "Weekly" to reduce costs or simplify configuration, unknowingly creating a compliance gap.¹⁴

Terraform Implementation:

Consider the following Terraform resource definition that a developer might attempt to deploy:

Terraform

resource "azurerm_backup_policy_vm" "example_policy" {
  name                = "policy-critical-app"
  resource_group_name = azurerm_resource_group.rg.name
  recovery_vault_name = azurerm_recovery_services_vault.vault.name

  backup {
    frequency = "Weekly"  # NON-COMPLIANT for Critical Workloads
    time      = "23:00"
    weekdays  =
  }

  retention_weekly {
    count    = 42
    weekdays =
  }
}

The Sentinel Enforcement Policy: To prevent this, we write a Sentinel policy that inspects the Terraform plan. Sentinel operates on the mock data generated during the planning phase, allowing it to evaluate the "after" state of the resource.¹⁵

Python

# Import the standard tfplan/v2 module to access the planned changes
import "tfplan/v2" as tfplan

# Filter for Azure VM Backup Policy resources in the plan
# We are interested in resources that are being created or updated
backup_policies = filter tfplan.resource_changes as _, rc {
    rc.type is "azurerm_backup_policy_vm" and
    (rc.change.actions contains "create" or rc.change.actions contains "update")
}

# Rule: Enforce Daily Backup Frequency
# This rule iterates through all identified backup policies and checks the frequency attribute.
daily_backup_enforced = rule {
    all backup_policies as _, policy {
        # Navigation to the nested 'backup' block in the resource schema
        all policy.change.after.backup as backup_block {
            backup_block.frequency is "Daily"
        }
    }
}

# Main rule: The policy passes only if the daily_backup_enforced rule is true.
main = rule {
    daily_backup_enforced
}

Deep Analysis of the Policy Logic:

Interception: The policy hooks into the tfplan output. It specifically filters for azurerm_backup_policy_vm resources, ignoring other infrastructure components.¹⁵

Attribute Inspection: It accesses the change.after.backup list. In the Terraform provider schema for Azure, the backup block defines the schedule. The policy explicitly asserts that the frequency attribute must match the string "Daily".¹⁴

Outcome: If the developer attempts to apply the "Weekly" configuration shown above, Sentinel evaluates the rule as false. The Terraform Cloud/Enterprise run is hard-stopped. The developer receives immediate feedback: "Policy Check Failed: Backup frequency must be Daily." This prevents the non-compliant state from ever existing in the production environment, satisfying the "prevention" aspect of DORA's risk management requirements.

2.2 Scenario B: Enforcing Encryption at Rest on AWS S3

The Regulatory Requirement: Article 9 of DORA emphasizes the protection of data availability, authenticity, integrity, and confidentiality. For data at rest, this mandates strong encryption. A financial entity's policy dictates that all AWS S3 buckets must utilize Server-Side Encryption (SSE). Furthermore, to ensure higher control (as per key management requirements), the encryption must use either AES-256 or, preferably, AWS KMS (Key Management Service).¹³

The Technical Constraint:

By default, older Terraform modules or quick console creations might leave S3 buckets unencrypted or configured with legacy settings. We must enforce the presence of the server_side_encryption_configuration block.

The OPA (Rego) Implementation:

Open Policy Agent (OPA) uses Rego, a declarative query language, to inspect the JSON representation of the Terraform plan.

Code snippet

package terraform.dora.encryption

import input.resource_changes

# Default to denying the plan unless explicit allowance logic allows it (Security by Default)
# However, for this specific rule, we define specific 'deny' conditions.

# Rule 1: Deny if S3 bucket completely lacks encryption configuration
deny[msg] {
    # Identify S3 bucket resources in the plan
    resource := resource_changes[_]
    resource.type == "aws_s3_bucket"
    
    # Filter for resources being created or updated
    is_create_or_update(resource.change.actions)

    # Check for the absence of the encryption block
    not has_encryption_config(resource)

    msg := sprintf("DORA Art. 9 Violation: S3 bucket '%v' is missing Server-Side Encryption configuration.", [resource.address])
}

# Rule 2: Deny if the encryption algorithm is insufficient (not AES256 or aws:kms)
deny[msg] {
    resource := resource_changes[_]
    resource.type == "aws_s3_bucket"
    is_create_or_update(resource.change.actions)
    
    # Drill down into the complex JSON structure of the plan
    # resource.change.after.server_side_encryption_configuration is a list
    encryption_config := resource.change.after.server_side_encryption_configuration[_]
    rule := encryption_config.rule[_]
    apply_server_side_encryption_by_default := rule.apply_server_side_encryption_by_default[_]
    algorithm := apply_server_side_encryption_by_default.sse_algorithm
    
    # Define allowed algorithms (Allowlist approach)
    allowed_algorithms := {"AES256", "aws:kms"}
    not allowed_algorithms[algorithm]

    msg := sprintf("DORA Art. 9 Violation: S3 bucket '%v' uses disallowed encryption algorithm '%v'. Must be AES256 or aws:kms.", [resource.address, algorithm])
}

# Helper functions
is_create_or_update(actions) {
    actions[_] == "create"
}
is_create_or_update(actions) {
    actions[_] == "update"
}

has_encryption_config(resource) {
    count(resource.change.after.server_side_encryption_configuration) > 0
}

Implementation Details:

JSON Parsing: Terraform does not natively output JSON for OPA. The workflow requires running terraform plan -out=tfplan.binary followed by terraform show -json tfplan.binary > tfplan.json. This JSON file is the input for OPA.¹⁷

Granularity: The Rego policy first checks for the existence of the encryption block. If present, it traverses the nested arrays (server_side_encryption_configuration -> rule -> apply_server_side_encryption_by_default) to validate the sse_algorithm.¹⁸

Audit Trail: The output of the OPA check can be piped to a compliance log. This provides evidence to auditors that "100% of buckets provisioning attempts were scanned for encryption compliance," satisfying the documentation requirements of RTS Article 16.20

2.3 Managing Sovereign Controls and Concentration Risk

DORA Article 28 places strict oversight on ICT third-party risk, specifically concentration risk. If a bank relies entirely on a single US-based cloud provider's native security tools without supplementary measures, they may face scrutiny regarding data sovereignty and the risk of extraterritorial data access (referencing concerns similar to those in the Schrems II judgment).²¹

The Sovereign Landing Zone (SLZ) Architecture:

To mitigate these risks, financial entities are increasingly adopting "Sovereign Landing Zone" architectures.

Microsoft Cloud for Sovereignty: This architectural pattern on Azure utilizes Azure Confidential Computing (ACC). It enforces the use of Trusted Execution Environments (TEEs) or "enclaves" (using Intel SGX or AMD SEV-SNP technologies) to protect data in use, ensuring that even the cloud provider cannot access the memory space of the processing VM.²³

Google Cloud Sovereign Controls (with T-Systems): This model employs external key management (EKM). Encryption keys are stored and managed by a trusted European partner (T-Systems) outside of Google’s infrastructure. Google has no access to the keys, ensuring that data stored in GCP cannot be decrypted by the provider, satisfying strict sovereignty interpretations.⁸

Policy Enforcement of Sovereignty:

Terraform policies can enforce these architectural decisions. For example, a policy can restrict resource deployment to specific "Sovereign" regions and enforce the use of Confidential VMs.

Terraform

# Conceptual Sentinel Policy for Sovereign Region Enforcement
allowed_sovereign_regions = ["germanywestcentral", "germanynorth", "europe-west3"]

rule "enforce_sovereign_residency" {
    all tfplan.resource_changes as _, rc {
        # Check for location attribute if it exists
        rc.change.after.location in allowed_sovereign_regions
    }
}

This ensures that data residency compliance—a critical component of DORA's broader digital sovereignty goals—is immutable and code-enforced.²⁴

3 The 'Resilience Dashboard': Monitoring Impact Tolerance

Traditional IT monitoring dashboards focus on component health (CPU usage, RAM availability, network latency). While necessary for operations, these metrics do not directly map to DORA's requirements. DORA requires monitoring of service resilience and impact tolerance. The dashboard must answer a business question: "Are we currently within the boundaries of tolerable disruption?"

3.1 Architecture: From SLA to Impact Tolerance

The architecture requires a translation layer that converts raw infrastructure metrics into business-contextualized resilience indicators.

The Telemetry Stack:

Data Sources: Prometheus (infrastructure metrics), Dynatrace/AppDynamics (Application Performance Monitoring), ServiceNow (Incident metadata), CloudWatch/Azure Monitor (Cloud native metrics).

Aggregation Layer: A high-cardinality data store (like Grafana Mimir or a specialized SRE platform like Nobl9) that can ingest distinct data streams.

Visualization: Grafana Enterprise or custom React-based dashboards integrating with the aggregation layer.²⁶

3.2 Defining the Metrics: SLA vs. DORA

The transition to DORA compliance requires a shift in metric definitions.

3.3 Dashboard Logic and Visualization

The "Resilience Dashboard" should utilize the concept of Error Budget Burn Rates derived from Google's Site Reliability Engineering (SRE) handbook, but adapted for DORA's regulatory thresholds.

Panel 1: The Impact Tolerance Gauge

Visual: A gauge tracking the status of a "Critical or Important Function" (e.g., Payments Processing).

Logic: When the service health check fails (e.g., success rate < 95%), a "Resilience Timer" starts.

Green Zone (0 - 30 minutes): Incident Management phase. No regulatory impact yet.

Yellow Zone (30 minutes - 2 hours): Approaching Impact Tolerance. Warning alerts to senior management.

Red Zone (> 2 hours): Impact Tolerance Breach. This signifies a "Major Incident" under DORA based on duration, triggering mandatory reporting workflows.²⁸

Panel 2: Third-Party Risk Concentration Map

Visual: A dependency map or Sankey diagram.

Data: Real-time status of Critical Third-Party Providers (CTPPs) derived from cloud provider status APIs (AWS Health Dashboard, Azure Service Health).

DORA Context: Article 28 requires the management of third-party risk. If aws-eu-central-1 experiences a degradation, the dashboard must highlight which specific internal business services are at risk of cascading failure. This moves monitoring from "AWS is down" to "Payments are at risk because AWS is down".²

Panel 3: The "Compliance Budget"

Visual: A time-series graph.

Metric: Percentage of infrastructure resources compliant with Policy-as-Code definitions.

Logic: If the percentage drops below 100% (e.g., a developer manages to manually disable encryption on a resource, bypassing the CI/CD pipeline via a "break-glass" account), the dashboard alerts. This provides a leading indicator of compliance drift before an audit occurs.

3.4 Integrating DORA (DevOps) with DORA (Regulation)

It is vital to distinguish between DevOps DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore) and EU DORA Regulation metrics. However, they are intrinsically linked.

A high Change Failure Rate (DevOps metric) is a leading indicator for Operational Instability (EU Regulation risk).³⁰

A low Time to Restore Service (DevOps metric) directly supports meeting the Impact Tolerance (EU Regulation requirement). A sophisticated Resilience Dashboard tracks DevOps metrics not just for efficiency, but as predictors of regulatory compliance posture.

4 Case Study: Automating Reporting at "Bankfurt Financial"

The Scenario:

"Bankfurt Financial," a hypothetical Significant Institution (SI) headquartered in Frankfurt, operates a hybrid cloud architecture (Azure + On-Premise Mainframe). On a Tuesday morning at 09:00 CET, a corrupted firmware update on a storage array triggers a cascading failure in their core payments processing system. The defined "Impact Tolerance" for this service is 2 hours.

The Regulatory Challenge:

Under DORA Article 19, Bankfurt must:

Detect the incident.

Classify it as "Major" based on quantitative criteria (e.g., number of clients affected, duration, data loss).

Submit an Initial Notification to the competent authority (the ECB, via the German regulator BaFin) within 4 hours of classification.³

In the "old world," this would involve chaotic phone calls, manual data gathering, and drafting a PDF report—a process prone to errors and delays that could easily breach the 4-hour window. Bankfurt decides to automate this critical path.

4.1 The Automation Architecture: "AIRE"

Bankfurt implements an Automated Incident Reporting Engine (AIRE).

Step 1: Detection & Aggregation (The Trigger)

09:05 CET: Prometheus alerts that payment_success_rate has dropped to 0%.

09:06 CET: The Alertmanager pushes a JSON payload to the Incident Management System (ServiceNow).

Key Innovation: The alert payload includes DORA-specific metadata tags injected by the monitoring agent: dora_criticality: critical, service_id: payments-core, estimated_active_users: 1.5m (derived from the last 24h average).

Step 2: Automated Classification (The Logic)

09:10 CET: A "DORA Classifier" bot (a Python microservice) polls the open Major Incident ticket in ServiceNow.

It evaluates the incident against the RTS classification criteria defined in Delegated Regulation (EU) 2024/1772 33:

Criterion 1 (Clients): Is estimated_active_users > 10% of total client base OR > 100,000? Yes.

Criterion 2 (Duration): Is the projected Time to Restore > 2 hours? The SRE team updates the ticket estimate to "4 hours." Yes.

Criterion 3 (Geo-spread): Are clients in >1 Member State affected? Yes (Data shows traffic drops in DE and FR).

09:12 CET: Since the criteria are met, the bot tags the incident as "DORA Major: Candidate" and sends a high-priority push notification to the Crisis Management Team (CMT) via MS Teams.

Step 3: The "One-Click" Report Generation

09:30 CET: The CMT Lead convenes and confirms the classification. They click "Confirm DORA Incident" in the internal dashboard.

AIRE immediately generates the Initial Notification payload. It populates the specific fields required by the Implementing Technical Standards (ITS) templates 33:

Field 1.1 (Type of Submission): "Initial notification"

Field 1.3 (LEI): "529900..." (Bankfurt's Legal Entity Identifier)

Field 2.2 (Date/Time Detection): "2025-01-27T09:05:00Z" (Auto-filled from Prometheus)

Field 2.4 (Incident Description): "Total loss of payments processing due to storage failure." (Pulled from Ticket)

Field 2.5 (Classification Criteria): "Clients; Duration; Geographical Spread" (Auto-selected based on the bot's logic).

Step 4: Submission via Interface (The Interface)

The Constraint: As of early 2025, BaFin's MVP Portal provides forms but does not yet fully support a direct SOAP/REST API for machine-to-machine submission of these specific incident reports (a "second step" feature planned by BaFin).³⁵

The Solution: AIRE constructs the required XML/JSON document adhering to the strict schema of Commission Implementing Regulation (EU) 2025/302.33

It generates a pre-validated file named CCCCCCC_20250127_DIR_1.xlsx (following the specific naming convention: C-Code + Date + DIR code + Sequence).³³

This file is securely delivered to the Regulatory Liaison officer, who simply uploads it to the MVP Portal. This eliminates the time-consuming manual entry of data into web forms, ensuring data accuracy and formatting compliance.

Future State: Once the BaFin/ESA central hub API is live (anticipated 2025/2026), AIRE will switch to a direct POST request via mTLS to the regulator's endpoint.³⁶

4.2 The Outcome

By automating the collection, classification, and formatting of the report, Bankfurt Financial reduces the "Time to Report" from a potential 3-4 hours to 25 minutes post-detection.

Accuracy: Timestamps and user counts are derived from system metrics, not human guesses.

Focus: The engineering team saves hours of administrative work, allowing them to focus entirely on restoring the storage array and recovering the service.

Compliance: The bank meets the 4-hour deadline with a wide margin of safety, creating a robust audit trail of the classification decision.

023 Conclusion

DORA represents a rigorous challenge to the status quo of financial IT operations. It transforms vague notions of "best practice" into hard legal requirements for backup frequencies, encryption standards, and incident reporting speeds. For the modern financial entity, manual compliance is a liability—it is too slow, too error-prone, and too disconnected from the reality of the infrastructure.

The "Compliance as Code" approach detailed in this whitepaper reframes DORA from a burden into a blueprint for engineering excellence. By treating regulatory constraints as code—enforced by Terraform, monitored by Prometheus, and managed by OPA—institutions do more than just avoid penalties. They build infrastructure that is intrinsically resilient, self-documenting, and capable of withstanding the operational shocks of the digital age. A bank that must encrpyt and backup to deploy code is a bank that is secure by design, not just by policy.

024 Detailed Technical Appendix

025 Appendix A: Terraform Sentinel Code for Azure Backup Frequency

Purpose: Enforce daily backups for VM policies.¹⁴

Terraform

# This Sentinel policy ensures that all Azure VM Backup Policies
# are configured with a backup frequency of "Daily".

import "tfplan/v2" as tfplan

# Get all Azure Backup Policy resources from the plan
backup_policies = filter tfplan.resource_changes as _, rc {
    rc.type is "azurerm_backup_policy_vm" and
    (rc.change.actions contains "create" or rc.change.actions contains "update")
}

# Rule: Frequency must be "Daily"
backup_frequency_check = rule {
    all backup_policies as _, policy {
        # Check if the backup block exists and has frequency set to Daily
        any policy.change.after.backup as backup {
            backup.frequency is "Daily"
        }
    }
}

# Rule: Retention policy must exist (Basic sanity check for DORA retention)
retention_check = rule {
    all backup_policies as _, policy {
        keys(policy.change.after) contains "retention_daily"
    }
}

# Main rule that aggregates checks
main = rule {
    backup_frequency_check and retention_check
}

026 Appendix B: OPA Rego Code for AWS S3 Encryption

Purpose: Enforce AES256 or KMS encryption on all buckets.¹⁷

Code snippet

package terraform.aws.s3

import input.resource_changes

# Helper to find S3 buckets in the plan
s3_buckets[r] {
    r := resource_changes[_]
    r.type == "aws_s3_bucket"
    # Filter for create or update actions
    r.change.actions[_] == "create"
}
s3_buckets[r] {
    r := resource_changes[_]
    r.type == "aws_s3_bucket"
    r.change.actions[_] == "update"
}

# Deny if encryption configuration is missing entirely
deny[msg] {
    bucket := s3_buckets[_]
    not bucket.change.after.server_side_encryption_configuration
    msg := sprintf("S3 Bucket %v missing server_side_encryption_configuration", [bucket.address])
}

# Deny if encryption algorithm is not valid
deny[msg] {
    bucket := s3_buckets[_]
    # Navigate the complex Terraform JSON structure for SSE rules
    rules := bucket.change.after.server_side_encryption_configuration[_].rule
    rule := rules[_]
    algo := rule.apply_server_side_encryption_by_default[_].sse_algorithm
    
    # Valid algorithms: AES256 or aws:kms
    not valid_algorithm(algo)
    
    msg := sprintf("S3 Bucket %v has invalid encryption algorithm: %v", [bucket.address, algo])
}

valid_algorithm("AES256") = true
valid_algorithm("aws:kms") = true

Works cited

DORA - Draft RTS - AFME, accessed January 27, 2026, https://www.afme.eu/publications/consultation-responses/dora-draft-rts-on-risk-management-framework/

Digital Operational Resilience Act (DORA) - | European Securities and Markets Authority, accessed January 27, 2026, https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora

Seconds matter: Understanding DORA's real-time response requirements | DLA Piper, accessed January 27, 2026, https://www.dlapiper.com/insights/publications/derisk-newsletter/2025/seconds-matter-understanding-dora-s-real-time-response-requirements

Joint Technical Standards on major incident reporting | European Banking Authority, accessed January 27, 2026, https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting

Documentation requirements for financial entities according to DORA - Strategies - BaFin, accessed January 27, 2026, https://www.bafin.de/SharedDocs/Downloads/EN/Anlage/dl_anlage_DORA_Dokumentationsanforderungen_2_en.pdf?__blob=publicationFile&v=4

JC 2023 86 - Final report on draft RTS on ICT Risk ... - eiopa, accessed January 27, 2026, https://www.eiopa.europa.eu/system/files/2024-01/JC%202023%2086%20-%20Final%20report%20on%20draft%20RTS%20on%20ICT%20Risk%20Management%20Framework%20and%20on%20simplified%20ICT%20Risk%20Management%20Framework.pdf

dora-regulation-rts--2024-1532_en.pdf - European Commission, accessed January 27, 2026, https://ec.europa.eu/finance/docs/level-2-measures/dora-regulation-rts--2024-1532_en.pdf

T-Systems Sovereign Cloud | Google Cloud, accessed January 27, 2026, https://cloud.google.com/t-systems-sovereign-cloud

Sovereign Controls by Partners product page | Google Cloud, accessed January 27, 2026, https://cloud.google.com/security/products/sovereign-controls-by-partners

Digital Operational Resilience Act (DORA), Article 12, accessed January 27, 2026, https://www.digital-operational-resilience-act.com/Article_12.html

White Papers 2025 Resilience and Security in Critical Sectors Navigating NIS2 and DORA Requirements - ISACA, accessed January 27, 2026, https://www.isaca.org/resources/white-papers/2025/resilience-and-security-in-critical-sectors-navigating-nis2-and-dora-requirements

Preparing for DORA: ESAs Publish Incident Reporting Requirements - Morgan Lewis, accessed January 27, 2026, https://www.morganlewis.com/blogs/sourcingatmorganlewis/2024/08/preparing-for-dora-esas-publish-incident-reporting-requirements

Guide to DORA and its Impact on Storage & Backup ICT Assets - Part 1 - Continuity Software, accessed January 27, 2026, https://www.continuitysoftware.com/blog/guide-to-dora-and-its-impact-on-storage-backup-ict-assets-part-1/

azurerm_backup_policy_vm | Resources | hashicorp/azurerm - Terraform Registry, accessed January 27, 2026, https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/backup_policy_vm.html

Writing and Testing Sentinel Policies for Terraform - HashiCorp, accessed January 27, 2026, https://www.hashicorp.com/en/resources/writing-and-testing-sentinel-policies-for-terraform

Using the Terraform Foundational Policies Library with Microsoft Azure - HashiCorp, accessed January 27, 2026, https://www.hashicorp.com/en/blog/using-the-terraform-foundational-policies-library-with-azure

Automating Terraform Security Checks with OPA and Rego Policies - Firefly, accessed January 27, 2026, https://www.firefly.ai/academy/automating-terraform-security-checks-with-opa-and-rego-policies

Securing Terraform with OPA - Oso, accessed January 27, 2026, https://www.osohq.com/learn/opa-policy-as-code-for-terraform

Resourcely and IaC Scanners, accessed January 27, 2026, https://www.resourcely.io/and/iac-scanners

What is Open Policy Agent (OPA) and how to implement it with Terraform - Terrateam, accessed January 27, 2026, https://terrateam.io/blog/open-policy-agent-terraform

EU Data Transfer Requirements and U.S. Intelligence Laws: Understanding Schrems II and Its Impact on the EU-U.S. Privacy Shield | Congress.gov, accessed January 27, 2026, https://www.congress.gov/crs-product/R46724

Whitepaper: International Data Transfers & the EU-U.S. Data Privacy Framework - Splunk, accessed January 27, 2026, https://www.splunk.com/en_us/pdfs/resources/whitepaper/splunk-a-risk-assessment-of-eu-cross-border-data-transfers.pdf

Confidential computing overview - Microsoft Sovereign Cloud, accessed January 27, 2026, https://learn.microsoft.com/en-us/industry/sovereign-cloud/sovereign-public-cloud/capabilities/confidential-computing

Deploy Azure Landing Zones - Azure Architecture Center | Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy

Sovereign Landing Zone (SLZ) - Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/industry/sovereign-cloud/sovereign-public-cloud/sovereign-landing-zone/overview-slz

Deploying Prometheus & Grafana, Tracking DORA Metrics, and Setting Up Alerts: A DevOps Intern's Journey at HNG Tech. | by Nixie | Medium, accessed January 27, 2026, https://medium.com/@NixieB/deploying-prometheus-grafana-tracking-dora-metrics-and-setting-up-alerts-6aa39fdce2cd

SLO Dashboards | Grafana Cloud documentation, accessed January 27, 2026, https://grafana.com/docs/grafana-cloud/alerting-and-irm/slo/overviewdashboards/

Impact tolerance in operational resilience: A guide for businesses - Everbridge, accessed January 27, 2026, https://www.everbridge.com/blog/impact-tolerance-in-operational-resilience/

The Most Important SRE Metrics & How to Track Them | by Rajat Gupta | Engineering Pulse, accessed January 27, 2026, https://medium.com/mr-dops/the-most-important-sre-metrics-how-to-track-them-fe55724ce147

Understanding The 4 DORA Metrics And Top Findings From 2024/25 DORA Report | - Octopus Deploy, accessed January 27, 2026, https://octopus.com/devops/metrics/dora-metrics/

Web service interface: Data | Deutsche Bundesbank, accessed January 27, 2026, https://www.bundesbank.de/dynamic/action/en/statistics/time-series-databases/help-for-sdmx-web-service/web-service-interface-data/855914/web-service-interface-data

How to create a DORA metrics dashboard - SquaredUp, accessed January 27, 2026, https://squaredup.com/dashboard-gallery/dora-metrics-dashboard-devops-team/

Reporting Major ICT-related Incidents and Significant Cyber Threats ..., accessed January 27, 2026, https://www.centralbank.ie/regulation/digital-operational-resilience-act-dora/reporting-major-ict-related-incidents-and-significant-cyber-threats

Publications & Data - DORA Incident Reporting Template - BaFin, accessed January 27, 2026, https://www.bafin.de/SharedDocs/Downloads/EN/Anlage/dl_DORA_Incident_reporting_Template_en.html

ESAs explore centralised ICT incident reporting under DORA - XBRL International, accessed January 27, 2026, https://www.xbrl.org/news/esas-explore-centralised-ict-incident-reporting-under-dora/

JC 2024 108 Report on the feasibility for further centralisation of reporting of major ICT-related incidents - | European Securities and Markets Authority, accessed January 27, 2026, https://www.esma.europa.eu/sites/default/files/2025-01/JC_2024_108_Report_on_the_feasibility_for_further_Centralisation_of_reporting_of_major_ICT_incidents.pdf