Open resource LC-R03
Deployment checklist
Thirteen areas, eight columns, one release record.
Make a release operable: for each area, the action, the owner, the evidence and the recovery path — before the release and after it.
Reach for it when A release is going out and the question "who would notice if this silently stopped working" has no answer yet.
The page is the resource. Everything is here to read, fill in or print, and nothing asks for an email address.
What this helps you decide
Make a release operable by naming the action, owner, evidence and recovery path. Adapt the checklist to the system's risks.
A small team still needs deliberate boundaries; a long checklist is not a substitute for effective controls.
Worked example
Illustrative Illustrative case, not a claimed customer incident.
A service deploys successfully, but the scheduled task that prepares the next period's output is absent. A homepage check passes while the product's main work is not happening.
A useful verification therefore checks both service health and expected job completion. It records when output was due, whether it appeared and who responds if it does not. Recovery must recognise completed work before retrying it.
Review before release
| Area | Check and evidence |
|---|---|
| Change | Identify the version, owner, purpose and dependencies. |
| Fast checks | Run relevant type, static and unit checks; record what they do not cover. |
| Environment | Verify configuration parity deliberately; separate secrets and production access. |
| Data | Review migrations, backup and recovery, and compatibility with the previous version. |
| Permissions | Test that routine development and review cannot modify production data. |
| Promotion | Record the approver, evidence and exact version being promoted. |
| Recovery | Explain rollback or forward recovery, including irreversible data changes. |
Review after release
| Area | Check and evidence |
|---|---|
| Service | Verify a meaningful task as well as a health endpoint. |
| Schedule | Verify jobs exist and expected work completes; detect missing success. |
| Observability | Check useful logs and alerts without exposing unnecessary personal data. |
| Response | Name who responds, how they are reached and what recovery they can perform. |
| Repetition | Test that retries and catch-up work do not duplicate completed actions. |
| Deferrals | Record omitted controls, their reason, owner and revisit trigger. |
Complete the release record
One row per area — the seven before the release and the six after it, in that order. Record status, owner, evidence, unresolved risk and follow-up for each. A check marked “not applicable” needs a reason.
Every row starts at “Not assessed”, which is the truthful starting state and the one worth leaving visible on the rows nobody got to.
Nothing here is scored. There is no grade, no percentage, no readiness level and no certificate — the columns exist so that a decision can be read and challenged by somebody else, not added up.
| area | status | owner | evidence | unresolved_risk | next_action | due_date | revisit_trigger |
|---|---|---|---|---|---|---|---|
| Change | Not assessed | ||||||
| Fast checks | Not assessed | ||||||
| Environment | Not assessed | ||||||
| Data | Not assessed | ||||||
| Permissions | Not assessed | ||||||
| Promotion | Not assessed | ||||||
| Recovery | Not assessed | ||||||
| Service | Not assessed | ||||||
| Schedule | Not assessed | ||||||
| Observability | Not assessed | ||||||
| Response | Not assessed | ||||||
| Repetition | Not assessed | ||||||
| Deferrals | Not assessed |
Do not mark a release complete solely because the deployment command succeeded.
The file is the table above, with the same column names. There is no PDF to download — printing this page, or saving it as a PDF from the print dialogue, gives you the whole of it as a form.
Limits and next step
This checklist does not prescribe your deployment stack or certify a secure system. Review it against your architecture and obligations.
Next step
Which missing control presents the most consequential failure for your next release?