Audits rarely fail teams. Undocumented habits do. When a small newsroom or local digital business finally examines how its software actually reaches the public, the findings are predictable: releases depend on one person’s laptop, rollbacks exist only in theory, and nobody has written down what happens when a deploy goes wrong at midnight. A structured DevOps audit makes those habits visible before an outage does it for you. This checklist is built from the delivery research that has shaped the field over the past decade, and it is deliberately answerable in an afternoon — no consultants, no tooling purchases, just honest answers written down where the whole team can see them.
DevOps Audit, Section One: Delivery Health
Start with evidence, not opinion. The DORA research programme defines five delivery metrics, and a credible audit measures all of them rather than the two that flatter the team.
- Can the team state its current lead time from “change agreed” to “change live” without guessing?
- How often does the team deploy in an ordinary week — and is that frequency a policy or an accident?
- What is the recorded time-to-restore after the last three service disruptions?
- What fraction of changes cause a failure that users noticed?
- How much delivered work is being redone — the rework rate added to the research in 2024?
If any of these five questions produces a shrug, that is the first finding. You cannot improve a number nobody tracks, and you cannot fake your way past all five at once. The good news is that measuring them is easier than most teams fear: a shared spreadsheet updated weekly is enough to start, and the act of writing the numbers down changes behaviour before any improvement project begins. A note on honesty while collecting them: count from the moment work started, not the moment it was approved. Approval queues are delivery time in disguise, and teams that exclude them consistently report lead times half as long as their users actually experience. The audit’s purpose is a true picture, and a flattering one fails that purpose.
Section Two: Rollback Readiness
The difference between an incident and a catastrophe is usually preparation. Audit it directly.
- Does each deployment arrive tagged with an identifier plus a named owner, recorded somewhere a stranger could find?
- Has a rollback been physically rehearsed this quarter, with a stopwatch?
- Is there a decision rule for when to roll back, when to toggle a feature off instead, and when to fix forward?
- Are irreversible database migrations flagged before release, so a rollback never destroys data?
The published evidence here is sobering. In one documented case, an unrehearsed rollback of a payment-error spike consumed more than three hours; the same operation, once practised, took about twenty minutes. The gap between those figures is your audit score. Note the decision rule question particularly: teams without one burn their worst hours debating options that should have been settled in daylight.
Section Three: Access and Change Controls
Controls matter more, not less, in small teams, because small teams have no slack to absorb a compromise. Modern DevOps treats governance as automation rather than paperwork.
- Are permissions granted on a least-privilege basis, reviewed when people change roles?
- Do deployments use short-lived credentials issued through OIDC instead of long-lived keys pasted into configuration files?
- Are risky schema changes built as expand-and-contract migrations — add the new shape, then remove the old one only once the new code is completely live?
- Is there a quarterly sampling routine that pulls roughly ten random changes and traces each from request to production?
- Do “break-glass” merges produce a signal — an alert, a log, a ticket — rather than silence?
That last cluster of checks is what lets regulated and semi-regulated organisations adopt fast delivery with a clear conscience. Automated evidence replaces the signing queue, and the audit trail becomes a byproduct of shipping rather than a separate project. The tracing exercise deserves emphasis: follow a change from the original request through review, test and release, and write down every place the trail goes cold. Cold trails are where compliance findings come from.
DevOps Audit, Section Four: Culture and Habits
Process audits miss the half of delivery that lives in behaviour. Ask these with genuine curiosity.
- After an incident, does the review assign causes to systems or blame to people?
- Is the post-incident review completed within five working days, while memory is still reliable?
- Are approvals proportionate, or has the approval list grown after every incident?
- Do builders and operators share one dashboard and one on-call rota, or two separate worlds?
Research on organisational culture — the Westrum typology among it — keeps finding the same thing: teams that treat information as something to share outperform teams that treat it as something to hoard. Where a team sits on the maturity ladder — siloed at the foot, then islands of automation, then integrated working, then a genuine learning system — usually shows up here before it shows up anywhere else. The approval question deserves special attention, because the instinct after an outage is always to add a signature, and the research finding runs the other way: heavier change boards track with poorer delivery performance, not with better.
Scoring the Audit Without Fooling Yourself
Mark each check green, amber or red, then resist the urge to fix everything at once. Big-bang programmes score poorly against focused pilots in the adoption data — one comparison rated a coached pilot 4.25 out of 5 and a mandate imposed from the top just 2.50. Ninety days is enough for a first pass: stabilise what you measured, automate one painful path, then spread what worked. For tooling context across source control, automation and monitoring, this overview of essential DevOps tools is a practical companion piece, and the infrastructure side is covered in these infrastructure-as-code fundamentals. When you reach the monitoring questions, observability architectures for hybrid cloud will fill in the gaps.
Two closing habits keep the audit honest. First, date every answer and name the person who gave it; undated checklists rot into decoration within a quarter. Second, re-audit on a calendar, not on a mood — the teams that improve are the ones that look again when nothing has gone wrong lately, which is precisely when looking feels unnecessary. And share the scores with the whole team, including the reds; a scoreboard nobody is allowed to see is just a diary.
For the underlying research, definitions and history in one place, the Ops Atlas reference guide to DevOps is the most complete single source this checklist draws on. Audit once a quarter, act between audits, and the reds will migrate upward on their own.
