---
name: change-release-record
description: Turns a proposed production change into a structured risk, test, approval, rollback, and verification record with traceable evidence. Use for change management, release readiness, deployment review, CAB preparation, rollback planning, and audit documentation.
license: Apache-2.0
metadata:
  adlass.categories: "it-security/runbooks, it-security/audit-evidence"
  adlass.industries: ""
  adlass.tags: "change-management, release, rollback, testing, approvals, audit"
  adlass.adaptation: "reference-doc"
  adlass.source: "original"
  adlass.version: "1"
---

# Change release record

## Purpose

Assess whether a proposed production change is described well enough to understand risk, verify testing, identify required approvals, and recover if implementation fails. Produce a record that distinguishes evidence from planned work.

## Scope

One change or release, its affected systems, test results, approval matrix, implementation plan, rollback plan, and post-change checks. **Excluded:** executing the change, granting approval, or notifying users.

## Data basis

- Change description, implementation steps, dependencies, and affected services.
- Test results, risk policy, approval matrix, and rollback standard.
- Release notes, incident history, and post-change observations when available.

## Result

A change record, a structured log entry, and release notes containing risk, evidence, approvals required, recovery criteria, and verification status.

## Quality criteria

- Scope, impact, dependencies, and implementation window are explicit.
- Test evidence names environment, result, date, and coverage.
- Rollback triggers and verification checks are measurable.
- Required approvals are derived from the supplied matrix, not assumed.

## Instructions

Separate planned actions from completed evidence. Treat missing test or rollback details as gaps. Use the company risk classification; if absent, label the classification indicative. Never state that a change is approved because an approver is named. Preserve technical identifiers and version values exactly.

The review should make the population, calculation basis, and exception treatment understandable to a second operator. Preserve source identifiers in every working table, and state the effect of missing evidence on the decision. A reviewer must be able to reproduce each material result from the cited rows, clauses, dates, or policy rules. Where two sources disagree, show both values and explain which source was treated as authoritative.

## Adapt before use

- Add the change policy, risk matrix, approval matrix, and rollback standard.
- Define required test evidence and post-change verification fields.
- Set release-note audience, terminology, and maintenance-window format.