Release, authorisation and transition procedure

Release, authorisation and transition procedure

RL-01 — Release policy

[Organisation] releases or transitions systems under recorded authority, using evidence relevant to the configuration and intended operating context. The release owner assembles the package; the decision authority considers the evidence, outstanding matters and risk. Operations accepts the continuing responsibilities assigned to it. These responsibilities can be held by the same person where the role and authority records establish that arrangement.

The release scope identifies software, configuration, information migration, interfaces, supplier changes, operating procedures and user communications included in the transition. A decision to release one component does not automatically authorise unrelated changes in connected systems. The release record identifies the exact artefacts and conditions covered by the decision.

RL-02 — Prepare the release package

The owner records the release identifier, source and build references, artefact integrity information, dependency inventory, configuration and intended deployment targets. The package includes requirements coverage, verification and validation results, unresolved defects and vulnerabilities, relevant supplier evidence, operational readiness and the current risk position. The owner identifies which earlier evidence is reused and why it remains applicable.

Release information includes the changes users and operators need to understand, supported configurations, known limitations, secure configuration instructions and support routes. Where a migration changes data or interfaces, the package states prerequisites, compatibility, validation and recovery arrangements. Evidence that is missing or limited is identified in the decision material.

RL-03 — Confirm readiness

The release owner confirms that adopted release criteria have been assessed and records the result for each. Criteria are drawn from the approved requirements, policies, agreements and risk decisions. The owner checks that required reviews relate to the release revision and that subsequent changes did not invalidate the evidence.

The operations owner confirms responsibility for monitoring, access, maintenance, support, incident response and recovery. Required instructions, contacts, training and service dependencies are available. The owner verifies that operational settings match the approved configuration, including identity, logging, data destinations, secrets and exposed interfaces. A working demonstration in a development environment does not establish operational readiness.

RL-04 — Make the decision

The designated authority records whether the release or operation is authorised, rejected, deferred or permitted subject to stated conditions. The decision identifies the configuration, scope, evidence considered, unresolved issues, accepted risks and relevant uncertainty. Conditions state who will act, when, and what effect failure to satisfy them has on the authorisation.

The decision is bounded by the authority’s delegation and any applicable external requirements. Risk acceptance is linked to the risk record and does not alter the assessment result. A decision that permits operation despite a deficiency states that position directly. Approval is not inferred from silence, an automatically successful pipeline or the absence of reported defects unless an established standing authority explicitly defines the applicable mechanism.

RL-05 — Deploy and verify

The deployment performer confirms the approved release, target, authority and execution window or trigger. The performer verifies the artefact identity and integrity using the agreed mechanism, applies the recorded configuration and executes the migration or transition steps. Actual actions, versions, actors and times are retained. Unexpected conditions are handled through the change or incident arrangements identified in the plan.

Post-deployment checks establish that the intended artefact and configuration are operating and that essential functions and relevant controls behave as expected. Migration checks examine completeness and correctness, not merely process termination. The owner records monitoring observations and stakeholder validation required by the plan. Failure invokes the recorded recovery decision and preserves evidence of the failed transition.

RL-06 — Handover and support

The receiving owner acknowledges the system, baseline, known issues and continuing responsibilities. Handover includes operating instructions, access administration, monitoring thresholds, supplier contacts, support periods, recovery arrangements and outstanding action ownership. The evidence repository and relevant assurance limitations are included so that operations can understand the basis on which the system was accepted.

Users and affected stakeholders receive the agreed notices, instructions and support contact routes. Release artefacts and supporting evidence are archived under the retention schedule. The owner records the conditions that require reassessment, including material changes in intended use, exposure, suppliers, processing, model behaviour or threat information.

RL-07 — Release assurance

The reviewer traces selected operating artefacts backwards to the release decision, build and source, and then to requirements and authorised changes. The review checks whether the evidence supports the configuration actually delivered. It also checks that conditions and post-release actions were followed through. A cryptographic hash supports identification of content; it does not by itself establish that the identified content was correctly specified, securely developed or appropriately authorised.