How Airflow supports SOC 2 CC8.1 change management evidence
Apache Airflow helps produce change evidence for DAG code, but it does not make a change controlled by itself. A SOC 2 auditor testing CC8.1 will look for an authorized, designed, tested, approved and implemented change, and most of those steps happen in your version control, review and release process, not inside the scheduler. CC8.1 covers every stage of a change to infrastructure, data, software or procedures, from authorization through implementation, and the common criteria in the AICPA's 2017 Trust Services Criteria apply to every SOC 2 examination. DeployOpen prepares systems, controls and evidence for that examination, but independent auditors issue any opinion, so the goal is evidence an auditor can sample and trace, not a claim that the platform passes.
The platform contributes most where traceability matters. Each DAG change that is deployed from a version-controlled bundle can be tied to a commit, and the run history can show which code version executed a given run, which supports the criterion's focus on tracking system changes. Airflow's own configuration, such as the auth_manager setting and role assignments, should itself be placed under change control, so that changes to who can trigger, clear or edit runs are as visible as changes to pipeline code. Staging and production environments should be separated with distinct connections, variables and secrets so that a test change cannot quietly reach production data. Confirm with your own environment how your bundle and deployment tooling records commit identifiers, since that record is what the auditor will request.
Several parts of CC8.1 sit with people and process, and the platform does not replace them. Someone must authorize each change, the pull request must be reviewed by a person other than its author, and testing results must be retained with the change ticket. The emergency change path, where a fix is applied before review, needs a written procedure, a named approver and a follow-up review after the fact. Patch changes to Airflow itself, including moves between supported lines such as the current 3.x patch series, need the same documented approval and testing. Ask your auditor early which samples they will pull, and make sure the ticket, the commit, the review and the run record can be connected for each sample.
Mapping CC8.1 points of focus to Airflow capabilities and configuration
This table maps each CC8.1 change management element to the Airflow 3 capability that supports it and the configuration an assessor will expect to see. Read each row as a question: what does the auditor ask, which part of Airflow answers it, and what must your team configure and record. Items marked as needing confirmation depend on your deployment choices and should be verified against the version you run.
| CC8.1 element | Airflow capability | Configuration and evidence to prepare |
|---|---|---|
| Authorization | DAG code reviewed and merged through your own version control before deployment | Require approval from someone other than the author on protected branches; retain approval records as the authorization evidence for each DAG change |
| Design and development | DAG files are Python code, so design choices live in the repository alongside the change | Document DAG purpose, owners and dependencies in the repository; use Ruff AIR301 and AIR302 checks, as the Airflow 3 upgrade guide recommends, as a gate in review |
| Testing | Airflow 3 task code uses the REST API or Task SDK instead of direct database sessions, which keeps tasks testable outside the metadata database | Run DAG import and unit tests in CI before merge; keep test results linked to the pull request |
| Configuration baseline | Airflow 3 separates the API server and the DAG processor into their own components, so each has a defined configuration | Store deployment configuration as code and record the Airflow version, Python version and database version in the baseline; confirm the supported combinations in the prerequisites |
| Tracking changes | Versioned DAG bundles record the commit used for each run, so a run can be tied to the code that produced it | Confirm how your installed version exposes the bundle version on each run; keep run history and audit logs as the trace from change to execution |
| Staging and implementation | Separate environments with the same code promoted through the pipeline | Show that the production release is the same commit tested in staging; record promotion approvals and deployment timestamps |
| Emergency changes | Pipeline changes can be deployed outside the normal cycle, so the process must be defined before an incident | Write an emergency path with after-the-fact review of the commit, named approver and reason; record each use in the change log |
| Patch and upgrade changes | Airflow 2 reached end of life on April 22, 2026, and gets no fixes; Airflow 3 is the supported line | Track the version life cycle, schedule upgrades through the Airflow 3 upgrade guide, and keep upgrade tickets with test results and rollback notes |
| Access to change controls | Auth manager set by the auth_manager option; Simple auth manager is the default and only one manager runs at a time | Confirm which auth manager you use and document who can trigger, clear or deploy runs; keep role assignments in your access review evidence |
Which change records auditors can sample from Airflow
Auditors testing CC8.1 will ask you to show a change, then trace it back to an approval, a test and a deployed version. The cards below cover the records that usually sit in Git, in Airflow's run history and logs, and in your ticketing system, along with how to keep each one and what to confirm for your version.
Pull request review history
For each DAG change, auditors will look for a pull request that shows who wrote the change, who approved it, and when approval happened relative to merge. Keep the review history in your Git platform, not in chat threads, and confirm your branch protection settings require approval before merge. Ask whether approvals are retained when a branch is force-pushed or a pull request is reopened, because that determines what you can show for a sampled change.
Commit recorded per run
The strongest link between code and execution is the commit or bundle version that a given DAG run used. Confirm how your deployment records the DAG version for each run in your Airflow version and DAG delivery method, and test it by triggering a run after a known merge. Retain the mapping from run identifier to commit alongside the run history so an auditor can trace a sampled run to reviewed code.
API server and DAG processor logs
The API server and DAG processor record activity that helps reconstruct when a DAG was parsed, paused, triggered or changed in the metadata database. Ship these logs to a central store with a retention period set by your policy, and confirm which events are written at your configured log level. Do not assume a given action appears in these logs until you have tested it in your own environment.
Promotion records between environments
Auditors will ask how a change moved from development to staging to production and who authorized each step. Records can come from pipeline logs, deployment tags or merge records, and each should name the commit promoted and the approver. Define which record is the system of record before the audit period starts, since switching sources mid-period makes sampling harder to explain.
Emergency change tickets
When a DAG is changed outside the normal review path, auditors expect a ticket that records the reason, the approver, the change made and the follow-up review. Link the ticket to the commit or deployment it authorized, and check that the post-change review happens within the window your change policy sets. Test this path at least once so the ticket, commit and run history can be shown together.
Change policy and access records
Auditors often ask who could merge to production and who could deploy, which requires exporting repository permissions and deployment roles at the time of the sample. Keep dated snapshots of these roles and the change policy they support, since point-in-time evidence is easier to defend than reconstructed lists. Confirm with your identity team how Airflow roles are mapped to your identity provider for your chosen auth manager.
Configuring the change path before the first audit period
This sequence sets up the version, code, environments, run records, emergency route and evidence retention that an auditor will sample for CC8.1. Each step closes with a artifact or check the team can show before the audit period begins.
Fix the Airflow version and support status
The platform team records the Airflow version in use, its patch level and its support status from the Airflow version life cycle page. Airflow 3 is the current major line, and Airflow 2 reached end of life on April 22, 2026, after which it gets no fixes. Confirm the upgrade path from your current version with the Airflow 3 upgrade guide, which requires Airflow 2.7 or later before upgrading. Done when the version, support window and any planned upgrade are written into the system description and change log.
Move DAG code into Git with protected branches
The DAG author team stores all DAG source, configuration and supporting code in a version control repository, with the main branch protected from direct pushes. Required reviewers approve each merge request, and the reviewer must not be the author. Confirm in your own environment that the repository platform enforces these rules and records who approved each change. Done when a test change without approval cannot reach the main branch, and the blocked attempt is visible in the repository history.
Set up separate dev, staging and production deployments
The platform team builds three Airflow environments with separate metadata databases, connections and secrets, so a change is tested before it touches production data. Promotion moves the same reviewed commit from development to staging to production rather than rebuilding code in each place. Confirm that production credentials are not available to development workers. Done when a documented promotion record shows which commit reached each environment and when.
Version DAG bundles so each run records its commit
The platform team configures DAG delivery so every deployed bundle is tied to a specific commit identifier, and the run history can show which commit produced each run. Check the Airflow production deployment and DAG delivery documentation for the bundle option that fits your delivery method, and confirm it in your own environment. Done when a sample run can be traced from the run record to the commit, the reviewed merge request and the approver.
Define the emergency change route with after-the-fact review
The change owner writes a short emergency procedure that lets an authorized person deploy a fix outside the normal approval path when an outage requires it. The procedure requires the change to be logged with a reason, the approver's identity and the commit, and a review by the change board after the fix. Confirm who may invoke the route and how access is granted and removed. Done when a rehearsal produces a ticket, a commit and a completed after-the-fact review.
Start retaining logs and tickets from day one
The operations team sets retention for Airflow audit logs, task logs, repository history, deployment records and change tickets, and confirms that they are exported or stored outside the systems that produce them. Retention periods should follow your own policy and the auditor's sampling period, so confirm them with your compliance lead. Done when a sample change can be followed from ticket to approval to deployment to run log, and the evidence is still available after the environment is rebuilt.
How a DAG change moves from request to production
A DAG change is authorized, tested and traceable only if every step leaves a record that someone other than the author can retrieve. In a self-hosted Airflow, the request starts as a branch and a pull request in the repository that holds the DAG files, and the pull request approval is the first evidence point an auditor samples. Record who requested the change, who approved it, and whether the approver is independent of the author. Your change policy should state which DAG paths need a code owner review and whether any change to shared libraries or connection-handling code needs a second approver. Confirm that branch protection in your Git platform blocks merges without the required approval, because a reviewer who can be bypassed produces no reliable evidence.
Before merge, automated checks should run against the proposed code. For Airflow 3, the upgrade guide recommends checking DAG code with the Ruff AIR301 and AIR302 rules, which flag patterns that Airflow 3 removed or changed. Treat these as a gate in the same pipeline that runs your DAG tests, and keep the pipeline's pass or fail output attached to the pull request. Staging then runs the merged commit. The staging run record, with its run ID and the commit it executed, shows the change was exercised before production. Approval for promotion should be a separate, named sign-off, not the same click as the merge, so the auditor can see distinct authorizations.
Production deployment should use the same commit that passed staging, and each run should carry that commit reference so a sampled production run can be traced back to its approved change. Confirm with your platform team how your DAG bundle versioning records the commit per run in your chosen Airflow 3 deployment, and test that the record survives a scheduler restart. Emergency changes need their own path: an expedited approval, a post-deployment review within a window you define in policy, and a link from the emergency change record to the commit that was applied. Auditors often test the emergency path separately, so decide before the audit period starts how it is documented.
What buyers ask about SOC 2 change evidence for Airflow
What does a SOC 2 Type 1 versus Type 2 report change for change management evidence?
A Type 1 report describes the system and whether control design was suitable as of a single date, so the auditor mainly examines whether the change process was designed correctly at that point. A Type 2 report adds an opinion on operating effectiveness over a period, so the auditor samples changes across that whole window and expects each sampled change to show authorization, review, testing and approval. For Airflow, that means every sampled DAG change should link to a reviewed pull request, a recorded approval, a staging run where applicable, and a deployed version that matches the approved commit. The Type 2 period is set with your auditor, and the sample is their decision. Ask them which evidence they will request before the period starts, since the Trust Services Criteria point of focus on tracking system changes shapes what they sample.
Does running Airflow by itself satisfy CC8.1?
No. CC8.1 concerns the change process as a whole, covering authorization, design, development, configuration, documentation, testing, approval and implementation, so Airflow can only support that process. Airflow records what ran and which code version each run used when you deliver DAGs in a versioned way, but it does not decide who may change a pipeline, enforce review, or document an emergency change. Those controls come from your Git hosting settings, CI checks, promotion steps and written procedures. Your policies must describe how changes are authorized and how emergencies are handled, and the evidence must show the controls were followed. DeployOpen can help design and configure the platform side of these controls, but the policy and control ownership stay with your organization.
What drives the effort to build change evidence for Airflow?
The main drivers are the number of DAGs and teams committing to them, how many environments you run and how promotion between them works, and how mature your Git and CI setup already is. Teams with branch protection, required reviewers, automated tests and tagged releases need less new work than teams that edit DAGs directly on a shared server. The Airflow version and upgrade status also matter, because Airflow 2 reached end of life on April 22, 2026 and the Airflow 3 upgrade guide asks you to check DAG code with Ruff AIR301 and AIR302 rules before moving. Delivery method is another factor: container images, Git-synced bundles or a Helm chart each produce different evidence trails. Ask any provider to break their quote down along these drivers.
Can our own team build this without outside help?
Often yes, if you have engineers who know Git administration, CI pipelines and Airflow deployment, and someone who understands SOC 2 evidence expectations. The work is mostly configuration and documentation rather than new software, so the question is capacity and experience rather than tooling. Teams that struggle usually lack a clear owner for the change procedure, or they find that the auditor wants evidence they did not plan to collect, such as proof of approval for emergency changes. A partner is useful when you need a fixed scope, a written deliverable list and someone to rehearse the evidence pull before the auditor arrives. Compare the cost of your team's time against a written scope, and check whether the people who would do the work are also needed for production operations during the audit period.
How long does this work take, and who sets the timeline?
The duration depends on the scope agreed in writing, including how many DAG repositories, environments and teams are involved, and how much Git and CI work is needed before the Airflow side can be connected. No duration is stated here because it has to come from that scope. Most engagements are fixed-scope, so the scope document sets the deliverables and the timeline before work starts. Plan separately for the audit period itself, which your auditor defines, and remember that evidence must exist for the whole sampled window. Changes made before the controls are in place will not carry the same evidence, so a timeline that starts the controls early gives you more history to show.
What do we need to provide for this work?
You will need named process owners for change management and for Airflow, a Git administrator who can change repository settings and approval rules, and an auditor liaison who knows what evidence your SOC 2 engagement requires. Engineers who write and review DAGs must be available to test the new workflow, and whoever runs production operations should confirm how deployments and emergency changes happen today. You should also share existing change policies, access lists and any tickets or logs that already record changes. Access to the Airflow environments, the CI system and the logging platform is needed to verify the evidence trail. Confirm these responsibilities in the written scope so that gaps are visible before work starts.
Does DeployOpen issue a SOC 2 report for our Airflow environment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. A SOC 2 report is issued by an independent CPA firm after examining your system and controls, and management provides written representations as part of that engagement. Your auditor decides the scope of the examination, the Type 1 or Type 2 period and the samples they test. DeployOpen's role is to help your team design the controls, set up the Airflow and Git configuration, and organize the evidence so the auditor can test it. Ask your auditor to confirm the evidence they expect before implementation begins.
Keeping change evidence ready for the audit period
An auditor tests whether a change control operated across the whole examination period, so the evidence has to exist for every change, not just the ones you chose to show. For a Type 2 report, that means the Git history of the DAG repository, the approval record in your review tool, the ticket that authorized the change, the deployment record for the bundle, and the run history that shows which code ran. Decide where each of these lives, who can delete or rewrite them, and how long they are kept before the period starts. Confirm the retention rules of your Git host, your ticketing system and your Airflow log storage, because a default that expires logs after a set number of days can silently remove evidence from the middle of an examination period.
Matching a change to a ticket and an approval is the step most often left to memory. Require every merge to reference a ticket identifier in the commit message or pull request title, and have your pipeline reject merges without one. Then sample a few production runs and trace each one back: the run's recorded bundle version, the commit it points to, the merged pull request, the reviewer who approved it, and the ticket that authorized it. Emergency changes need the same chain, with the approval recorded after the fact and linked to the incident. Run this trace as a test before the auditor does, so gaps surface while they can still be fixed.
The representations your management provides in the management representation letter are statements that controls were operating, not only that they were designed. The AICPA's illustrative letter for a SOC 2 Type 2 engagement sets out the kind of statements management signs, and an examination under AT-C section 205 depends on those statements being backed by evidence. Treat the letter as a list of claims you must be able to prove for each day of the period. Also decide with your auditor which report you need: a SOC 3 is a general use report that can be freely distributed, while a SOC 2 report is generally restricted to specified parties, so the distribution plan for your change control evidence should follow from that choice.
How DeployOpen scopes and delivers compliance-ready Airflow change control
DeployOpen plans, implements, documents and hands over Airflow change control in infrastructure you control, so the evidence for CC8.1 is produced by the pipeline process itself. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. DeployOpen prepares controls and evidence for your assessment, but independent auditors issue the SOC 2 report.
How we scope
- Written scope lists the repositories, DAG bundles and Airflow environments that fall inside the change control design.
- Scope maps each change stage to CC8.1 points of focus, including authorization, testing, approval and emergency handling.
- Scope names who approves production promotion, who may run emergency changes and which systems hold the change record.
How we build
- Pull request review rules, branch protection and required approvers are configured in your Git platform for DAG code.
- Versioned DAG bundles are set up so each run records the commit it executed, linking every run to an approved change.
- Staging promotion and a documented emergency change path are built and tested against sample changes before go-live.
How we hand over
- Written procedures describe the change lifecycle, roles, approval steps and how emergency changes are reviewed afterward.
- An evidence guide shows which records to retain, where they live and how an auditor can sample them from run history.
- Handover includes a walkthrough with your change board and a test of retrieving a complete change trail for a sample run.
How we support
- Ongoing support, upgrades and testing are available as a retainer, covering Airflow version changes that affect change records.
- Retained support can review periodic change samples so gaps are found before your auditor's fieldwork begins.
- Confirm with your auditor and your change board which evidence formats and retention periods they expect before the design is finalized.
