ATO Overview

ATO is the Engineering operating model for shipping safely. GitOps is not a separate practice beside it; GitOps is the delivery and evidence mechanism inside ATO.

That means delivery, access, environment promotion, scanning, monitoring, release evidence, and recovery are documented together. A developer should not have to choose between reading an “ATO” path and a “GitOps” path to understand how a change reaches production.

ATO does not mean “stop shipping until an auditor approves every line.” It means normal engineering work should leave behind enough proof that the team can show what changed, who approved it, which controls ran, and how the system recovered when something went wrong.

Operating model

Principle	What it means in practice
Git is the source of truth	If it is not declared in Git, it should not be running
Review creates authorization	PR approval, CODEOWNERS, branch rules, and environment approval are the change-control record
Environments are promotion targets	Lower and upper tiers are separated by account, runner group, IAM role, and approval boundary
Evidence is produced by the work	Workflow runs, scan results, ArgoCD syncs, release records, and restore tests are retained as evidence
Recovery is a controlled change	Fix forward, revert, re-pin, or restore through the documented path instead of editing live systems by hand

What to notice: ATO is the umbrella; GitOps is how the umbrella becomes enforceable and auditable.

Read this section in order

If this is your first time through the section, read the pages in this order:

1. Delivery — learn the normal path from branch to production.
2. Authorization — learn who can approve, promote, and bypass.
3. Environments — learn why environments are separated and how promotion works.
4. Compliance — learn how scans, dependency updates, and evidence fit into the same PR flow.
5. Disaster Recovery — learn how recovery stays controlled when something breaks.

Then use Authentication, Secrets, Networking, and Monitoring as the deeper technical references when a change touches identity, credentials, traffic, logs, alerts, or drift.

Delivery path

flowchart LR
  subgraph HumanWork["Human work"]
    Branch["Short-lived branch"] -->|opens| PR["PR + review"]
    PR -->|on approval| Merge["Squash merge to main"]
  end
  subgraph CIAutomation["Automation"]
    Merge -->|triggers| Build["Build and test"]
  end
  subgraph EnvPromotion["Environment promotion"]
    Build -->|if green| Staging["Staging approval"]
    Staging -->|if approved| Prod["Production approval"]
    Prod -->|on sync| Evidence["Release and ATO evidence"]
  end
  style Evidence fill:#dcfce7,stroke:#16a34a,color:#14532d

Every box creates or preserves evidence: the PR records intent and approval, checks record verification, the build records the artifact digest, environment approvals record separation of duties, ArgoCD records sync state, and monitoring records the outcome.

Everyday examples

If you are doing this	Start here	Evidence you should expect
Opening a feature PR	Delivery	PR description, checks, reviewer approval
Reviewing a vendor PR	Authorization	Engineering approval and resolved review notes
Promoting to production	Delivery and Environments	Workflow run, approver, image digest, ArgoCD sync
Updating dependencies	Compliance	Renovate PR, checks, scan result, release record
Adding a secret reference	Secrets	1Password record, External Secret reference, no plaintext in Git
Debugging a staging-only issue	Environments	Values diff, sync state, logs, monitoring signal
Responding to an incident	Disaster Recovery	Incident timeline, recovery PR, sync record, RCA follow-up

What to notice: every normal engineering action has a matching evidence trail. ATO works best when that trail is automatic.

Pages

Page	Developer job it answers
Authorization	Who can approve, promote, bypass, and review access
Delivery	How branches, PRs, reviews, releases, feature flags, and deployments work
Environments	How lower and upper tiers stay separated while sharing the same delivery model
Authentication	How people and workloads prove identity
Secrets	How Git references secret material without storing it
Networking	How traffic crosses inspected, encrypted boundaries
Monitoring	How logs, alerts, drift, and findings route back into Git
Compliance	How scans, SARIF, SBOMs, policy-as-code, and ConMon evidence are produced
Disaster Recovery	How to recover systems and data without losing auditability

What to notice: pages are organized by the job a developer is trying to do, not by whether the source material used to be called security or GitOps.

Why this is easier to use

The old split forced a reader to decide whether a deployment question belonged in ATO, security, or GitOps. The merged model gives each fact one home: delivery rules live with delivery, access rules live with authorization, scanner behavior lives with compliance, and recovery rules live with disaster recovery.

That improves developer experience in three concrete ways. First, review and release guidance is next to the evidence it creates. Second, links now point to one canonical ATO path instead of two competing sections. Third, audits and incident reviews can follow the same trail developers use every day: PR, workflow, approval, sync, scan, release, monitoring, and recovery record.