Where Airflow fits in an NIS2 continuity plan for Article 21
If your organization is in scope of NIS2 and schedules critical pipelines in Apache Airflow, you must be able to show business continuity and disaster recovery under Article 21(2)(c) of the Directive. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, information requests and administrative fines, so the evidence you produce is what you will be asked to show. DeployOpen prepares systems, controls and evidence for that assessment, but it does not issue audit reports, attestations or certifications. Independent assessors and national authorities make those determinations.
Airflow supplies recovery building blocks, not the plan itself. The components you will need to protect are the scheduler, the API server, the DAG processor, the workers and, above all, the metadata database, which holds run state and history. Airflow's own production guidance warns against the default SQLite backend in production and recommends PostgreSQL or MySQL. Whether a restored scheduler can resume correctly depends on how the database and the DAG bundles were backed up together. Confirm your recovery design against the current Airflow production deployment guide and your own environment rather than assuming defaults hold.
Airflow does not decide your risk assessment, the roles and contacts for activation, the order in which dependent pipelines return, your recovery time and recovery point objectives, or how you resume from temporary measures. Implementing Regulation (EU) 2024/2690 expects those to come from the risk assessment and to be written into the plan. Before implementation starts, decide who declares an incident, which downstream reports depend on which DAGs, and what your objectives are for each class of pipeline. Those decisions set the scope of the Airflow work, and they remain yours even when a partner builds and operates the platform.
Mapping NIS2 continuity requirements to Airflow configuration
This table compares each NIS2 continuity requirement with the Airflow capability that supports it and the configuration you still need to set. Read each row as an input to your own plan: Airflow supplies features, but the roles, objectives, tests and supplier terms come from your organization. The main takeaway is that no single Airflow setting satisfies a requirement on its own.
| Requirement | Airflow capability | Configuration needed |
|---|---|---|
| Article 21(2)(c): business continuity and backup management | Metadata database holds DAG run state, task history and connections, so its backup determines what can be recovered | Use PostgreSQL or MySQL instead of SQLite, which the production guide says is for testing only; schedule tested backups of the database and DAG source |
| Implementing Regulation 2024/2690, point 4.1.2: roles, activation and recovery order | Airflow 3 splits the API server and DAG processor from the scheduler, so each component can be restored and sized separately | Document which component fails over first, the order in which dependent DAGs resume, and who decides to activate recovery |
| Point 4.1.2: recovery objectives and required resources | Multiple schedulers can run at once using database row-level locks, which supports resilience of scheduling | Set recovery objectives per pipeline, size the database and workers for the standby site, and confirm the scheduler count with your own tests |
| Point 4.1.2: executor and DAG delivery as recovery inputs | Executors such as Kubernetes or Celery determine where tasks run, and DAG code is delivered from a source you control | Record the executor choice and the DAG source repository, then confirm the standby environment can run the same images and versions |
| Points 4.1.4 and 4.3.4: testing, review and updating | Airflow does not test your continuity plan; its run history and logs can serve as evidence of a restore exercise | Schedule restore drills against a copy of the metadata database, record results, and update the plan after significant changes or incidents |
| Article 21(2)(d): supply chain security | Airflow is Apache-2.0 licensed software with no paid edition from the project, so supplier risk sits with any partner or hosting provider you use | Set written obligations for any partner who runs Airflow, covering backup custody, access, incident notice and exit terms |
How to back up and recover the scheduler and metadata database
The metadata database is the single most important thing to protect in a self-hosted Airflow. It holds run state, task instances, variables, connections references and the history that shows what ran and when, so losing it means losing the record that your continuity plan depends on. The Airflow production deployment guide warns that the default SQLite backend is for testing only and that running it in production can lead to data loss. For a plan you must show to a supervisor, use PostgreSQL or MySQL from day one, and confirm the supported versions against the prerequisites for the Airflow release you run. Under Airflow 3, the DAG processor and API server are separate components, so the database is shared state across more moving parts than in Airflow 2.
A restore only works if you capture everything needed to rebuild the platform. At minimum, define backups for the metadata database (scheduled dumps or physical backups with tested point-in-time recovery, depending on your database service), the DAG bundle source in version control so every deployed version maps to a commit, the airflow.cfg settings and environment variables, the secrets backend configuration and the secrets themselves held in the vault, and the container image tags or Helm chart values used for each release. Write down which of these are in your backup scope, who owns each one, and where the copy sits. Ask your database and secrets platform teams to confirm restore procedures for each store, not only that backups run.
Running more than one scheduler is worthwhile for resiliency within one site, because Airflow supports multiple schedulers using database row-level locks. It does not protect you from losing the site, the database cluster or the cloud region that hosts them. A second-site recovery path needs its own replicated or restorable metadata database, a secondary location for the DAG source and images, and a tested activation runbook. Your organization must set its own recovery time and recovery point objectives for the scheduler and each dependent pipeline, since these depend on your risk assessment and the business impact of delayed data. Confirm those objectives with the business owners before you design the second site, not after.
Setting the recovery order for dependent pipelines
This sequence turns a list of Airflow pipelines into an agreed recovery order, so the platform comes back first, the most critical pipelines follow, and each restart avoids duplicate or missing data. The order is a business decision that should trace back to the risk assessment NIS2 requires.
Inventory DAGs that feed critical services
Start with a list of every DAG and the business service each one supports, such as regulatory reporting, customer-facing data feeds, or payment reconciliation. Pipeline owners confirm which DAGs are needed for essential services and which can wait. The check is a signed inventory with one named owner per DAG and a criticality rating that links to the risk assessment.
Map upstream and downstream dependencies
For each critical DAG, record the systems it reads from and writes to, including databases, object storage, message brokers, APIs, secrets stores and identity providers. Also record which other DAGs depend on its output, using Airflow's dataset and task dependencies as a starting point. The check is a dependency map reviewed by the pipeline owners and the platform team.
Define the platform restore order
Place the Airflow components in the order they must return: the metadata database first, then the secrets and identity services the scheduler needs, then the scheduler, DAG processor, API server, executors and workers. Confirm the database restore point with the team that owns it, because the scheduler cannot resume correctly on an unknown state. The check is a runbook that lists each component, its owner and the condition that marks it healthy.
Set the pipeline restore order and activation rules
Rank the critical DAGs by the business impact of delay, then group the upstream systems they need so that each group restores before its dependants. Define the activation conditions that trigger recovery, and name the role that decides, such as the service owner with the incident commander's approval. The check is a ranked list with written activation criteria and a named decision-maker for each tier.
Record the resources each recovery step needs
For every step in the restore order, list the people, credentials, compute capacity, storage and network access it depends on, and note where each is stored and who can access it during an outage. Check that backup copies of secrets and configuration are available outside the failed environment. The check is a resource register that the on-call team can use without relying on the failed system.
Plan the move from temporary processing
Where a critical pipeline ran manually or through another tool during the outage, define how its output is reconciled with what Airflow later processes. Use idempotent task design, watermarks or data checks to confirm which intervals were already loaded, and clear or backfill only the missing intervals. The check is a documented catch-up procedure tested on a non-production copy of one representative DAG.
Confirm the order against the test results
Run a recovery exercise that follows the written order, then compare the actual restore sequence and timings with the plan and record any dependency that was missed. Update the inventory, map and runbook, and re-approve the criticality ranking with the service owners. The check is a dated exercise report with corrective actions, which NIS2 expects to be reviewed after significant changes or incidents.
Testing the continuity plan on a schedule and after change
A restore test proves that the backup of the Airflow metadata database can be brought back into an isolated environment and that the restored state matches what the plan says it should contain. Run it against a copy of production-equivalent data, never against the live database. Airflow keeps DAG run history, task instances, connections references, variables and pools in this database, so the test should confirm more than that the restore command finished.
- Isolated target: Restore into a separate PostgreSQL or MySQL instance with no network path to production schedulers, workers or source systems.
- Row count comparison: Compare row counts for key tables such as
dag_runandtask_instanceagainst the backup manifest or a recorded snapshot taken at backup time. - Recent run check: Confirm that the latest successful runs for the most critical DAGs appear in the restored data with the expected states.
- Restore duration: Record how long the restore took from the start of the restore to a verified database, so the recovery objectives in the plan can be checked against actual timings.
- Dated record: Keep the commands used, the backup identifier, the operator, the start and end times, and any differences found.
Before closing the test, ask the team to confirm that the restored database is destroyed or access-controlled according to the data handling rules, because it contains run metadata that may reference personal data.
A tabletop exercise walks the people named in the plan through a realistic but invented scenario without touching systems. Its purpose is to test decisions: who declares an incident, who decides to fail over, who contacts the business owners of dependent pipelines and who talks to the supervisor if the plan says so. Write the scenario so that the Airflow scheduler, the metadata database and one downstream data store are unavailable at the same time (illustrative).
- Activation conditions: Ask participants to state, from the plan, which condition triggers the continuity arrangements and whether the scenario meets it.
- Roles and contacts: Check that each named role has a current contact route and that the contacts listed are still employed or contracted.
- Recovery order: Ask participants to name, in order, which pipelines restart first and which wait for upstream data.
- Temporary measures: Discuss how manual runs or reduced schedules would be used and how normal operation resumes.
- Evidence: Record the date, the scenario, attendees, decisions taken, gaps found and owners and due dates for fixes.
The exercise should end with a list of plan changes, each assigned to a named owner, because an exercise without tracked fixes will not satisfy a reviewer.
A partial failover test moves one dependent pipeline to the recovery arrangement while the rest of the platform stays in place. This shows that the recovery path works technically, not only in the plan. Choose a pipeline that has real downstream consumers but limited blast radius, and agree in advance how its output will be checked, so the test does not disrupt business reporting.
- Recovery path: Confirm the target scheduler or environment, the DAG bundle version it runs and the connections it needs, without copying production secrets into documentation.
- Controlled trigger: Run the pipeline for a defined interval and compare its outputs with the outputs from the primary path for the same input.
- Dependency checks: Verify that upstream sensors or triggers behave as designed when the upstream dataset is late or missing.
- Failback: Test the return to the primary path, including how duplicate or missing runs are reconciled.
- Evidence: Keep the run IDs from both paths, output comparison results, timing observations and any manual steps taken.
Check with the platform team that the test did not depend on undocumented knowledge held by one person, since that dependency is one of the first things a reviewer will probe.
Plans must be reviewed and updated after significant changes, and an upgrade is one of the clearest triggers. Airflow 3 changed core components: the webserver is replaced by an API server, the DAG processor runs as a separate component, and task code uses the Task SDK rather than database sessions. Each of these can change how a backup is taken, how a restore is validated or how a failover is started, so the affected tests need to be run again rather than assumed.
- Scope the retest: List which components changed (scheduler, API server, DAG processor, executor, database, Helm chart or image) and map each to the test it affects.
- Repeat the restore: Restore a backup taken after the upgrade and confirm the schema and row counts are as expected for the new version.
- Repeat the recovery path: Confirm the recovery environment runs the same Airflow version and configuration as production.
- Update the plan: Record any changed commands, hostnames, roles or recovery order in the plan and version the change.
- Evidence: Keep the change ticket, the retest records and the plan revision together so the link between change and test is visible.
Check that the upgrade itself was preceded by a tested backup, and confirm which Airflow versions remain under security support at the time of the change, since that affects how long the platform can stay on a given release.
Evidence auditors and supervisors ask to see
A supervisor reviewing NIS2 continuity will ask for a plan, the risk assessment behind it, and proof that the plan has been exercised and kept current. The cards below list the items to keep for Airflow, how to keep each one up to date, and where Airflow run history and logs add useful detail.
Continuity and recovery plan
The written plan should name the people responsible for Airflow recovery, their contacts, the conditions that activate the plan, the order in which DAGs and dependent systems return, recovery objectives, and the resources needed. Record the metadata database, scheduler and worker locations as part of the plan so a reviewer can trace each recovery step. Review the plan after every significant change to the Airflow deployment, such as a version upgrade or a move to a new executor, and record the approval and date of each revision.
Risk assessment behind the plan
The continuity plan has to rest on a documented risk assessment, so keep the assessment that identifies Airflow as a dependency for critical processes and rates the impact of losing the scheduler or metadata database. Note which DAGs feed reporting, customer services or regulated data flows, and why each is ranked where it is. Revisit the assessment when new pipelines are added or when Airflow becomes responsible for a process it did not handle before.
Backup job records and restore tests
Keep the schedule and success records for metadata database backups, along with the configuration used to back up DAG code, connections and any external secrets references. Most important is the restore test log: date, scope, the person who ran it, the time to recover, and the defects found. A backup job that completes does not prove that a restored scheduler resumes correctly, so the restore record is the evidence that matters most. Confirm the backup tooling for your PostgreSQL or MySQL instance with the vendor documentation.
Test and review records with dated changes
Continuity, disaster recovery and crisis plans must be tested, reviewed and updated at planned intervals and after significant incidents or changes. Keep a dated register of each exercise, its scenario (for example, a lost scheduler host in a single-scheduler setup), the findings, and the plan revision that followed. Dated entries let an assessor confirm the plan changed when Airflow changed, not just that a review happened once.
Incident and post-incident reviews
When the scheduler stops, a worker pool fails or a metadata database becomes unavailable, record the timeline, the detection source, the recovery steps and the decisions made. Airflow run history, task logs and scheduler logs can reconstruct when runs stopped and resumed, which supports the timeline. Do not treat those logs as the full review, because the review must also cover the people, communication and supplier steps taken, and it must feed back into the plan.
DAG change history from version control
Changes to DAG code, plugins and deployment configuration should be traceable to a commit and an approver, so you can show which version of a pipeline ran during an outage or a recovery. Pair the Git history with a record of which Airflow version was deployed and when each upgrade was tested. Airflow 3 supports the Task SDK and API server split, so the upgrade record should also cover component changes that affect recovery order.
Supplier obligations when a partner runs Airflow for you
Article 21(2)(d) of NIS2 requires supply chain security, which covers the security-related aspects of the relationship between your entity and its direct suppliers or service providers. If a partner installs, operates or recovers your Airflow environment, that partner sits inside your continuity plan, and the contract should say so. Write down who holds each backup of the metadata database, the DAG bundles and the secrets backend configuration, where those copies are stored, how they are encrypted, and how quickly the partner must produce them during an incident. Confirm that the partner's restore runbook names the same recovery order your plan sets for dependent pipelines, and that the restore is tested against your own environment rather than assumed.
Access is the second point to settle in writing. List which partner staff can reach the scheduler host, the Kubernetes namespace or the database, under what approval, and how those sessions are logged and reviewed by your team. Ask for the partner's incident notification path with named contacts, the time they commit to notify you after detecting an event affecting Airflow, and who decides on activation of the continuity plan. Require the partner to take part in your planned recovery tests and to support reviews after significant changes, since the Implementing Regulation expects plans to be tested and updated at those points. Exit terms should cover handover of configuration, DAG code, credentials rotation and a documented return to in-house operation.
Hosting and support location add separate questions that this section does not settle. If the environment runs in a cloud or data center operated outside the EU, or if the partner's engineers can view data from a third country, the GDPR transfer rules in Chapter V and the switching and third-country access provisions of the EU Data Act may apply. Your organization needs to assess those questions with its legal and data protection teams. The EDPB guidance on transfers addresses remote access and storage outside the EEA in general terms, so start from that guidance and confirm your own position before signing.
What Airflow and DeployOpen do not cover for NIS2
A self-hosted Airflow can carry part of a continuity plan, but the obligations around it sit with your organization, its regulator and its suppliers. The cards below name the gaps so that your risk assessment, notification process and legal review are scoped before any recovery work starts.
Risk assessment and recovery objectives
The continuity and disaster recovery plan must rest on your risk assessment, and the recovery objectives it sets determine how often the metadata database is backed up and how fast the scheduler must return. Neither the platform nor DeployOpen can decide which pipelines are critical to your services. Before scoping backups, confirm which DAGs feed essential services, what downtime each can tolerate and who signs off those objectives.
Incident reporting under Article 23
Article 23 sets reporting deadlines for significant incidents, and a failed or corrupted scheduler can meet the threshold even when no data leaves the environment. Airflow records task and run history, but it does not classify incidents or notify your national authority. Your incident response procedure must define who decides significance, who files the report and which Airflow evidence is preserved before a restore overwrites it.
National transposition rules
NIS2 is a directive, so the obligations that bind your entity come from the national law that transposes it, and Member States may keep or adopt stricter rules. Recovery timing, backup location and evidence formats can differ by country. Ask legal counsel which national law applies to your entity, which competent authority supervises it and whether any local rule sets retention or reporting periods for run data.
Supervision, inspections and fines
NIS2 creates no certificate of compliance. Competent authorities oversee compliance through inspections, security audits, scans, information requests and administrative fines, and essential entities face ex ante supervision. A tested Airflow recovery process helps you answer those requests, but it does not replace your own evidence file. Plan who collects test records, restore logs and plan reviews so they can be produced on request.
Source systems and target databases
Airflow restores its own scheduler and metadata database, but the data pipelines read from and write to systems it does not control, such as warehouses, object stores and operational databases. A restored DAG that reruns against a source that was itself restored to an earlier point can duplicate or skip records. Each dependency needs its own recovery point, owner and rerun rule, and those owners must agree the recovery order with you.
Proposed amendments in COM(2026) 13
The Commission proposed targeted amendments on 20 January 2026, including a new small mid-cap category, but the proposal still needs approval by the European Parliament and the Council. Your obligations today follow the directive and its national laws, not the proposal. Track the file through the adoption process and reassess your entity category and deadlines when the text is final.
Configuration sequence for a continuity-ready Airflow
This sequence sets up Airflow so its scheduler, metadata database, DAG source and secrets can be rebuilt in a known order, and it leaves dated evidence that the recovery was tested. Each step produces an artifact an auditor or competent authority can ask to see.
Select a supported metadata database
The platform team chooses PostgreSQL or MySQL from the versions listed for Airflow 3.3.2 in the prerequisites, and rules out MariaDB and SQLite for anything beyond testing. Confirm the chosen engine version against the prerequisites page at the time of build, and record the version, the Airflow release and the Python and Kubernetes versions in the continuity configuration record. The step is done when a clean install connects to the database and the version record matches what is running.
Separate scheduler, API server and DAG processor
Deploy the scheduler, the API server started with the airflow api-server command, and the DAG processor as separate components, each with its own restart policy and resource limits. Airflow 3 requires the DAG processor to run separately, and the scheduler supports more than one instance using database row-level locks, so the team should decide and document how many scheduler replicas run in each environment. The step is done when each component can be stopped and restarted independently and the runbook names the start order.
Store DAG source in version control
Keep all DAG code, the requirements files and the deployment configuration in a Git repository that the recovery team can reach without the production cluster. Pin the commit or bundle version that each environment runs, so a rebuild restores the same code that was live before the incident. The step is done when the team can name the commit running in production and rebuild the DAG folder from that commit in a separate environment.
Script metadata database backups
Automate regular backups of the metadata database with a documented schedule, encryption and off-site storage chosen by the operations team, and have the job report success or failure to a monitored channel. Store backup retention and location in the continuity plan so a reviewer can trace them. The step is done when a backup job has run and produced a file whose location, size and checksum are logged.
Test restore of the metadata database
Restore the most recent backup into an isolated environment, start the Airflow components against it, and confirm that DAG runs, task history, connections and variables load as expected. Time the restore and record every manual step that was needed, because those steps become the runbook. The step is done when the restored system shows the expected run history and the test record is signed by the operator who performed it.
Externalize secrets and connection credentials
Move connection passwords, API keys and encryption keys out of the metadata database and configuration files into the secrets backend your organization already operates, and document which key material the restore procedure needs. Confirm that a restored environment can reach the secrets store and that the Fernet or equivalent encryption key is held separately from the database backup. The step is done when a test restore connects to its sources using secrets fetched from the external store, without copying credentials by hand.
Document recovery order and roles
Write the recovery order for the platform and each dependent pipeline group, naming the owner, the deputy and the contact for each role, and the condition that activates the plan. Include which upstream sources must be healthy before a dependent DAG is reactivated and how backfills are scoped after recovery. The step is done when the plan lists every role with a named contact and the order is agreed by the owners of the dependent pipelines.
Schedule tests and record results
Set a recurring restore test and tabletop exercise on a schedule the organization sets in the continuity plan, and run an extra test after any significant change to Airflow, the database or the secrets store. Record each test with its date, scope, participants, failures and the corrective actions, and link corrective actions to the change management system. The step is done when the register holds results for the latest test and each open finding has an owner.
Questions buyers ask before engaging a partner for Airflow continuity
What does Airflow continuity work cost and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of environments in scope (production, staging and any disaster recovery site), the number of dependent pipelines that must be restored in order, the recovery objectives you set for each, and how often the plan is tested. Each added environment or pipeline adds design, build and test work. Ask for a quote that separates one-time work (plan design, backup configuration, restore runbooks, first test) from recurring work (scheduled restore tests, plan reviews after significant changes, and any retainer for ongoing support). Ask who provisions and pays for the infrastructure and storage, because that cost sits outside the service fee.
How long does an Airflow continuity engagement take?
Duration depends on the same factors that drive cost: how many environments and dependent pipelines are in scope, how much of the backup and recovery design already exists, and how quickly your team can review and approve each deliverable. Engagements are fixed-scope, so the timeline is agreed in writing before work starts. A plan that must cover a disaster recovery site, or pipelines with long dependency chains, takes longer to test than a single-environment plan. Ask for a timeline with named milestones and for the dates on which your team must provide access, approvals and test windows.
What does our team need to provide during a continuity engagement?
You need to provide the people and access that the plan depends on. In practice this means a named owner for the continuity plan, access to the production Airflow environment, its metadata database and the infrastructure that runs it, and a list of business owners for each dependent pipeline with their acceptable downtime and data loss. Your team must also supply the output of your risk assessment, because the plan should be based on it, and approve the recovery order and contacts. Plan for test windows that do not disrupt live reporting. Confirm which systems are out of scope, such as source databases or downstream consumers, since their recovery sits with their owners.
Can our internal team build and test the Airflow continuity plan alone?
Yes, if your team has the skills and capacity. Internal teams usually handle the core work well when they already run Airflow, the metadata database and the underlying infrastructure. The gaps tend to be the independent restore test, the recovery order across dependent pipelines, and the written evidence that a regulator or auditor will ask for. NIS2 requires the plan to be tested, reviewed and updated after significant incidents or significant changes, so the question is whether your team can sustain that cycle alongside daily operations. Ask an outside partner to review your plan against the requirements, or to run a first restore test, if you want a second set of eyes. Whichever route you choose, the plan remains your responsibility as the regulated entity.
Does our Airflow version affect continuity planning?
Yes. Airflow 2 reached end of life on April 22, 2026, after which it receives no fixes, so a continuity plan built around an Airflow 2 deployment must include the upgrade path. According to the Airflow version support table, Airflow 2 entered limited maintenance on October 22, 2025, when it began receiving only security and critical bug fixes. Airflow 3 was first released on April 22, 2025, and its current patch release is 3.3.2. The Airflow 3 upgrade guide requires being on Airflow 2.7 or later before upgrading. If you are still on Airflow 2, ask for the upgrade to be planned alongside the continuity work, and confirm the target version against the official support table before you finalize recovery objectives.
Does DeployOpen certify that our Airflow continuity plan is NIS2 compliant?
No. DeployOpen does not issue certifications, attestations or audit reports. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DeployOpen can prepare the plan, the recovery runbooks, the test records and the supporting evidence so your organization can show how it meets the business continuity and disaster recovery requirements. Your national authority or an independent assessor decides whether that evidence is sufficient. Ask any partner who offers a compliance certificate to explain which body issued it and what it covers.
What does a supplier obligation mean when a partner runs our Airflow?
NIS2 Article 21(2)(d) requires supply chain security, including the security-related aspects of your relationship with direct suppliers and service providers. When a partner plans, restores or operates your Airflow, that partner becomes part of your supply chain for continuity purposes. Expect the contract to cover roles, contacts, incident notification, access control, how backups are protected, where data is stored, and what happens when the engagement ends. Confirm in writing who can trigger recovery, how the partner's access is logged and removed, and how your plan keeps working if the partner is unavailable. Your legal and compliance teams should review these terms against your national transposition law.
How DeployOpen scopes continuity work
Continuity work for Airflow starts with a written scope, not an hourly estimate. DeployOpen agrees the scope, deliverables and timelines in writing before any work begins, and then provides a written quote that follows from that scope. For this topic, the scope should name the components in the plan: the scheduler and DAG processor, the API server, the metadata database and its backup method, the executors and workers that run dependent pipelines, the secrets backend, and the recovery order you need for each pipeline. It should also state which environments are covered (production only, or staging as a restore target) and who owns each decision, such as the recovery objectives and the activation conditions for the plan. Ask for these items to appear as explicit deliverables so that a missing one is visible before work starts, not after an incident.
Two kinds of work recur after the first build, and they should be priced separately. The first is the initial build: the plan, the backup and restore configuration, the recovery runbook and the first full restore test. The second is ongoing testing and upgrades, which can be covered by an optional retainer. Because NIS2 expects continuity plans to be tested and updated after significant changes, a retainer that covers repeated restore tests and Airflow upgrades may suit your organization better than a one-off project. DeployOpen prepares systems, controls and evidence for assessments, including the test records and plan documents your auditor or national competent authority may ask for. It does not issue audit reports, attestations or certifications. Confirm with your own compliance lead which evidence format your regulator expects, and confirm that the quote states what the retainer covers and how it can be changed.
How DeployOpen delivers NIS2 continuity for Airflow
DeployOpen plans, builds and documents the continuity arrangements for a self-hosted Apache Airflow inside infrastructure you control, so the backup, recovery order and test evidence can be reviewed by your team and your auditors. Engagements are fixed-scope, with the deliverables and timelines agreed in writing before work starts.
How we scope
- We confirm which DAGs, workloads and dependent systems fall within the continuity plan and which sit outside it.
- The written scope names the metadata database, scheduler, executors, DAG delivery and secrets backends covered by recovery work.
- Recovery objectives, roles, contacts and activation conditions are agreed with your risk owners before any build begins.
How we build
- We configure and document backups of the Airflow metadata database and the DAG delivery source, with restores tested in a separate environment.
- We design the recovery order for upstream sources, Airflow components and downstream pipelines, and record it as a runbook.
- We set up scheduler and executor redundancy in the target environment and verify failover behavior against the agreed scope.
How we hand over
- You receive the continuity plan, runbooks, restore test records and configuration documentation for your own records.
- Your team runs a walkthrough of a planned recovery exercise so operators know the activation steps before an incident.
- We document which supplier responsibilities, access paths and evidence sources apply when DeployOpen operates parts of the platform.
How we support
- Ongoing support, upgrades and periodic recovery testing are available as a retainer, scoped in writing.
- We review the plan after significant changes, such as an Airflow upgrade or a new executor, and update the runbooks accordingly.
- Support terms, response expectations and reporting are confirmed in the written agreement, and quotes follow from the agreed scope.
