Which ISO 27001 controls Airflow evidence supports
An ISMS owner or platform lead who must show an auditor how DAG changes and pipeline logs are controlled needs to know which Annex A controls the Airflow records actually answer. The short answer: A.8.32 Change management and A.8.15 Logging are the two controls where a self-hosted Airflow produces most of the evidence, and they are supported by configuration (how DAG code is reviewed, delivered and promoted) and by records (task logs, audit logs and run history) rather than by a single feature. A.8.9 Configuration management, A.8.19 Installation of software on operational systems and A.8.31 Separation of development, test and production environments are closely related and are usually sampled alongside them, so plan their evidence at the same time.
The standard in force is the 2022 edition, ISO/IEC 27001:2022, the third edition of the standard, and its Annex A is normative and lists 93 controls in four themes. Airflow does not make anyone compliant on its own. Your organization defines the change procedure, the approvers, the environment split and the log retention, and DeployOpen prepares the systems, controls and evidence for that work. Accredited certification bodies perform the audit and issue any certificate, and DeployOpen does not issue audit reports or certifications. Confirm with your certification body which controls and evidence samples it will select for your scope, and confirm your ISMS documentation covers DAG authorship and approval, not only application code.
Before the build starts, decide three things and write them down: which Airflow environments fall inside the ISMS scope, who may approve a DAG change for each environment, and how long task and audit logs are kept and where they are stored. The 2022 control attributes and wording are available from ISO and from ISO/IEC 27002:2022 guidance (which you must buy from the publisher to read in full). Use those decisions to map each Airflow record to a control ID, so the auditor sees a clear chain from policy to sample rather than a folder of exported logs.
Mapping A.8.32, A.8.15 and related controls to Airflow configuration
This table compares five ISO/IEC 27001:2022 Annex A controls with the Airflow capabilities and configuration that support them. Each row states the requirement, what Airflow provides, and what your team must set and confirm in its own version. Auditors test your operating records, so use the table to plan which evidence each setting produces.
| Control and requirement | Airflow capability | Configuration needed |
|---|---|---|
| A.8.32 Change management: changes to information systems follow a controlled procedure | DAG code can be reviewed in Git before deployment. Deployed DAG versions can be traced to a run, depending on how DAGs are delivered. | Require reviewed pull requests on the DAG repository. Confirm in your version how run history records the DAG version used. |
| A.8.15 Logging: activities, exceptions and faults are recorded, stored, protected and analyzed | Audit log for user actions, task logs per attempt, and scheduler and DAG processor logs. | Ship logs to a central store with restricted write access and set retention. Confirm which events your version writes to the audit log. |
| A.8.9 Configuration management: configurations are documented, approved and monitored | Settings come from the configuration file and environment variables. The auth_manager option allows only one auth manager at a time. | Keep configuration in version control and load secrets from a secrets backend. Review every change to auth settings. |
| A.8.19 Installation of software on operational systems: software is installed under controlled procedures | Official Docker image and Helm chart. Airflow 3 runs the API server and DAG processor as separate components. | Build images from pinned versions and promote them through approved change. Confirm supported Python, PostgreSQL and Kubernetes versions for your release. |
| A.8.31 Separation of development, test and production: environments are separated | Each environment can run its own Airflow deployment with its own metadata database and connections. | Use separate metadata databases and credentials per environment. Promote DAGs to production only after staging tests pass. |
How reviewed DAG changes meet change management in practice
A.8.32 expects changes to information systems to follow a change management procedure, and for Airflow that procedure is mostly about how DAG code gets from a pull request to the scheduler. The practical design question is where the reviewed version of each DAG is stored, who can approve it, and whether a run can later be tied back to the exact code that produced it. Keep DAG source in a Git repository that your organization controls, require review by someone other than the author before merge, and promote the same reviewed commit through a staging Airflow environment before production. Keep staging and production on separate infrastructure, as A.8.31 also expects, so a change that passes review is tested in an environment that resembles production.
Airflow 3 changes the mechanics. The DAG processor now runs as a separate component from the API server, so the process that parses DAG files and the process that serves the UI and API are distinct. Your change record should show which DAG bundle or source version each environment's DAG processor loads, not only which repository commit was merged. Confirm with the Airflow 3.3.2 documentation which bundle and versioning options your deployment supports, how a run records the bundle version it used, and how long those records are retained. Do not assume a run is traceable to a commit until you have tested it by triggering a run after a known change and reading the recorded version in the run details.
Define the approvers before the first change, not during an incident. Write down who may approve DAG changes for each team, who may approve changes to the Airflow deployment itself (image, providers, configuration and upgrades), and who may approve an emergency change that skips staging. Map these roles to the identity provider used for Airflow access so the approval record and the Airflow role model agree. Auditors commonly sample recent changes and ask for the review, the approver's authority and the deployment that followed, so an approval list that cannot be matched to the merged commit and the run history creates findings even when the review itself happened.
Separating development, test and production Airflow environments
Each stage runs its own Airflow installation with its own API server, scheduler, DAG processor, workers and metadata database. Nothing a developer does in development can reach the production metadata database or its connections, which makes the separation easy to explain to an auditor. Evidence for A.8.31 is a clear inventory of stage boundaries, and evidence for A.8.19 is a record of which package versions and images were installed in each stage and when.
- Metadata database isolation: Each deployment gets its own PostgreSQL or MySQL instance or database and its own credentials. The Airflow 3.3.2 prerequisites and the production guide recommend PostgreSQL or MySQL, not SQLite, and MariaDB is not supported as the metadata database.
- Connection and secret scope: Production connections exist only in the production secrets backend, so test runs cannot touch live systems by accident.
- Operating effort: Upgrades, patches and backups run once per stage, so the effort roughly multiplies with each environment.
- Configuration drift: Settings such as executors and resource limits can diverge over time, so keep the deployment definitions in version control and compare them during change reviews.
Confirm with your own team how many stages must be fully separate, and whether the staging environment needs production-sized capacity for realistic test runs.
One Airflow installation serves several stages, and separation comes from how DAG code is delivered and which DAG bundles each stage can see. This reduces the number of components to patch and back up. The trade-off is that the shared control plane becomes a single point of failure for every stage, so the separation depends on access controls and delivery design rather than on infrastructure boundaries.
- DAG delivery by branch or bundle: Each stage loads DAGs from a version-controlled source tied to a branch or release tag, so the commit in use is recorded for each run. This supports A.8.32 evidence as well as A.8.31.
- Role-based access: Restrict who can trigger, clear or edit runs in production, and record those permissions for the auditor.
- Connection separation: Use distinct connection IDs and secrets per stage, because a shared metadata database holds every connection definition.
- Blast radius: A faulty upgrade or scheduler outage affects all stages at once, so plan the change window and rollback steps carefully.
Ask how the team will prove that a test DAG cannot write to production data, since a shared control plane makes that proof rely on configuration and access reviews.
When Airflow runs on Kubernetes, each stage can sit in its own namespace with separate Helm releases, service accounts, network policies and resource quotas, while the cluster itself is shared. The official Helm chart and the official Docker image are used per namespace, which gives a consistent deployment pattern. Namespaces separate workloads, but they are not a full security boundary on their own, so treat the cluster's role-based access control and network policy as part of the evidence.
- Per-namespace database: Each namespace should point at its own PostgreSQL or MySQL instance or database, not a shared one.
- Image promotion: Promote the same container image digest from test to production, and record the digest in change records for A.8.19 evidence.
- Access boundaries: Limit who can change namespace resources, Helm values and secrets, and log those changes through the Kubernetes audit log.
- Operating effort: The platform team maintains the cluster, policies and quotas, which adds effort if the team is not already running Kubernetes.
Confirm that your Kubernetes distribution and Airflow 3.3.2 are on supported versions and that the policies you rely on are enforced in every namespace.
Which Airflow logs an auditor can sample for A.8.15
An auditor testing A.8.15 Logging will ask which records show who changed what, what ran, and what failed. In a self-hosted Airflow, those answers come from several separate components, each with its own storage and retention, so the evidence set has to be designed rather than assumed. The cards below cover the sources to confirm and protect.
Audit logs of user and API actions
Airflow records administrative and user actions such as triggering, pausing, clearing or editing runs, which is the record an auditor uses to test who changed operational state. Confirm the exact event names and fields in the audit log for your Airflow version, and check whether API calls made with service tokens are attributed to a named identity. Store the table or exported records outside the metadata database so a cleanup job cannot remove them. Restrict read access to the audit trail itself, since it reveals who runs sensitive pipelines.
Task logs per run
Each task instance writes its own log, which holds the commands, output and errors for one attempt of one DAG run. These logs are the primary evidence that a scheduled job executed and how it failed, so an auditor will sample them against a specific run ID. Confirm where your deployment stores them (local disk, a shared volume, or object storage) and how long they persist. Protect them because task output can include data values or connection details if code prints them.
Scheduler and DAG processor logs
The scheduler decides when runs start, and the DAG processor parses DAG files and reports import errors. Both are needed to show when a changed DAG was picked up, why a run was or was not created, and whether a broken file was rejected. Airflow 3 runs the DAG processor as its own component, so collect its logs separately from the scheduler. Confirm the log level and rotation settings for each process on your host or pod.
API server access logs
The API server now serves the web interface and the REST API in Airflow 3, so it is the entry point for every interactive and programmatic action. Its access logs record requests, source addresses and response codes, which support investigations of unexpected triggers or failed logins. Confirm whether your reverse proxy or load balancer logs requests before they reach Airflow, since client addresses may otherwise show only the proxy. Keep these logs with the same retention as your identity provider's records.
Metadata database run history
The metadata database keeps DAG run and task instance state, start and end times, and retry counts, which is the structured record of what happened over time. Auditors often use it to sample a population of runs and check status and timing against the change that was supposed to be in effect. Back it up on a schedule and avoid aggressive cleanup of run history without an approved retention rule. Confirm the cleanup settings for your version before enabling them.
Log shipping to a central store
Shipping scheduler, API server, worker and audit logs to a central platform such as a SIEM or log store gives you one protected, time-synchronized record that outlives individual containers. This is where retention, access separation and tamper resistance are usually enforced. Decide which fields are forwarded, how logs are labeled by environment and DAG bundle, and who can delete them. Confirm the shipping method your Airflow deployment supports before committing to a design.
What an auditor samples and how to answer the request
A certification body samples records across the audit period, not just the day of the visit. Accredited bodies work to ISO/IEC 17021-1 and ISO/IEC 27006-1, and a certificate sits in a three-year cycle with at least one surveillance or recertification audit in every calendar year. Each audit looks back over the period since the previous one, so the auditor will ask for a spread of changes made across that window, including some made early in it. Ask your certification body which period it will sample and how many changes it expects to select, because that number is set by its own procedures and your organization's change volume, not by DeployOpen.
A typical sample for one DAG change follows a chain. The auditor picks a change record and checks who requested it, who approved it and whether the approver was independent of the author. They then compare the approval with the version that actually ran: the commit or bundle version recorded for the DAG, the deployment time and the environment it reached. Finally they pick run logs from the period after deployment and check that the task and scheduler records belong to that version. Confirm with your team which Airflow fields and log entries carry the DAG version for each run, since a run that cannot be matched to a version will fail the test even when the change was approved.
The evidence must tie the change to the run, in both directions. A change record with no runs behind it shows that a change was approved but not that it operated, and runs with no change record raise the question of unauthorized modification. Before the audit, pick two or three changes yourself, trace each to its runs and check that the chain can be rebuilt from stored records without someone's memory. Treat any gap you find as a finding to fix now, because the auditor will find it too.
What Airflow does not cover for ISO 27001
Airflow can produce change and log records for A.8.32 and A.8.15, but it cannot make your organization conform to ISO/IEC 27001:2022. The cards below name the parts that sit with other owners, and what each owner must provide before an auditor asks.
The ISMS itself
The scope statement, risk assessment, information security policies and management review belong to the organization's ISMS, owned by the information security lead and top management. Airflow has no part in defining which systems are in scope or how risks are rated. Check that the ISMS scope names the Airflow environments, the metadata database and the DAG repositories, so the change and logging evidence has a documented home.
Change approval workflow outside Airflow
Approval of a DAG change is a business and risk decision made in your change process, usually owned by the change advisory board or the platform owner. Airflow records who triggered a run and which code version ran, but it does not know whether the change was approved. Confirm that each merged DAG change maps to a ticket or approval record that names the approver and the date.
Emergency change process
Urgent fixes to a failing production pipeline need a defined path that still leaves a record. This process is owned by the on-call or operations lead and must be written down before the emergency happens. Ask who may bypass normal review, how the change is recorded afterward and when it is reviewed retrospectively, because auditors often sample emergency changes separately.
Git hosting and branch protection
Airflow sees the DAG bundle, not the repository controls that protect it. The Git platform owner must enforce required reviews, restrict direct pushes to the production branch and keep the account and group settings under change control. Confirm that the commit hash deployed to each Airflow environment can be traced back to a protected branch and an approved merge request.
Log retention and SIEM analysis
A.8.15 asks that logs are produced, stored, protected and analyzed. Airflow writes task and audit logs, but retention periods, tamper protection and review of alerts sit with the security operations owner and the SIEM. Decide where Airflow logs are shipped, who reviews failures and suspicious access, and how long records are kept. Do not assume the default local log location meets your retention requirement.
The certification decision
Whether to pursue certification, choose a certification body and accept its findings belongs to the organization's leadership. ISO does not certify organizations, and certification bodies assess the ISMS against ISO/IEC 27001:2022 under their own accreditation. DeployOpen prepares systems and evidence, but it does not issue audit reports or certificates. Ask the certification body early which evidence it will sample from Airflow.
Configuration sequence for change and logging controls
This sequence sets up the change procedure, reviewed DAG delivery, separated environments and logging so that each A.8.32 and A.8.15 control produces evidence an auditor can sample. Each step closes with a check that the output exists before the next step starts.
Define the change procedure and approvers
The information security or platform owner writes a short change procedure that covers DAG changes, Airflow upgrades, configuration changes and emergency changes. It names who may request, review, approve and deploy each change type, and which changes need a test run first. Done means the procedure is approved, version-controlled, and every named approver has confirmed their role in writing.
Set up version control and DAG review
The engineering lead places all DAG code, shared libraries and Airflow configuration in a Git repository with protected main branches. Every change goes through a pull request that a second person reviews and approves, and the author cannot approve their own change. Done means a test merge is blocked without an approval, and the approval, author and commit are visible in the repository history.
Create separated development, test and production environments
The platform team deploys separate Airflow environments with their own metadata databases, connections, secrets and access groups, so development and test workloads never touch production data sources. Promotion moves a tagged commit from one environment to the next after the review step. Done means each environment is documented, production credentials are not available in lower environments, and a promotion record names the commit deployed.
Deploy PostgreSQL or MySQL metadata databases
The database administrator provisions a PostgreSQL or MySQL metadata database for each environment, since the production guide warns that the default SQLite backend is for testing only. Airflow 3 runs the API server and the DAG processor as separate components, so the platform team deploys them as separate processes alongside the scheduler. Done means every component connects to the intended database, the version matches the supported list in the prerequisites, and a restart test shows run history persists.
Configure audit and task log shipping and retention
The operations team turns on task logging and ships task logs and Airflow audit events to a central log platform under the organization's retention schedule, with write access restricted to the logging service. Access to the stored logs is limited to named roles. Done means a sample failed task and a sample manual trigger both appear in the central store with timestamp, user and DAG identifiers, and the retention setting is recorded in the procedure.
Set access for triggering and clearing runs
The security team maps Airflow roles to the access model, so that only the operators named in the procedure can trigger, pause, clear or mark runs. Access changes go through the same approval path as DAG changes. Done means an access review export lists each role and member, and a test user without the operator role is refused when attempting to clear a run.
Run a test change through the procedure
The change owner makes a small, low-risk DAG change, opens a pull request, obtains the required review, promotes it through test to production and records the outcome. The run is logged end to end so that the request, approval, deployment and first run can be traced. Done means the change record links the pull request, the approver, the promoted commit and the first production run, and any gap found is logged as a procedure fix.
Collect a sample evidence pack
The compliance lead assembles a sample pack that an auditor could select from: the approved procedure, approver list, several pull requests with reviews, promotion records, the test change record, access review exports and matching log entries. The pack is stored with the control owner's name and date. Done means each control in the mapping points to at least one artifact that can be retrieved without help from the engineer who made the change.
Questions buyers ask before engaging help on Airflow ISO 27001 evidence
What drives the cost and effort of ISO 27001 evidence work for Airflow?
The biggest drivers are how many DAG repositories, environments and teams are in scope, how many log sources must feed the evidence trail, and how mature your existing change process is. A team with pull request reviews, separated development, test and production Airflow environments, and central log retention needs far less new work than one that changes DAGs directly in production. Costs fall into two groups: one-time work to map controls, configure review gates, separate environments and set up log export, and recurring work to keep the evidence current, such as periodic access reviews and upgrade records. DeployOpen plans and delivers work under a written, fixed scope, so ask for a quote that lists environments, repositories, log sources, deliverables and what the client team provides. DeployOpen does not publish prices.
How long does ISO 27001 change management and logging work take for Airflow?
Duration depends on the number of environments, the state of your DAG delivery process, and how many log sources need to be connected and retained. Work usually moves faster when DAGs already live in version control with review, because the main job becomes documenting the process and collecting evidence. It moves slower when Airflow itself must be separated into environments, when task logs need to be shipped to a central store, or when approvers and owners are not yet named. Ask for a timeline in the written scope that ties each phase to the environments and log sources it covers. No duration is given here because none has been supplied for this topic, so confirm it against your own environment during scoping.
What does the work need from our team?
Expect to name three roles before work starts. The ISMS owner decides which Airflow changes fall under the change procedure, which events must be logged, and how exceptions are handled. Platform administrators provide access to the Airflow deployment, the Git hosting system, the metadata database, the log destination and the identity provider. Approvers, usually data owners or engineering leads, must be available to review DAG changes and sign off on production promotion. Your team also needs to decide who can trigger, clear or pause runs, because auditors will ask who did what. Without these roles assigned, evidence gaps tend to appear late in the assessment.
Can our internal team implement ISO 27001 evidence for Airflow alone?
Yes, an internal team can do this if it has Airflow operations skills, someone who understands Annex A controls, and time to document the procedure. The control concepts are not especially technical, but applying them to DAG delivery, environment separation and log retention requires Airflow-specific knowledge. Internal teams often underestimate the work of proving a change was reviewed, tested and promoted in a way that can be sampled later. A useful test is whether you can pick a production run from last month and trace it back to an approved commit, a reviewer and a deployment record. If you cannot, the gap is the scope of any help you need. ISO/IEC 27002:2022 gives guidance on the Annex A controls and can support the internal design work.
Can DeployOpen get our organization ISO 27001 certified?
No. DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. ISO does not certify organizations either. Accredited certification bodies do that work, and they audit your management system against ISO/IEC 27001:2022 under their own accreditation rules. Ask any certification body you consider to confirm it is accredited and that it applies ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024. You can check accredited certificates through the IAF CertSearch database that ISO references. The certification body will decide which samples to test, so treat DeployOpen's work as readiness support for that decision.
Which Airflow version should we start on, given Airflow 2 reached end of life?
Start on Airflow 3. According to the Airflow version support table, Airflow 2 reached end of life on April 22, 2026, after which it receives no fixes, so an ISO 27001 evidence trail built on it would show an unsupported platform. The current Airflow 3 patch release is 3.3.2, and the Airflow 3.3.2 prerequisites list Python 3.10 to 3.14 and PostgreSQL 14 to 18. Airflow 3 requires moving from Airflow 2.7 or later, and the upgrade guide recommends moving to the latest 2.x first and checking DAG code with Ruff AIR301 and AIR302 rules. Confirm your current version and whether your DAGs need changes before you set the change management baseline.
What will an auditor sample when checking Airflow change management and logs?
Auditors usually select a set of changes and a set of events, then ask for the evidence behind each one. For DAG changes, expect requests for the approved change record, the commit that introduced it, the reviewer, the test results, and proof of promotion to production. For logs, expect a sample of audit and task log entries tied to a defined period and a specific event, such as a failed run, a manual trigger or a configuration change. Each sample must show that logs were produced, stored, protected from tampering and reviewed. Because the Airflow scheduler can run more than one instance using database row-level locks, confirm how scheduler and API server logs are collected from every instance. Confirm the exact sampling method with your certification body.
Where to confirm the standard and Airflow behavior
Confirm Airflow behavior against the documentation for your exact version before you write a control. The Airflow version life cycle page shows which release lines still receive fixes, and the prerequisites page lists the Python, database and Kubernetes versions each release supports. The production deployment guide covers the metadata database, logging and scheduler setup that your evidence will describe, and the auth manager page explains how access to trigger, clear and edit DAG runs is governed in Airflow 3. Record the Airflow version, database and auth manager in your control narrative, because a feature described for one release line may not exist or may behave differently on another. If you are still on Airflow 2, check the life cycle table first, since the support status of your version affects what you can claim about security fixes during the audit period.
Read the control wording from the official ISO sources, not from this page or a summary. A.8.32 Change management and A.8.15 Logging are defined in ISO/IEC 27001:2022, and the Annex A guidance that explains how to apply them is in ISO/IEC 27002:2022. Both are copyrighted and sold by ISO and IEC, so buy or access your own copies and quote only your internal reference to them. Use the NIST OLIR crosswalk between SP 800-53 Rev. 5 and ISO/IEC 27001:2022 as a secondary cross-check, not as a replacement for the standard. Ask your certification body which edition and wording it will assess against, since the 2022 edition replaced the 2013 controls under the transition rules.
How DeployOpen scopes and delivers Airflow compliance configuration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apache Airflow and ISO 27001 change management and logging, we start from the controls your organization has to evidence and build the DAG delivery, environment separation and logging setup around them.
How we scope
- Review which A.8.32 change management and A.8.15 logging obligations apply to your Airflow environments and information systems.
- Agree the written scope in advance, covering environments, DAG repositories, review workflow, log destinations and retention inputs.
- Confirm which Airflow version, executor and metadata database you will run, since these shape what evidence is available.
How we build
- Configure Git-based DAG delivery so every deployed change traces to a reviewed commit and an approver.
- Separate development, test and production Airflow environments with distinct credentials, connections and promotion steps.
- Set up audit log and task log collection, then test that sample events can be retrieved and tied to a named change.
How we hand over
- Document the change procedure, emergency change path and how each control maps to the relevant Annex A control.
- Provide a sampling guide that shows where an auditor can find approvals, deployment records, run history and log extracts.
- Walk your operations and compliance staff through the evidence locations and the steps to produce them on request.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial fixed scope.
- Review changes to Airflow versions and provider packages before they reach production, including their effect on logging.
- Confirm with your certification body which evidence it expects, since DeployOpen prepares evidence but does not issue audit reports or certifications.
