{"description":"Quarterly outsourced- and critical-component development oversight, run as a recurring operating cycle against the EXISTING Control item for outsourced/critical-component secure development (UC-SDLC-10 / UC-SDLC-11; domains secure_development_sdlc + third_party_supply_chain_risk; NIST 800-53 SA-20/SA-21/SA-23, ISO 27001 A.8.30) — the workflow enriches that Control, it never creates a duplicate. Each quarter it inventories the active outsourced/third-party development engagements (enriching the Vendor register), verifies contract secure-development / IP-ownership / audit-rights terms, traces deliverables to requirements with security-test evidence on file, screens critical-system developers before access, refreshes the register of components critical to security or mission, and re-tests the specialized-development rationale and assurance evidence. It consumes the prior cycle's carry-forward Issue items (open corrective actions, contract renewals, components due for rationale review) and the archived prior workflow instance's registers; every gap it surfaces becomes an Issue linked to the anchor Control, giving one queryable corrective-action population. In scope: active outsourced and third-party development engagements and the register of components critical to security or mission; out of scope: internal-only development with no third-party contributor and general procurement risk unrelated to development. Self-terminating: no downstream workflow consumes this cycle's output — corrective actions are tracked to closure within this workflow and carried forward to the next quarter.","edges":[{"id":"e-review-deliverables-and-test-evidence-screen-critical-system-developers","source":"review-deliverables-and-test-evidence","target":"screen-critical-system-developers"},{"id":"e-screen-critical-system-developers-log-corrective-actions","label":"Clear to grant","source":"screen-critical-system-developers","target":"log-corrective-actions","whenValue":"clear_to_grant"},{"id":"e-screen-critical-system-developers-resolve-access-conditions","label":"Access blocked","source":"screen-critical-system-developers","target":"resolve-access-conditions","whenValue":"access_blocked"},{"id":"e-resolve-access-conditions-log-corrective-actions","source":"resolve-access-conditions","target":"log-corrective-actions"},{"id":"e-evaluate-specialized-development-rationale-log-corrective-actions","label":"Current","source":"evaluate-specialized-development-rationale","target":"log-corrective-actions","whenValue":"rationale_current"},{"id":"e-evaluate-specialized-development-rationale-update-rationale-and-evidence","label":"Gap identified","source":"evaluate-specialized-development-rationale","target":"update-rationale-and-evidence","whenValue":"rationale_gap"},{"id":"e-update-rationale-and-evidence-log-corrective-actions","source":"update-rationale-and-evidence","target":"log-corrective-actions"},{"id":"e-review-deliverables-and-test-evidence-log-corrective-actions","source":"review-deliverables-and-test-evidence","target":"log-corrective-actions"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-SDLC-10","UC-SDLC-11"],"department":"procurement","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-outsourced-critical-component-development-oversight","contentDigest":"sha256:f420cdf1d70a9a9222512c83f000ea88e6d3b4be6315825595c9cbb43247ea6b","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:f420cdf1d70a9a9222512c83f000ea88e6d3b4be6315825595c9cbb43247ea6b","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-outsourced-critical-component-development-oversight"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-outsourced-critical-component-development-oversight","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001"],"teams":["procurement","it"]},"name":"Outsourced & Critical-Component Development Oversight","nodes":[{"data":{"description":"Accept the complete access-reconciled engagement population and judge contract terms and requirement-traced supplier deliverables, directing amendment, rework or documented risk acceptance.","formData":{"fields":[{"key":"secure_development_standard","label":"Secure-coding standard or secure-development framework applied","required":false,"type":"text"},{"key":"subcontractor_contributors","label":"Subcontractors or other parties that contributed code, and what they contributed (enter none if there were none)","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Accept the complete access-reconciled engagement population and judge contract terms and requirement-traced supplier deliverables, directing amendment, rework or documented risk acceptance.\n\n**Inputs**\n- The anchor Control item (UC-SDLC-10 / UC-SDLC-11) — this quarterly instance runs against it; its `framework` (nist-800-53, iso-27001) and description bound the scope. Enrich this Control; do not create a duplicate.\n- Vendor management system, procurement register, and statement-of-work (SOW) repository (external systems) — every engagement where a third party writes or maintains code on company systems; copies pulled in as uploads on this step.\n- Source-code repository access logs and the active-contributor roster (external repo / IAM) — extract attached as an upload on this step, to catch vendor developers with live access but no registered engagement.\n- The prior-cycle engagement inventory — the XLSX document on last cycle's archived instance of this step — for carry-forward and change detection.\n- System-criticality classifications from the asset/architecture inventory (external CMDB), to tag each engagement's blast radius.\n- Open carry-forward Issue items created when last cycle closed out its corrective actions, linked to the anchor Control (contract renewals, engagements flagged for follow-up).\n- The confirmed engagement inventory from \"Inventory active outsourced engagements\" — the Vendor items and the inventory document, each engagement with its contract reference.\n- Executed contracts, SOWs, and any side letters per engagement — pulled in as uploads (PBC/external) on this step.\n- The organization's standard secure-development / IP / audit clause library, if one exists, as the benchmark.\n- The confirmed engagement inventory from \"Inventory active outsourced engagements\" — the Vendor items and inventory document, which engagements and deliverables are in scope.\n- Requirements repository and the delivery/release tracker (external systems).\n- Security-testing evidence stores (external): SAST, DAST, dependency and container scans, and penetration-test results — brought in as uploads (PBC/external) on this step and through the supplier attestation form on this step.\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**\n_This checkpoint absorbs “Inventory active outsourced engagements”, “Verify contract security, IP, and audit terms”. 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. Inventory active outsourced engagements: Pull every active engagement from the vendor system, procurement register, and SOW repository. For each, capture: vendor, contract reference, engagement start/end dates, systems and components touched, and each touched system's criticality classification (critical-to-security, critical-to-mission, or standard).\n2. Reconcile the list against repository access logs and the active-contributor roster. Any vendor developer with live commit or environment access whose engagement is absent from the register is a population gap — add the engagement or flag it for confirmation.\n3. Flag engagements with no matching executed contract on file; these are contract-coverage exceptions the contract-terms review must resolve.\n4. Enrich or create the Vendor item for each engagement's third party and link it to the anchor Control; capture engagement-specific attributes that have no Vendor field (contract reference, SOW, specific systems touched) as rows in the inventory document.\n5. Draft the engagement inventory summarizing engagement count, criticality mix, and any gaps.\n6. Verify contract security, IP, and audit terms: For each engagement in the inventory, pull the executed contract, SOW, and any side letters.\n7. Test each contract against three clause classes and mark each present, weak, or missing:\n   - Secure-development: secure-coding standards, vulnerability handling and disclosure SLAs, and security-testing obligations.\n   - IP ownership: work-product assignment to the company, license terms, and disclosure of third-party and open-source components.\n   - Audit rights: the company's right to inspect the vendor's development practices, evidence, and subcontractors.\n8. For every missing or weak clause, draft the specific contract-amendment or side-letter language required, create a remediation Issue, and link it to the engagement's Vendor and the anchor Control.\n9. Assemble a contract-terms compliance matrix (engagement x clause class x status), noting which gaps require legal and procurement engagement before the engagement may continue.\n10. Review deliverables and test evidence: For each engagement, pull the deliverables accepted this quarter and the requirements they were built against.\n11. For an engagement with unresolved supplier facts, issue only those questions to the eligible supplier contact, naming the deliverables in scope and the return date, requesting only missing facts about the secure-development standard actually applied and subcontractor contributions. Obtain test reports and component/license disclosures as evidence documents, and derive testing coverage and unresolved finding counts from those records.\n12. Build a requirement-to-deliverable trace and flag: deliverables accepted with no traceable requirement, requirements with no delivered artifact, and deliverables accepted past a planned milestone with no documented waiver.\n13. Collect the security-testing evidence per deliverable — the supplier's returned reports plus what the internal evidence stores hold — and link each artifact to its deliverable. Flag deliverables with no evidence on file, any with unresolved critical or high findings, any supplier that did not return its attestation, and any case where the dated test reports and delivery/issue records disagree on unresolved findings.\n14. Draft the deliverable-and-evidence review summary listing traced deliverables, coverage gaps, and open critical or high findings.\n15. Engineering Director: decide rework versus documented risk acceptance for each flag, judging whether the evidence on file is sufficient for the deliverable's criticality.\n\n**Record in AssureSwarm**\n- Enrich the Vendor register: create or update a Vendor item per outsourced-development third party (coach-item-create / coach-item-update) — `category` (professional_services or managed_services), `tier` (by touched-system criticality), `business_owner`, `risk_owner`, `monitoring_status`, `contract_end_date` — and link each Vendor to the anchor Control (coach-items-link). Engagement-specific attributes with no Vendor field stay as rows in the inventory document.\n- Attach the engagement inventory (XLSX) as a document on this step (coach-document-upload) — engagement count, criticality mix, and gaps.\n- Create an Issue for any engagement with no executed contract on file (coach-item-create — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`), linked to its Vendor and the anchor Control (coach-items-link).\n- Source registers and access logs via coach-query-data.\n- Attach the contract-terms compliance matrix (engagement x clause class x status) as a document on this step (coach-document-upload), carrying the drafted amendment/side-letter language.\n- Create an Issue per missing or weak clause (coach-item-create — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`, `recommendation` carrying the drafted clause language) and link it to the engagement's Vendor and the anchor Control (coach-items-link).\n- Source contracts and SOWs via coach-query-data (contract copies uploaded to this step as PBC).\n- The supplier engineering lead’s form supplies only the missing secure-development standard actually applied and subcontractor contributions. The delivery tracker supplies scope; test reports and component/license disclosures are evidence documents, from which the executor derives coverage and unresolved findings.\n- Bring each security-testing evidence artifact in as an upload on this step and link it to its deliverable row (coach-document-link).\n- Attach the deliverable-and-evidence review summary as a document on this step (coach-document-upload) — the requirement-to-deliverable trace, coverage gaps, and open critical/high findings.\n- Rework flags and documented risk acceptances feed the consolidated corrective-action register at \"Log corrective actions\": a required rework becomes an Issue (`issue_type: deficiency`); a documented risk acceptance becomes an Issue (`issue_type: policy_exception`, `exception_approver`, `exception_expiry_date`), with `treatment: accept` set on any linked Risk.\n- Source deliverables and requirements via coach-query-data.\n\n**Exit criteria**\n- Every active third-party development engagement is represented by a Vendor item linked to the anchor Control; access-log reconciliation is documented with zero unexplained live-access developers; engagements lacking a contract are raised as Issues; the Engineering Director has confirmed the population is complete.\n- Every engagement has a scored row in the matrix across all three clause classes; each missing or weak clause has drafted language and an owned remediation item; the Engineering Director has approved the matrix and flagged which clauses must be amended before continuation.\n- Every accepted deliverable is traced to a requirement or flagged; each carries linked testing evidence or an evidence-gap flag; every in-scope supplier has returned its attestation or its non-response is itself flagged; no unresolved critical or high finding is left without a disposition; the Engineering Director has decided rework versus documented risk acceptance for each flag.\n\n**Form recipient** — The outsourced development supplier’s engineering lead supplies only secure-development standard actually applied; undisclosed subcontractor contributions only when this gate permits the assigned form. The workflow executor records their own analysis in the step result.","label":"Review deliverables and test evidence","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"review-deliverables-and-test-evidence"},{"data":{"decisionField":"developer_access_disposition","description":"Agent compiles the vendor developer roster against defined screening criteria for critical-system access; human decides which developers are clear to grant access","formData":{"fields":[{"key":"developer_access_disposition","label":"Developer Access Disposition","options":[{"label":"Clear to grant access","value":"clear_to_grant"},{"label":"Access blocked or conditional","value":"access_blocked"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether every outsourced developer requesting or holding development-environment access to a critical system is cleared for that access, or whether any must be held or removed. Owned by the Engineering Director (secure development), per SA-21's developer-screening requirement.\n\nBefore the decision, the agent assembles the evidence:\n1. Query the access-request queue and current development-environment entitlements to build the roster of vendor developers requesting new access or already holding access to systems classified critical to security or mission.\n2. Run each developer against the defined screening criteria: identity verification; background-check status and currency; executed NDA and confidentiality terms; completed secure-development and data-handling training; and documented need-to-know tied to a registered engagement.\n3. Score each developer fully screened, partially screened (named gap), or unscreened, and attach the screening roster with a recommended disposition and the specific criterion driving any hold.\n\n**Decision criteria**\n- **clear_to_grant** (Clear to grant access) — every in-scope developer is fully screened: identity verified, background check current, NDA executed, required training complete, and need-to-know documented. No open screening gap remains.\n- **access_blocked** (Access blocked or conditional) — any in-scope developer has an unresolved screening gap (missing or expired background check, unsigned NDA, incomplete training, or unjustified need-to-know), or must be held or removed. Selecting this routes to the access-conditions remediation step.\n\n**Record in AssureSwarm** — Submit this step's decision form: the `developer_access_disposition` SELECT, the driving criterion and evidence references in the step result, and the approver in the step's approver record. Source the screening roster via coach-query-data and attach it as a document on this step via coach-document-upload.\n\n**Exit criteria** — The screening roster is attached, the SELECT is submitted with a rationale naming the specific criterion behind any hold, and the unused branch is prunable.","kind":"decision","label":"Screen critical-system developers","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"screen-critical-system-developers"},{"data":{"description":"Agent logs each unresolved screening gap and tracks remediation or removal; human verifies conditions are resolved before access continues","instructions":"**Objective** — Close out every developer-screening gap flagged as access-blocked so no unscreened developer retains a live path into a critical system, before this cycle's corrective actions are consolidated.\n\n**Inputs**\n- The screening roster and the access-blocked disposition from \"Screen critical-system developers\" — each held developer and the specific gap.\n- The vendor manager contact per engagement (the engagement's Vendor item), for suspension or removal coordination.\n- The defined grace period for gap closure and the closure-evidence standard (completed check, signed NDA, training record).\n\n**Procedure**\n1. Create a tracked Issue per held developer recording the specific gap, the required remediation, owner, and due date; link it to the developer's Vendor and the anchor Control. (No Person/Developer item type exists — the held developer lives as this Issue plus a roster row.)\n2. Where a gap cannot close within the grace period, coordinate suspension or removal of the developer's development-environment access with the vendor manager and record the access change with a timestamp.\n3. Track remediation submissions and verify each closure-evidence artifact (completed check, signed NDA, training-completion record) against its open item.\n4. Draft the access-conditions closure register showing each held developer as remediated-with-verified-evidence or access-removed — nothing left ambiguous.\n\n**Record in AssureSwarm**\n- Create and track a remediation Issue per held developer (coach-item-create — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `remediation_plan`, `target_remediation_date`; set `actual_remediation_date` and `verified_date` on closure) linked to the developer's Vendor and the anchor Control (coach-items-link).\n- Scan for remediation submissions (coach-workflow-scan) and attach the access-conditions closure register as a document on this step (coach-document-upload).\n\n**Exit criteria** — Every held or conditional developer is either fully remediated with verified evidence or has had access suspended or removed; no developer remains in an ambiguous state; the Engineering Director has confirmed closure.","label":"Resolve access conditions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload"]}},"id":"resolve-access-conditions"},{"data":{"decisionField":"specialized_development_disposition","description":"Agent refreshes the register of components critical to security or mission and compiles each specialized-development component's rationale and assurance evidence; human decides whether the rationale and evidence remain current","formData":{"fields":[{"key":"specialized_development_disposition","label":"Specialized Development Disposition","options":[{"label":"Rationale and evidence current","value":"rationale_current"},{"label":"Rationale or evidence gap","value":"rationale_gap"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Refresh the register of components critical to security or mission, then decide whether every registered component built or maintained through customized or specialized development (because commercial items could not meet requirements) still carries current rationale and assurance evidence, or whether any carries a gap. Owned by the Engineering Director, per SA-20 and SA-23.\n\n**Inputs**\n- Asset inventory and the architecture/system-criticality register (external CMDB) — extract attached as an upload on this step.\n- The prior-cycle critical-component register — the document on last cycle's archived instance of this step — for change detection.\n- Data-sensitivity classifications and exposure/attack-surface data.\n- Each specialized-development component's recorded rationale and assurance evidence: commercial-market assessment, threat model, supply-chain risk assessment.\n- Note: this step is a parallel entry — it depends only on the asset and architecture inventories and the recorded rationales, not on any engagement or developer review, so it runs concurrently with the outsourced-engagement thread.\n\n**Procedure**\n_Items 1–7 are agent-run (items 1–4 folded from the former \"Maintain critical-component register\" step); the human moment is the disposition call in item 8._\n1. Compile candidate critical components: those whose failure or compromise would materially affect security or mission, drawing on criticality classifications, data sensitivity, and exposure.\n2. Compare candidates against the existing register and flag: newly critical components not yet registered; components whose criticality has changed; and previously critical components now retired or downgraded.\n3. Update the register document — add rows for newly critical components (owning system, owner, criticality rationale) and mark removals and reclassifications; where a newly critical component lacks current rationale or assurance evidence, raise a tracked Issue linked to the anchor Control.\n4. Attach the refreshed register together with a change log against the prior cycle.\n5. Query the refreshed register for every critical component flagged as using specialized or custom development (reimplementation, a custom variant, or context-specific augmentation of a commercial item), and pull each one's recorded rationale and assurance evidence (commercial-market assessment, threat model, supply-chain risk assessment).\n6. Test whether each rationale's commercial-market assessment is still current, whether a viable commercial alternative has since emerged, and whether the assurance evidence reflects the component's current version and configuration.\n7. Score each component current-and-sufficient or gap, and attach the rationale-and-evidence review summary.\n8. Resolve any disputed criticality call, pick the disposition against the criteria below, and submit the SELECT.\n\n**Decision criteria**\n- **rationale_current** (Rationale and evidence current) — every specialized-development component has a documented rationale, a current commercial-market assessment showing commercial items still cannot meet requirements, and assurance evidence matching the component's current version and configuration.\n- **rationale_gap** (Rationale or evidence gap) — any component has no documented rationale, a stale market assessment, missing or outdated assurance evidence, or a newly viable commercial alternative warranting re-evaluation. Selecting this routes to the rationale-and-evidence update step.\n\n**Record in AssureSwarm**\n- Submit this step's decision form: the `specialized_development_disposition` SELECT, the justification and evidence references in the step result, and the approver in the step's approver record.\n- Attach the refreshed register of components critical to security or mission with its change log against the prior cycle (XLSX), and the rationale-and-evidence review summary, as documents on this step (coach-document-upload). No Component/Asset item type exists — components live as register rows, not linkable items, so the register is a step document rather than typed items.\n- For any component that newly crosses the critical threshold without current rationale or assurance evidence, raise a tracked Issue (coach-item-create — `issue_type: deficiency`, `source: self_assessment`) linked to the anchor Control (coach-items-link).\n- Source the asset and architecture inventories via coach-query-data.\n\n**Exit criteria** — The register reflects current additions, removals, and reclassifications, every newly critical component carries an owning system, owner, and criticality rationale in its register row, and disputed criticality calls are resolved; the review summary is attached; the SELECT is submitted with a rationale; the unused branch is prunable.","kind":"decision","label":"Evaluate specialized-development rationale","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"evaluate-specialized-development-rationale"},{"data":{"description":"Agent drafts refreshed rationale and assurance evidence for each flagged component; human confirms documentation is current before closure","instructions":"**Objective** — Bring every flagged critical component's specialized-development rationale and assurance evidence up to date, or record an owned decision to re-evaluate the commercial alternative, before corrective actions are consolidated.\n\n**Inputs**\n- The rationale-and-evidence review summary and the rationale-gap flags from \"Evaluate specialized-development rationale\".\n- Current commercial-market inputs, threat-model inputs, and supply-chain risk data.\n- Architecture and engineering leadership as the routing target for any commercial-alternative re-evaluation.\n\n**Procedure**\n1. For each flagged component, draft the updated rationale stating why commercial items still cannot meet requirements — or, where a viable alternative has emerged, draft the recommendation to re-evaluate migrating to it, using the current market and threat-model inputs.\n2. Refresh the assurance-evidence package per component (updated threat model, supply-chain risk assessment, current-version test or assessment results). For any evidence that cannot be refreshed this cycle, create a tracked item linked to the component.\n3. Where re-evaluation is recommended, create a routing Issue carrying the commercial-alternative assessment (owner = architecture or engineering leadership) and link it to the anchor Control; name the flagged component in the Issue and its register row.\n4. Attach the updated rationale-and-evidence package for every flagged component.\n\n**Record in AssureSwarm**\n- Attach the updated rationale-and-evidence package per flagged component (refreshed threat model, supply-chain risk assessment, current-version results, market assessment) as documents on this step (coach-document-upload).\n- For any evidence that cannot be refreshed this cycle, create a tracked Issue (coach-item-create — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`) linked to the anchor Control (coach-items-link). No Component item type exists — the flagged component is named in the Issue and its register row.\n- Where a viable commercial alternative has emerged, create a routing Issue (coach-item-create — `recommendation` carrying the re-evaluation, `issue_owner` = architecture/engineering leadership) linked to the anchor Control (coach-items-link).\n- Source current market and threat-model inputs via coach-query-data.\n\n**Exit criteria** — Every flagged component now carries a current, documented rationale and assurance evidence, or an owned, dated item tracking the outstanding refresh or re-evaluation; the Engineering Director has confirmed before closure.","label":"Update rationale and evidence","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"update-rationale-and-evidence"},{"data":{"description":"Agent converts every gap from contract terms, deliverable evidence, developer screening, and component rationale into an owned corrective action and archives the signed oversight record; human declares the cycle closed with nothing left untracked","instructions":"**Objective** — Consolidate every gap surfaced this cycle — across contract terms, deliverable evidence, developer screening, and specialized-development documentation — into one owned, tracked corrective-action register, and close the quarterly oversight cycle on that record with nothing left untracked.\n\n**Inputs**\n- Contract-amendment items from \"Verify contract security, IP, and audit terms\".\n- Deliverable rework / risk-acceptance items and open critical or high findings from \"Review deliverables and test evidence\".\n- Developer-screening remediations from \"Screen critical-system developers\" and \"Resolve access conditions\".\n- Rationale-or-evidence refresh items from \"Evaluate specialized-development rationale\" and \"Update rationale and evidence\".\n- The designated evidence repository and its retention-control configuration; contract-renewal dates and each critical component's next rationale-review due date.\n- Note: this is a join — it waits for all upstream review threads (both the outsourced-engagement thread and the critical-component thread) to reach it.\n\n**Procedure**\n_Items 5–8 close the workflow (folded from the former \"Close and archive\" step); the Engineering Director's sign-off recorded here is the closure._\n1. Compile every open item raised this cycle across the four threads.\n2. Create a corrective-action Issue for any gap not already tracked, recording root cause, owner, due date, and interim mitigation; link each to the anchor Control, and to the source Vendor where the gap is a vendor-engagement gap.\n3. Escalate any gap carrying contractual, regulatory, or supply-chain exposure to the accountable executive owner; flag systemic issues (a vendor with repeated contract-term gaps, or a chronically under-evidenced component) for a program-level response.\n4. Assemble the consolidated corrective-action register and confirm every gap across all four threads carries a named owner and due date.\n5. Export the full operating record and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n6. Create carry-forward Issue items for open corrective actions, upcoming contract renewals or amendments, and components due for their next rationale review; link each to the anchor Control so it arrives as an explicit input to the next cycle.\n7. Update the control execution log with the cycle result, the engagement and component counts reviewed, and key metrics; confirm the next quarterly review is scheduled.\n8. Attach the closure record and record the Engineering Director's declaration that nothing is left untracked — that sign-off is the cycle's closure, not a separate step.\n\n**Record in AssureSwarm**\n- Create a corrective-action Issue per untracked gap (coach-item-create — `issue_type: deficiency`, or `policy_exception` for a documented risk acceptance; `source: self_assessment`; `issue_owner`; `target_remediation_date`; `root_cause`; `remediation_plan`) and link each to the anchor Control, plus the source Vendor for a vendor-engagement gap (coach-items-link).\n- Create carry-forward Issue items (coach-item-create — `issue_type: deficiency`/`observation`, `issue_owner`, `target_remediation_date`) for open corrective actions, upcoming contract renewals/amendments, and components due for next rationale review, each linked to the anchor Control (coach-items-link) so the next quarterly instance finds them.\n- Export the full operating record (coach-workflow-export) — the archived workflow instance is the cycle's audit-trail record — and archive it in the evidence repository under retention controls.\n- Attach the consolidated corrective-action register (XLSX) and the closure record as documents on this step (coach-document-upload); compile open Issues via coach-query-data.\n\n**Exit criteria** — Every gap across all four review threads has a named owner and due date and escalations are routed; the archived record is immutable and retrievable; carry-forward items are created and linked to the anchor Control and the next quarterly review is scheduled; the Engineering Director's recorded declaration that nothing remains open without a tracked owner closes the cycle.","label":"Log corrective actions","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-workflow-export"]}},"id":"log-corrective-actions"}],"sourceTemplateId":"workflow-library:controls-outsourced-critical-component-development-oversight"}