Release Management

18. Release Management #

18.1 Objectives #

Release Management ensures that production changes are predictable, reviewed, reversible, communicated, and executed within approved windows. No production change may proceed without passing SDLC gates and obtaining required approvals.

18.2 Change classification #

Every change must be classified to determine the evidence depth, notice, testing, and approvals required:

Standard: routine, low‑risk, repeatable (e.g., content/config toggles) with pre‑approved procedure.
Normal: functional or security changes with moderate impact requiring full gate evidence.
High‑risk: significant functional, architectural, or platform changes with elevated impact and rollback complexity; may require canary/blue‑green.
Emergency: production fixes to restore service or mitigate exploited security issues; allowed outside normal windows with immediate notification and post‑facto review.

PENDING: Definitions/examples for each class; who assigns the class (Vendor + CLD ISO concurrence)

18.3 Notice and scheduling #

Changes must be scheduled within approved windows with sufficient notice:

Standard changes: PENDING: __ business days notice.
Normal changes: PENDING: __ business days notice.
High‑risk changes: PENDING: __ business days notice, plus change review call if requested.
Emergency hotfixes: no prior notice required, but immediate notification to CLD and a post‑implementation report within PENDING: __ hours .
PENDING: Maintenance windows (days/times), blackout periods (e.g., holidays, quarter end)

18.4 Prerequisites to schedule #

To place a release on the calendar, the vendor must confirm:

All gate evidence for Pre‑Production is complete and approved.
UAT sign‑off is attached.
Deployment and rollback plans are current and have owners.
On‑call/escalation matrix for the release window is confirmed with contact details.
Monitoring dashboards and alerts are ready and thresholds verified in staging.

18.5 Approvals #

Standard: Product/Process Owner + IT Operations (or documented pre‑approval for the standard change procedure).
Normal: Product/Process Owner + ISO + IT Operations.
High‑risk: Product/Process Owner + ISO + IT Operations + Executive Sponsor (or delegate).
Emergency: ISO (or delegate) + IT Operations concurrence; Executive Sponsor notified immediately; post‑facto approval within PENDING: __ hours .

Approvals must be recorded in the release ticket/record.

18.6 Deployment conduct #

Execute deployments from CI/CD; no manual steps that bypass version control unless under break‑glass.
For higher‑risk releases, use canary or blue‑green patterns when feasible and monitor key metrics (error rate, latency, WAF blocks, auth failures) before full cutover.
Enforce a change freeze during critical business hours if required by the schedule.
Maintain a live checklist during the window and record start/end times and outcomes of each step.

18.7 Rollback criteria and plan #

Each release must define clear, measurable rollback triggers (e.g., sustained error rate or login failure > X%, security regression detected, broken business‑critical flow) and a step‑by‑step rollback plan with pre‑checks and validation tests. A named owner must be accountable for the rollback decision. Post‑rollback, verify system integrity and log restoration steps. Rollback readiness must be rehearsed (tabletop minimum) for High‑risk changes.

18.8 Communication #

Prior to deployment, communicate customer‑visible impact, if any, including window, expected behavior, and recovery time. During deployment, provide status at agreed intervals; escalate deviations from plan immediately. After deployment, send a completion notice summarizing the change, any incidents, and next steps. PENDING: Internal/external comms channels; status update cadence

18.9 Post‑implementation review (PIR) #

For Normal and High‑risk changes, complete a brief PIR within PENDING: __ business days covering outcomes vs plan, issues encountered, rollback decisions (if any), and improvement items. Emergency changes require a full PIR with root cause analysis, mitigations, and preventive actions; findings must feed the POA&M and Section 21 review.

18.10 Versioning and documentation #

Tag releases with immutable versions; maintain a change log describing user‑visible and operational impacts. Update runbooks, admin/user guides, API docs (OpenAPI), and data‑flow diagrams when behavior or interfaces change. If logging schemas or alert thresholds changed, submit updated mappings prior to deployment.

18.11 Records and evidence #

All release artifacts—approvals, evidence package, deployment/rollback logs, PIR—must be attached to the release record and retained per the Records Management and Retention Schedule. PENDING: Repository/path for storing release records

18.12 Exceptions #

Any deviation from these requirements (e.g., reduced notice, missing artifact, manual step) requires a documented exception with scope, rationale, risk assessment, compensating controls (e.g., extended monitoring, dedicated on‑call), owner, ISO recommendation, Executive Sponsor approval, and expiry.