{"description":"Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.","edges":[{"id":"e-run-intake-gate-run-requirements-gate","label":"Cleared","source":"run-intake-gate","target":"run-requirements-gate","whenValue":"cleared_to_requirements"},{"id":"e-run-intake-gate-remediate-gate-exceptions","label":"Held","source":"run-intake-gate","target":"remediate-gate-exceptions","whenValue":"held_pending_scope_fix"},{"id":"e-run-requirements-gate-run-design-gate","label":"Approved","source":"run-requirements-gate","target":"run-design-gate","whenValue":"requirements_approved"},{"id":"e-run-requirements-gate-remediate-gate-exceptions","label":"Changes required","source":"run-requirements-gate","target":"remediate-gate-exceptions","whenValue":"requirement_changes_required"},{"id":"e-run-design-gate-run-release-gate","label":"Approved","source":"run-design-gate","target":"run-release-gate","whenValue":"design_approved"},{"id":"e-run-design-gate-remediate-gate-exceptions","label":"Rework","source":"run-design-gate","target":"remediate-gate-exceptions","whenValue":"design_rework_required"},{"id":"e-run-release-gate-monitor-program-adherence","label":"Approved","source":"run-release-gate","target":"monitor-program-adherence","whenValue":"approved_for_release"},{"id":"e-run-release-gate-remediate-gate-exceptions","label":"Blocked","source":"run-release-gate","target":"remediate-gate-exceptions","whenValue":"release_blocked"},{"id":"e-remediate-gate-exceptions-monitor-program-adherence","source":"remediate-gate-exceptions","target":"monitor-program-adherence"},{"id":"e-monitor-program-adherence-close-and-archive","label":"On track","source":"monitor-program-adherence","target":"close-and-archive","whenValue":"on_track"},{"id":"e-monitor-program-adherence-escalate-program-gaps","label":"Escalate","source":"monitor-program-adherence","target":"escalate-program-gaps","whenValue":"needs_escalation"},{"id":"e-escalate-program-gaps-close-and-archive","source":"escalate-program-gaps","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-SDLC-01","UC-SDLC-02","UC-SDLC-03","UC-SDLC-04","UC-SDLC-05"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-secure-sdlc-phase-gate-program","contentDigest":"sha256:72fbb361652e21aa8489b2417f6663964be17b14d016ab666d678b92e457f419","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:72fbb361652e21aa8489b2417f6663964be17b14d016ab666d678b92e457f419","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-secure-sdlc-phase-gate-program"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-secure-sdlc-phase-gate-program","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001","cobit-2019","nist-csf-2"],"teams":["it"]},"name":"Secure SDLC Phase-Gate Program","nodes":[{"data":{"decisionField":"intake_gate_disposition","description":"Agent compiles each initiative's intake package; human decides whether the intake gate clears the batch or holds initiatives for scope rework","formData":{"fields":[{"key":"intake_gate_disposition","label":"Intake Gate Disposition","options":[{"label":"Cleared to requirements","value":"cleared_to_requirements"},{"label":"Held, pending scope fix","value":"held_pending_scope_fix"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide, for the batch of initiatives newly entering the program this cycle, whether each one's intake package (governed scope, stakeholders, milestones, and an explicit information-security resource and budget line) is complete enough to advance to requirements, or must be held for scope rework. Owned by the Application Security Lead (SA-2, SA-3, BAI02).\n\n**Inputs**\n- The development-initiative register entries due at the intake gate this cycle — governed scope statement, stakeholder and sponsor list, and dated milestone plan for each — uploaded (PBC/external) as a CSV/XLSX extract at this step. There is no native Development Initiative item type, so the register is an uploaded document, not AssureSwarm items. This is an entry point: its inputs are the initiative register and planning artifacts, not another gate's output.\n- The initial risk-register entries per initiative: the existing Risk items (category: cyber_security, domains include secure_development_sdlc), referenced from the intake package.\n- The planning artifact that identifies the information-security requirement with its named resource and budget line item (SA-2 requires security resources to be determined during planning), uploaded (PBC/external) at this step.\n- The intake-gate checklist in force: the Policy item for the documented secure development lifecycle and its intake-gate procedure (policy_type: standard / procedure), attached to the anchor Control.\n\nAgent preparation (before the human decides):\n1. For each initiative due at intake, compile the intake package: governed scope statement, stakeholders and sponsors, dated milestones, initial risk entries, and the security resource and budget line.\n2. Compile an intake record per initiative — scope, stakeholders, milestones, the named security resource, and the budget line — as a section of the consolidated intake package (there is no Development Initiative item type to hold it); reference the supporting planning artifacts.\n3. Check each package against the intake-gate checklist — governed scope present, stakeholders named, milestones dated, security resource and budget line explicit — and flag any initiative missing an element.\n4. Assemble the consolidated intake-gate package for every initiative due this cycle and attach it as a document.\n\n**Decision criteria**\n- `cleared_to_requirements` — every in-scope initiative's scope is governed, stakeholders are named, milestones are dated, and an explicit security resource and budget line was identified during planning; no required element is missing.\n- `held_pending_scope_fix` — any initiative is missing a required element (ungoverned scope, no named security resource, no budget line, or undated milestones) and must be corrected before it proceeds.\n\n**Record in AssureSwarm**\n- Step form — submit the `intake_gate_disposition` SELECT with the step result (decision rationale and evidence references) and the step's approver record (decision owner or approver).\n- Step document — attach the consolidated intake-gate package (PDF/XLSX) carrying each initiative's intake record and the linked planning artifacts; because there is no Development Initiative item type, the per-initiative records live inside this document rather than as items.\n- Item relationship — link the referenced Risk items to the anchor Control and to this workflow instance, so the cycle's intake evidence hangs off the secure-SDLC Control.\n\n**Exit criteria** — The `intake_gate_disposition` routing selector is submitted and the step result contains a rationale; every initiative due at intake has a recorded outcome; the unused branch is prunable.","kind":"decision","label":"Run intake gate","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"run-intake-gate"},{"data":{"decisionField":"requirements_gate_disposition","description":"Agent compiles functional and application-security requirements and routes any requirement changes to re-approval; human decides whether the requirements gate is approved","formData":{"fields":[{"key":"requirements_gate_disposition","label":"Requirements Gate Disposition","options":[{"label":"Requirements approved","value":"requirements_approved"},{"label":"Requirement changes required","value":"requirement_changes_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether each initiative's full functional and application-security requirement set — including any change re-routed through change control — has stakeholder and management approval to proceed to design, or needs rework. Owned by the Application Security Lead with the requirement stakeholders (SA-3, ISO 27001 A.8.26).\n\n**Inputs**\n- The intake gate's cleared output for each advancing initiative (the intake-gate package and disposition form from the prior step): the governed scope, stakeholders, and milestones that bound the requirement set.\n- The functional and non-functional requirements for each initiative — including the application-security requirements (authentication, authorization, input and output handling, logging, and data protection) — uploaded (PBC/external) at this step.\n- The last approved requirement baseline and the change-control records, uploaded (PBC/external) at this step.\n\nAgent preparation (before the human decides):\n1. Compile the functional and non-functional requirements, including the application-security requirements, for each initiative due at this gate.\n2. Assess feasibility and alternative options for each requirement and compile the requirements-risk register entry for the initiative.\n3. Compare the current requirement set against the last approved baseline; for every changed or added requirement, capture a requirement-change record as a row in the approval package (requirement changes have no native item type), reference the original requirement, and route it for re-approval rather than treating it as pre-approved.\n4. Build the stakeholder and management approval package for the full requirement set (baseline plus any re-approved changes) and attach it.\n\n**Decision criteria**\n- `requirements_approved` — the full functional and application-security requirement set, including any changes routed through change control, has stakeholder and management approval.\n- `requirement_changes_required` — a requirement or a proposed change still needs rework before it can be approved.\n\n**Record in AssureSwarm**\n- Step form — submit the `requirements_gate_disposition` SELECT with the step result and the step's approver record.\n- Step document — attach the stakeholder and management approval package (PDF/XLSX): the full requirement set, each requirement-change record cross-referenced to its original requirement, and the re-approval sign-offs. Requirement-change records have no native item type, so they live in this package.\n- Item relationship — keep this cycle's requirements evidence linked to the anchor Control via the workflow instance.\n\n**Exit criteria** — The `requirements_gate_disposition` routing selector is submitted and the step result contains a rationale; every changed requirement carries a re-approval record; the unused branch is prunable.","kind":"decision","label":"Run requirements gate","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"run-requirements-gate"},{"data":{"decisionField":"design_gate_disposition","description":"Agent compiles the secure-architecture review and confirms the security architecture description is maintained; human decides whether the design gate is approved","formData":{"fields":[{"key":"design_gate_disposition","label":"Design Gate Disposition","options":[{"label":"Design approved","value":"design_approved"},{"label":"Design rework required","value":"design_rework_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether each initiative's design passes secure-architecture review against established engineering principles and is backed by a current security architecture description, or needs rework. Owned by the Application Security Lead (SA-3, SA-8, ISO 27001 A.8.27).\n\n**Inputs**\n- The requirements gate's approved requirement set for each advancing initiative (the approval package from the prior step), which the design must satisfy.\n- The proposed architecture and design artifacts for each initiative, uploaded (PBC/external) at this step.\n- The enterprise architecture and the security architecture description (SA-8, A.8.27), uploaded (PBC/external) at this step — the description is maintained externally; the uploaded copy is the evidence.\n\nAgent preparation (before the human decides):\n1. Assess the design against least privilege, defense in depth, isolation of execution domains, fail-safe defaults, and attack-surface minimization.\n2. Confirm a security architecture description has been produced and is consistent with the enterprise architecture; where one is missing or stale, flag it.\n3. Assess the design's robustness and resilience against errors, faults, and adversarial manipulation; create an Issue for each violated principle (issue_type: finding, source: self_assessment, severity set, description naming the principle and required fix) and link it to the anchor Control — there is no initiative item to link it to.\n4. Assemble the design-gate review package, including the architecture-description reference and any findings, and attach it.\n\n**Decision criteria**\n- `design_approved` — the design meets the secure-architecture principles and the security architecture description is current and consistent with the enterprise architecture.\n- `design_rework_required` — a principle is violated, or the security architecture description is missing or stale.\n\n**Record in AssureSwarm**\n- Step form — submit the `design_gate_disposition` SELECT with the step result and the step's approver record.\n- Item create — one Issue per violated secure-architecture principle (`issue_type: finding`, `source: self_assessment`, `severity`, `description` = the principle and required fix, `identified_date`).\n- Item relationship — link each finding Issue to the anchor Control; there is no Development Initiative item type, so the finding cannot be linked to its initiative (initiative traceability lives in the review-package document).\n- Step document — attach the design-gate review package (PDF), including the security-architecture-description reference and every finding.\n\n**Exit criteria** — The `design_gate_disposition` routing selector is submitted and the step result contains a rationale; each violated principle carries a linked finding; the unused branch is prunable.","kind":"decision","label":"Run design gate","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"run-design-gate"},{"data":{"decisionField":"release_gate_disposition","description":"Agent verifies secure-coding-standard adherence and trust-boundary input validation evidence from code review and static analysis; human decides whether the release gate is approved","formData":{"fields":[{"key":"release_gate_disposition","label":"Release Gate Disposition","options":[{"label":"Approved for release","value":"approved_for_release"},{"label":"Release blocked","value":"release_blocked"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether each initiative reaching build/release has evidence that secure-coding standards were followed and that inputs are validated at every trust boundary — verified through completed code review and static analysis — or must be blocked. Owned by the Application Security Lead (SA-11, SC-39, SI-10, ISO 27001 A.8.28).\n\n**Inputs**\n- The design gate's approved architecture for each advancing initiative (the design-gate review package from the prior step), which the built code must implement.\n- Completed code-review records and static-analysis scan results per initiative, uploaded (PBC/external) at this step — exports from the code-review and SAST tooling (external systems); the AssureSwarm copies are the evidence.\n- The secure-coding standard (common weakness classes, secure use of reused components) and the trust-boundary and input-validation map: the Policy item for the secure-coding standard (policy_type: standard) attached to the anchor Control (SI-10).\n\nAgent preparation (before the human decides):\n1. Pull the completed code-review records and static-analysis results, and compile adherence to the secure-coding standard covering common weakness classes and the secure use of reused components.\n2. Verify that inputs are validated for syntax, semantics, type, length, and range at every identified trust boundary, and that unsafe input is rejected or safely encoded rather than passed through (SI-10).\n3. Compile every open code-review comment and static-analysis finding by severity; create an Issue for each (issue_type: finding, source: self_assessment, severity by rank), link it to the anchor Control, and record its disposition — fixed, accepted risk, or false positive — with an owner.\n4. Assemble the release-gate evidence package and attach it.\n\n**Decision criteria**\n- `approved_for_release` — secure-coding adherence and trust-boundary input validation are evidenced and no unresolved high-severity finding remains.\n- `release_blocked` — a required review is incomplete, or a high-severity finding is unresolved.\n\n**Record in AssureSwarm**\n- Step form — submit the `release_gate_disposition` SELECT with the step result and the step's approver record.\n- Item create — one Issue per open code-review comment or static-analysis finding (`issue_type: finding`, `source: self_assessment`, `severity`, `description` = the weakness and its disposition of fixed / accepted risk / false positive, `identified_date`).\n- Item relationship — link each finding Issue to the anchor Control (no Development Initiative item type exists for the per-initiative link; initiative traceability lives in the evidence package).\n- Step document — attach the release-gate evidence package (PDF/XLSX).\n\n**Exit criteria** — The `release_gate_disposition` routing selector is submitted and the step result contains a rationale; every high-severity finding carries a recorded disposition; the unused branch is prunable.","kind":"decision","label":"Run build/release gate","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"run-release-gate"},{"data":{"description":"Agent converts every held or blocked gate item into an owned corrective action with an escalation and re-review path; human confirms nothing is left untracked","instructions":"**Objective** — Convert every initiative held or blocked at any gate this cycle into a tracked, owned corrective action with a scheduled re-review, so no exception silently stalls (SA-15, BAI02).\n\n**Inputs**\n- The held or blocked outcomes from the intake, requirements, design, and build/release gate decision forms this cycle, each with the specific gap that triggered the exception. This node joins all four gate exception branches, so wait for every upstream gate that produced one.\n- The gate packages those exceptions attach to, and the open corrective-action backlog carried from prior cycles — the still-open Issue items (issue_type: exception, source: self_assessment) linked to the anchor Control.\n\n**Procedure**\n1. Compile every initiative held at intake, sent back for requirement changes, sent back for design rework, or blocked at release this cycle, each with the specific gap that triggered the exception.\n2. Create an Issue for each exception (issue_type: exception, source: self_assessment) capturing root_cause, issue_owner, target_remediation_date (the scheduled re-review date), and a remediation_plan naming the gate it must clear at re-review; link it to the anchor Control (no Development Initiative item type exists for a per-initiative link).\n3. Escalate any exception that is a repeat occurrence, blocks a committed release date, or reflects a systemic gap — a consistently unresourced security line item, or a chronically missing security architecture description — to accountable engineering and security leadership.\n4. Attach the consolidated exception and corrective-action register.\n\n**Record in AssureSwarm**\n- Item create — one Issue per held or blocked exception (`issue_type: exception`, `source: self_assessment`, `root_cause`, `issue_owner`, `target_remediation_date` = the re-review date, `remediation_plan` naming the gate to clear, `identified_date`).\n- Item relationship — link each exception Issue to the anchor Control; the originating gate and initiative are captured in the register document, since there is no Development Initiative item type.\n- Step document — attach the consolidated exception and corrective-action register (XLSX).\n\n**Exit criteria** — Every held or blocked initiative has a named owner, a due date, and a scheduled re-review gate; systemic gaps are escalated; the register is attached.","label":"Remediate gate exceptions","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"remediate-gate-exceptions"},{"data":{"decisionField":"program_health_disposition","description":"Reconcile every initiative to an evidenced gate outcome and classify program trends and systemic gaps.","formData":{"fields":[{"key":"program_health_disposition","label":"Program Health Disposition","options":[{"label":"On track, within tolerance","value":"on_track"},{"label":"Needs escalation","value":"needs_escalation"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Reconcile every initiative to an evidenced gate outcome and classify program trends and systemic gaps.\n\n**Inputs**\n- The build/release gate's approved-for-release output and every other gate's recorded disposition produced this cycle.\n- The exception and corrective-action register from the remediation step (this node joins the approved-release path and the remediation path).\n- The list of initiatives due at each gate this cycle.\n- This cycle's consolidated gate-evidence record (document assembled in this checkpoint) and the exception and corrective-action register (the exception Issues plus the register document).\n- Prior cycles' program metrics for trend context — the adherence summary and closure-record documents on the previous instances' steps — and the overdue corrective actions carried forward as still-open exception Issues.\nAgent preparation (before the human decides):\n1. Compute the cycle's program metrics: on-time gate rate, held or blocked rate per gate, average time to clear an exception, repeat-exception initiatives, and overdue corrective actions carried from the prior cycle.\n2. Build a program-health dashboard showing each metric against its threshold and the trend across the last several cycles.\n3. Identify any systemic pattern: a gate with a persistently high hold rate, a recurring missing security-resource line item, a chronically stale architecture-description practice, or a code-review or static-analysis step that is regularly skipped.\n4. Draft the program-adherence summary and attach it.\n\n**Procedure**\n_This checkpoint absorbs “Compile gate evidence record”. 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. Compile gate evidence record: Assemble every gate's package, decision, and rationale from this cycle into one traceable record that evidences the documented secure development lifecycle was actually followed (SA-3, SA-15).\n2. Pull the intake, requirements, design, and release gate packages and decisions produced this cycle, alongside the exception and corrective-action register.\n3. Cross-check that every initiative due at a gate this cycle has a recorded disposition — cleared, approved, or held or blocked with a linked corrective action — and flag any initiative processed at a gate without a recorded decision.\n4. Compile the consolidated evidence record mapping each gate to its initiatives, decisions, approvers, and control references (SA-3, SA-15, SA-2, SC-39, SI-10, ISO 27001 A.8.25 through A.8.28).\n5. Attach the consolidated evidence record.\n6. Monitor program adherence and performance: Decide whether the secure-development process itself — not just individual gate outcomes — is on track this cycle, or whether a systemic pattern requires escalation. Owned by the Application Security Lead (SA-15, BAI02).\n\n**Decision criteria**\n- `on_track` — metrics are within tolerance and no systemic pattern requires escalation.\n- `needs_escalation` — a metric is out of tolerance, or a systemic pattern threatens the lifecycle's integrity.\n\n**Record in AssureSwarm**\n- Step document — attach the consolidated cycle gate-evidence record (XLSX/PDF) mapping each gate to its initiatives, decisions, approvers, and control references (SA-3, SA-15, SA-2, SC-39, SI-10, ISO 27001 A.8.25 through A.8.28).\n- Note any initiative flagged as processed without a recorded decision in the evidence record so it can be reconciled before the cycle closes.\n- Step form — submit the `program_health_disposition` SELECT with the step result and the step's approver record.\n- Dashboard — the program-health dashboard of gate-cycle metrics against thresholds and trend (built via the accelerator below), refreshed each cycle.\n- Step document — attach a snapshot of the program-health dashboard and the program-adherence summary (PDF).\n\n**Exit criteria**\n- Every initiative processed this cycle has a traceable, evidenced gate decision; no gate was chaired without a recorded outcome; the consolidated record is attached.\n- The `program_health_disposition` routing selector is submitted and the step result contains a rationale; the dashboard is attached; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` builds the program-health dashboard of gate-cycle metrics against thresholds and trend.","kind":"decision","label":"Monitor program adherence and performance","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-dashboard-create"]}},"id":"monitor-program-adherence"},{"data":{"description":"Agent packages the systemic finding and sends it to accountable leadership with a commitment form; human confirms an owner and a dated remediation commitment before closing","formData":{"fields":[{"key":"commitment_response","label":"Response to the recommended lifecycle, staffing, or tooling adjustment","options":[{"label":"Accepted as recommended","value":"commitment_accepted"},{"label":"Alternative adjustment proposed","value":"alternative_proposed"},{"label":"Declined — rationale and accepted risk stated below","value":"declined_with_rationale"}],"required":false,"type":"select"},{"key":"committed_adjustment","label":"The lifecycle, staffing, or tooling adjustment being committed (or the rationale for declining)","required":false,"type":"textarea"},{"key":"committed_completion_date","label":"Date the committed adjustment will be in place","required":false,"type":"date"},{"key":"resourcing_change","label":"Resourcing change required to deliver the commitment","options":[{"label":"None — absorbed by the current team","value":"none"},{"label":"Additional staffing","value":"staffing"},{"label":"Tooling investment","value":"tooling"},{"label":"Budget approval required","value":"budget_approval"}],"required":false,"type":"select"},{"key":"interim_mitigation","label":"Interim mitigation holding the gate until the adjustment lands","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Route a systemic secure-development-process gap to the leadership that owns the lifecycle definition and its resourcing, so the process itself is adjusted rather than repeatedly failing initiatives at the same gate (SA-15, BAI02).\n\n**Inputs**\n- The program-health finding from the adherence-monitoring decision (its disposition form and adherence summary): the affected gate or gates, the out-of-tolerance metric or pattern, and the initiatives involved.\n- The contributing gate packages and the exception Issues (the corrective actions) they attach to.\n\n**Missing-input gate** — Before any form request below, inspect the existing source records, reports and correspondence. Reuse every established fact and record its source. Send a form only when a listed fact remains genuinely unresolved and the named respondent is outside the complete roster of people executing or approving any checkpoint in this workflow. If the respondent is on that roster, record their contribution in native results and approvals. Ask only the unresolved fields; leave known, unasked or inapplicable fields optional and blank. Skip the form entirely when no missing facts remain. Attach evidence documents and record sign-off through native approval. References below to form answers or completion also accept the existing authoritative record or native participant contribution.\n\n**Procedure**\n1. Compile the systemic finding, including the affected gate or gates, the metric or pattern that triggered it, and the initiatives involved.\n2. Create a program-level improvement Issue (issue_type: observation, source: self_assessment, issue_owner = the accountable leadership, remediation_plan = the committed lifecycle/staffing/tooling adjustment) and link it to the contributing exception Issues and the anchor Control.\n3. Draft the escalation package, addressed to engineering and security leadership, recommending a specific lifecycle, staffing, or tooling adjustment.\n4. Send this step's form with the escalation package so the assigned accountable leader responds to the recommendation and commits an adjustment and date; a `declined_with_rationale` answer records the leader’s response only. Risk acceptance requires the existing delegated authority’s native approval with conditions and expiry recorded on the improvement Issue before closure.\n5. Attach the escalation package and update the improvement Issue's `issue_owner` and `remediation_plan` from the returned commitment.\n\n**Record in AssureSwarm**\n- Item create — one Issue for the systemic gap (`issue_type: observation`, `source: self_assessment`, `issue_owner` = accountable engineering/security leadership, `remediation_plan` = the recommended lifecycle, staffing, or tooling adjustment, `identified_date`).\n- Item relationship — link the improvement Issue to the contributing exception Issues and to the anchor Control.\n- Step form — the form on this step, answered by the accountable engineering or security leader receiving the escalation, uses the assigned leader identity and captures their response to the recommendation, the committed adjustment and completion date, the resourcing change required, any interim mitigation; record any required sign-off through native approval; those answers are what the improvement Issue's owner and remediation plan are set from.\n- Step document — attach the escalation package (PDF) addressed to leadership.\n\n**Exit criteria** — The escalation reached the accountable leader, and their remediation commitment and date, or reasoned declination, are recorded from existing authoritative records, a workflow participant’s native contribution, or a genuinely outside respondent’s answer to unresolved questions under the missing-input gate. A declination authorizes no risk acceptance by itself: any acceptance has the existing delegated authority’s separate native approval, with conditions and expiry recorded. The improvement item and escalation package are recorded.\n\n**Form recipient** — The accountable engineering or security leader outside the complete executor and approver roster supplies only response and committed adjustment or decline rationale; completion date; required resourcing change; interim mitigation only when this gate permits the assigned form. The workflow executor records their own analysis in the step result.","label":"Escalate program gaps","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"escalate-program-gaps"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The consolidated gate evidence record, every gate package and decision, and the exception and corrective-action register.\n- Open corrective actions, initiatives awaiting re-review, and any open escalation (this node joins the on-track path and the escalation path).\n- The control execution log and the next cycle's gate schedule.\n\n**Procedure**\n1. Export the full cycle record — every gate package, decision, and the evidence record — and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Carry forward the open corrective actions and any open escalation as their existing open Issues — do not mint new items — confirming each keeps a re-review `target_remediation_date`, and set `actual_remediation_date` on any exception Issue closed this cycle; list initiatives awaiting re-review in the closure document, since they have no item home.\n3. Update the control execution log with the cycle result, gate-level dispositions, and program-health metrics; confirm the next initiatives' due gates are scheduled.\n4. Attach the closure record.\n\n**Record in AssureSwarm**\n- Workflow instance — export and archive the full cycle run (every gate form and document) as the retention-controlled audit trail; record the archive location and reference.\n- Item field update — leave open corrective actions as open Issues with `target_remediation_date` set to their re-review date so next cycle's backlog query returns them, and set `actual_remediation_date` on any exception Issue closed this cycle. Initiatives awaiting re-review have no item home, so they are listed in the closure document.\n- Item relationship — keep the still-open carry-forward Issues linked to the anchor Control so they arrive as explicit inputs to the next cycle.\n- Step document — attach the closure record (the workflow-export output).\n\n**Exit criteria** — The archived record is immutable and retrievable; every open item has a tracked owner; next cycle's due gates are scheduled; and the authorized cycle record is complete.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` exports the full signed cycle record for archival under retention controls.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-secure-sdlc-phase-gate-program"}