{"description":"Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.","edges":[{"id":"e-classify-change-track-assess-security-and-risk-impact","label":"Standard","source":"classify-change-track","target":"assess-security-and-risk-impact","whenValue":"standard_track"},{"id":"e-assess-security-and-risk-impact-perform-acceptance-testing-and-release-readiness","source":"assess-security-and-risk-impact","target":"perform-acceptance-testing-and-release-readiness"},{"id":"e-classify-change-track-execute-emergency-change-under-safeguards","label":"Emergency","source":"classify-change-track","target":"execute-emergency-change-under-safeguards","whenValue":"emergency_track"},{"id":"e-perform-acceptance-testing-and-release-readiness-cab-authorization-and-ratification-decision","source":"perform-acceptance-testing-and-release-readiness","target":"cab-authorization-and-ratification-decision"},{"id":"e-execute-emergency-change-under-safeguards-cab-authorization-and-ratification-decision","source":"execute-emergency-change-under-safeguards","target":"cab-authorization-and-ratification-decision"},{"id":"e-cab-authorization-and-ratification-decision-execute-deployment-and-verify-outcome","label":"Approved","source":"cab-authorization-and-ratification-decision","target":"execute-deployment-and-verify-outcome","whenValue":"approved_or_ratified"},{"id":"e-cab-authorization-and-ratification-decision-execute-rollback-and-record-disposition","label":"Rejected","source":"cab-authorization-and-ratification-decision","target":"execute-rollback-and-record-disposition","whenValue":"rejected_or_rollback"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CONFIG-02","UC-CONFIG-03","UC-ACCESS-16","UC-SDLC-07","UC-SDLC-06","UC-SDLC-08","UC-SDLC-09"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-change-release-management-operation","contentDigest":"sha256:bff91696eb5798d65dae1ed4785cae7e0def347c88e46ca51aa4faed126fbe9b","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:bff91696eb5798d65dae1ed4785cae7e0def347c88e46ca51aa4faed126fbe9b","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-change-release-management-operation"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-change-release-management-operation","source":"coworkcanvas-gallery","standards":["nist-800-53","cobit-2019","iso-27001","soc1"],"teams":["it","finance"]},"name":"Change & Release Management (CAB)","nodes":[{"data":{"decisionField":"change_track","description":"Agent pulls, logs and prioritizes every change request and emergency-change entry into the cycle register and drafts the routing; human selects the dominant track for the cycle","formData":{"fields":[{"key":"change_track","label":"Change Track","options":[{"label":"Standard pre-approval track","value":"standard_track"},{"label":"Emergency expedited track","value":"emergency_track"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Log every change awaiting this CAB cycle into a single prioritized intake register, then decide whether the cycle runs on the standard pre-approval track or the emergency expedited track so the correct authorization sequence applies before any change reaches production. Owned by the change manager.\n\n**Inputs**\n- The anchor: the existing change-management ITGC Control item this instance runs against (domains: secure_configuration_change_management; Control.framework nist-800-53|cobit-2019|iso-27001|soc1), plus the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls in the library.\n- The open change-request queue exported from the ticketing system (all five in-scope categories: application, database, infrastructure, configuration, procedure) raised since the last cycle.\n- The emergency-change log — any change already implemented under the expedited procedure that owes CAB a retrospective record.\n- The prior instance's closure export (the archived prior-cycle evidence set) and the standing CAB backlog it carries forward.\n- This cycle's trigger and roster: the routine weekly cadence, a batch of queued standard changes, or an emergency change awaiting ratification, plus the change owners, risk assessor, environment owner, independent-migrator role, and CAB chair.\n- The documented emergency-change criteria.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from the former \"Intake and log change requests\" step); the human moment is the track classification at item 7._\n\n1. Pull every new change request exported from the ticketing system and every entry in the emergency-change log since the last cycle, covering all five in-scope categories across development, test, and production, and query the prior instance's closure export for carry-forward items with coach-query-data. Record which trigger opened the cycle.\n2. Log each request as a line in the intake register capturing requestor, business justification, affected systems and configuration items, requested implementation date, and change category. Reject back to the requestor any request missing a named owner or a justification — an unattributed change cannot enter the pipeline.\n3. Record each logged change's source ticket and any carry-forward backlog item it resolves against its register line.\n4. Prioritize the batch by business impact and urgency (production-critical, then time-boxed, then routine) and compile the CAB agenda in priority order.\n5. Draft the intake register and prioritized agenda and attach them with coach-document-upload.\n6. Evaluate each logged change against the documented emergency-change criteria with coach-query-data and draft the track classification with per-change reasoning, attaching the classification memo with coach-document-upload.\n7. The change manager reviews the register, the agenda and the drafted classification, and selects the dominant track for the cycle.\n\n**Decision criteria**\n- **standard_track** — Every change in the batch can wait for the next scheduled CAB: none meets the documented emergency criteria, and the target CAB date leaves enough lead time to complete risk assessment, environment and baseline verification, and acceptance testing before promotion.\n- **emergency_track** — The batch is led by a change that must be implemented before CAB can convene because it meets a documented emergency criterion: an active incident, an imminent security exposure, or a production-down condition. Before selecting this branch, confirm a named emergency approver is available to grant expedited pre-implementation authorization outside the full CAB.\n\n**Record in AssureSwarm**\n- The intake register and prioritized CAB agenda as a step document (coach-document-upload), carrying one line per change with requestor, business justification, affected systems and configuration items, requested implementation date, and change category. Studio ships no native Change Request item type, so each change record lives as a line in this document and in the workflow instance itself rather than as an item; source-ticket and carry-forward-backlog references are recorded against each line in the same register.\n- The track-classification memo as a step document (coach-document-upload).\n- Submit the `change_track` SELECT (standard_track or emergency_track). Record the per-change reasoning and evidence references in the step result, and the deciding approver in the step's approver record.\n\n**Exit criteria** — Every in-scope change since the last cycle is logged in the intake register with a named requestor, a justification, and a source-ticket reference; the agenda is compiled in a defensible priority order; the classification memo is attached; the routing selector is submitted and the step result contains a rationale and decision owner; the unchosen branch is prunable.","kind":"decision","label":"Classify change track","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"classify-change-track"},{"data":{"description":"Agent scores every standard-track change for security and risk impact and identifies affected configuration items; human confirms mitigations are adequate","instructions":"**Objective** — Score every standard-track change for security and risk impact and name the required mitigations, satisfying the risk-assessed design gate before the change proceeds to the environment, testing, and authorization controls.\n\n**Inputs**\n- The change records placed on the standard track by the change-track decision (their register lines from intake, with affected systems and configuration items).\n- Each affected system's data classification, criticality tier, and prior change/incident history.\n- The organization's risk-scoring rubric — a Policy item (policy_type: standard, policy_owner set) if the org maintains a documented risk-scoring standard, else uploaded as PBC at this step (use the dimensions below when none exists).\n\n**Procedure**\n1. For each standard-track change, query the affected systems for data classification, criticality tier, and prior change/incident history with coach-query-data.\n2. Score the change against four dimensions: security impact (does it touch authentication, authorization, encryption, or regulated data), blast radius (how many systems and users), rollback complexity, and segregation-of-duties exposure. Assign a low, medium, or high rating with the reasoning for each dimension.\n3. Identify the configuration items the change touches and the required mitigations or compensating controls for every change scoring above the low threshold — for example additional review, a staged rollout, or heightened monitoring during the change window.\n4. Draft a risk-assessment memo per change recording the rating, the dimension scores, and the mitigations, and attach it with coach-document-upload.\n\n**Record in AssureSwarm** — A risk-assessment memo per change as a step document (coach-document-upload) recording the low/medium/high rating, the four dimension scores, the affected configuration items, and the required mitigations. There is no native Change Request item to carry a risk-rating field, so the rating and mitigation notes live in this memo and are echoed on the change's line in the intake register.\n\n**Exit criteria** — Every standard-track change has a documented risk rating with dimension-level reasoning; mitigations are named for all above-low-risk changes; the risk owner has confirmed the ratings and mitigations are adequate and evidenced.","label":"Assess security and risk impact","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"assess-security-and-risk-impact"},{"data":{"description":"Agent verifies development/test/production segregation, test-data protection and configuration baselines, then runs acceptance testing against documented criteria and tracks defects to closure; human confirms release readiness","instructions":"**Objective** — Confirm the technical environment enforces development, test, and production separation with protected test data and intact configuration baselines, then test every standard-track change against documented acceptance criteria in that production-representative environment and confirm release readiness before CAB authorization.\n\n**Inputs**\n- The standard-track change records and the configuration items each one touches.\n- Environment access-control lists and logical-boundary definitions for development, test, and production.\n- The last verified configuration baseline for each affected item (code, dependencies, build settings, infrastructure-as-code).\n- The acceptance criteria and applicable test plans for each change — supplied by the change owners as PBC/external uploads at this step, echoed from the change's intake register line.\n- The approved change scope, to confirm the build under test contains only what was approved.\n\n**Procedure**\n_Items 1–4 are agent-run environment and baseline verification (folded from the former \"Verify environment segregation and configuration baselines\" step); items 5–8 run the testing, and the human moment is the release-readiness confirmation at item 9._\n\n1. Query the environment ACLs and logical boundaries with coach-query-data to confirm development, test, and production remain separated and that production-change access is restricted to the authorized migrator role.\n2. Confirm test data used this cycle is masked or anonymized where it originates from production, and that prior-cycle test data was removed on completion.\n3. For each change, identify the configuration items it touches, record the current protected baseline for each, and flag any deviation from the last verified baseline — an unexplained drift blocks the change until it is reconciled.\n4. Draft the environment-and-baseline verification memo and attach it with coach-document-upload; testing does not begin until segregation and baselines are verified or every deviation is explained.\n5. Compile the acceptance criteria for each change from the change record and applicable test plans with coach-query-data.\n6. Execute or verify execution of acceptance testing in the production-representative test environment, capturing the test cases run and pass/fail results per change in the acceptance-testing summary.\n7. Track defect remediation and retesting to closure with coach-workflow-scan, and confirm only the approved change scope reached the build under test — flag any untracked addition, which voids readiness until it is removed or separately authorized.\n8. Draft the acceptance-testing summary per change and attach it with coach-document-upload.\n9. The environment owner and the change owner review the verification memo and the testing summaries and confirm release readiness.\n\n**Record in AssureSwarm**\n- The environment-and-baseline verification memo as a step document (coach-document-upload), recording the segregation and test-data checks, each affected configuration item's protected baseline reference, and any deviation flag. Baseline references and deviations live in this memo — there is no native Change Request item field to hold them — and are echoed on the change's register line.\n- An acceptance-testing summary per change as a step document capturing the test cases run, pass/fail results, the defect-remediation and retest status, and confirmation the tested build matches the approved scope. Test cycles have no native item type, so they are recorded in this summary and tracked to closure with coach-workflow-scan.\n\n**Exit criteria** — Segregation and test-data protection are confirmed and every affected configuration item's baseline is verified or its deviation is explained; acceptance criteria were met for each change; no open severity-blocking defect remains; the tested build matches the approved change scope; the environment owner and change owner have confirmed release readiness before the CAB gate.","label":"Perform acceptance testing and release readiness","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-workflow-scan","coach-document-upload"]}},"id":"perform-acceptance-testing-and-release-readiness"},{"data":{"description":"Agent captures pre-implementation authorization, enforces the independent-migrator safeguard, executes the change, and packages evidence; human confirms it is ready for retrospective ratification","instructions":"**Objective** — Implement the emergency change immediately under the same core safeguards as the standard track — pre-authorization, independent migration, and a rollback plan — while preserving the evidence CAB needs to ratify it retrospectively.\n\n**Inputs**\n- The change record(s) placed on the emergency track by the change-track decision.\n- The named emergency approver's expedited pre-implementation authorization.\n- The rollback plan prepared before implementation and the identity of the migrator independent of development.\n\n**Procedure**\n1. Record the emergency approver's expedited pre-implementation authorization — who approved, when, and the justification — into the evidence package, satisfying the authorize-before-implementation requirement even on the expedited path.\n2. Confirm migration to production is performed by personnel independent of development, the same segregation of duties the standard track enforces, and record the migrator's identity in the package.\n3. Capture the rollback plan prepared before implementation, execute the change, and log start time, end time, and outcome against the change's register line.\n4. Assemble the full evidence package — authorization, risk rationale, migrator identity, rollback plan, implementation log — and attach it with coach-document-upload for CAB's retrospective review.\n\n**Record in AssureSwarm** — The full emergency evidence package as a step document (coach-document-upload): the expedited pre-implementation authorization (approver, timestamp, justification), the migrator's identity confirming independence from development, the pre-implementation rollback plan, and the implementation log (start, end, outcome). There is no native Change Request item to hold these, so the migrator identity and implementation record are captured in this package and in the workflow instance.\n\n**Exit criteria** — Expedited authorization, independent migration, and a rollback plan are all evidenced; the implementation log is complete; the emergency approver has confirmed the package is ready for retrospective ratification at the next CAB.","label":"Execute emergency change under safeguards","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"execute-emergency-change-under-safeguards"},{"data":{"decisionField":"cab_disposition","description":"Agent refreshes documentation and trains affected stakeholders, then assembles the CAB packet and verifies every SOX ITGC change-lens gate has evidence; CAB decides authorization or ratification for the cycle","formData":{"fields":[{"key":"cab_disposition","label":"CAB Disposition","options":[{"label":"Approved or ratified","value":"approved_or_ratified"},{"label":"Rejected or rollback required","value":"rejected_or_rollback"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — The single CAB authorization gate for both tracks: with documentation refreshed and affected people trained, approve standard changes for promotion or retrospectively ratify emergency changes, under the SOX ITGC change-control lens. Owned by the CAB.\n\n**Inputs**\n- The standard-track change records with their risk memos, environment-and-baseline verification memo and acceptance-testing summaries; for emergency changes, the full implementation evidence package.\n- Existing administrator and user documentation for the affected systems and procedures: secure-configuration, use, and maintenance procedures, runbooks, and support procedures.\n- The stakeholder map: administrators, end users, and security personnel affected by each change.\n\n**Procedure**\n_Items 1–6 are agent-run preparation (items 1–4 folded from the former \"Update documentation and train users\" step); the human moment is the CAB vote at item 7._\n\n1. Identify the administrator and user documentation each change affects with coach-query-data and draft the updates covering secure configuration, use, and maintenance procedures.\n2. Distribute or protect the updated documentation to the authorized roles who need it, and confirm development and operational knowledge such as runbooks and support procedures is current.\n3. Identify the stakeholders who need role-appropriate training or communication ahead of go-live, build the training material and a communication plan in the existing training channel, and assign completion tracking with coach-workflow-scan.\n4. Attach the updated documentation, training materials, and completion tracker with coach-document-upload — operational readiness is a gate the CAB sees, not a post-approval afterthought.\n5. Assemble the CAB packet with coach-query-data: for standard changes the risk memo, the environment-and-baseline verification, the acceptance-testing summary and the documentation/training readiness evidence; for emergency changes the full implementation evidence package. Verify every required gate has documented evidence.\n6. Build the CAB agenda dashboard with coach-dashboard-create showing each change, its track, gate-evidence completeness, and a recommended disposition, and attach the packet with coach-document-upload.\n7. The CAB reviews the packet and dashboard and votes the cycle's disposition.\n\n**Decision criteria**\n- **approved_or_ratified** — For a standard change: every required gate has documented evidence — authorized request, risk-assessed design, acceptance testing passed, documentation current and affected users trained or scheduled, and a migrator identified as independent of development — and the CAB authorizes promotion. For an emergency change: the retrospective justification holds and the implementation evidence (authorization, independent migration, rollback plan, log) is complete, so CAB ratifies it.\n- **rejected_or_rollback** — A standard change is missing a required gate or fails CAB review and is not promoted; or an emergency change's retrospective justification does not hold and it must be backed out.\n\n**Record in AssureSwarm**\n- Training and communication documents with existing training-system acknowledgement records; completion tracker (coach-workflow-scan); updated documentation and training materials (coach-document-upload).\n- The CAB packet and agenda dashboard (coach-document-upload, coach-dashboard-create).\n- Submit the `cab_disposition` SELECT (approved_or_ratified or rejected_or_rollback). Record the per-change rationale and gate-evidence references in the step result, and the deciding CAB owner in the step's approver record.\n\n**Exit criteria** — Documentation is current and distributed; affected administrators, users, and security personnel are trained or scheduled to be trained; the packet and dashboard are attached; the routing selector is submitted and the step result contains a rationale and decision owner; the unchosen branch is prunable.","kind":"decision","label":"CAB authorization and ratification decision","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload","coach-form-create","coach-workflow-scan"]}},"id":"cab-authorization-and-ratification-decision"},{"data":{"description":"Execute authorized standard promotion or verify the already-executed ratified emergency, and judge production acceptance and adoption before completing the cycle record.","instructions":"**Objective** — Execute authorized standard promotion or verify the already-executed ratified emergency, and judge production acceptance and adoption before completing the cycle record.\n\n**Inputs**\n- The CAB disposition (approved_or_ratified) and the approved change records from the authorization decision.\n- For standard changes: the deployment schedule, the independent-migrator assignment, and the rollback plan on standby.\n- For ratified emergency changes: the prior implementation record from the emergency execution step.\n- Each change's acceptance criteria, to reverify in production.\n- The full operating record from this cycle: change records, risk memos, environment-and-baseline verification, testing results, documentation and training records, CAB minutes, and deployment or rollback evidence.\n- The control execution log and the designated evidence repository with its retention policy.\n- Any open items: backlog-returned changes, open training completions, open documentation updates.\n\n**Procedure**\n_This checkpoint absorbs “Close and archive”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Execute deployment and verify outcome: For standard-track changes, schedule and execute the controlled deployment through the independent-migrator role, keeping the rollback plan on standby, and record it in the deployment-and-verification document; for ratified emergency-track changes, confirm the prior implementation record instead of re-deploying.\n2. Verify migration to production was performed by personnel independent of development for every change in this batch, recording the independent-migrator evidence in the same document.\n3. Run post-implementation verification against each change's acceptance criteria in production with coach-query-data, confirm systems behave as expected, and for any security flaw found create an Issue item (coach-item-create) — issue_type: deficiency, source: management_identified, identified_date set — related to the change-management Control with coach-items-link.\n4. Confirm the documentation and training delivered earlier reached affected users and sustained adoption after go-live, and attach the deployment-and-verification record with coach-document-upload.\n5. Close and archive: Export the full operating record with coach-workflow-export and archive it in the designated evidence repository under retention controls.\n6. Update the control execution log with the cycle result, the per-change disposition, and the key metrics: SLA adherence, gate-evidence completeness, defect rate, and rollback rate.\n7. Compile the carry-forward list — any backlog-returned change, open training completion, or open documentation update — into the closure record so the next cycle's intake reads it as its carry-forward source.\n8. Attach the closure record and confirm the next CAB cadence is scheduled with coach-document-upload.\n\n**Record in AssureSwarm**\nThe deployment-and-verification record as a step document (coach-document-upload): the controlled promotion through the independent migrator, the independent-migration confirmation, and the post-implementation verification (coach-query-data) against each change's acceptance criteria. Any security flaw found becomes an Issue item (coach-item-create) — issue_type: deficiency, source: management_identified, identified_date set — related to the change-management Control (coach-items-link, Issue ↔ Control). The deployment record itself has no native Change Request item type and lives in the document and the workflow instance.\nThe workflow instance itself as the archived per-cycle evidence set (coach-workflow-export), preserved under retention — the terminal audit trail for this cycle. The closure record as a step document (coach-document-upload) carrying the cycle result, per-change disposition, the key metrics (SLA adherence, gate-evidence completeness, defect rate, rollback rate), and the carry-forward list. Studio ships no native Change Request item type to hold carry-forward items, so they live in the closure record that the next cycle's intake reads.\n\n**Exit criteria**\n- Every deployment was performed by an independent migrator; post-implementation verification passed; no unresolved security flaw or user-adoption gap remains; the change & release manager has confirmed before closure.\n- The archived record is immutable and retrievable under retention; the control execution log reflects the cycle result and metrics; every open item has a tracked owner; the change & release manager has formally declared the cycle closed.","label":"Execute deployment and verify outcome","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-query-data","coach-document-upload","coach-workflow-export"]}},"id":"execute-deployment-and-verify-outcome"},{"data":{"description":"Back out an unratified emergency and judge restored baseline evidence, or return a rejected standard change with CAB resubmission conditions.","instructions":"**Objective** — Back out an unratified emergency and judge restored baseline evidence, or return a rejected standard change with CAB resubmission conditions.\n\n**Inputs**\n- The CAB disposition (rejected_or_rollback) and the change records it applies to.\n- For an emergency change that failed ratification: the rollback plan captured before implementation.\n- The CAB's stated conditions for resubmission, for a rejected standard change.\n- The change owner and affected-stakeholder contacts.\n- The full operating record from this cycle: change records, risk memos, environment-and-baseline verification, testing results, documentation and training records, CAB minutes, and deployment or rollback evidence.\n- The control execution log and the designated evidence repository with its retention policy.\n- Any open items: backlog-returned changes, open training completions, open documentation updates.\n\n**Procedure**\n_This checkpoint absorbs “Close and archive”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Execute rollback and record disposition: For a rejected standard change, return it to the backlog with the CAB's stated conditions for resubmission, recorded in the disposition document and flagged on the change's register line.\n2. For an emergency change that failed retrospective ratification, execute the pre-captured rollback plan, verify the environment is restored to its pre-change state with coach-query-data, and record the restoration evidence.\n3. Cross-reference the disposition to the change's original register line, and notify the change owner and affected stakeholders of the outcome.\n4. Attach the rollback evidence, or the rejection record and resubmission conditions, with coach-document-upload.\n5. Close and archive: Export the full operating record with coach-workflow-export and archive it in the designated evidence repository under retention controls.\n6. Update the control execution log with the cycle result, the per-change disposition, and the key metrics: SLA adherence, gate-evidence completeness, defect rate, and rollback rate.\n7. Compile the carry-forward list — any backlog-returned change, open training completion, or open documentation update — into the closure record so the next cycle's intake reads it as its carry-forward source.\n8. Attach the closure record and confirm the next CAB cadence is scheduled with coach-document-upload.\n\n**Record in AssureSwarm**\nThe rollback or rejection disposition as a step document (coach-document-upload): for a rolled-back emergency change, the executed rollback plan and the restoration-verification evidence (coach-query-data) confirming the environment matches its pre-change baseline; for a rejected standard change, the rejection record and the CAB's resubmission conditions. There is no native Change Request item, so the backlog-return/rollback record lives in this document and in the workflow instance; the disposition ties back to the cab_disposition form value.\nThe workflow instance itself as the archived per-cycle evidence set (coach-workflow-export), preserved under retention — the terminal audit trail for this cycle. The closure record as a step document (coach-document-upload) carrying the cycle result, per-change disposition, the key metrics (SLA adherence, gate-evidence completeness, defect rate, rollback rate), and the carry-forward list. Studio ships no native Change Request item type to hold carry-forward items, so they live in the closure record that the next cycle's intake reads.\n\n**Exit criteria**\n- Any failed emergency change is rolled back and verified clean against its pre-change baseline, or the rejected standard change is returned to the backlog with conditions; every affected stakeholder is notified; the change & release manager has confirmed before closure.\n- The archived record is immutable and retrievable under retention; the control execution log reflects the cycle result and metrics; every open item has a tracked owner; the change & release manager has formally declared the cycle closed.","label":"Execute rollback and record disposition","performedBy":{"primitives":["coach-item-create","coach-query-data","coach-items-link","coach-document-upload","coach-workflow-export"]}},"id":"execute-rollback-and-record-disposition"}],"sourceTemplateId":"workflow-library:controls-change-release-management-operation"}