{"description":"Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.","edges":[{"id":"e-inventory-and-tier-vendors-review-soc-and-cuecs","source":"inventory-and-tier-vendors","target":"review-soc-and-cuecs"},{"id":"e-inventory-and-tier-vendors-approve-or-revise-package","source":"inventory-and-tier-vendors","target":"approve-or-revise-package"},{"id":"e-review-soc-and-cuecs-embed-contract-protections","source":"review-soc-and-cuecs","target":"embed-contract-protections"},{"id":"e-embed-contract-protections-classify-disposition","source":"embed-contract-protections","target":"classify-disposition"},{"id":"e-classify-disposition-approve-or-revise-package","label":"No reportable gap","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-create-action-plan","label":"Remediate","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-TPRM-01","UC-TPRM-02","UC-TPRM-03","UC-TPRM-04","UC-ASSET-05","UC-ACCESS-21","UC-DATA-16","UC-HR-05","UC-LOG-09","UC-SDLC-10","UC-TPRM-05","UC-TPRM-06","UC-TPRM-07","UC-TPRM-09","UC-TPRM-08"],"department":"procurement","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-third-party-vendor-risk-lifecycle","contentDigest":"sha256:96f9e2a2333ab1b869a093e9ffa77920c2a18e3719304346f9daebe8bc6ce5fa","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:96f9e2a2333ab1b869a093e9ffa77920c2a18e3719304346f9daebe8bc6ce5fa","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-third-party-vendor-risk-lifecycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-third-party-vendor-risk-lifecycle","source":"coworkcanvas-gallery","standards":["nist-800-53","soc2"],"teams":["procurement"]},"name":"Third-Party Vendor Risk Lifecycle","nodes":[{"data":{"description":"Lock the engagement plan and build a complete, risk-tiered inventory of the in-scope third parties","instructions":"**Objective** — Establish the scoped engagement plan and a complete, risk-tiered inventory of the third parties in scope, so every downstream assessment activity works from an owned, prioritized vendor population.\n\n**Inputs**\n- The vendor/supplier master reconciled from procurement, accounts-payable vendor lists, and the contract repository, represented as AssureSwarm Vendor (third-party) items with legal entity, spend, business owner, data classification handled, and system access.\n- Policy inputs: the third-party risk policy and framework source (NIST SP 800-53 SA and SR control families, SOC 2 vendor-management criteria, IIA 2024 guidance), the tiering rubric, and risk-appetite thresholds.\n- Prior assessments, issue history, and KRIs for existing vendors.\n- This workflow is self-initiating; it consumes no upstream workflow package.\n\n**Procedure**\n1. Lock the executable workplan: confirm why the lifecycle is running now (new-vendor onboarding, periodic reassessment, or a trigger event), name the assessment owner and the approver, and set target dates, evidence requirements, and review expectations. Record any explicit exclusion with the accountable owner's concurrence and a monitoring trigger.\n2. Assemble the vendor population: reconcile the procurement, AP, and contract sources; dedupe by legal entity; and flag fourth-party and subservice dependencies for later C-SCRM review.\n3. Capture inherent-risk attributes per vendor: data classification handled (PII, PHI, PCI, or none), system access and integration depth, business criticality, annual spend, geography and concentration, and regulatory sensitivity.\n4. Apply the tiering rubric to assign a tier and record the threshold that drove it — for example Tier 1 (critical or high: full assurance plus annual reassessment), Tier 2 (moderate: questionnaire plus SOC review), Tier 3 (low: attestation only).\n5. Assign both a business owner and a risk owner to each in-scope vendor, and set the reassessment cadence by tier.\n6. Produce the scoped, tiered vendor register that seeds every downstream step.\n\n**Record in AssureSwarm**\n- Create or update a Vendor item per third party — category, tier (criticality), data_classification (highest data shared), business_owner, risk_owner, reassessment_cadence — with the remaining inherent-risk attributes (spend, geography, integration depth, regulatory sensitivity) in its description.\n- Attach the workplan (scope, owners, dates, evidence requirements) as a document on this step.\n- Link each Vendor item to the workflow and to the Risk items its exposure maps to.\n\n**Exit criteria** — Vendor population reconciled and deduped; every in-scope vendor carries a tier with a documented threshold, an assigned owner, and a cadence; the workplan is attached and scope and exclusions are signed off.","label":"Inventory and tier vendors","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"inventory-and-tier-vendors"},{"data":{"description":"Analyze each vendor's SOC report to confirm assurance coverage and extract the Complementary User Entity Controls (CUECs) the organization must operate for the vendor's controls to be effective.","formData":{"fields":[{"key":"subprocessors","label":"Subprocessors used to deliver the service to the organization","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nAnalyze each vendor's SOC report to confirm assurance coverage and extract the Complementary User Entity Controls (CUECs) the organization must operate for the vendor's controls to be effective.\n\n**Inputs**\nThe scoped, tiered vendor register produced by the inventory step (Vendor items with tier and owner).\n- The standard questionnaire set (SIG Core, CAIQ, or the internal equivalent) and the evidence checklist by tier.\n- Vendor points of contact for each in-scope third party.\n\nThe received SOC 1 and SOC 2 Type II reports and certificates attached to the Vendor items by the evidence-request step.\n- The systems and processes each vendor supports, and the internal control owners for the relied-upon services.\n\nThe questionnaire responses and evidence attached during the evidence-request step.\n- Each vendor's subservice and fourth-party list from the inventory step.\n- The C-SCRM baseline (NIST SP 800-161 and the SP 800-53 SR control family) and the vendor's tier.\n\n**Procedure**\nFirst reconcile the current inventory, contracts, prior responses, reports, certificates and other supplied evidence against the assessment period. Record supported answers and their sources as request context. Send a form only for unresolved facts, and identify exactly which optional questions need an answer; leave known questions unanswered and do not require their re-entry. If the artifacts answer every question, omit the form assignment and assess those artifacts directly. Use a named supplier contact who holds none of this workflow’s preparation, execution, review or approval assignments. The internal executor resolves evidence conflicts and records the assessment in the step result.\n\n*Agent retrieval, preparation and filing absorb “Request vendor evidence”, “Assess C-SCRM controls”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Request vendor evidence: Issue tier-appropriate evidence and questionnaire requests to each in-scope vendor and track them to receipt, so the analysis steps have complete, current assurance artifacts.\n\n2. Derive the request package per tier: Use the full SIG Core or CAIQ criteria to assess Tier 1 vendors, with a current SOC 1 or SOC 2 Type II report, a penetration-test summary, BCP and DR documentation, a cyber-insurance certificate, and the subservice list; Use the lite assessment criteria and a SOC 2 or ISO 27001 certificate for Tier 2; use an attestation for Tier 3. These are evidence-depth requirements: request only missing answers after artifact review, never a completed questionnaire merely to repeat supported facts.\n3. Build a document request keyed to each vendor, with due dates aligned to the locked workplan. Read existing artifacts first; use the named vendor contact’s form only for genuinely missing provider facts, not known report metadata, internal analysis or sign-off.\n4. Send requests to the vendor contacts and log the send date and expected return date.\n5. Track receipt and chase overdue items. Validate that each artifact is current — the report period covers the assessment window and certificates are unexpired — and complete (a bridge letter alone does not satisfy a stale Type II period).\n6. Record every gap where a vendor cannot produce an artifact; these feed the disposition decision and contract remediation.\n\n7. Assessment scope for Review SOC and CUECs: Analyze each vendor's SOC report to confirm assurance coverage and extract the Complementary User Entity Controls (CUECs) the organization must operate for the vendor's controls to be effective.\n\n8. Confirm report validity: the report type (SOC 1 for financial-reporting reliance versus SOC 2 for security), the Type II period covering the assessment window (obtain a bridge letter for any gap), scope covering the services relied upon, and an unqualified opinion. Record any qualified or adverse opinion or scope exclusion as a finding.\n9. Read the Section 4 test results: list every exception or deviation the service auditor noted, assess its relevance to the services consumed, and rate severity.\n10. Extract the CUECs from the complementary-controls section: map each CUEC to an internal control owner and confirm it is actually operating, not merely assumed. An unowned CUEC is a gap.\n11. Evaluate subservice organizations: note whether the carve-out or inclusive method was used; for carve-outs, confirm coverage of the subservice controls (fourth-party risk).\n12. Summarize residual assurance per vendor: what is covered, the relevant exceptions, unmet CUECs, and any scope gaps.\n\n13. Assessment scope for Assess C-SCRM controls: Assess each vendor's cyber supply-chain risk management (C-SCRM) controls against the baseline, so supply-chain and fourth-party exposures are evaluated alongside the SOC-based assurance.\n\n14. Scope the assessment to tier: Tier 1 vendors get the full SR-family review; lower tiers get a targeted subset proportional to inherent risk.\n15. Evaluate the key control areas: supplier vetting and provenance, software and component integrity (SBOM, code signing), vulnerability and patch SLAs, subcontractor flow-down of security requirements, data location and sovereignty, personnel screening, and incident-notification commitments.\n16. For each area, compare the vendor evidence to the baseline and rate coverage (met, partial, or gap) with the criterion cited.\n17. Map fourth-party concentration and single points of failure; flag any critical dependency that lacks its own assurance.\n18. Consolidate the C-SCRM findings and residual risk per vendor, distinguishing items fixable by contract flow-down from items requiring an action plan.\n\n**Record in AssureSwarm**\nThe form on this step, answered by the vendor's security or compliance contact, captures missing current subprocessors used to deliver the service. Attach reports and bridge material as documents; read report dates/findings and contract notification windows directly, and use the named assignment for contact identity.\n- Attach each received artifact to the corresponding Vendor item (document upload) with the report period or expiry captured.\n- Track per-vendor evidence status (requested, received, or gap) in the evidence tracker on this step — it has no native Vendor field; the artifacts on the item are the ground truth.\n- Log outstanding requests on the step.\n\nWrite a SOC-review summary on each Vendor item (coverage, opinion, exceptions, CUEC ownership status, subservice method).\n- Create issue or gap items for each unmet CUEC or relevant exception, linked to the Vendor and the responsible internal control owner.\n\nWrite a C-SCRM assessment summary on each Vendor item with per-area ratings and cited criteria.\n- Create gap or issue items for partial and gap areas, linked to the Vendor and owner, tagged as contract-remediable or action-plan.\n\n**Exit criteria**\nEvery in-scope vendor has a tracked evidence status; requested missing-fact answers are returned or a gap is logged with a reason; artifacts are received and their report periods and expiries are validated against the assessment window. Each SOC report is validated for period, scope, and opinion; exceptions are triaged; every CUEC is mapped to an owner with an operating status; gaps are logged. Each in-scope vendor is assessed against the C-SCRM baseline at tier depth; every area is rated with a cited criterion; fourth-party concentration is flagged; gaps are logged and classified.\n\n**Form recipient** — Vendor security or compliance contact, only when that person holds none of the preparation, execution, review or approval assignments anywhere in this workflow. Request only the unresolved facts listed in the assignment; the optional fields do not require known information to be entered again. If no facts are missing, no form response is required.\n\n> **⚡ Audit Artist accelerator:** `/coach-form-create` builds the questionnaire and document-request set; `/coach-notify` issues the requests and chases overdue vendors.\n\n> **⚡ Audit Artist accelerator:** `/coach-form-create` builds the questionnaire and document-request set; `/coach-notify` issues the requests and chases overdue vendors.","label":"Review SOC and CUECs","performedBy":{"note":"","primitives":["coach-document-upload","coach-item-create","coach-items-link","coach-query-data","coach-form-create","coach-notify"]}},"id":"review-soc-and-cuecs"},{"data":{"description":"Translate the assurance and supply-chain gaps into enforceable contractual protections","instructions":"**Objective** — Translate the assurance and supply-chain gaps into enforceable contractual protections, so identified risks are addressed in the vendor agreement before onboarding completes.\n\n**Inputs**\n- The SOC and CUEC gaps from the SOC-review step and the C-SCRM gaps from the C-SCRM assessment step (linked gap items on each Vendor).\n- The contract and clause library, legal and procurement contacts, and the current MSA and DPA status.\n\n**Procedure**\n1. Consolidate the gap set from both analyses and keep only items that are contract-remediable: right-to-audit, security SLAs, breach-notification windows, subcontractor flow-down, data return and deletion, and insurance minimums.\n2. Select clauses from the library per gap and note the standard each clause satisfies (for example, a breach-notification window tied to a regulatory requirement, or flow-down tied to the C-SCRM SR family).\n3. Confirm the DPA and security exhibit are present and adequate for the data classification handled; require one where it is missing.\n4. Draft the required-clause redline package and route it to legal and procurement; track negotiation status per clause (accepted, negotiating, or rejected).\n5. For any rejected clause, record the residual risk and route it to the disposition decision or escalation rather than treating it as closed.\n\n**Record in AssureSwarm**\n- Attach the redline and clause package to the Vendor item and set the per-clause negotiation-status fields.\n- Link each clause back to the gap item it remediates and flag unresolved clauses for disposition.\n\n**Exit criteria** — Every contract-remediable gap has a mapped clause with a negotiation status; the DPA and security exhibit are confirmed or requested; rejected clauses carry a documented residual risk routed onward.","label":"Embed contract protections","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-items-link"]}},"id":"embed-contract-protections"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Third-Party Vendor Risk Lifecycle so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Determine the overall disposition of the vendor's risk assessment and route to the correct closure path. Owned by the vendor's risk owner with GRC review.\n\n**Decision criteria**\n- **clean (No reportable gap):** SOC coverage is current and unqualified for the relied-upon services, all CUECs are owned and operating, the C-SCRM areas are met at tier depth, and no contract-remediable gap of consequence remains. Residual risk sits within appetite.\n- **remediate (Remediation required):** One or more gaps exist that are addressable through an owned action plan within a defined timeframe — unmet CUECs, partial C-SCRM areas, or clauses still negotiating — and residual risk is manageable with committed remediation without breaching appetite.\n- **escalate (Escalate significant issue):** Residual risk breaches appetite or a critical control is absent with no near-term fix — a qualified or adverse SOC opinion on relied-upon services, a rejected essential clause (for example breach notification), an uncovered critical fourth party, or a material concentration or financial-viability concern requiring a risk-owner or executive decision.\n\n**Record in AssureSwarm** — Submit the `disposition_path` SELECT. In the step result, cite the specific findings (SOC exceptions, unmet CUECs, C-SCRM gaps, rejected clauses) and the appetite position that drove the choice; name the decision owner in the step's approver record.\n\n**Exit criteria** — The form is submitted with a cited rationale, and the two unused branches are prunable because the branch edge values match the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-form-fill"]}},"id":"classify-disposition"},{"data":{"description":"Build an owned, time-bound remediation plan for the gaps that drove a remediate disposition","instructions":"**Objective** — Build an owned, time-bound remediation plan for the gaps that made the disposition remediate, so each is tracked to closure with defined validation evidence.\n\n**Inputs**\n- The open gap and issue items from the SOC-review, C-SCRM assessment, and contract-protection steps.\n- The disposition rationale and the assigned remediation owners.\n\n**Procedure**\n1. Pull every open gap tagged for remediation and state the root cause per gap, not just the symptom.\n2. Assign a single accountable owner, a due date proportional to risk, and an interim mitigation for anything exploitable now.\n3. Define the validation evidence that will close each item — a re-issued SOC bridge letter, a signed clause, or a patched-SLA attestation.\n4. Set a reporting cadence and the KRI or threshold that would trigger escalation if remediation slips.\n5. Confirm the aggregate plan brings residual risk within appetite; if it cannot, route that item to escalation instead.\n\n**Record in AssureSwarm**\n- Create an action-plan item per gap (owner, due date, interim mitigation, validation evidence, cadence), linked to its gap item and the Vendor.\n- Set the vendor's residual-risk and remediation-status fields.\n\n**Exit criteria** — Every remediation gap has an owned, dated action-plan item with defined validation evidence and an interim mitigation; aggregate residual risk is confirmed within appetite or escalated.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Prepare the escalation and risk-acceptance decision for significant issues","instructions":"**Objective** — Prepare the escalation and risk-acceptance decision for significant issues, so an accountable executive or risk owner formally accepts, rejects, or directs treatment of the residual risk.\n\n**Inputs**\n- The disposition rationale and the specific significant findings, quantified impact and likelihood, and the appetite thresholds breached.\n- The escalation matrix identifying the risk owner, GRC lead, executive sponsor, or board delegate for this severity.\n\n**Procedure**\n1. Assemble the escalation memo: the issue, the breached appetite threshold, the root cause, and the specific finding (a qualified opinion, a rejected essential clause, an uncovered critical fourth party, or a financial-viability concern).\n2. Quantify impact and likelihood and state the residual risk in the organization's rating scale.\n3. Lay out the options — remediate with conditions, an alternative vendor or compensating control, or formal risk acceptance — with the cost, benefit, and timeline of each.\n4. Route to the correct authority per the escalation matrix and capture the decision, any conditions, and an expiry or reassessment date for an acceptance.\n5. If risk is accepted, define the monitoring trigger and the owner who revisits it.\n\n**Record in AssureSwarm**\n- Attach the decision memo to the Vendor item; record the acceptance as an Issue item with issue_type: policy_exception — exception_approver (the accepting authority), exception_expiry_date (the acceptance's expiry/re-review date), conditions and the monitoring trigger in its description — linked to the Vendor item and the underlying Risk (treatment set to accept).\n- Link the escalation to the underlying finding Issues.\n\n**Exit criteria** — The escalation memo is prepared and routed to the named authority; the decision, conditions, and expiry or monitoring trigger are recorded; any accepted risk has an owner and a revisit date.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-render-package","coach-document-upload","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Capture the accountable approver's decision on the final vendor-risk package — approve it as presented or return it for revision. Owned by the risk owner, GRC lead, executive sponsor, or board delegate per the tier's approval authority.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nCapture the accountable approver's decision on the final vendor-risk package — approve it as presented or return it for revision. Owned by the risk owner, GRC lead, executive sponsor, or board delegate per the tier's approval authority.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe scoped, tiered vendor register from the inventory step.\n- The available monitoring feeds (security ratings, breach and news alerts, sanctions and adverse-media screening, financial health) and the monitoring policy's cadence by tier.\n\nThe SOC-review and C-SCRM assessment summaries, the gap and action-plan items, the contract-protection status, and the monitoring enrollment.\n- The disposition and any escalation or risk-acceptance decision, and the current vendor register.\n\n*Agent retrieval, preparation and filing absorb “Enroll in monitoring”, “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Enroll in monitoring: Enroll each in-scope vendor in tier-appropriate continuous monitoring, so post-onboarding risk changes are detected on a defined cadence rather than only at reassessment.\n\n2. Map each tier to a monitoring package: Tier 1 gets continuous security-rating, breach, adverse-media, and financial monitoring plus annual reassessment; Tier 2 gets periodic rating and breach alerts plus biennial reassessment; Tier 3 gets an attestation refresh only.\n3. Register each vendor with the relevant feeds and keys, and set alert thresholds and the owner who triages alerts.\n4. Schedule the reassessment cadence and the monitoring-review cadence on the Vendor item.\n5. Define the alert-to-action path: which alert types trigger a re-review or escalation, and who owns the response.\n6. Verify enrollment is live — a test or health signal returns — so monitoring is not nominal only.\n\n7. Assessment scope for Prepare final package: Compile the complete evidence-and-decision package for the vendor assessment and update the vendor's tiering and monitoring cadence to reflect the outcome, producing the single artifact the approver reviews.\n\n8. Compile the package: scope and workplan, vendor tier, SOC-review summary (coverage, opinion, exceptions, CUEC status), C-SCRM assessment, contract-protection status, monitoring enrollment, the disposition with rationale, action plans and/or the escalation decision, and any unresolved constraints.\n9. Update the supplier tiering: if the assessment changed the vendor's risk profile — new data access, exceptions, or a financial concern — re-tier the vendor and record the driver.\n10. Update the monitoring cadence to match the final tier and any conditions from an acceptance or action plan.\n11. Confirm every conclusion is traceable to evidence and the appetite position, and reconcile that no open gap is silently dropped.\n12. Draft the proposed conclusion for the approver and list what the downstream engagement must not repeat.\n\n13. Assessment scope for Approve or revise package: Capture the accountable approver's decision on the final vendor-risk package — approve it as presented or return it for revision. Owned by the risk owner, GRC lead, executive sponsor, or board delegate per the tier's approval authority.\n\n\n\n**approved:** The package is complete and traceable, the disposition and any risk acceptance fall within this approver's authority and appetite, action plans are owned and dated, and no material evidence gap remains.\n- **revise:** Evidence is missing or untraceable, a conclusion is unsupported, an action plan lacks an owner or date, the residual risk exceeds this approver's authority, or a condition must be met before sign-off.\n\n**Record in AssureSwarm**\nSet monitoring_status to enrolled on each Vendor item, and stamp the assessment dates: last_assessment_date (this cycle) and next_reassessment_date (from the vendor's reassessment_cadence).\n- Attach the alert-to-action definition (feeds, thresholds, triage owner) as a document on this step — the feed wiring itself has no native Vendor fields.\n\nAttach the final package document to the workflow.\n- Set the vendor's final tier, monitoring cadence, and disposition fields.\n- Ensure every gap, action-plan, and escalation item is linked to the package.\n\nSubmit the `approval_path` SELECT. In the step result, state what was reviewed and, for a revise decision, the specific deficiencies to fix; name the approver in the step's approver record.\n\n**Exit criteria**\nEvery in-scope vendor is enrolled per tier with an active feed, a triage owner, thresholds, and a scheduled reassessment cadence; the alert-to-action path is documented. The package is compiled and attached; the tier and monitoring cadence are updated with a recorded driver; every conclusion traces to evidence; no open item is unlinked; the proposed conclusion is stated. The form is submitted with a rationale, and the unused branch is prunable because the branch edge values match the selected form value.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-scan` stands up the continuous-monitoring feeds and the alert-to-action triage cadence for each enrolled vendor.","kind":"decision","label":"Approve or revise package","performedBy":{"note":"","primitives":["coach-form-fill","coach-workflow-scan","coach-item-update","coach-render-package","coach-document-upload"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Address the approver's revision comments and conditions, so the package can return for a final decision without relitigating settled points.\n\n**Inputs**\n- The approver's revise rationale and comments from the approval decision.\n- The final package and the underlying evidence and gap items.\n\n**Procedure**\n1. Log each reviewer comment or condition as a discrete item with an owner.\n2. Resolve each: attach missing evidence, correct unsupported conclusions, add owners and dates to action plans, or obtain the higher-authority sign-off the residual risk required.\n3. Update the package and note exactly what changed and why, preserving the prior version for the audit trail.\n4. Confirm no new gap was introduced and re-run the traceability check on any changed conclusion. Return the exact new version to the original approver, or the required higher authority, and obtain native approval before final approval recording or handoff.\n\n**Record in AssureSwarm**\n- Update the package document as a new version and set the condition-resolution fields per comment.\n- Link each resolved condition item back to the approver's comment.\n\n**Exit criteria** — Every reviewer comment is resolved with evidence; the package is updated and versioned; the change log is recorded; the exact revised package has received the required native reapproval.","label":"Resolve approval conditions","performedBy":{"primitives":["coach-item-update","coach-document-upload"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Hand the approved vendor-risk package to the downstream Third-Party Vendor Assurance Engagement and close this lifecycle instance in the same motion, so the downstream fieldwork builds on this assessment instead of repeating it; the human moment is confirming with the receiving owner that the handoff was accepted.","instructions":"**Objective**\nHand the approved vendor-risk package to the downstream Third-Party Vendor Assurance Engagement and close this lifecycle instance in the same motion, so the downstream fieldwork builds on this assessment instead of repeating it; the human moment is confirming with the receiving owner that the handoff was accepted.\n\n**Inputs**\nThe approved package, reached either directly or after revision.\n- The approver's identity and any conditions attached to the approval.\n\nThe approved final package, the recorded approval decision and its conditions, the disposition, and the open action plans.\n- The downstream workflow's expected input format and the receiving owner.\n- The monitoring enrollment, the reassessment cadence, and the linked Vendor register records.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Record approval decision”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Record approval decision: Record the final governance approval decision and its conditions, so the sign-off is durable, attributable, and auditable.\n\n2. Capture the approver's name and role, the decision, and the date.\n3. Record any conditions of approval and the owner and due date for each.\n4. Confirm the approved version of the package is the one archived (version match).\n5. Set the follow-up ownership for conditions and the next reassessment date.\n\n6. Assessment scope for Handoff to related workflow: Hand the approved vendor-risk package to the downstream Third-Party Vendor Assurance Engagement and close this lifecycle instance in the same motion, so the downstream fieldwork builds on this assessment instead of repeating it; the human moment is confirming with the receiving owner that the handoff was accepted.\n\n7. Create or link the downstream Third-Party Vendor Assurance Engagement workflow instance for the vendor.\n8. Pass the final package, the tier, the disposition, the open action plans, and the monitoring cadence.\n9. State the assumptions the downstream should rely on and, explicitly, what it should not repeat — already-validated SOC coverage, mapped CUECs, and embedded contract protections.\n10. Note any open conditions the downstream must track to closure.\n11. Confirm receipt or linkage with the receiving owner so the handoff is not fire-and-forget, and verify the recorded approval decision matches the package version being passed.\n12. Archive the final package and all supporting evidence as read-only.\n13. Confirm every gap, action-plan and escalation item is either closed or transferred with a named owner — nothing is left unowned on either side of the handoff.\n14. Update the vendor register: status, final tier, disposition, and next reassessment date; confirm monitoring is live and the reassessment is scheduled on the cadence.\n15. Communicate the final decision to stakeholders — the business owner, the risk owner, and procurement.\n\n**Record in AssureSwarm**\nSet the approval fields on the workflow and Vendor item (approver, date, conditions).\n- Link the approved package version and create condition follow-up items with owners.\n\nLink the downstream workflow to this workflow and the Vendor item.\n- Attach a handoff note listing the passed artifacts and the items out of scope for the downstream engagement.\n- Set the workflow status to closed and archive or export the package and supporting evidence read-only.\n- Confirm the reassessment date and monitoring cadence on the Vendor item, and notify the stakeholders.\n\n**Exit criteria**\nApprover, date, and conditions are recorded; the approved package version is linked; condition follow-ups are owned and dated. The downstream engagement is created or linked with the package passed and linkage confirmed; assumptions and non-repeat scope are documented; open conditions are transferred; the package and evidence are archived read-only; every gap, action-plan and escalation item is closed or transferred with an owner; the vendor register is updated with the next reassessment date; monitoring is live; stakeholders are notified.","label":"Handoff to related workflow","performedBy":{"note":"","primitives":["coach-workflow-attach","coach-document-upload","coach-notify","coach-export-package","coach-workflow-export","coach-item-update"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-third-party-vendor-risk-lifecycle"}