Which DORA requirements Airflow helps you evidence for critical financial pipelines
If your financial entity runs scheduled pipelines behind critical or important functions, a self-hosted Apache Airflow deployment can help you evidence two DORA areas: risk-based ICT change management under Article 9(4)(d) to (f), and backup and recovery under Article 12. DORA compliance, and any assessment of it by your competent authority, remains your organization's responsibility. DeployOpen prepares systems, controls and evidence for that work, but it does not issue audit reports, attestations or certifications. For change management, Airflow gives you a place to record how DAG code, configuration and platform upgrades move through review, testing, approval and verification. Pull request approvals, versioned DAG delivery and separated environments produce the records Article 9 expects, provided you define who approves what. For recovery, the controls that matter are the metadata database backups, the procedures to restore it and the scheduler and DAG delivery components around it. Airflow 3 splits the API server, scheduler and DAG processor into separate components, so your backup and restore runbook needs to cover each one.
Airflow does not decide several things DORA requires. Strong authentication choices, cryptographic key protection and access policy under Article 9(4)(a) to (c) and (d) sit with your identity and secrets services, not with the scheduler. Recovery time and recovery point objectives under Article 12(6) are set by you per function, based on whether the function is critical or important, and Airflow can only be tested against them. Terms with ICT third-party providers, including the register of information and exit strategies under Article 28, are contractual matters. Incident classification and reporting under Chapter III are separate processes. Before you scope the work, confirm three things: which pipelines support critical or important functions, what your recovery objectives are for each, and which Airflow version you will run. Airflow 2 reached end of life on April 22, 2026, according to the Airflow version life cycle, so a platform still on Airflow 2 needs an upgrade plan before any change or recovery evidence will be meaningful.
Mapping DORA articles to Airflow capabilities and configuration
This table maps each DORA article in scope to the Airflow capability that supports it, the configuration you need to set, and the evidence to keep. Read each row as a question to answer for your own deployment, since Airflow supplies building blocks and your organization owns the policies, backups and recovery tests.
| Requirement | Airflow capability | Configuration and evidence to keep |
|---|---|---|
| Article 9(4)(d) to (f): risk-based change management and patch policy | DAG code lives in version control, so each change can be reviewed, tested and traced to a commit | Protected branches, required review for DAG and config changes, staging promotion, and a record of which commit each run used. Document who approves Airflow upgrades. |
| Article 9(4)(d) to (f): patch and update policy | Airflow release life cycle with limited maintenance and end-of-life dates | Track the version support table, pin the Airflow version and provider packages, and schedule upgrades before a line reaches end of life. Airflow 2 reached end of life on April 22, 2026 per the version support table. |
| Article 9(4)(d) to (f): upgrade testing before production | Ruff AIR301 and AIR302 rules flag Airflow 2 patterns that break in Airflow 3 | Run the rules in CI on every DAG repository, record the results, and confirm you are on Airflow 2.7 or later before the Airflow 3 upgrade. |
| Article 12(1): documented backup policy and scope | Airflow stores run history, connections and variables in the metadata database, but Airflow does not back it up | Name the metadata database as in scope, set backup frequency based on the criticality of the scheduled processes, and use PostgreSQL or MySQL. SQLite is for testing only and can cause data loss. |
| Article 12(2): backup activation without jeopardizing integrity | Multiple schedulers run at once using database row-level locks | Document how a standby database or restored instance is brought online, and check that backup tooling does not disrupt running schedulers. Confirm the supported database versions in the prerequisites. |
| Article 12(2): periodic restore and recovery testing | No built-in restore test; the test is performed on your database and DAG repository | Restore the metadata database to an isolated environment on a schedule, redeploy the pinned DAG version, and record the outcome and any gaps. |
| Article 12(6) and (7): RTO and RPO per function | Recovery speed depends on database, scheduler and DAG delivery, not on Airflow defaults | Set RTO and RPO per function as critical or important, and measure them in restore tests. Airflow publishes no recovery figures, so confirm targets with your business owners. |
| Article 12(6) and (7): reconciliation after recovery | Run history and task logs show what ran before and after the incident | Compare restored run state with source system records, rerun or clear affected tasks through reviewed procedures, and keep the reconciliation record. |
Change, backup and restore evidence auditors will ask for
DORA Article 9 and Article 12 expect each change and each backup or restore to leave a trace that can be sampled later. The records below connect DAG commits, upgrade tickets, database backups and restore tests so an examiner can follow one change from request to verified recovery.
Version-controlled DAG commits and reviews
Every DAG change should exist as a commit with a reviewer approval, linked to a change ticket. Export the pull request history and the deployed bundle version so you can show which commit ran in production on a given date. Confirm that your Git platform keeps approval records and that branch protection blocks merges without review. Airflow records which DAG version a run used, but the review and approval record lives in your own tooling.
Upgrade change tickets with test results
Each Airflow upgrade, including moves from 2.x to 3.x, needs a ticket that records the target version, the DAG checks run before the change (such as the Ruff AIR301 and AIR302 rules named in the upgrade guide), staging results and the approver. Keep the release notes and the version tested alongside the ticket. Your change management system owns this record, so confirm the ticket links to the commit and image digest that were deployed.
Metadata database backup logs
Backup jobs for the PostgreSQL or MySQL metadata database should write success or failure logs with timestamp, backup size, scope and storage location. Retain these logs with the backup policy that sets frequency and scope. Confirm that backups are taken while the scheduler is running, and that you can show the most recent successful backup for any audit date. The database is the source of run history, so treat its backups as primary evidence.
Restore test reports with reconciliation
A restore test should record the backup restored, the target environment, the steps followed, and the outcome. Reconciliation is the key step: compare DAG run counts, task states and the last successful run per DAG against the source before and after restore. Store the signed report with the change record for the restore exercise. Airflow does not produce this report, so your recovery runbook and test team must.
Recovery time measurements
Record the elapsed time from declared outage to a scheduler running, the database restored and dependent pipelines resumed, using the recovery time objective set for the function. Measure each drill separately and keep the start and end timestamps. Compare results against the objective, and log any gaps as remediation items with owners. Clock times come from your incident and runbook tooling, so confirm the drill record is retained with the restore report.
Linking records to each change
Auditors sample one change and expect to trace it through every record. Use the change ticket ID as the common key in commit messages, upgrade tickets, backup logs and restore reports. Store records for the retention period your policy sets and confirm that the chain can be rebuilt without access to a former engineer's mailbox. Assign the link discipline to your change owner, since no single Airflow feature enforces it.
How to document change management for DAGs and Airflow upgrades
Article 9(4)(f) of DORA requires documented, risk-based ICT change management in which every change is recorded, tested, assessed, approved, implemented and verified. For an Airflow platform, that means two change streams need one written procedure each: DAG releases, which change what runs against financial data, and platform upgrades, which change the scheduler, API server, DAG processor, executors and metadata database. The procedure should name the system of record for each stage, such as the Git pull request for the DAG change, the staging run that tests it, the approver who signs off and the post-release check that verifies the production result. Each DAG change should also link to the commit recorded for the runs it produced, so an examiner can trace a failed or altered run back to the exact code that executed it.
Upgrades carry the larger risk, and the support table sets the timeline. Airflow 2 reached end of life on April 22, 2026, and gets no fixes after that date, so any Airflow 2 estate still in production is an open finding that the change plan must close. The Airflow 3 upgrade guide requires being on Airflow 2.7 or later before upgrading and recommends moving to the latest 2.x first, with DAG code checked using the Ruff AIR301 and AIR302 rules. Record each of these steps as its own change with its own test evidence. Confirm your exact target patch against the version life cycle table on the day you approve the change, because the current patch release changes over time.
Your patch and update policy must be written down and tied to that same support table. State which versions you run, which support stage each one is in (limited maintenance gets security and critical fixes only, end of life gets none), and how quickly you apply each class of fix. Ask your auditor which evidence they will sample for DORA, typically the approved change record, the test result and the post-change verification, and keep those artifacts linked by change ID. Confirm with your own risk function how the policy treats emergency patches, since an out-of-cycle security fix still needs a recorded approval and a verification step.
Configuring backups, restores and recovery objectives in sequence
This sequence takes a self-hosted Airflow from a metadata database that cannot be backed up safely to a documented, tested recovery capability with evidence for each DORA backup and recovery requirement. Each step names who acts and what artifact closes it.
Move the metadata database off SQLite
The platform engineering team migrates the Airflow metadata database from SQLite to PostgreSQL 14 to 18 or MySQL 8.0 or 8.4. MariaDB is not supported as a metadata database, and the production deployment guide warns that SQLite can lead to data loss. The step closes when the production configuration points at the supported database, the Airflow prerequisites for that version are recorded in the change ticket, and a scheduler and API server run cleanly against it. The artifact is the change record with the database version and connection configuration reference, approved through the change process described earlier on this page.
Define the backup policy by data criticality
The information security or risk owner, with the business owner of each critical or important financial process, writes the backup policy. It sets the scope of what is backed up (metadata database, DAG bundles or source repository references, logs and configuration), and the minimum backup frequency for each class of data based on its criticality or confidentiality. The step closes when the policy is approved and every scheduled backup job maps to a named policy line. The artifact is the signed backup policy and a scope table that links each data set to its criticality rating.
Set RTO and RPO per function
The business continuity owner works with each process owner to set a recovery time objective and recovery point objective for every function that depends on Airflow, recording whether the function is critical or important. Recovery order for dependent pipelines is captured here so that restores start from the right upstream jobs. The step closes when each objective is approved by the accountable business owner and the risk owner. The artifact is a per-function objective register that auditors can trace back to the criticality assessment.
Activate and verify backup systems
The platform team configures the backup tooling for the metadata database and related artifacts so that backups run on the schedule in the policy without taking the scheduler offline. Backup systems must be able to be activated without jeopardizing security or data integrity, so the team confirms that backup credentials are scoped, encrypted at rest and access-controlled through the same secrets approach used for Airflow. The step closes when a backup job completes, the output is stored in a location separate from the primary platform, and the job log shows success. The artifact is the backup job configuration, the access list and the first successful run log.
Schedule and run restore tests
The operations team schedules periodic restore tests for the backup procedures and the recovery procedures, and runs them in an isolated environment rather than over the production metadata database. The test restores a recent backup, starts the scheduler and API server against it, and confirms that DAG definitions, connections references, variables and run history match the expected state. Test frequency is set in the backup policy, and the team confirms it with the risk owner. The artifact is a restore test plan and the signed result of each test run.
Reconcile data after recovery
After a restore test or a real recovery, the data owner and operations team run checks and reconciliations to confirm data integrity. They compare run history, task states and outputs of critical pipelines against the source systems or the last known good records, and they identify any runs that must be re-executed or cleared. This step is where the highest level of data integrity is demonstrated, not assumed. The step closes when every reconciliation check has a recorded outcome and any gap has an owner and a follow-up. The artifact is the reconciliation checklist with signed results.
Record results and feed them back
The risk owner reviews the restore test results, reconciliation outcomes and measured recovery times against the objectives in the register. Any missed objective or failed check leads to a logged corrective action, a policy or runbook update, and a re-test. The step closes when the review is minuted and the register and runbooks reflect the latest test. The artifact is the recovery test report, the corrective action log and the updated runbook version, which together form the evidence an assessor will sample.
What DORA backup and change work costs and what it needs from your team
Who pays for what when we build DORA backup and change controls internally versus with a partner?
Internally, your payroll covers every role: platform engineers who build backups and restores, DAG authors who follow the change process, compliance staff who define the evidence, and approvers who sign off changes. With a partner, the written scope sets which of these DeployOpen takes on, such as design, configuration, the first restore test, the upgrade plan and documentation, while your team keeps ownership of business decisions like recovery objectives and approval authority. Your own cloud or infrastructure spend for storage, compute and backup targets is paid to your providers either way. Ask the partner to state in writing which costs sit with you.
Which parts of DORA backup and change work are one-time and which recur?
One-time work includes the change management design, the backup policy, the first recovery objective setting, the first full restore test, and the initial upgrade plan. Recurring work includes periodic restore tests, which Article 12(2) requires to be tested periodically, patch and update cycles under Article 9(4), review of change records and approvals, backup monitoring, and evidence collection for supervisors or auditors. Recurring work is often handled under a retainer, which DeployOpen offers for ongoing support, upgrades and testing. Ask for the recurring items to be listed separately from the build.
What makes DORA backup and change work cost more or less?
The main drivers are the number of DAGs and teams that change them, the size and growth rate of the metadata database, the number of environments such as development, staging and production, and the number of external suppliers whose contracts must be reflected in your process. Each added environment adds promotion steps and tests. A larger database lengthens backup windows and restore tests. More suppliers add contract review and exit planning work under Article 28. Additional factors include whether Airflow runs on Kubernetes or virtual machines and whether restores must work in a separate recovery site.
How long does a fixed-scope DORA backup and change engagement take?
The duration of a fixed-scope engagement is set in the written scope and timeline agreed before work starts, and DeployOpen does not publish standard durations. The schedule depends on the number of environments, the state of existing DAG delivery, whether an Airflow 2 to 3 upgrade is part of the scope, and how quickly your teams can approve designs and run the first restore test. Ask for a timeline with milestones for design, build, restore testing and handover, and confirm which dates depend on your team's availability.
Can our own team implement DORA backup and change management for Airflow alone?
Yes, a capable internal team can build these controls if it has skills in Airflow administration, PostgreSQL or MySQL backup and recovery, Git-based review, and infrastructure automation, and if it can dedicate time to the tests and documentation. The harder parts are usually not technical: they are agreeing on recovery objectives per function, proving restores work on a schedule, and keeping evidence complete over time. Check whether your team has someone who can own the restore test calendar and the change register for the long term, since DORA expects these to be maintained rather than produced once.
What should we request in a written quote for DORA backup and change work?
Ask for a written scope that lists each deliverable, such as the change management procedure for DAGs and Airflow upgrades, the backup policy, the restore procedure, the first restore test report, the recovery objective worksheet and the upgrade plan. Request a statement of which environments, Airflow components and databases are covered, the assumptions your team must meet, and the acceptance criteria for each deliverable. Also ask for the recurring services separately, including restore test frequency, patch cycle support and evidence review, along with the change process for the scope itself. Confirm in writing that the quote is fixed-scope or state the basis if it is not.
What does our team need to provide before a DORA backup and restore build can start?
Your team needs to provide access to the Airflow environments, the metadata database and its current backup setup, the infrastructure where backups are stored, and the list of DAGs with their owners and criticality. It also needs named approvers for changes, a decision on recovery time and recovery point objectives for each function, and a list of the external suppliers that run or host parts of the pipeline. Confirm the data classification for pipelines that handle sensitive records, since it influences backup scope and encryption. Missing inputs in these areas are the most common causes of delay.
What Airflow and DeployOpen cannot provide for DORA
DORA compliance is a property of the financial entity, not of a scheduler or the firm that deploys it. The cards below list what remains with your organization, so that the change management and backup evidence you build with Airflow is scoped correctly and the remaining obligations have a named owner.
No certification or attestation
DORA sets no certification scheme. Competent authorities supervise compliance through their own powers, and the only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7). Neither Apache Airflow nor DeployOpen issues an audit report, attestation or certificate for your deployment. Ask your competent authority and your independent assessor which evidence they expect you to hold.
Recovery objectives are your decision
Article 12(6) requires recovery time and recovery point objectives set per function, taking into account whether the function is critical or important. Airflow does not set RTO or RPO values for the pipelines it runs. Your business owners must assign them to each dependent process, and the backup frequency and restore tests must be designed to meet them.
Strong authentication and key protection
Airflow does not define the strong authentication your organization must apply to administrators, DAG authors and service accounts. Under Article 9(4), you decide the authentication standard, and you manage how cryptographic keys for connections, secrets and metadata encryption are protected in line with your data classification and ICT risk assessment. Airflow provides configuration points for these, but the policy and key custody remain yours.
ICT third-party contract terms
Article 28 requires a register of information on all contractual arrangements for ICT services, and Article 30 requires contract terms covering service locations, data processing locations, advance notice of changes and data return. If DeployOpen or any other partner supports your Airflow, these obligations sit in your contract and your register. Confirm the exit strategy and transition plan under Article 28(8) before signing.
Incident classification and reporting
Airflow can record failed runs, retries and audit events, but it does not classify an ICT-related incident or decide whether it must be reported to a competent authority under Chapter III. Those decisions, and the reporting timelines that follow, remain with the financial entity. Define in your incident process which Airflow failures, such as a corrupted metadata database or a failed restore, trigger classification.
Patch and update policy ownership
Article 9(4)(f) requires documented patch and update policies. Airflow publishes its version life cycle, but your organization decides how quickly it applies limited-maintenance fixes, when it leaves an end-of-life line, and who approves each change. Confirm the support status of your running Airflow line against the version support table before you set the policy.
Where DORA obligations stay with your organization
DORA obligations stay with the financial entity. Your organization owns its ICT risk management framework, its change approval decisions, its backup and recovery objectives, its relationship with its competent authority and any regulatory reporting. DeployOpen and the Airflow community supply software, configuration and implementation help. Neither can make your scheduler compliant on its own, and neither issues an attestation that your entity is compliant. Supervision sits with the national competent authority for your entity type under Article 46, with the ECB involved for significant credit institutions. Ask your compliance team to confirm which authority supervises you before scoping any evidence work.
In practice, the decisions that carry DORA weight are yours: which DAGs count as supporting critical or important functions, who approves an Airflow upgrade, how often the metadata database is backed up, and what recovery time and recovery point objectives apply to each function. A partner can document how the platform behaves and test the procedures you define, but the risk classification and the sign-off belong to your ICT risk owners. Record those decisions in your own policies so that an examiner sees the entity's reasoning, not only the tool's configuration.
Two adjacent frameworks need confirmation with counsel rather than assumption. Article 1(2) links DORA to NIS2 for financial entities that are also essential or important entities, and the Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) is still moving through the legislative process and may change how these obligations are applied. Check the current status of both before you finalize the change management and backup policies described in this topic.
How DeployOpen scopes, delivers and supports DORA-aligned Airflow controls
DeployOpen approaches Apache Airflow under DORA as a written, fixed-scope engagement covering change management for DAGs and upgrades, metadata database backups and tested restores. Each step produces documents and evidence your own ICT risk, change and continuity teams can review and keep.
How we scope
- Inventory which critical or important functions depend on Airflow and which DAGs, schedulers and databases they touch.
- Agree the change workflow for DAGs and Airflow upgrades, including who reviews, approves and verifies each change.
- Set backup scope, backup frequency, RTO and RPO targets with your business owners, recorded in the written scope before work starts.
How we build
- Configure a PostgreSQL or MySQL metadata database with scheduled, encrypted backups stored outside the Airflow cluster.
- Build a restore runbook with reconciliation checks so recovered run history and data can be validated against expected results.
- Run a test restore into an isolated environment and record the results, timings and any gaps against the agreed objectives.
How we hand over
- Deliver the written change management procedure, upgrade procedure and backup and restore policy in a form your teams can maintain.
- Provide a test record for each restore exercise, showing what was tested, by whom, and what remediation followed.
- Walk your operations and audit contacts through where change, backup and restore evidence is stored and how to retrieve it.
How we support
- Ongoing support, upgrades and periodic restore testing are available as a retainer, scoped separately from the build.
- Repeat restore tests on a schedule you set, and update runbooks after each Airflow upgrade or infrastructure change.
- Confirm with your compliance and legal advisers how DORA applies to your entity type, since DeployOpen prepares evidence but does not issue attestations.
