{"description":"Standing operator workflow for the quarterly solution-asset lifecycle review and the availability/capacity planning cycle, from asset reconciliation and end-of-support disposition through capacity monitoring, corrective planning, and prior-period target validation. Each quarterly run is a recurring workflow instance attached to the EXISTING technology-lifecycle-and-capacity-management Control item (UC-SDLC-12/13; frequency = quarterly; control_owner = the IT control owner) — the instance enriches that standing Control and its linked records, never a fresh duplicate; the governing COBIT 2019 / NIST 800-53 mapping rides on Control.framework. In scope: the in-scope solutions, applications, and supporting infrastructure components (the services they run are Process items) with named owners, and the services carrying agreed availability and capacity (SLA/SLO) targets. Out of scope: the projects that execute an approved replacement or upgrade (each tracked externally as its own project item) and live incident response for availability outages. Named deliverables: the reconciled solution-asset register and optimization actions, the ranked end-of-support exposure list and disposition, funded replacement/upgrade plans (Issue items) and compensating-control records (Control items) with signed risk acceptances (policy_exception Issues carrying exception_expiry_date, on treatment: accept Risks), the capacity/availability dashboard and corrective plans, and the validated prior-period target package. No upstream workflow feeds this cycle and there is no separate downstream workflow to hand off to — the still-open replacement/upgrade plans, capacity corrective plans, and risk-acceptance expiries (their existing Issue and Risk items, linked to the anchor Control) carry forward as explicit inputs to the next quarterly run of this same workflow.","edges":[{"id":"e-disposition-end-of-support-components-open-replacement-upgrade-plans","label":"Replace or upgrade","source":"disposition-end-of-support-components","target":"open-replacement-upgrade-plans","whenValue":"replace_or_upgrade"},{"id":"e-disposition-end-of-support-components-document-compensating-controls-and-risk-acceptance","label":"Compensating controls","source":"disposition-end-of-support-components","target":"document-compensating-controls-and-risk-acceptance","whenValue":"compensating_controls_required"},{"id":"e-document-compensating-controls-and-risk-acceptance-open-replacement-upgrade-plans","source":"document-compensating-controls-and-risk-acceptance","target":"open-replacement-upgrade-plans"},{"id":"e-assess-capacity-disposition-log-corrective-actions-and-improvements","label":"Targets met","source":"assess-capacity-disposition","target":"log-corrective-actions-and-improvements","whenValue":"targets_met"},{"id":"e-assess-capacity-disposition-raise-capacity-corrective-plan","label":"Shortfall projected","source":"assess-capacity-disposition","target":"raise-capacity-corrective-plan","whenValue":"shortfall_projected"},{"id":"e-raise-capacity-corrective-plan-log-corrective-actions-and-improvements","source":"raise-capacity-corrective-plan","target":"log-corrective-actions-and-improvements"},{"id":"e-open-replacement-upgrade-plans-log-corrective-actions-and-improvements","source":"open-replacement-upgrade-plans","target":"log-corrective-actions-and-improvements"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-SDLC-12","UC-SDLC-13"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-technology-lifecycle-capacity-review","contentDigest":"sha256:bcb5dc6468aa8860bf2b008384f0dc30e2671f493be419239493ce585c592345","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:bcb5dc6468aa8860bf2b008384f0dc30e2671f493be419239493ce585c592345","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-technology-lifecycle-capacity-review"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-technology-lifecycle-capacity-review","source":"coworkcanvas-gallery","standards":["cobit-2019","nist-800-53"],"teams":["it"]},"name":"Technology Lifecycle & Capacity Review","nodes":[{"data":{"decisionField":"eos_disposition","description":"Approve complete ownership/licensing and optimization evidence, then choose the EOS cohort path from real lapse dates, exposure and achievable replacement timing.","formData":{"fields":[{"key":"eos_disposition","label":"End-of-Support Disposition","options":[{"label":"Replace or upgrade in time","value":"replace_or_upgrade"},{"label":"Compensating controls with risk acceptance required","value":"compensating_controls_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve complete ownership/licensing and optimization evidence, then choose the EOS cohort path from real lapse dates, exposure and achievable replacement timing.\n\n**Inputs**\nScope for this quarter: the in-scope solutions, applications, and supporting infrastructure components with named system/business owners, and the services that carry agreed availability and capacity targets. This cycle has no upstream workflow feeding it — the scope is the standing solution portfolio, plus any out-of-cycle vendor end-of-support notice or availability/capacity incident that triggered the run.\n- The solution asset register (item records for components/applications/infrastructure) with component, owner, and license-count fields.\n- License entitlement records, discovery/CMDB scan output, and procurement records.\n- Prior-cycle carry-forward items seeded into this run: open replacement/upgrade plans, risk-acceptance expiry dates, and open capacity corrective plans.\n- The governing framework mapping (COBIT 2019 / NIST 800-53) carried on the anchor Control's `framework` field, and the risk-acceptance-authority and evidence-retention Policy items (each a Policy record — policy_type: policy, with its policy_owner — linked to the anchor Control). These are relied on downstream (end-of-support disposition, compensating-control risk acceptance, and cycle close/archive), so they are surfaced here up front.\n\nThe reconciled asset register approved in the asset-reconciliation step (its component, version, and owner fields are the screening population).\n- Vendor end-of-life (EOL) and end-of-support (EOS) calendars for the products in scope.\n- Open replacement, upgrade, and risk-acceptance items already in flight (from prior cycles or earlier this cycle).\n- Comparable prior dispositions, for consistency of the call.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. IT control owner owns the stated judgments and authorizations.*\n\n*Reconcile assets and optimize use and cost.* Produce an accurate, reconciled record of every in-scope solution asset (component, ownership, licensing) plus an approved set of use- and cost-optimization actions, so the end-of-support review starts from a trustworthy register and spend is not wasted on unused capacity.\n\n1. Pull the current state: query the solution asset register, license entitlement records, discovery/CMDB scans, and procurement records, and build a single reconciliation view keyed by component.\n2. Reconcile components: for every deployed component found in discovery that is absent or stale in the register, and every registered component no longer discovered, flag the discrepancy with a reason (unregistered, decommissioned-but-open, owner-left, etc.).\n3. Reconcile ownership: confirm each in-scope component has a current, named system owner and business owner; flag any owned by a departed or unnamed party for reassignment.\n4. Reconcile licensing: tie deployed instance counts to entitlement counts; flag over-deployment (compliance exposure) and under-utilization (reclaim candidate) with the numeric gap.\n5. Correct the record: capture each discrepancy as a row in the reconciled register (XLSX) and raise an Issue item for it, linking that Issue to its supporting evidence (the discovery row, PO, or entitlement certificate) and to the anchor Control so the correction is traceable.\n6. Compute optimization: for each component, calculate utilization against entitlement and cost, and draft optimization actions — reclaim unused licenses, rightsize over-provisioned components, consolidate duplicate tooling — each with a projected annualized saving and the owner who must action it.\n7. Assemble the reconciled register and the ranked optimization recommendation into one package for review.\n\n*Disposition end-of-support components.* Compile the ranked exposure list of components reaching end of support within the review horizon and decide, for that cohort, whether the dominant disposition is to replace or upgrade in time, or whether a documented compensating control with explicit risk acceptance is required for components that cannot be replaced or upgraded before support lapses. The IT control owner owns this decision.\n\n*EOS screening and proposals support the owner’s cohort disposition.*\n8. Set the horizon: use this quarter plus the next two quarters as the standard lapse window; extend it for any component whose replacement lead time exceeds two quarters.\n9. Screen the population: cross-reference each reconciled component and its version against the vendor EOL/EOS calendars, and flag every component whose support lapses inside the horizon, recording the exact lapse date.\n10. Assess exposure per flagged component: capture the business services it supports, the data classifications it touches, and the concrete risk if support lapses without action (no security patches, unsupported configuration, no vendor break/fix).\n11. De-duplicate against work in flight: scan open replacement, upgrade, and risk-acceptance items so a component already being handled is annotated as in-flight rather than re-raised as new.\n12. Rank the list by lapse date ascending, then by exposure severity, so the soonest and highest-risk lapses lead, and attach it.\n13. Draft the per-component disposition recommendation: for each flagged component state whether a replacement or upgrade path can complete before its lapse date, with cost and lead time, and pull comparable prior dispositions to keep the call consistent.\n14. The IT control owner reviews the ranked list and the recommendation — confirming the list is complete for the horizon — and submits the cohort disposition against the criteria below.\n\nChoose **replace_or_upgrade** when every flagged component (or all material ones) has a viable replacement or upgrade path that can complete before its lapse date, funding and ownership are attainable, and no component needs to run unsupported. The cohort routes to replacement/upgrade planning.\n- Choose **compensating_controls_required** when at least one flagged component has no viable replacement or upgrade path that clears its lapse date, so it must run unsupported under a compensating control (network isolation, enhanced monitoring, restricted access) with formal risk acceptance. The cohort routes to compensating-control documentation first; any component in the cohort that does have a viable path is carried forward from there into replacement/upgrade planning.\n- Base the pick on the ranked exposure list: exposure severity, replacement cost and lead time, and remaining time to each lapse date.\n\n**Record in AssureSwarm**\nRaise an Issue item for every reconciliation discrepancy (coach-item-create — issue_type: exception, source: self_assessment, issue_owner, target_remediation_date) and link each to the anchor Control (coach-items-link). There is no native Asset/Component item type.\n- Attach the reconciled asset register (XLSX) — the register itself is the document, not item records — and the optimization recommendation as documents (coach-document-upload).\n- Source data pulled with coach-query-data.\n\nSubmit the `eos_disposition` SELECT field with the chosen branch value.\n- Record the driving rationale and evidence references in the native result and the named decision owner in the native approval; retain the single SELECT for routing only.\n- Attach the end-of-support exposure list ranked by lapse date and the per-component disposition recommendation that supports the call (coach-document-upload).\n- Cross-check in-flight items with coach-workflow-scan; source calendars, asset data, and comparables with coach-query-data.\n\n**Exit criteria**\nEvery in-scope component reconciled with a current owner and a licensing status; all discrepancies either corrected or recorded with a named remediation owner; the control owner has verified the record is accurate and complete for ownership and licensing and has approved which optimization actions proceed.\n\nEvery in-scope component is screened against vendor EOS timelines; each flagged component carries a lapse date, supported services, and stated exposure; in-flight components are annotated and not duplicated; the `eos_disposition` form is submitted with a rationale and named owner; the unchosen branch is prunable; every flagged component maps to the selected cohort disposition with its viable-path status recorded.","kind":"decision","label":"Disposition end-of-support components","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-workflow-scan"]}},"id":"disposition-end-of-support-components"},{"data":{"description":"Agent drafts funded replacement/upgrade plans as Issue items with owners and timelines ahead of the lapse date; human confirms each plan is funded, owned, and scheduled before support lapses","instructions":"**Objective** — Turn every viable replace-or-upgrade component into a funded, owned, scheduled plan that completes before the relevant support lapse date, so no component in this group is left to run unsupported.\n\n**Inputs**\n- The submitted end-of-support disposition and its per-component recommendation. This step runs both when the cohort disposition was `replace_or_upgrade` and when it was `compensating_controls_required` but individual components in the cohort still have a viable replacement or upgrade path (those arrive after their compensating controls are documented).\n- The end-of-support exposure list with each component's lapse date and supported services.\n- Available project/funding intake for capital or licensing spend.\n\n**Procedure**\n1. Build the plan population: list every component routed here for replacement or upgrade — from the replace branch directly, and any viable-path component surfaced during a compensating-controls cohort.\n2. Create a plan per component: capture the target component, the target end state (new product/version), the accountable owner, the estimated cost, and a required completion date set ahead of the lapse date with buffer.\n3. Link traceability: link each plan to the end-of-support exposure record whose lapse risk it retires, so the risk being closed is explicit.\n4. Buffer check: flag any plan whose completion date does not clear the lapse date with adequate lead time, and draft an escalation note for each at-risk plan naming what would be needed to recover the schedule.\n5. Assemble the replacement/upgrade plan register with owners, dates, costs, and at-risk flags.\n\n**Record in AssureSwarm**\n- Create an Issue item per component (coach-item-create — issue_type: finding, remediation_plan = the replace/upgrade plan, target_remediation_date set ahead of the lapse date) — not a project item; the externally-tracked execution project is out of scope. Link each Issue to the Process (service) it supports and to its end-of-support exposure record (coach-items-link).\n- Attach the plan register, including escalation notes for at-risk plans (coach-document-upload).\n\n**Exit criteria** — Every component with a viable path has a plan Issue with a named owner, funding, and a completion date that clears its lapse date; at-risk plans are flagged and escalated; the control owner has confirmed the register is complete and funded.","label":"Open replacement and upgrade plans","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"open-replacement-upgrade-plans"},{"data":{"description":"Agent drafts the compensating-control documentation and risk-acceptance record for each component that cannot be replaced or upgraded before its lapse date; human risk owner signs the acceptance","instructions":"**Objective** — Apply and document a compensating control with explicit, signed risk acceptance for each component that cannot be replaced or upgraded before support lapses, so the residual risk is deliberately owned rather than silently carried; any component in the same cohort that does have a viable path is passed forward for replacement/upgrade planning.\n\n**Inputs**\n- The submitted end-of-support disposition (`compensating_controls_required`) and the per-component recommendation identifying which components lack a viable path.\n- The end-of-support exposure list (supported services, data classifications, lapse dates).\n- The organization's risk-acceptance Policy item (a Policy record — policy_type: policy, with its policy_owner): who may accept residual risk at which exposure level, and the maximum acceptance term.\n\n**Procedure**\n1. Split the cohort: separate components with no viable replacement/upgrade path (documented here) from any component with a viable path (carried forward to replacement/upgrade planning).\n2. Specify the compensating control per no-path component: choose the mitigation proportionate to exposure — network isolation/segmentation, enhanced logging and monitoring, restricted or brokered access, or equivalent — and record the control, its owner, and its review date.\n3. Create a Control item for each compensating control and link it to the Risk it mitigates (and to the component's end-of-support exposure record) so the mitigated risk is traceable.\n4. Record the risk acceptance schema-natively (mirroring the policy-exception risk-acceptance pattern): create or update the Risk item for the accepted exposure with treatment: accept, the accepting owner (per policy authority) as risk_owner, and its residual_rating; then raise a policy_exception Issue carrying exception_approver (the accepting authority) and an explicit exception_expiry_date after which the risk must be revisited, linked to that Risk.\n5. Package the compensating-control register and the signed risk-acceptance package for the record.\n\n**Record in AssureSwarm**\n- Create a Control item per compensating control (coach-item-create — control_type: preventive|detective, control_owner, frequency) and link it to the Risk it mitigates (coach-items-link).\n- Create/update the Risk item for each accepted exposure (coach-item-create / coach-item-update — treatment: accept, risk_owner = the accepting authority, residual_rating) and record the risk acceptance as a policy_exception Issue (coach-item-create — issue_type: policy_exception, exception_approver, exception_expiry_date) linked to that Risk and the anchor Control (coach-items-link).\n- Attach the compensating-control register and the signed acceptance package as documents (coach-document-upload).\n\n**Exit criteria** — Every no-path component has a specified compensating control with an owner and review date, plus a risk acceptance signed by the accountable risk owner and carrying an expiry date; any viable-path component is explicitly passed forward to replacement/upgrade planning; no component is allowed to lapse without a signed acceptance or a plan.","label":"Document compensating controls and risk acceptance","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link","coach-form-create","coach-document-upload"]}},"id":"document-compensating-controls-and-risk-acceptance"},{"data":{"decisionField":"capacity_disposition","description":"Agent compiles current and forecast demand against solution availability and capacity metrics and agreed targets and summarizes attainment and projected shortfalls; human decides whether prior-period targets are validated as met or a capacity corrective plan is required","formData":{"fields":[{"key":"capacity_disposition","label":"Capacity Disposition","options":[{"label":"Targets met, no shortfall projected","value":"targets_met"},{"label":"Shortfall projected or target missed","value":"shortfall_projected"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Compare each in-scope service's availability and capacity against current and forecast demand and its agreed targets, then decide whether current provisioning covers forecast demand with no projected shortfall, or whether a projected or realized shortfall requires a corrective plan. The IT control owner owns this decision.\n\n**Inputs**\n- Scope for this quarter: the in-scope solutions and services and their agreed availability and capacity (SLA/SLO) targets. This is an independent entry point — it needs only the standing service portfolio and its monitoring feeds, not the output of the asset-lifecycle track.\n- Availability and capacity monitoring data and current utilization for each service (CPU/memory/storage/throughput, uptime).\n- The business demand forecast: known demand changes this cycle — new customers, seasonal peaks, retired workloads, feature launches.\n\n**Procedure**\n*Monitoring and forecast assembly support the owner’s capacity disposition.*\n1. Pull metrics: query availability and capacity monitoring data and current utilization for every in-scope solution and service.\n2. Establish targets: for each service, retrieve the agreed availability and capacity targets (SLA/SLO) that apply this cycle.\n3. Compare current position: contrast current utilization and availability against provisioned capacity and against each target, noting headroom or breach.\n4. Model forecast demand: apply the business demand forecast and known demand changes to the capacity model, and project the future position for each service, including any point where forecast demand crosses provisioned capacity (a projected shortfall) with its expected date.\n5. Build the picture: assemble a capacity/availability dashboard showing current position, forecast trajectory, and target lines per service, and a supporting analysis of the demand-change impacts.\n6. Rank the shortfalls and missed targets by business impact and time-to-impact and draft the disposition summary enumerating which targets, which services, and what dates drive the call.\n7. The IT control owner reviews the comparison and the summary — confirming the forecast and comparison are current and complete — and submits the capacity disposition against the criteria below.\n\n**Decision criteria**\n- Choose **targets_met** when the prior-period availability and capacity targets were met and no service shows a projected shortfall within the planning horizon. The cycle proceeds directly to validating prior-period target attainment.\n- Choose **shortfall_projected** when any prior-period target was missed, or any service shows a projected shortfall (forecast demand crosses provisioned capacity) within the horizon. A corrective plan is required before the shortfall affects the business; the cycle raises corrective plans and then still validates prior-period attainment.\n- A single material breach or projected shortfall is sufficient to route to `shortfall_projected`.\n\n**Record in AssureSwarm**\n- Submit the `capacity_disposition` SELECT field with the chosen branch value.\n- Record the rationale and evidence references (targets, services and dates) in the native result and name the owner in the native approval; do not add questionnaire fields to the SELECT.\n- Build the capacity/availability dashboard (coach-dashboard-create); attach the supporting demand-and-capacity analysis and the disposition summary that supports the call (coach-document-upload).\n- Source monitoring, utilization, forecast, and attainment data with coach-query-data.\n\n**Exit criteria** — Every in-scope service has a current-vs-target and forecast-vs-capacity comparison with any projected shortfall dated; the `capacity_disposition` form is submitted with a rationale and named owner; the unchosen branch is prunable; every projected shortfall or missed target that drove the pick is enumerated in the summary.","kind":"decision","label":"Assess capacity disposition","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-dashboard-create"]}},"id":"assess-capacity-disposition"},{"data":{"description":"Agent drafts corrective plans for each projected shortfall with cost and timeline; human approves the plan owner and completion date","instructions":"**Objective** — Turn every projected or realized availability/capacity shortfall into a funded corrective plan that corrects provisioning before the shortfall affects the business.\n\n**Inputs**\n- The submitted capacity disposition (`shortfall_projected`) and the disposition summary enumerating each shortfall or missed target.\n- The capacity/availability dashboard and analysis: each shortfall's service, metric, projected impact date, and magnitude.\n- Budget/scope intake for capacity additions or demand-shaping changes.\n\n**Procedure**\n1. Draft a corrective plan per shortfall: specify the capacity addition (scale-up/scale-out, storage, licensing) or demand-shaping action (throttling, workload reschedule, retirement), with estimated cost, accountable owner, and a required completion date set ahead of the projected impact date.\n2. Link each corrective plan to the affected service (the Process carrying the target) so the shortfall it retires is traceable.\n3. Escalate the unbudgeted: where a shortfall is driven by an unbudgeted demand change, draft the budget or scope escalation needed and route it to the accountable owner for a funding decision.\n4. Sequence against impact: order plans by time-to-impact so the nearest shortfalls are actioned first, and flag any plan that cannot complete before its impact date.\n\n**Record in AssureSwarm**\n- Create an Issue item per shortfall (coach-item-create — issue_type: finding, source: management_identified, remediation_plan = the corrective plan, target_remediation_date set ahead of the projected impact date) — the plan-shaped output is an Issue, not a generic item, so it carries forward as an open Issue linked to the anchor Control. Link each Issue to the Process (the service carrying the target) it restores (coach-items-link); capacity metric/target is not an item type and cannot be a link target.\n- Attach the corrective-plan register, including budget escalations, as a document (coach-document-upload).\n\n**Exit criteria** — Every projected shortfall or missed target has a funded corrective plan with a named owner and a completion date ahead of impact; budget escalations are routed to their owners; the control owner has confirmed the register is complete before prior-period targets are validated.","label":"Raise capacity corrective plan","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"raise-capacity-corrective-plan"},{"data":{"description":"Validate evidence-backed met/narrow/missed target outcomes, reconcile both tracks and approve owned corrections and systemic improvements with complete carry-forward coverage.","instructions":"**Objective** — Validate evidence-backed met/narrow/missed target outcomes, reconcile both tracks and approve owned corrections and systemic improvements with complete carry-forward coverage.\n\n**Inputs**\nThe capacity disposition outcome. On the targets_met branch this step runs directly on the monitoring outputs; on the shortfall branch it also consumes the corrective-plan register raised in the prior step, so each missed target reconciles to its plan.\n- Prior-period attainment evidence per service: uptime logs, incident records, and utilization history.\n- The agreed availability and capacity targets for the prior period.\n\nThis step joins both tracks and needs their reviewed outputs: from the asset-lifecycle track, the replacement/upgrade plan register (including at-risk plans) and any unresolved reconciliation discrepancies and risk-acceptance expiry dates; from the capacity track, the validated-target records and any corrective plans.\n- The prior-cycle carry-forward list, to confirm nothing rolled forward was dropped.\n- The full operating record of this cycle: reconciled asset register, end-of-support disposition and its plans/acceptances, capacity comparison and disposition, and validated-target records.\n- The organization's evidence-retention Policy item (a Policy record — policy_type: policy, with its policy_owner): repository, retention period, immutability controls; and the next-review scheduling calendar.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. IT control owner owns the stated judgments and authorizations.*\n\n*Validate prior-period targets met.* Validate and formally record whether each in-scope service met its agreed availability and capacity targets in the prior period, closing the loop on the commitments made to the business — including services for which a corrective plan was just raised.\n\n1. Compile evidence per target: gather uptime logs, incident records, and utilization history for the prior period and package them per service and per target.\n2. Classify attainment: mark each target as met, met only narrowly, or missed, capturing the attained value and, for misses, the duration and root cause.\n3. Record attainment in the validation package: for each service capture the period, the target, and the attained-or-shortfall value as a row in the validation package (XLSX) with its supporting evidence — there is no per-service SLA/target item type, so the per-service attainment record lives in the package.\n4. Reconcile misses to plans: for any missed or narrowly-met target where a corrective plan was raised, update the matching corrective-plan Issue with the miss's root_cause and identified_date and link the miss to that plan Issue, confirming the plan addresses the miss without duplicating it.\n5. Flag the narrow ones: mark any target met only narrowly for closer monitoring next cycle so a near-miss does not become next quarter's breach.\n\n*Log corrective actions and improvements.* Convert every gap surfaced this cycle into an owned, tracked action and raise program-level improvements for systemic issues, then close the quarterly review on that record: archive an immutable audit trail under retention and seed the next cycle so its inputs arrive explicitly.\n\n*The approved corrective register authorizes record retention and next-cycle scheduling without another confirmation.*\n6. Assemble the gap list: parse the cycle's outputs — reconciliation discrepancies not yet closed, at-risk replacement/upgrade plans, approaching risk-acceptance expiries, and open capacity corrective plans — into one consolidated list.\n7. Reuse and link the existing corrective Issue for each gap; create a new one only where no owned action exists, capturing the root cause, accountable owner, due date, and any interim mitigation, and link it to the source record it derives from.\n8. Raise improvements: for any systemic pattern this cycle exposed — chronic license mismatch, a vendor with poor end-of-support notice, a recurring capacity forecast miss — raise a program-level improvement item and escalate it to the accountable owner.\n9. Confirm completeness: verify every gap on the list maps to exactly one owned action and nothing on the prior carry-forward list was silently dropped. The IT control owner signs off the corrective-action register — that sign-off is this cycle's closure.\n10. Export the record: export the full operating record and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n11. Seed carry-forward: create carry-forward items for open replacement/upgrade plans, upcoming risk-acceptance expiry dates, and open capacity corrective plans, and link each to its source so it arrives as an explicit input to the next quarterly run of this workflow.\n12. Update the log: update the control execution log with the cycle result and key metrics (components reconciled, EOS components dispositioned, targets met/missed, shortfalls corrected).\n13. Schedule the next run: confirm the next quarterly review is scheduled with its owner, and attach the closure record.\n\n**Record in AssureSwarm**\nAttach the validation package (XLSX + evidence) as a document (coach-document-upload) — the per-service attainment record lives in the package; there is no per-service SLA/target item type.\n- For each missed or narrowly-met target, update the matching corrective-plan Issue with root_cause and identified_date (coach-item-update) and link the miss to that plan Issue (coach-items-link).\n- Compile attainment evidence with coach-query-data.\n\nCreate an Issue item per remaining gap and per systemic improvement (coach-item-create — issue_type: finding for a gap or opportunity for a systemic improvement, issue_owner, target_remediation_date) — plan-shaped outputs are Issues, not generic items, so they carry forward as open Issues linked to the anchor Control. Carry existing open Issues forward by reference rather than duplicating them, create an item only for a new untracked obligation, and link every Issue to its source Issue/Risk/Control record (coach-items-link).\n- Export and archive the operating record (coach-workflow-export).\n- Attach the corrective-action register and the closure record (coach-document-upload); compile the gap list with coach-query-data.\n\n**Exit criteria**\nEvery in-scope target has a per-service attainment record in the validation package backed by evidence and classified met/narrow/missed; narrowly met targets are flagged for next cycle; every missed target reconciles to a corrective plan without duplication; the control owner has signed off the validation.\n\nEvery open gap has a corrective-action item with a named owner and due date; systemic issues are raised as improvement items and escalated; the archived record is immutable and retrievable under retention; carry-forward items exist and are linked for the next cycle; the next quarterly review is scheduled. The control owner's sign-off on the corrective-action register closes the cycle with nothing left untracked.","label":"Log corrective actions and improvements","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-item-update","coach-items-link","coach-document-upload","coach-workflow-export"]}},"id":"log-corrective-actions-and-improvements"}],"sourceTemplateId":"workflow-library:controls-technology-lifecycle-capacity-review"}