A release readiness check brings together the evidence and decisions needed before a proposed change is made available to its intended users. It should show what is ready, what remains unresolved and who is authorised to decide whether to proceed.
This guide is a coordination exercise. It does not authorise deployment, prescribe a complete technical release process or establish that passing a checklist makes software safe or defect-free.
Define the proposed release
Identify the version, scope, intended audience and actual release process. Check which requirements, tests, approvals and operational arrangements apply.
The GOV.UK Service Manual’s pre-production guidance discusses testing before live use. Its live-phase guidance provides broader context for moving a service into operation. Use the actual organisation’s governance and technical requirements.
Separate evidence gathering from the go or no-go decision. The person maintaining the readiness record may not have authority to accept an unresolved risk or approve release.
Use a readiness record
Review:
- Scope: agreed version and changes included.
- Requirements: relevant acceptance evidence and unresolved conditions.
- Testing: completed checks, blocked cases and outstanding defects.
- Specialist review: required security, accessibility or other competent input.
- Operations: support ownership, approved documentation and monitoring arrangements.
- Change control: required implementation and recovery planning through authorised roles.
- Communication: affected users and staff needing accurate information.
- Decision: authorised reviewer, conditions and recorded outcome.
Reference supporting records rather than copying sensitive details into a broad summary. A green status should have an explainable evidence basis.
A fictional readiness gap
In this invented internal-form project, the agreed acceptance cases are complete, but the support team has not received the current instructions. The coordinator records the operational gap and identifies its owner.
The decision-maker considers the required evidence and the effect of the gap under the actual release process. The coordinator does not mark support ready because an email with a draft attachment was sent.
No actual deployment, approval or platform feature is described in this example.
Make unresolved matters actionable
For each exception, state the effect, evidence, owner and decision required. Distinguish an accepted condition from an unresolved issue and keep the approval reference available. In the technical roles discussed in our IT jobs guide, coordinating readiness and authorising a deployment may sit with different people; identify those responsibilities explicitly in the actual release record.
Do not hide a blocked test by omitting it from the report or treat a planned fix as an implemented one. Where the situation changes materially, obtain the appropriate renewed review rather than relying on an earlier readiness result.
Any recovery or rollback arrangement needs an authorised technical plan. A general coordination checklist should not invent instructions for a live environment.
Confirm the decision and follow-through
Record whether the release is approved, deferred or subject to specific conditions, with the actual decision-maker and timing. Communicate the authorised outcome to the people implementing and supporting it.
After an approved release, use the organisation’s planned verification and support process, recording relevant findings. A useful readiness check gives decision-makers a clear view of evidence, uncertainty and responsibility, preserving the distinction between preparation, approval and an actual operational change.
