This CI/CD pipeline checklist sets out 12 checks that either pass or fail. Each one names the rule it must meet and the evidence to collect. Award a point per pass. Then the total tells you whether the pipeline is ready to ship. A check with no evidence on the day scores zero, and that gap becomes your first fix.
Last reviewed 2026-11-05 by Manish Sharma.
CI/CD in a pipeline means every change is built, tested and released by machine. This page scores a pipeline you already run, as part of accelerating your software releases. Fixes for failed checks sit in the eight-step build guide. If the review shows the current tool no longer suits your team, a shortlist guide for CI/CD tools can help you decide what to move to.
How the CI/CD Pipeline Checklist Scores
One rule decides every check: evidence or no point.
A point is given only when you can produce the item in the Evidence column on request. However, believing it is true earns nothing, and neither does a partial pass.
The engineering lead runs the review with the release owner and the daily operator, because they hold the proof.
Paste the tables into a spreadsheet and add date, reviewer and score columns. Then you have a ci cd pipeline checklist template with no download needed.
The numbers here are our own suggestions: 12 checks, 12 points, a sample of the last 10 releases, a 90-day rotation window and a quarterly rehearsal. Change any of them, because none is a benchmark or a study result.
It is no certification or external audit.
The Full CI/CD Pipeline Checklist: 12 Checks, Pass Rules and Evidence
The four tables below hold all 12 checks. Figure 1 shows the four groups.
Merge Gate Checks in the CI/CD Pipeline Checklist: C1 to C3
| No. | Check | Pass rule | Evidence | Fix in the guide |
|---|---|---|---|---|
| C1 | Main branch is protected | Direct pushes are blocked, and a change merges only when it has a named reviewer and passing checks. | A screenshot of the branch rule, and the last 10 merges each showing a review and a green run. | Step 1 |
| C2 | Every change is built from a clean copy | The run starts from a fresh copy on a clean machine with pinned dependency versions, and when the run fails, a message goes to the author. | The build log of the last run, and the committed file that pins versions. | Step 2 |
| C3 | Tests gate the merge | A failing test stops the run and nobody can skip it. The fast tests run before merge. | A deliberately broken change that was stopped, and the setting showing no bypass for admins. | Step 3 |
Artifact, Secret and Access Checks: C4 to C6
| No. | Check | Pass rule | Evidence | Fix in the guide |
|---|---|---|---|---|
| C4 | Build once, promote the same artifact | One stored, versioned artifact goes to every stage while no stage rebuilds it. | The artifact identifier shown in staging and in production for one release. | Step 4 |
| C5 | Secrets are kept out of code and logs | A scan of the repository and the last 10 logs finds no secret. Secrets are injected when the pipeline runs, and a named owner holds a dated rotation record inside the window you set (our suggestion: 90 days). | The scan output, the owner’s name and the rotation record. | Step 5 (one line) |
| C6 | Pipeline files and deploy access are reviewed | The pipeline definition lives in the repository, a change to it needs a review before merge, and each deploy account holds only the access its stage needs. | The history of the pipeline file, and the list of deploy accounts with their access. | Step 1 for pipeline files; deploy access is not covered by the guide |
Release Path Checks in the CI/CD Pipeline Checklist: C7 to C9
| No. | Check | Pass rule | Evidence | Fix in the guide |
|---|---|---|---|---|
| C7 | Staging runs on the stored artifact | The artifact from C4 is deployed to staging, and acceptance tests pass before the next stage opens. | The staging run record for the last release. | Step 5 |
| C8 | Approval before production has a named owner | A named role and a named backup approve. Before approving, the approver sees the change list, the test result and the rollback status, and the approval is recorded. | The approver roles, and the approval record for the last 10 releases. | Step 6 |
| C9 | A smoke test runs after each production deploy | A short test runs straight after deploy, and if it fails, the rollback starts. | The smoke-test result for the last release, and the trigger setting. | Step 7 |
Rollback, Record and Owner Checks: C10 to C12
| No. | Check | Pass rule | Evidence | Fix in the guide |
|---|---|---|---|---|
| C10 | The rollback has been tested | The rollback puts the previous artifact back, was rehearsed in staging inside the window you set (our suggestion: the last quarter), and the elapsed time was recorded. | The rehearsal date, the person who ran it and the time taken. | Step 8 |
| C11 | Every release leaves a record | The record holds what shipped, when, who approved and which build. When you pick a running version, it traces back to one commit. | A running version traced to its commit and approval in under 10 minutes (our suggestion). | Steps 4 and 6 |
| C12 | The pipeline has a named owner | One named person owns the pipeline and its upkeep, and reviews this checklist each quarter. | The owner’s name and the date of the last review. | Step 6 and the overview table |
Gates Before Merge: What to Ask For
Ask for the branch rule, the no-bypass setting and one broken change that the pipeline stopped.
Take the last 10 merges, each showing a review and a green run.
For C3, ask the team to push a change that fails a test, then watch the run stop. A pass counts only if no one, admins included, can skip the gate.
Key Takeaway If an admin can skip a gate, C3 fails.
A gate stops a fault early, which is part of why manual releases hurt. Also, Steps 1 to 3 of the guide build all three.
One Artifact, Kept Secrets and Reviewed Pipeline Files: What to Ask For
Ask for one artifact identifier seen in two stages, a scan result and a list of deploy accounts. Together, these three checks answer how to keep a pipeline secure.
Key Takeaway When one identifier shows in two stages, the artifact was built once.
Ask for one release and read the identifier in staging and in production. If the two differ, something was rebuilt and C4 fails.
C5 has three parts: a scan, an owner and a rotation record. A secret found in a log counts as a fail, even if the repository is clean. Also, secrets injected when the pipeline runs are the pass rule.
For C6, read the history of the pipeline file and the list of deploy accounts. A deploy account that reaches beyond its own stage fails. Step 4 of the guide covers the artifact, while Step 5 has the secrets line.
Staging, Approval and Smoke Test: What to Ask For
This group asks for the run record, the approver names and the smoke-test result.
For C8, an approval with no named owner scores zero. “The team approves” is not a name. The approver should see the change list, test result and rollback status first, so approval is a decision, not a click. Handing the change to another team that re-tests it is not an approval either.
A low-risk class of change may skip approval if the firm agrees that in writing.
For C7, staging is one stage of your release path.
For C9, also ask for the result of the smoke test on the last release and the setting that ties a failure to the rollback.
Rollback, Record and Owner: What to Ask For
Ask for the rehearsal date and the time taken, then trace one running version back to its commit. A rollback that was written but not rehearsed scores zero.
Key Takeaway Until someone has run the rollback in staging, C10 fails.
For C10, the person who ran the rehearsal should say what they did and how long it took. That time is comparable to DORA’s recovery measure, which counts how long recovery takes after a failed deployment.
For C11, pick one running version and follow it to a commit and an approval. The record holds what shipped, when, who approved and which build. If the trace takes longer than 10 minutes, our suggested line, the record fails.
C12 closes the loop. A pipeline with no owner decays: rules drift, secrets age and nobody reviews this list. Steps 4, 6 and 8 of the guide cover all three checks.
What Your Score Means: Ready to Ship or Not
Total the points and find your band in Figure 2. Bands and gate rule are our wording; adjust them to fit.
| Score | Band | First action |
|---|---|---|
| 11 to 12 | Ready to ship | Hold on to the evidence and review again next quarter. |
| 8 to 10 | Ship with named fixes | Fix the failed checks, then review again in 30 days. |
| 5 to 7 | Not ready | Fix the gate checks first (C3, then C10, then C8), then C4 and C5. |
| 0 to 4 | Unmanaged | Stop adding stages and name who owns the pipeline (C12) before anything else. |
The gate rule sits over the total. If C3, C8 or C10 fails, the pipeline is not ready to ship, whatever the score, because those three decide whether a bad change reaches users and whether it can be taken back.
This invented illustration is not data. A pipeline passes 9 checks and fails C10. The total says “ship with named fixes”, but the gate rule overrides it to “not ready”, and the first task is to rehearse the rollback.
Run the review yourself or bring in an outside reviewer. In a ci/cd pipeline audit checklist, the evidence column is what an auditor would ask to see. Also, no named standard or law is claimed here. Then, for each failed check, use the step in the eight-step build guide.
CI/CD Pipeline Checklist FAQ: Questions on Scoring
When should you review your CI/CD pipeline checklist again?
Who should score the pipeline?
Does a small team need every check in this CI/CD pipeline checklist?
How is a check scored when its evidence is missing?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.