{"description":"Each run attaches as a workflow instance to the existing Control item for the secure-development/release-security-gate control (domains: secure_development_sdlc + vulnerability_patch_management) — enrich that Control, never create a duplicate; release runs and the quarterly checkpoint are separate instances on the same anchor Control. This workflow originates on its own artifacts (the release candidate, design artifacts, and the standing portfolio registers) and receives no upstream handoff package. Decision-aware: it branches on trigger type. In scope — for a release or major upgrade entering development, run security-and-privacy-by-design engineering, security test-plan execution, and runtime-hardening verification as parallel evidence streams, then resolve the release security disposition and assemble the release security evidence package with its acceptance-criteria index; for the quarterly portfolio checkpoint, run the vulnerability, patch, and end-of-life software review, publish the portfolio-health dashboard, and log corrective actions. Out of scope — the final production go/no-go, which the separate SDLC gate review workflow owns using the evidence package this workflow hands off to it. The release track and the quarterly track never force each other's steps.","edges":[{"id":"e-classify-cycle-trigger-engineer-security-and-privacy-by-design","label":"Release trigger","source":"classify-cycle-trigger","target":"engineer-security-and-privacy-by-design","whenValue":"release_trigger"},{"id":"e-engineer-security-and-privacy-by-design-assess-release-security-disposition","source":"engineer-security-and-privacy-by-design","target":"assess-release-security-disposition"},{"id":"e-assess-release-security-disposition-close-and-archive","label":"Clear to proceed","source":"assess-release-security-disposition","target":"close-and-archive","whenValue":"clear_to_proceed"},{"id":"e-assess-release-security-disposition-drive-remediation-and-risk-exceptions","label":"Requires action","source":"assess-release-security-disposition","target":"drive-remediation-and-risk-exceptions","whenValue":"requires_action"},{"id":"e-drive-remediation-and-risk-exceptions-close-and-archive","source":"drive-remediation-and-risk-exceptions","target":"close-and-archive"},{"id":"e-classify-cycle-trigger-classify-portfolio-maintenance-disposition","label":"Quarterly checkpoint","source":"classify-cycle-trigger","target":"classify-portfolio-maintenance-disposition","whenValue":"quarterly_checkpoint"},{"id":"e-classify-portfolio-maintenance-disposition-log-corrective-actions","label":"Escalation","source":"classify-portfolio-maintenance-disposition","target":"log-corrective-actions","whenValue":"escalation_required"},{"id":"e-classify-portfolio-maintenance-disposition-close-and-archive","label":"On track","source":"classify-portfolio-maintenance-disposition","target":"close-and-archive","whenValue":"on_track"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CONFIG-04","UC-VULN-04","UC-VULN-07"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-secure-development-release-security-gate","contentDigest":"sha256:97dde0cbe2525c8b4665900d4ab33c1d99daacd4ad3a2b8cf27e14ff86954a66","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:97dde0cbe2525c8b4665900d4ab33c1d99daacd4ad3a2b8cf27e14ff86954a66","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-secure-development-release-security-gate"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-secure-development-release-security-gate","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","gdpr","pci-dss"],"teams":["it"]},"name":"Secure Development & Release Security Gate","nodes":[{"data":{"decisionField":"cycle_trigger_type","description":"Agent assembles the trigger context from the release calendar, inventory, and backlogs; human confirms whether this run is a release-triggered cycle or the quarterly portfolio checkpoint and selects the branch","formData":{"fields":[{"key":"cycle_trigger_type","label":"Cycle Trigger Type","options":[{"label":"Release or major upgrade entering development","value":"release_trigger"},{"label":"Quarterly portfolio checkpoint","value":"quarterly_checkpoint"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Determine whether this run is a release-triggered secure-development cycle or the recurring quarterly portfolio-maintenance checkpoint, and route it down the correct track, because a release entering development and the quarterly review are two distinct procedures on two distinct cadences. This instance attaches to the existing Control item for the secure-development/release-security-gate control — enrich it, never create a duplicate. Owned by the application-security lead.\n\n**Inputs**\n- The release calendar and any release-candidate record, with target production date, for releases or major upgrades entering development. There is no native Release item type — capture these as an upload (PBC/external) on this step and carry the build identifier and target date into the step result.\n- The system and component inventory, including each system's data classification and internet exposure — in-scope systems modelled as Process items (`process_type: it_general_control` or `security_process`) where they exist; the classified inventory itself is a CSV/register uploaded on this step (no native System/Asset type).\n- The production vulnerability backlog — the open Issue items (`source: vulnerability_scan`, `severity` set) — plus the patch-status register and the software end-of-life register, which have no native type and arrive as CSV extracts uploaded on this step.\n- The prior-cycle operating log: the archived workflow instance of the prior cycle on this same anchor Control, plus its open carry-forward Issue items (remediation still open, risk-acceptance review dates due, replacement-queue items) linked to the anchor Control.\n- This workflow originates on its own artifacts and the standing portfolio registers; it does not receive a handoff package from another workflow.\n\n**Decision criteria**\n1. Gather the context with `coach-query-data`: pull the release calendar, the inventory, the vulnerability/patch/end-of-life registers, and the prior-cycle log, and summarise what is in flight and what is due this cycle.\n2. Establish the trigger. If a specific release or major upgrade is entering development, confirm a release candidate and a target production date exist so the design, test-plan, and hardening streams have a real build to operate against — pick `release_trigger`. Per-release secure-design engineering, security testing, and runtime-hardening verification are in scope.\n3. If instead this is the standing quarterly portfolio-maintenance run, confirm no release candidate is in scope and that the vulnerability, patch, and end-of-life registers are current enough to review — pick `quarterly_checkpoint`. Only vulnerability remediation against risk-based timeframes, patch-SLA adherence, and unsupported-software replacement are in scope.\n4. If both conditions appear true in the same window (a release is mid-flight and the quarter has turned), run them as two separate executions of this workflow — one per branch — not one blended run.\n\n**Record in AssureSwarm** — Submit the `cycle_trigger_type` SELECT (`release_trigger` or `quarterly_checkpoint`) on the step form. Capture the rationale and the evidence references (calendar entry, register snapshot, build identifier) in the step result, and the deciding owner in the step's approver record. Attach the trigger-classification note as a step document with `coach-document-upload`. The run itself is the workflow instance on the anchor Control.\n\n**Exit criteria** — The SELECT is submitted with a written rationale and named owner; the non-selected branch is prunable; the selected track's starting inputs (release candidate, or current portfolio registers) are confirmed present.","kind":"decision","label":"Classify cycle trigger","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"classify-cycle-trigger"},{"data":{"description":"Agent maps the release design against the secure coding standard and privacy-preserving defaults; human confirms security and data protection are built in, not deferred","instructions":"**Objective** — Produce a reviewed secure-and-privacy-by-design checklist proving security and data-protection requirements are engineered into the release from design onward, so it starts from a secure baseline rather than retrofitting controls later.\n\n**Inputs**\n- The release candidate confirmed on the `release_trigger` branch of the trigger decision (captured in the trigger step result and upload — there is no Release item type).\n- Design and architecture artifacts and data-flow diagrams for the release — uploaded (PBC/external) on this step; there is no native design-artifact type.\n- The organisation's current secure coding standard — a Policy item (`policy_type: standard`, `framework`, `domains: secure_development_sdlc`) in the policy library, whose governed document is attached to that Policy; its mandatory-topic list drives the mapping.\n- The system's data classification (from the Process-modelled inventory / trigger upload), marking which flows carry personal or sensitive data.\n- This stream consumes the design artifacts directly; the security-testing and runtime-hardening work now runs inside the release security disposition step, which consumes this checklist alongside them.\n\n**Procedure**\n1. Pull the design/architecture artifacts, data-flow diagrams, and the secure coding standard Policy with `coach-query-data`, and enumerate every field and flow carrying personal or sensitive data.\n2. Map each design element against the secure coding standard's mandatory topics — authentication, authorization, input validation, output encoding, cryptography, error handling, and logging — and flag any element with no corresponding, explicit design decision (NIST 800-53 SA-11 / SI-11; PCI DSS Requirement 6).\n3. For each personal or sensitive data flow, confirm a privacy-preserving default is designed in per GDPR Article 25 (data protection by design and by default): data minimisation (collect/retain only what is justified), pseudonymisation, or tokenisation. Record the design decision and its owner; flag any flow with no minimisation or pseudonymisation decision.\n4. Cross-check that logging and error handling do not themselves capture sensitive data beyond what is justified, and that cryptography choices name specific algorithms and key-management responsibilities rather than \"encrypted\" as an assertion.\n5. Raise an Issue for each flagged gap with `coach-item-create` (`issue_type: observation` or `finding`, `source: self_assessment`, `severity`, `issue_owner`, `target_remediation_date`), link each to the anchor Control with `coach-items-link` (the design artifacts are step documents, so the tracked link lands on the anchor), and compile the secure-and-privacy-by-design checklist recording pass/gap per topic and per data flow.\n\n**Record in AssureSwarm** — Attach the secure-and-privacy-by-design checklist (XLSX/PDF) as a step document with `coach-document-upload`. Create one Issue per gap (`coach-item-create` — `issue_type: observation`/`finding`, `source: self_assessment`, `severity`, `issue_owner`) and link each to the anchor Control (`coach-items-link`). The checklist stays as the step document on this step — there is no Release item to link it to.\n\n**Exit criteria** — Every mandatory secure-coding topic has an explicit design decision or a tracked gap; every identified personal/sensitive data flow has a recorded privacy-preserving default or a tracked gap; the application-security lead and engineering owner have confirmed the standard was applied before development proceeds.","label":"Engineer security and privacy by design","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"engineer-security-and-privacy-by-design"},{"data":{"decisionField":"release_security_disposition","description":"Agent executes the documented security test plan against the release-candidate build, verifies runtime hardening, and consolidates both with the design checklist against the acceptance criteria; human application-security lead decides whether the release is clear to proceed or needs remediation or a formal risk acceptance","formData":{"fields":[{"key":"release_security_disposition","label":"Release Security Disposition","options":[{"label":"Clear to proceed","value":"clear_to_proceed"},{"label":"Requires remediation or risk acceptance","value":"requires_action"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Execute the documented security test plan against the release-candidate build, verify its runtime hardening, and resolve — together with the secure-and-privacy-by-design checklist — whether this release meets the defined security acceptance criteria, so only a release that is genuinely ready (or explicitly and accountably not) continues toward evidence packaging. Owned by the application-security lead.\n\n**Inputs**\n- The release candidate confirmed on the `release_trigger` branch of the trigger decision, with its build identifier (from the trigger step result/upload — there is no Release item type).\n- The documented security test plan for the release's technology stack — uploaded (PBC/external) on this step; there is no native test-plan type (the Control-hosted SOX testing workflow model is ICFR-only and not reusable here).\n- The input-surface and error-path inventory for the build (endpoints, forms, file and upload handlers) — uploaded on this step; no native type — and the list of supporting platforms and runtimes hosting the release, with their OS/runtime versions.\n- The system's data classification, which sets the defined security acceptance criteria for severity.\n- The reviewed secure-and-privacy-by-design checklist handed over by the upstream design step.\n\n**Procedure**\n_Items 1–5 execute the security test plan and items 6–10 verify runtime hardening — both agent-run (folded from the former \"Execute the security test plan\" and \"Verify runtime hardening\" steps, which used to be parallel evidence streams); the human moment is the disposition call below._\n1. Pull the documented security test plan with `coach-query-data` and confirm it specifies static analysis (SAST), dynamic analysis (DAST), and any additional testing the technology requires — dependency/software-composition analysis, container image scanning, or API testing.\n2. Execute or retrieve the result of each specified analysis against the release-candidate build, recording for every result the tool, its configuration profile, the run date, and the build identifier so the run is reperformable.\n3. Normalise and de-duplicate findings across tools, map each to the defined security acceptance criteria for this system's data classification, and compile the findings register by severity (critical / high / medium / low) with the evidence reference behind each finding.\n4. Confirm coverage is complete: every component and interface named in the test plan has a corresponding executed analysis; a gap in coverage is itself a finding to record, not a silent omission.\n5. Retain every scan report, log, and configuration snapshot as step documents with `coach-document-upload` and link each to the anchor Control with `coach-document-link`.\n6. Pull the input-surface and error-path inventory with `coach-query-data`, exercise each surface, and review the resulting error messages and logs for stack traces, credentials, internal paths, or any sensitive detail beyond the minimum a user needs to correct the input (NIST 800-53 SI-11 — error handling).\n7. Verify that information leaving the application — API responses, rendered output, and exports to downstream systems — is validated and filtered against expected content and format before exposure (SI-15 — information output filtering).\n8. Confirm memory protections per NIST 800-53 SI-16: data-execution prevention (DEP) and address-space layout randomisation (ASLR) are enabled on every supporting platform and runtime; record any platform where a protection is unavailable or disabled, with its justification.\n9. Confirm the build fails closed — an unexpected error, a dependency outage, or an authorization failure denies rather than grants access, and does not drop into a permissive default.\n10. Compile the runtime-hardening checklist with an explicit pass/fail per control and the evidence (screenshot, log excerpt, platform configuration) behind each.\n11. Consolidate the three reviewed inputs with `coach-query-data`: the secure-and-privacy-by-design checklist from the upstream design step, the findings register from items 1–5, and the runtime-hardening checklist from items 6–10. Do not score until all three are present and complete.\n\n**Decision criteria**\n1. Score the consolidated package against the defined security acceptance criteria: count outstanding critical or high findings, unresolved privacy-by-design gaps, and failed hardening checks.\n2. Pick `clear_to_proceed` only when every acceptance criterion is met — no outstanding critical/high findings, no unresolved privacy-by-design gap, and no failed hardening check without an already-approved, recorded exception. Test evidence must tie to the actual release-candidate build identifier, and coverage gaps count as findings.\n3. Pick `requires_action` when any critical/high finding, privacy-by-design gap, or failed hardening check remains open and must be remediated or formally risk-accepted before the release is packaged. When in doubt between the two, choose `requires_action` — a gap routed to remediation is recoverable; a premature clearance is not.\n\n**Record in AssureSwarm**\n- Attach every scan report, log, and configuration snapshot as step documents (`coach-document-upload`) and link them to the anchor Control (`coach-document-link`); attach the compiled findings register (XLSX/CSV) alongside them on this step.\n- Attach the runtime-hardening checklist (XLSX/PDF) with pass/fail and evidence per control as a step document; it stays on this step (there is no Release item to link it to).\n- Submit the `release_security_disposition` SELECT (`clear_to_proceed` or `requires_action`). Record the specific criteria driving the call, with evidence references, in the step result, and the deciding owner in the step's approver record. Attach the consolidated disposition package with `coach-document-upload`.\n\n**Exit criteria** — The plan's analyses match the technology and every result ties to the release-candidate build identifier; the findings register is complete and severity-scored with coverage gaps recorded as findings; error handling reveals no sensitive data, output is validated and filtered, DEP and ASLR are confirmed everywhere the release runs (or each exception is explicitly justified), and the build is shown to fail closed; all three checklists are consolidated and scored; the SELECT is submitted with a written, criteria-specific rationale and named owner; the non-selected branch is prunable.","kind":"decision","label":"Assess release security disposition","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"assess-release-security-disposition"},{"data":{"description":"Agent tracks each finding to a verified fix or a formal risk acceptance; human verifies nothing reaches production unresolved and unowned","instructions":"**Objective** — Close out every outstanding finding and privacy-by-design gap for this release through either a verified fix or a formal, owned risk acceptance, so nothing reaches production unresolved and unowned before the evidence is packaged.\n\n**Inputs**\n- The consolidated disposition package from the release security disposition decision, reached on its `requires_action` branch.\n- The findings register, the secure-and-privacy-by-design checklist, and the runtime-hardening checklist that surfaced the open items.\n- The original test tools and configuration profiles, needed to reperform closure scans.\n\n**Procedure**\n1. Create an Issue for every outstanding finding and gap with `coach-item-create` (`severity`, `source: vulnerability_scan` or `self_assessment`, `issue_owner`, `target_remediation_date` — shorter for critical/high and for internet-exposed or regulated systems); link each to the anchor Control with `coach-items-link` (the findings register is a step document, so the tracked link lands on the anchor).\n2. For items being fixed, verify closure by re-scanning or re-testing against the same tool and configuration used originally, and record the passing evidence against the Issue, setting `actual_remediation_date` and `verified_date` — a fix asserted without a passing re-scan is not closed.\n3. For items the risk owner elects to accept rather than fix, record the acceptance as an Issue (`issue_type: policy_exception`, `exception_approver` = the accountable approver authorised to accept that level of risk, `exception_expiry_date` = the expiry or review date) linked to the anchor Control, and set `treatment: accept` (with `residual_rating` and `risk_owner`) on the associated Risk, linking that Risk to its source Issue; retain the signed acceptance record and its compensating-controls detail as a step document.\n4. Reconcile the register: every open item is now either verified-fixed with evidence or formally accepted with a signed record — no item is left in an ambiguous \"in progress\" state at this gate.\n5. Compile the remediation-and-exceptions register showing final status per item.\n\n**Record in AssureSwarm** — Create/update one Issue per finding (`coach-item-create` — `severity`, `source`, `issue_owner`, `target_remediation_date`; on verified closure `actual_remediation_date` + `verified_date`) and link each to the anchor Control (`coach-items-link`). Record each risk acceptance as an `issue_type: policy_exception` Issue (`exception_approver`, `exception_expiry_date`) linked to the anchor Control, with `treatment: accept` on the associated Risk (`residual_rating`, `risk_owner`) linked to its source Issue. Attach the re-scan evidence and the remediation-and-exceptions register as step documents with `coach-document-upload`.\n\n**Exit criteria** — Every fixed item has passing re-scan evidence; every accepted item has a signed, dated risk acceptance from an owner authorised to accept it; no item remains open and untracked; the application-security lead has verified the register before the release is packaged.","label":"Drive remediation and risk exceptions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"drive-remediation-and-risk-exceptions"},{"data":{"decisionField":"portfolio_maintenance_disposition","description":"Review patch/vulnerability SLA evidence and unsupported-software replacements and classify portfolio health.","formData":{"fields":[{"key":"portfolio_maintenance_disposition","label":"Portfolio Maintenance Disposition","options":[{"label":"On track, within tolerance","value":"on_track"},{"label":"Escalation required","value":"escalation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Review patch/vulnerability SLA evidence and unsupported-software replacements and classify portfolio health.\n\n**Inputs**\n- The quarterly checkpoint confirmed on the `quarterly_checkpoint` branch of the trigger decision.\n- The production vulnerability backlog — open Issue items (`source: vulnerability_scan`, `severity`) — and the patch-status register (a CSV/register uploaded on this step; no native type) for every in-scope system.\n- The software and component inventory with vendor end-of-life dates — in-scope systems as Process items where they exist, the inventory itself uploaded as a register on this step (no native System/Asset type).\n- The organisation's risk-based remediation timeframes by severity tier (the SLA definitions) — a Policy item (`policy_type: standard` or `procedure`) where one exists, otherwise the SLA definition document uploaded on this step.\n\n**Procedure**\n_This checkpoint absorbs “Operate post-release maintenance”. 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. Operate post-release maintenance: Produce a reviewed portfolio-maintenance summary showing vulnerabilities remediated and patches applied within risk-based timeframes and unsupported or no-longer-justified software queued for replacement, across the whole portfolio rather than a single release.\n2. Pull the production vulnerability backlog (open Issue items) and patch status for every in-scope system with `coach-query-data`, and classify each open item against its risk-based remediation timeframe by severity tier (e.g. critical/high on the shortest clocks, weighted up for internet-exposed or regulated systems) — NIST 800-53 SI-2 and CSF 2.0 PR.PS-02.\n3. Identify items past their remediation timeframe and compile the breach list with each item's age beyond SLA and its owner.\n4. Pull the software and component inventory, identify software that is unsupported (past vendor end-of-life) or no longer justified by risk, and create/update a replacement-queue Issue for each with `coach-item-create` (`issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date` = the replacement date), linking each to the affected Process item where one exists, otherwise to the anchor Control, with `coach-items-link` (no native System/Asset type).\n5. Confirm patch application evidence exists for items marked patched (a patched assertion without a version/build confirmation is not closed), and note any patch that introduced a regression needing follow-up.\n6. Draft the portfolio-maintenance summary covering SLA adherence by tier, the breach list, and replacement-queue status.\n7. Classify portfolio maintenance disposition: Resolve whether the vulnerability, patch, and unsupported-software portfolio operated within tolerance this cycle or carries breaches needing tracked, escalated corrective action. Owned by the application-security lead.\n\n**Decision criteria**\n1. Compute portfolio metrics from the maintenance summary with `coach-query-data`: remediation SLA adherence by severity tier, the count and age of breached items, and the count and age of overdue replacement-queue items.\n2. Build a portfolio-health dashboard with `coach-dashboard-create` showing each metric against its threshold and the trend against prior cycles.\n3. Pick `on_track` only when every metric is within tolerance — no SLA breach, no overdue replacement-queue item — for the cycle to close directly.\n4. Pick `escalation_required` when any remediation SLA is breached or any replacement-queue item is overdue; these must become owned corrective actions before closure. A single breach on an internet-exposed or regulated system is sufficient on its own to require escalation.\n\n**Record in AssureSwarm**\nCreate/update a replacement-queue Issue per unsupported/unjustified component (`coach-item-create` — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`) and link each to its affected Process item where one exists, otherwise to the anchor Control (`coach-items-link`). Attach the portfolio-maintenance summary (XLSX/PDF) as a step document with `coach-document-upload`.\nSubmit the `portfolio_maintenance_disposition` SELECT (`on_track` or `escalation_required`). Record the metrics and the breaches driving the call in the step result, and the deciding owner in the step's approver record. Attach the portfolio disposition summary and the dashboard reference with `coach-document-upload`.\n\n**Exit criteria**\n- The full vulnerability and patch backlog is triaged against risk-based timeframes; the breach list is complete with ages and owners; every unsupported or unjustified component is queued for replacement with an owner; the application-security lead has confirmed the portfolio is current.\n- The metrics and dashboard are produced; the SELECT is submitted with a written rationale and named owner; the non-selected branch is prunable.","kind":"decision","label":"Classify portfolio maintenance disposition","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"classify-portfolio-maintenance-disposition"},{"data":{"description":"Agent converts each portfolio breach into an owned corrective action; human confirms every breach is owned, dated, and escalated where required","instructions":"**Objective** — Convert every SLA breach and overdue replacement-queue item surfaced at the portfolio review into an owned, tracked corrective action, so nothing degrades the secure-development and maintenance capability unaddressed.\n\n**Inputs**\n- The portfolio disposition summary and dashboard from the portfolio-maintenance decision, reached on its `escalation_required` branch.\n- The breach list with ages and owners and the overdue replacement-queue items.\n- The register of accountable owners for internet-exposed and regulated systems (for escalation routing).\n\n**Procedure**\n1. Parse the portfolio disposition summary to list each breach with its root cause and the metric that surfaced it.\n2. Create a corrective-action Issue for each breach with `coach-item-create` (`issue_type: finding` or `deficiency`, `root_cause`, `issue_owner`, `target_remediation_date`, plus any interim mitigation), and link each to the anchor Control — or to the driving backlog Issue where one exists — with `coach-items-link`.\n3. Raise capability-level improvement Issues for systemic gaps — a chronically under-resourced remediation function, a stale test-plan template, an inventory that misses end-of-life dates — rather than only patching the individual breach.\n4. Escalate any breach tied to an internet-exposed or regulated system to its accountable owner, recording the escalation and its acknowledgement in `management_response` on the corrective-action Issue.\n5. Compile the corrective-action register showing owner, due date, and escalation status per item.\n\n**Record in AssureSwarm** — Create one corrective-action Issue per breach (`coach-item-create` — `issue_type: finding`/`deficiency`, `root_cause`, `issue_owner`, `target_remediation_date`; escalation acknowledgement in `management_response`) and link each to the anchor Control, or to the driving backlog Issue where one exists (`coach-items-link`). Attach the corrective-action register (XLSX/PDF) as a step document with `coach-document-upload`.\n\n**Exit criteria** — Every breach has a named owner and due date; systemic gaps have capability-level improvement items; escalations for exposed/regulated systems are routed and acknowledged; the application-security lead has confirmed nothing is left untracked before closure.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"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 reviewed release security disposition record (reached here either directly on `clear_to_proceed` or after remediation on the `requires_action` path).\n- The secure-and-privacy-by-design checklist, the test-plan findings register with evidence, and the runtime-hardening checklist.\n- The remediation-and-exceptions register, where remediation was run.\n- The downstream consumer is the separate SDLC gate review workflow, which owns the final production go/no-go; this step produces the package it relies on and does not itself issue that decision.\n- For a release cycle: the packaged release security evidence and its handoff record.\n- For a quarterly cycle: the portfolio-maintenance summary, the disposition record, and the corrective-action register (where escalation was required).\n- The designated evidence repository and its retention controls; the release calendar / quarterly schedule for the next cycle.\n\n**Procedure**\n_After the preceding authorized decision, run the packaging, linkage, archival and carry-forward procedure automatically. No additional human approval is required._\n1. Package release security evidence (release-triggered runs only; skip this entire release-package phase on quarterly runs): Assemble a complete, traceable evidence package for this release's secure-development and security-testing work and hand it to the separate SDLC gate review workflow, so that workflow can verify the release without re-performing the work. This concludes the release-triggered track.\n2. Assemble the by-design checklist, the findings register with its retained evidence, the runtime-hardening checklist, the disposition record, and the remediation-and-exceptions register (where produced), linking each to the anchor Control with `coach-document-link`.\n3. Build an evidence index mapping every defined acceptance criterion to the artifact that satisfies it, so a gate reviewer can trace each conclusion to its source without re-performing the analysis.\n4. Verify internal consistency: the disposition record's conclusion matches the state of the findings register and remediation register (nothing marked cleared that is still open); flag and resolve any mismatch before handoff.\n5. Record the SDLC-gate-review handoff with `coach-item-create`, referencing this release's evidence index, and link it to the anchor Control with `coach-items-link`. There is no native handoff/Release item type, so this is a tracking record that points the gate reviewer at the package — the substantive handoff is the document package itself.\n6. Attach the packaged evidence and its index as step documents with `coach-document-upload`.\n7. Close and archive: Close the operating cycle, preserve the evidence trail for the required retention period, and seed the next cycle, so the record is immutable and retrievable and nothing open is dropped. This is the single sink for both the release and the quarterly tracks.\n8. Export the full operating record for whichever track ran with `coach-workflow-export` — the workflow instance on the anchor Control — and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n9. Create carry-forward Issues with `coach-item-create` (`issue_owner`, `target_remediation_date`) for open remediation items, risk-acceptance review dates, and open replacement-queue items, and link each to the anchor Control with `coach-items-link`, so they arrive as explicit existing-item inputs to the next cycle's trigger classification.\n10. Update the control execution log with the cycle result and key metrics (disposition reached, findings closed vs accepted, SLA adherence), and confirm the next release or quarterly review is scheduled.\n11. Verify the archived record is retrievable from the repository and immutable under its retention controls before completing automatic archival.\n\n**Record in AssureSwarm**\nLink each evidence artifact to the anchor Control (`coach-document-link`). The substantive handoff is the evidence package + acceptance-criteria index as step documents (`coach-document-upload`) that the SDLC gate review workflow's first step consumes. There is no native handoff/Release item type, so the `coach-item-create` handoff record is a tracking item linked to the anchor Control (`coach-items-link`) that references that package — not a substantive artifact of its own.\nExport and archive the operating record — the workflow instance on the anchor Control — with `coach-workflow-export`. Create carry-forward Issues (`coach-item-create` — `issue_owner`, `target_remediation_date`) and link each to the anchor Control (`coach-items-link`). Attach the closure record as a step document with `coach-document-upload`.\n\n**Exit criteria**\n- The package is complete and internally consistent; the evidence index maps every acceptance criterion to an artifact; the handoff item to the SDLC gate review is recorded and linked; the release-triggered package has been assembled from the preceding authorized disposition.\n- The archived record is confirmed immutable and retrievable; every open item has a tracked owner as a carry-forward; the control execution log is updated and the next cycle is scheduled; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link","coach-workflow-export"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-secure-development-release-security-gate"}