{"description":"Vendor Due Diligence & Contracting Gate as a modular, decision-aware workflow. Anchor: the vendor's register entry — the Vendor item (slug: vendor). For a net-new engagement the gate creates the Vendor item and populates its tier, data_classification, business_owner, and risk_owner; for a renewal it enriches the existing Vendor item rather than duplicating it (enrich, never recreate). This is the first-line pre-contract gate the vendor-management office runs for every new engagement or renewal - tiering criticality, running proportionate due diligence into the vendor due-diligence report, documenting the risk-acceptance decision and any risk-reducing sourcing conditions, binding the contract to required security, privacy, and regulatory clauses, authorizing the specific information exchange before access begins, and - where personal data is involved - obtaining the signed written privacy commitments and scheduling compliance monitoring and incident-response routing. In scope: pre-contract due diligence, risk acceptance, and contract execution for one vendor engagement, ending with the Vendor item enrolled in monitoring (Vendor.monitoring_status = enrolled). There is no upstream workflow — the engagement trigger (a new prospective vendor or a renewal) is its own entry point. Downstream handoff: the archived gate record exported at close is the handoff package the ongoing third-party risk monitoring / vendor oversight lifecycle picks up to sustain the scheduled compliance checks and incident routing; that linkage is a prose handoff of live controls on the same Vendor item, not a triggered downstream node.","edges":[{"id":"e-run-proportionate-due-diligence-decide-acceptance-and-sourcing","source":"run-proportionate-due-diligence","target":"decide-acceptance-and-sourcing"},{"id":"e-decide-acceptance-and-sourcing-bind-contract-security-privacy-terms","label":"Accepted","source":"decide-acceptance-and-sourcing","target":"bind-contract-security-privacy-terms","whenValue":"accepted"},{"id":"e-decide-acceptance-and-sourcing-apply-risk-reducing-sourcing-conditions","label":"Accepted with conditions","source":"decide-acceptance-and-sourcing","target":"apply-risk-reducing-sourcing-conditions","whenValue":"accepted_with_sourcing_conditions"},{"id":"e-decide-acceptance-and-sourcing-close-and-archive","label":"Declined","source":"decide-acceptance-and-sourcing","target":"close-and-archive","whenValue":"declined"},{"id":"e-apply-risk-reducing-sourcing-conditions-bind-contract-security-privacy-terms","source":"apply-risk-reducing-sourcing-conditions","target":"bind-contract-security-privacy-terms"},{"id":"e-bind-contract-security-privacy-terms-authorize-exchange-and-execute-contract","source":"bind-contract-security-privacy-terms","target":"authorize-exchange-and-execute-contract"},{"id":"e-bind-contract-security-privacy-terms-determine-personal-data-commitment-scope","source":"bind-contract-security-privacy-terms","target":"determine-personal-data-commitment-scope"},{"id":"e-authorize-exchange-and-execute-contract-close-and-archive","source":"authorize-exchange-and-execute-contract","target":"close-and-archive"},{"id":"e-determine-personal-data-commitment-scope-obtain-written-privacy-commitments","label":"Personal data involved","source":"determine-personal-data-commitment-scope","target":"obtain-written-privacy-commitments","whenValue":"personal_data_involved"},{"id":"e-determine-personal-data-commitment-scope-schedule-monitoring-and-incident-routing","label":"No personal data","source":"determine-personal-data-commitment-scope","target":"schedule-monitoring-and-incident-routing","whenValue":"no_personal_data"},{"id":"e-obtain-written-privacy-commitments-schedule-monitoring-and-incident-routing","source":"obtain-written-privacy-commitments","target":"schedule-monitoring-and-incident-routing"},{"id":"e-schedule-monitoring-and-incident-routing-close-and-archive","source":"schedule-monitoring-and-incident-routing","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-TPRM-02","UC-TPRM-03","UC-DATA-16"],"department":"procurement","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-vendor-due-diligence-contracting-gate","contentDigest":"sha256:5119b29be115a4aef6f49bee55dd7116b088d3345b47938ce2a9e3dd6fa846dc","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:5119b29be115a4aef6f49bee55dd7116b088d3345b47938ce2a9e3dd6fa846dc","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-vendor-due-diligence-contracting-gate"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-vendor-due-diligence-contracting-gate","source":"coworkcanvas-gallery","standards":["nist-800-53","soc2","nist-csf-2","gdpr"],"teams":["procurement","privacy"]},"name":"Vendor Due Diligence & Contracting Gate","nodes":[{"data":{"description":"Agent tiers the vendor by criticality and executes the proportionate due-diligence plan across security posture, financial and operational risk, and supply-chain exposure into one due-diligence report; human risk analyst reviews the ratings and red flags before the acceptance decision.","formData":{"fields":[{"key":"data_locations","label":"Countries where that data is stored or accessed","required":false,"type":"text"},{"key":"mfa_enforced","label":"Multi-factor authentication is enforced for all staff with access to customer data","required":false,"type":"checkbox"},{"key":"encryption","label":"Encryption at rest and in transit - describe","required":false,"type":"textarea"},{"key":"incident_history","label":"Security incidents affecting customer data in the last 24 months","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Tier the vendor engagement by criticality and execute the proportionate due-diligence plan into the single **vendor due-diligence report** — security posture, financial and operational risk, and supply-chain exposure at the depth the tier requires; the human moment is the risk analyst clearing the ratings and red flags for the acceptance decision.\n\n**Inputs**\n- Vendor intake: legal name, requesting business unit, business sponsor, accountable decision owner, legal/privacy counsel, and the proposed services or systems. Net-new → create the **Vendor item** (the anchor); renewal → enrich the **existing Vendor item**, never recreate it. The intake document is uploaded here and its narrative summarized into `Vendor.description`. This gate has no upstream workflow — the engagement trigger is its own entry point; log why the cycle is running now.\n- Data profile: data categories, volume, and explicitly whether personal data (GDPR personal data, HIPAA PHI, or CCPA consumer personal information) is in scope — in the intake document, reflected in `Vendor.data_classification`.\n- Access profile: depth of systems or network access requested, business-process dependency, and annual spend, in the same document; the dependency ties to the affected **Process item(s)** where they exist.\n- For a renewal: prior findings and open **Issue items** from the ongoing third-party risk oversight program, plus the expiring contract on the prior gate's archived workflow instance.\n- The org's criticality-tiering rubric and vendor-management policy — the **Policy item** (policy_type: policy/standard) where maintained; otherwise the default buckets below.\n- Vendor-supplied evidence: completed security questionnaire, current certifications (SOC 2 Type II report, ISO 27001 certificate), penetration-test summaries, vulnerability-management evidence, financial statements or a third-party financial rating, business-continuity/DR plans, and a sub-processor/subcontractor list.\n- External signals where available: breach history, adverse media, sanctions/watchlist screening, and geographic/concentration risk data.\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_Items 1–10 are agent-run (items 1–6 folded from the former \"Tier vendor by criticality\" step); the human moment is the risk analyst's review at item 11._\n1. Confirm scope: this cycle covers pre-contract due diligence, risk acceptance, and contract execution only. Ongoing monitoring after execution runs under the separate third-party risk oversight program — do not duplicate it here.\n2. Assemble the scoring profile across four rubric dimensions: (a) data sensitivity and volume, weighting any personal-data involvement highest; (b) depth of systems/network access; (c) business-process dependency (would an outage halt a critical process?); (d) annual spend and switching cost.\n3. Assign a tier using the rubric. Default buckets: **critical** = handles regulated personal data at scale or is a single point of failure for a critical process; **high** = material access or dependency with sensitive but non-regulated data; **moderate** = limited access, low data sensitivity; **low** = no sensitive data, minimal access, easily substitutable. Record the deciding dimension.\n4. Derive the proportionate due-diligence plan for the tier, naming which assessments are mandatory versus abbreviated or waived. Reference plan (tune to policy): critical/high → full security questionnaire + certification review (SOC 2 Type II / ISO 27001) + penetration-test and vulnerability evidence + financial-stability check + business-continuity review + supply-chain/sub-processor mapping; moderate → security questionnaire + certification attestation + light financial check; low → attestation and self-certification only.\n5. Explicitly flag personal-data involvement (yes/no and category) so the privacy-commitment track downstream is anticipated rather than discovered late.\n6. Record the tier, its rationale, and the plan on the Vendor item, and, only for facts unresolved after artifact review, assign the relevant optional questions to the qualified vendor contact with a due date.\n7. Execute the security-posture assessment the tier calls for: review questionnaire responses for gaps, validate certifications are current and scoped to the services in question (a SOC 2 that excludes the relevant system is not coverage), and confirm penetration-testing and vulnerability-management evidence exists and is recent (typically within 12 months).\n8. Execute the financial and operational assessment: financial-stability indicators (liquidity, going-concern signals, negative rating actions), business-continuity and resilience capability (RTO/RPO, tested DR), and key-person or single-point-of-failure concentration risk.\n9. Map supply-chain exposure to the tier's required depth: enumerate the vendor's subcontractors and sub-processors, identify fourth-party dependencies that reach your data, and flag geographic or concentration risk (e.g., a critical sub-processor in a high-risk jurisdiction).\n10. Rate each dimension (low / moderate / high / critical residual risk) with the evidence reference supporting the rating, so a reviewer can trace every rating to a document.\n11. Consolidate into the single vendor due-diligence report, listing red flags and unresolved gaps explicitly at the top for escalation — never bury a material finding inside a dimension section — then have the risk analyst review it against the tier's plan before it feeds the acceptance decision.\n\n**Record in AssureSwarm**\n- Create the **Vendor item** (item create), or enrich it for a renewal: set `category`, `tier` (low/medium/high/critical — the native tier field), `data_classification` (restricted or confidential carries the personal-data flag; none/internal where no personal data), `business_owner` (sponsor), and `risk_owner` (accountable decision owner). Summarize the intake and tier rationale into `Vendor.description` and set `Vendor.last_assessment_date` to the assessment date (item update).\n- Enter the vendor's standing third-party risk posture as a **Risk item**: `category: third_party`, `taxonomies: third_party_risk`, `inherent_rating` set from the tier, `risk_owner` = decision owner; link Risk ↔ Vendor (items link). Set `Risk.residual_rating` from the consolidated dimension ratings.\n- Attach the due-diligence plan (mandatory vs waived assessments, DOCX/PDF), the vendor due-diligence report, and the underlying evidence artifacts (PBC/external, document upload) as documents on this step, against the anchor Vendor item.\n- Create each material red flag as an **Issue item**: `issue_type: finding`, `source: compliance_review`, `severity` per its residual rating, `issue_owner`, `identified_date`; link Issue ↔ Vendor and Issue ↔ the third-party Risk item.\n- Query and link the affected **Process item(s)** (business-process dependency) and the vendor-management **Policy item** (the tiering rubric) where they already exist.\n- The form on this step, answered by the prospective vendor, captures current data storage/access countries, MFA enforcement for staff with data access, encryption at rest and in transit and incidents in the last 24 months. Use the intake for legal identity and data scope; read assurance metadata from its report and attach the insurance certificate as a document — the questionnaire input to items 7–9.\n\n**Exit criteria** — The tier is scored against the rubric with its rationale, the plan is proportionate (neither excessive for a low-risk engagement nor insufficient for a critical one), and the personal-data flag is set. Every mandatory assessment was performed or its waiver justified; each dimension carries a rating with an evidence reference; red flags are surfaced at the top of the report rather than buried, and the risk analyst has cleared the findings to support an acceptance decision.\n\n**Form recipient** — Prospective vendor security 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.","label":"Run proportionate due diligence","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-item-update","coach-items-link"]}},"id":"run-proportionate-due-diligence"},{"data":{"decisionField":"vendor_acceptance_decision","description":"Agent synthesizes due-diligence findings into an acceptance recommendation and risk-reducing sourcing options; human decision owner accepts, accepts with sourcing conditions, or declines the engagement","formData":{"fields":[{"key":"vendor_acceptance_decision","label":"Vendor acceptance decision","options":[{"label":"Accepted - proceed to contracting","value":"accepted"},{"label":"Accepted with risk-reducing sourcing conditions","value":"accepted_with_sourcing_conditions"},{"label":"Declined - pursue alternate sourcing","value":"declined"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether this vendor engagement is accepted as-is, accepted only subject to risk-reducing sourcing conditions, or declined. The accountable decision owner (not the analyst who ran diligence) owns this call.\n\n**Decision criteria**\n- **accepted** (Accepted — proceed to contracting): the due-diligence report shows residual risk within appetite on every dimension, with no open red flag that additional sourcing controls would be needed to tolerate. Proceed straight to contract binding.\n- **accepted_with_sourcing_conditions** (Accepted with risk-reducing sourcing conditions): residual risk is elevated but manageable — one or more findings can be brought within appetite by concrete conditions (reduced access scope, additional mandatory security controls, phased/limited onboarding, or a qualified backup vendor on standby). Select this whenever acceptance depends on a condition being applied, so the condition is tracked rather than assumed.\n- **declined** (Declined — pursue alternate sourcing): residual risk is outside appetite and cannot be reduced to tolerable by feasible conditions (e.g., a critical vendor with no current security certification and a going-concern flag). Record the decline rationale and any alternate-sourcing recommendation; the engagement routes straight to close.\n\n**Record in AssureSwarm**\n- Submit the step form: `vendor_acceptance_decision` SELECT with the chosen value, the step result (evidence references — which findings drove the call), and the step's approver record (the accountable owner).\n- Set `Risk.treatment` on the linked third-party Risk item to record the disposition: `accept` on `accepted`, `mitigate` on `accepted_with_sourcing_conditions` (the conditions are the mitigation), `avoid` on `declined` (item update).\n\n**Exit criteria** — The decision form is submitted with a rationale that cites the diligence evidence and names the accountable owner; the branch not selected is prunable. `accepted` proceeds to contract binding, `accepted_with_sourcing_conditions` proceeds to applying the conditions first, and `declined` proceeds to close and archive.","kind":"decision","label":"Decide acceptance and sourcing","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-item-update","coach-form-fill"]}},"id":"decide-acceptance-and-sourcing"},{"data":{"description":"Agent translates the accepted sourcing conditions into tracked commitments; human sourcing owner confirms conditions are attached before contracting","instructions":"**Objective** — Turn the accepted sourcing conditions into specific, assigned, checkable commitments attached to the vendor record so they can be written into contract negotiation, rather than remaining verbal caveats on the acceptance decision.\n\n**Inputs**\n- The acceptance decision and its recorded rationale, specifically the risk-reducing sourcing conditions attached to the `accepted_with_sourcing_conditions` outcome.\n- The due-diligence report findings each condition is meant to mitigate.\n- The business sponsor and the vendor contact needed to confirm each condition is feasible.\n\n**Procedure**\n1. Translate each sourcing condition into a specific, checkable requirement. Vague (\"improve security\") becomes concrete (\"restrict access to the reporting API only; MFA enforced on all vendor accounts; phased onboarding — pilot BU first, full rollout only after a 60-day clean review; backup vendor X qualified and on standby\").\n2. Attach each condition to the vendor record as a tracked commitment with a named owner and a due date or milestone, and link it to the finding it mitigates so the mitigation chain is auditable.\n3. Confirm feasibility with the vendor and the business sponsor before the conditions go into negotiation — a condition the vendor will not agree to must be resolved (renegotiate, escalate, or re-open the acceptance decision) now, not at signature.\n4. Note on the anchor Vendor item that the engagement proceeds subject to these documented sourcing conditions, so the contract-binding step knows to carry them into the agreement.\n\n**Record in AssureSwarm**\n- Create one **Issue item** per sourcing condition (item create): `issue_type: exception`, `source: compliance_review`, `issue_owner`, `target_remediation_date` (the due date/milestone), and `remediation_plan` = the concrete, checkable condition text.\n- Link each condition Issue to its source-finding Issue and to the anchor Vendor item (items link).\n- Confirm `Risk.treatment: mitigate` remains set on the linked third-party Risk — these tracked conditions are the mitigation that brings residual risk within appetite.\n\n**Exit criteria** — The sourcing owner confirms every risk-reducing condition is specific, assigned, feasible, and ready to be written into the contract before the engagement proceeds to binding.","label":"Apply risk-reducing sourcing conditions","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"apply-risk-reducing-sourcing-conditions"},{"data":{"description":"Agent drafts and verifies the contract against the required security, privacy, and applicable regulatory clause checklist; human legal and privacy counsel confirm all required terms are bound before execution","instructions":"**Objective** — Ensure the contract is bound to the complete set of required security, privacy, and applicable regulatory clauses (including any accepted sourcing conditions) before it proceeds to execution, so no required protection is left to a later amendment.\n\n**Inputs**\n- The acceptance decision, and — on the conditions branch — the tracked sourcing commitments that must appear as contract terms.\n- The data categories and vendor role identified during tiering (drives which regulatory regimes apply).\n- The draft contract or the vendor's paper, plus the org's clause checklist / contract-standards library.\n\n**Procedure**\n1. Draft or verify the core security and privacy terms: the specific security controls the vendor must maintain, confidentiality obligations, breach-notification timelines, audit rights, subcontractor/sub-processor flow-down terms, and data handling, return, and deletion obligations at termination.\n2. Determine which regulatory clause regimes apply from the data profile and bind them: GDPR Article 28 processor terms where EU personal data is processed; HIPAA business-associate agreement provisions where PHI is involved; CCPA service-provider terms where California consumer personal information is involved. Where none apply, record that determination so the exemption is evidenced.\n3. Fold any accepted sourcing conditions into contract language (restricted access scope, additional controls, phased-onboarding milestones, backup-vendor obligations) so the conditions are contractually binding, not just tracked internally.\n4. Cross-check the full draft against the security/privacy/regulatory clause checklist and flag every missing or weakened clause. Route the gap list to legal and the vendor's counterparty for redline; iterate until each required clause is present and acceptable.\n\n**Record in AssureSwarm**\n- Upload the contract draft (PDF) and the completed clause checklist (XLSX) as documents on this step, attached to the anchor Vendor item. The contract has no first-class item type — the uploaded document IS the record (honest fallback).\n- Link the contract document to the anchor Vendor item and to the sourcing-condition **Issue items** it now embodies (document link).\n- Once the term is fixed, set `Vendor.contract_end_date` on the anchor Vendor item (item update).\n\n**Exit criteria** — Legal and privacy counsel confirm every required security, confidentiality, breach-notification, audit-rights, subcontractor, data-handling, and applicable regulatory clause — plus any accepted sourcing conditions — is bound in the contract language before it proceeds to execution.","label":"Bind contract to security, privacy, and regulatory terms","performedBy":{"primitives":["coach-document-upload","coach-item-update"]}},"id":"bind-contract-security-privacy-terms"},{"data":{"description":"Agent confirms contract execution, documents the authorized information exchange, and schedules the periodic agreement review; human contract owner confirms authorization before any access begins","instructions":"**Objective** — Confirm the contract is executed, authorize the specific information exchange or system interconnection under it, and schedule the periodic agreement review — ensuring no access, service, or data flow begins ahead of recorded authorization.\n\n**Inputs**\n- The bound, counsel-approved contract from the binding step, ready for signature.\n- The specific information exchange or system interconnection this engagement requires (data flows, systems, access scope).\n- The IT / access-management provisioning process and the contract or policy cadence for periodic agreement review.\n\n**Procedure**\n1. Confirm the contract is executed by both parties and record the effective date, term, and renewal/expiry date on the vendor record.\n2. Document and authorize the specific information exchange or interconnection, explicitly linking each authorized data flow or access grant to the contract clause that permits it — authorization by reference to the executed agreement, not a standalone approval.\n3. Confirm no access, service delivery, or data exchange occurred ahead of this authorization. Only once authorization is recorded, release provisioning instructions to IT and access management. (For engagements involving personal data, provisioning of personal-data access remains additionally gated on the signed privacy commitments produced on the privacy track.)\n4. Schedule the periodic review of the agreement itself — distinct from the privacy-commitment compliance check — at the cadence the contract or policy requires, and record the next review date.\n\n**Record in AssureSwarm**\n- Set the executed-contract dates on the anchor Vendor item: `contract_end_date` (renewal/expiry) and `next_reassessment_date` (the periodic agreement-review date) (item update).\n- Document the information-exchange / interconnection authorization — the effective date, term, each authorized data flow or access grant, and the permitting contract clause — as a note/document on this step; there is no native Vendor field for the interconnection detail (honest fallback).\n- Link the authorization document to the executed contract document and to the anchor Vendor item (items link).\n\n**Exit criteria** — The contract owner confirms the agreement is fully executed, the information exchange or interconnection is explicitly authorized under it, no access was granted ahead of authorization, and the periodic agreement-review date is scheduled.","label":"Authorize information exchange and execute contract","performedBy":{"primitives":["coach-items-link","coach-item-create","coach-item-update","coach-document-upload"]}},"id":"authorize-exchange-and-execute-contract"},{"data":{"decisionField":"personal_data_commitment_scope","description":"Agent determines whether the vendor will access personal information and drafts the required written privacy commitments; human privacy owner decides whether commitments must be obtained before access","formData":{"fields":[{"key":"personal_data_commitment_scope","label":"Personal-data commitment scope","options":[{"label":"Personal data involved - commitments required before access","value":"personal_data_involved"},{"label":"No personal data involved","value":"no_personal_data"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the engagement grants the vendor access to personal information, and therefore whether written privacy commitments must be obtained before access begins. The privacy owner owns this call.\n\n**Decision criteria**\n- **personal_data_involved** (Personal data involved — commitments required before access): the vendor will access, process, or store personal information of any regulated category (GDPR personal data, HIPAA PHI, or CCPA California consumer personal information), confirmed from the intake data profile and the executed contract's data-handling clauses. Select this whenever personal data is in scope — even a limited or incidental exposure. Written privacy commitments must be obtained before any personal-data access is provisioned.\n- **no_personal_data** (No personal data involved): the engagement involves no personal information — only non-personal business data or systems with no PII/PHI/consumer-PI exposure. Record the positive basis for this determination (which data categories were reviewed and excluded) so the exemption is evidenced rather than assumed, then route straight to scheduling monitoring.\n\n**Record in AssureSwarm**\n- Submit the step form: `personal_data_commitment_scope` SELECT with the chosen value, the step result (data categories reviewed, relevant contract clause), and the step's approver record.\n- Reconcile against tiering: confirm this determination matches `Vendor.data_classification` set at step 1. If the executed contract's data-handling clauses changed the personal-data scope, update `Vendor.data_classification` to match (item update) and re-open the tiering assumptions — a late scope change must not leave the tier stale.\n\n**Exit criteria** — The decision form is submitted with a rationale grounded in the intake and contracting record and a named owner; the branch not selected is prunable. `personal_data_involved` proceeds to obtaining written commitments; `no_personal_data` proceeds directly to scheduling compliance monitoring and incident routing.","kind":"decision","label":"Determine personal-data commitment scope","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-form-fill","coach-item-update"]}},"id":"determine-personal-data-commitment-scope"},{"data":{"description":"Agent finalizes and collects the vendor's signed written privacy commitments; human privacy owner confirms commitments are in hand before personal-data access is granted","instructions":"**Objective** — Obtain the vendor's signed written privacy commitments and confirm they are consistent with the contract, so personal-data access can be provisioned against a documented evidence gate rather than a verbal assurance.\n\n**Inputs**\n- The personal-data scope decision confirming personal data is involved and its rationale.\n- The executed contract's data-handling, return, and deletion clauses (for consistency checking).\n- The draft written privacy-commitment document and the vendor signatory contact.\n\n**Procedure**\n1. Finalize the written privacy-commitment document covering: the permitted use of the personal information, the specific safeguards the vendor must maintain, and the vendor's obligation to notify of actual or suspected unauthorized disclosure within a defined window.\n2. Route the commitment document to the vendor for signature and track it to completion — do not let it sit as a draft; access is blocked until it is signed.\n3. Verify the signed commitments are consistent with the contract's data-handling, return, and deletion clauses so the two documents do not conflict (a commitment permitting broader use than the contract, or a shorter breach-notice window in one than the other, must be reconciled).\n4. File the signed commitments to the vendor record as the evidence gate that must clear before any personal-data access is provisioned, and confirm access provisioning is held until this gate is recorded.\n\n**Record in AssureSwarm**\n- Upload the vendor-signed privacy-commitment document (PBC/external, document upload) as a document on this step, attached to the anchor Vendor item. Signed commitments have no first-class item type — the uploaded document IS the evidence-gate record (honest fallback).\n- Retain the actual vendor-signed instrument as the evidence of permitted purposes, subprocessor notification, return/deletion timing and authorized signatory identity; reconcile those terms against the executed agreement.\n- Record the consistency-check result — the reconciliation against the contract's data-handling, return, and deletion clauses — in the step result.\n\n**Exit criteria** — The privacy owner confirms the signed written privacy commitments are in hand, are consistent with the contract, and are filed before any access to personal information is granted.\n\n","label":"Obtain written privacy commitments","performedBy":{"primitives":["coach-document-upload","coach-form-fill"]}},"id":"obtain-written-privacy-commitments"},{"data":{"description":"Agent schedules the periodic privacy-commitment compliance check and configures vendor breach notifications to route into incident response; human owner confirms monitoring and escalation are live before close","instructions":"**Objective** — Stand up the ongoing controls that must be live before the gate closes: the periodic privacy-commitment compliance check (where applicable), breach/incident notifications routed into incident response, and a defined escalation path — so oversight does not depend on re-running this gate.\n\n**Inputs**\n- The privacy-scope decision and, where personal data is involved, the signed privacy commitments (their cadence and safeguards drive the compliance check).\n- The organization's incident-response process and the owner who receives vendor breach notifications.\n- The vendor record and the executed contract's breach-notification and audit-rights terms.\n\n**Procedure**\n1. Where personal data is involved, schedule the periodic check of the vendor's compliance with its written privacy commitments at a defined cadence (e.g., annually, or more often for critical-tier vendors). Where no personal data is involved, schedule the tier-appropriate relationship review instead.\n2. Configure the vendor's breach and incident notifications to route directly into the incident-response process — a named owner and an intake path — rather than sit in a shared mailbox. Confirm the routing is demonstrably wired, not just documented.\n3. Define the escalation path for a missed compliance check or a notified breach: corrective action first, with contract suspension or termination if the vendor fails to remediate within the contractual cure period.\n4. Record the schedule, the routing configuration, and the escalation path on the vendor record, and hand these live controls to the ongoing third-party risk oversight program.\n\n**Record in AssureSwarm**\n- Enroll the vendor in ongoing oversight on the anchor Vendor item: set `monitoring_status: enrolled`, `reassessment_cadence` (the compliance-check / review cadence), and `next_reassessment_date` (item update) — these Vendor fields are the native home for the monitoring schedule.\n- Optionally surface the cadence on an oversight dashboard entry (dashboard create) for the third-party risk program.\n- Link the breach-routing configuration and escalation path to the incident-response **Process item** (`process_type: security_process`; `Process.process_owner` = the named breach-notification owner) and to the anchor Vendor item (items link). The escalation-path detail (cure period, suspension/termination triggers) is captured as a document on this step (honest fallback — no native field).\n\n**Exit criteria** — The Third-Party Risk Manager confirms the compliance-check (or review) cadence is scheduled, breach notifications are demonstrably routed into incident response with a named owner, and the corrective-action/termination escalation path is defined before the engagement is closed out.","label":"Schedule compliance monitoring and incident routing","performedBy":{"primitives":["coach-dashboard-create","coach-items-link","coach-item-update"]}},"id":"schedule-monitoring-and-incident-routing"},{"data":{"description":"Automatically archive the selected engagement outcome and preserve accepted oversight controls under the prior approvals.","instructions":"**Objective** — Assemble and archive a self-contained, audit-ready evidence record for the path this engagement took, communicate the outcome, and formally close the due-diligence and contracting gate.\n\n**Inputs**\n- The full gate trail: criticality tier and rationale, due-diligence report, the acceptance decision, and — for accepted engagements — any sourcing-condition commitments, the executed contract with its bound clauses, the interconnection authorization, the personal-data scope decision, any signed privacy commitments, and the monitoring/incident-routing configuration. For declined engagements: the decline rationale and any alternate-sourcing recommendation.\n- The retention location and the vendor's master record.\n\n**Procedure**\n1. Assemble the complete gate record for the path taken. Accepted: tier → diligence → acceptance (with conditions if any) → executed contract and bound clauses → exchange authorization → privacy scope and commitments → monitoring/routing. Declined: tier → diligence → decline decision, rationale, and alternate-sourcing recommendation.\n2. Archive the record to the retention location tagged with vendor name, tier, and decision date — plus execution date and next review dates when accepted — and link it to the vendor's master record.\n3. Communicate the outcome (onboarded / onboarded with conditions / declined) to the business sponsor, legal, and privacy counsel.\n4. Where accepted, hand off the scheduled compliance checks, agreement-review date, and incident-routing configuration to the ongoing third-party risk oversight program so this pre-contract gate does not have to be re-run to sustain them. (This gate has no successor workflow node; the linkage is a handoff of live controls, not a triggered downstream template.)\n\n**Record in AssureSwarm**\n- The workflow instance itself is the audit trail for this gate — attached to the anchor Vendor item and archived on close (workflow instance).\n- Export the closed gate record / workflow package (workflow export, ZIP/PDF) as a document on this step; this export doubles as the **handoff package** the ongoing third-party risk monitoring / vendor oversight lifecycle consumes to sustain the scheduled compliance checks and incident routing.\n- Link the archived record to the anchor Vendor item (document link), and confirm the final `Vendor.monitoring_status` — `enrolled` on an accepted engagement, `exited` on a declined one (item update).\n\n**Exit criteria** — After the selected path’s approvals, automatically verify the self-contained record for that path, communicate the authorized outcome to sponsor and counsel, and record cycle closure.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-document-upload","coach-item-update"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:grc-vendor-due-diligence-contracting-gate"}