{"description":"Runs automatically on a new System item marked as a vendor (System.vendor is true). Collect the requester's business facts and the vendor's security questionnaire, assess system and third-party risk, and approve the onboarding decision. Deliver the approved system risk review record, set the System item's tier, data classification, monitoring status and last and next assessment dates, and hand open actions to the responsible register owner; the yearly System & Third-Party Risk Review takes over from there.","edges":[{"id":"e-vendor-request-intake-vendor-security-questionnaire","source":"vendor-request-intake","target":"vendor-security-questionnaire"},{"id":"e-vendor-security-questionnaire-system-risk-assessment","source":"vendor-security-questionnaire","target":"system-risk-assessment"},{"id":"e-system-risk-assessment-system-review-closure","source":"system-risk-assessment","target":"system-review-closure"}],"isPublic":true,"itemTypeSlug":"system","metadata":{"capabilities":["new-vendor-onboarding"],"controlVerbs":{"UC-CONFIG-10":"operates","UC-RISK-18":"operates","UC-TPRM-02":"operates","UC-TPRM-04":"operates","UC-TPRM-08":"operates"},"controls":["UC-RISK-18","UC-TPRM-02","UC-CONFIG-10","UC-TPRM-08","UC-TPRM-04"],"department":"risk-management","domains":["grc"],"formRespondents":{"vendor-request-intake":{"missingInputs":"The type and description of the products and services, the impacted locations, the access the vendor needs, the most sensitive data it will handle, how much the business depends on its availability, and the vendor security contact","nonExecuting":true,"role":"The person who requested the vendor, outside every executing and approving role in this workflow"},"vendor-security-questionnaire":{"missingInputs":"The current independent assurance report, subprocessors, data locations, encryption, security incidents in the last 24 months and recovery commitments","nonExecuting":true,"role":"The vendor's security contact, outside the organization"}},"kind":"new-vendor-onboarding","library":{"aliases":[{"source":"studio-seed","sourceTemplateId":"coworkcanvas:template:new-vendor-onboarding"}],"canonicalUrl":"https://evidenceflows.com/workflows/all/?w=grc-new-vendor-onboarding","contentDigest":"sha256:30ac179fd116d09282f0116498473c3c250a9a7c00dc76f5e09b77649ef50b92","prerequisites":{"anchorItemType":{"slug":"system"},"evidenceDestinations":[{"description":"Restricted native step results, the requester and vendor form responses, the vendor's assurance report as a step document, durable System item fields and native approvals.","id":"review-evidence"}],"fields":[{"itemTypeSlug":"system","key":"vendor"},{"itemTypeSlug":"system","key":"tier"},{"itemTypeSlug":"system","key":"data_classification"},{"itemTypeSlug":"system","key":"business_owner"},{"itemTypeSlug":"system","key":"reassessment_cadence"},{"itemTypeSlug":"system","key":"last_assessment_date"},{"itemTypeSlug":"system","key":"next_reassessment_date"},{"itemTypeSlug":"system","key":"monitoring_status"}],"handoffs":[{"direction":"input","name":"Vendor request submitted by the requester on the first step's form"},{"direction":"input","name":"Security questionnaire answered by the vendor on the second step's form"},{"direction":"output","name":"Approved vendor due for its next yearly review","sourceTemplateId":"workflow-library:grc-system-third-party-risk-review"}],"roles":[{"contribution":"expertise","description":"Third-party risk analyst. Sets the review depth from the requester's answers and judges whether the vendor's questionnaire and evidence are complete.","id":"tprm-analyst","nodeIds":["vendor-request-intake","vendor-security-questionnaire"]},{"contribution":"expertise","description":"System owner and technical specialist. Assess system and third-party risk.","id":"reviewer-1","nodeIds":["system-risk-assessment"]},{"contribution":"approval","description":"Independent system-risk reviewer. Approve the onboarding decision and the system risk review record.","id":"reviewer-2","nodeIds":["system-review-closure"]}],"status":"declared"},"provenance":[{"source":"workflow-library","sourceTemplateId":"coworkcanvas:template:new-vendor-onboarding"}],"releaseId":"sha256:30ac179fd116d09282f0116498473c3c250a9a7c00dc76f5e09b77649ef50b92","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-new-vendor-onboarding"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-new-vendor-onboarding","source":"coworkcanvas-gallery","standards":["iso-27001","nist-800-53","soc2"],"teams":["risk-management","procurement","it"]},"name":"New Vendor Onboarding","nodes":[{"data":{"controls":["UC-RISK-18"],"description":"The third-party risk analyst sets the depth of the review from the requester's answers; the requester supplies the business facts on the form.","formData":{"fields":[{"key":"product_type","label":"What type of product or service will the vendor provide?","options":[{"label":"Software as a service","value":"saas_software"},{"label":"Cloud infrastructure","value":"cloud_infrastructure"},{"label":"Managed service","value":"managed_services"},{"label":"Professional services","value":"professional_services"},{"label":"Data processing","value":"data_processing"},{"label":"Hardware or equipment","value":"hardware_supplier"},{"label":"Facilities","value":"facilities"},{"label":"Other","value":"other"}],"required":true,"type":"select"},{"key":"products_services","label":"Describe the products and services, and the business process they support","required":true,"type":"textarea"},{"key":"impacted_locations","label":"Which of our locations, sites or regions will the vendor serve or affect?","required":true,"type":"textarea"},{"key":"access_requirements","label":"What access will the vendor need to our systems, data, networks or facilities?","required":true,"type":"textarea"},{"key":"data_classification","label":"What is the most sensitive data the vendor will receive, store or access?","options":[{"label":"None","value":"none"},{"label":"Public","value":"public"},{"label":"Internal","value":"internal"},{"label":"Confidential","value":"confidential"},{"label":"Restricted","value":"restricted"}],"required":true,"type":"select"},{"key":"vendor_availability","label":"How much do we depend on this vendor being available?","options":[{"label":"Critical","value":"critical"},{"label":"Important","value":"important"},{"label":"Less important","value":"less_important"},{"label":"Other","value":"other"}],"required":true,"type":"select"},{"key":"vendor_security_contact_email","label":"Vendor security contact email","required":true,"type":"email"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nEstablish what the business is asking the vendor to do and set the depth of the onboarding review from the requester's answers.\n\n**Inputs**\n- The System item created for the vendor: its title, `System.category`, `System.business_owner` and any other field the requester already set.\n- This step's form, answered by the person who requested the vendor.\n- The System register, to check whether this vendor, or a service approved for the same purpose, already exists.\n\n**Procedure**\n1. Send this step's form to the person who requested the vendor. Where the request or the System item already answers a question, a first draft of that answer may be suggested on the form for the requester to confirm or correct; a drafted answer counts only once the requester submits it. Do not ask for anything the System item already records.\n2. Search the System register for the same vendor or an approved service with the same purpose. If one exists, name it so the approver can weigh reuse against a new vendor.\n3. From the submitted answers, propose `System.category` (from the product type), `System.data_classification` and `System.tier`. Vendor availability guides the tier: critical suggests `critical`, important suggests `high`, less important suggests `medium` or `low`, and other needs the analyst's judgment. Give the reason for each.\n4. Check the impacted locations and access requirements against the data classification, and note any access to restricted data, production systems or facilities that the security questionnaire must cover.\n5. Set the questionnaire depth. A vendor that will hold confidential or restricted data, needs privileged or production access, or is critical to availability answers every question and supplies an independent assurance report. A vendor that sees only public or internal data and needs no system access may skip the report.\n6. Confirm the vendor security contact from the form so the questionnaire can go out.\n\n**Record in AssureSwarm**\n- Step form: the requester's answers (`product_type`, `products_services`, `impacted_locations`, `access_requirements`, `data_classification`, `vendor_availability`, `vendor_security_contact_email`).\n- Item field update: `System.category`, `System.data_classification`, `System.tier`, and `System.business_owner` when it is blank.\n- Step result: the proposed category, tier and data classification with reasons, the access and locations the questionnaire must cover, the questionnaire depth, and any existing vendor or service that could be reused.\n\n**Exit criteria**\nThird-party risk analyst provides expertise: the category, tier, data classification and questionnaire depth follow from the requester's submitted answers, the vendor security contact is known, and any duplicate or reusable service is named.\n\n**Form recipient** — this step's form is answered by the person who requested the vendor, who holds none of this workflow's executing or approving roles. Send it with a form assignment; the analyst's own work goes in the step result.","kind":"task","label":"Scope the vendor request","requiredApprovals":1},"id":"vendor-request-intake"},{"data":{"controls":["UC-TPRM-02"],"description":"The vendor's security contact answers the questionnaire; the analyst judges whether the answers and evidence are enough to assess the vendor and chases what is missing.","formData":{"fields":[{"key":"assurance_report","label":"Your current SOC 2 Type II report, ISO/IEC 27001 certificate or equivalent independent assurance report","type":"file"},{"key":"subprocessors","label":"Which subprocessors will handle our data, and for what?","required":true,"type":"textarea"},{"key":"data_locations","label":"Where will our data be stored and processed (countries or regions)?","required":true,"type":"text"},{"key":"encryption","label":"How is our data encrypted at rest and in transit?","type":"textarea"},{"key":"incident_history","label":"Security incidents in the last 24 months that affected customer data, and what changed afterwards","required":true,"type":"textarea"},{"key":"recovery_commitments","label":"Recovery time and recovery point commitments for the service, and when they were last tested","type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nObtain the vendor's security facts and evidence, and decide whether they are complete enough to assess the vendor.\n\n**Inputs**\n- The questionnaire depth, data classification and vendor security contact from Scope the vendor request.\n- This step's form, answered by the vendor's security contact.\n- The vendor's public security or trust page, published certifications and any reported breaches.\n\n**Procedure**\n1. Send this step's form to the vendor security contact. When the questionnaire depth allows it, tell the contact the assurance report is optional.\n2. Read the uploaded assurance report before relying on any answer it covers. Take the report type, period, opinion, exceptions, subservice organizations and complementary user entity controls from the report itself instead of asking the vendor to restate them.\n3. Compare each answer with the report and the public sources, and mark answers the evidence contradicts or does not support.\n4. Check the subprocessors and data locations against the data classification. Flag any location or subprocessor the classification does not allow.\n5. Follow up with the vendor on missing or contradicted answers, and record what was asked, when, and what came back.\n\n**Record in AssureSwarm**\n- Step form: the vendor's answers (`assurance_report`, `subprocessors`, `data_locations`, `encryption`, `incident_history`, `recovery_commitments`).\n- Step document: the assurance report as the vendor uploaded it (PDF).\n- Step result: the evidence summary, covering report period and opinion, exceptions, subservice organizations, complementary user entity controls, contradicted or unsupported answers, and open follow-ups with owners and dates.\n\n**Exit criteria**\nThird-party risk analyst provides expertise: the answers and evidence are complete enough to assess the vendor, every contradicted or unsupported answer is listed, and each outstanding follow-up has an owner and a date.\n\n**Form recipient** — this step's form is answered by the vendor's security contact, who is outside the organization and holds no role in this workflow. Send it with a form assignment; the analyst's evidence review goes in the step result.","kind":"task","label":"Review the vendor security questionnaire","requiredApprovals":1},"id":"vendor-security-questionnaire"},{"data":{"controls":["UC-CONFIG-10","UC-TPRM-08"],"instructions":"**Objective**\nAssess system and third-party risk. The reviewer decides from the complete package described below.\n\n**Inputs**\n1. Review the System item, architecture and data-flow records, inventory, contracts, service descriptions, business impact analysis, prior assessments, incidents, changes, user populations, and provider documentation.\n2. Use the confirmed scope, risk criteria, due-diligence responses, security and privacy evidence, service performance, incidents, vulnerabilities, continuity tests, contract terms, change history, monitoring, and prior findings.\n3. Use the requester's answers, tier and data classification from Scope the vendor request, and the vendor's answers, assurance report and evidence summary from Review the vendor security questionnaire.\n\n**Procedure**\n1. Reconcile inventory and ownership, map data types and trust boundaries, identify critical business processes and integrations, distinguish provider and customer responsibilities, identify material fourth parties, and document scope changes.\n2. Evaluate threats and business impacts, inspect control and performance evidence, assess concentration and exit risk, compare contract commitments to practice, analyze incidents and changes, and challenge ratings based only on questionnaires or attestations.\n\nMap data flows, access boundaries and system/provider dependencies explicitly and inspect associated security/control coverage.\n\n**Record in AssureSwarm**\n1. Capture the review period, system and service scope, owners, provider, environments, data classification, users, integrations, critical processes, subservices, locations, changes, exclusions, and information gaps.\n2. Document risk ratings and direction, criteria, evidence, control strengths and gaps, provider and customer responsibilities, concentration and resilience concerns, incidents, uncertainties, and prior-period comparison. Also record risk assessment.\n\n**Exit criteria**\nSystem owner and technical specialist provides expertise: The review boundary and responsibility model are unambiguous, critical dependencies are represented, and missing information that could affect risk is assigned. The assessment is reproducible, material gaps and uncertainty remain visible, and rating changes or reliance on provider evidence are supported before response selection.","kind":"task","label":"Assess system and third-party risk","requiredApprovals":1},"id":"system-risk-assessment"},{"data":{"controls":["UC-TPRM-02","UC-TPRM-04"],"instructions":"**Objective**\nApprove system risk review record. The reviewer decides from the complete package described below.\n\n**Inputs**\n1. Use the completed assessment, open findings, service roadmap, remediation commitments, contract rights, business continuity and exit plans, stakeholder needs, appetite criteria, and proposed monitoring indicators.\n2. Review every stage result, source evidence, ratings, provider and customer responsibilities, response approval, linked issues, monitoring commitments, contract actions, and information gaps.\n\n**Procedure**\n1. Compare continued use, remediation, restriction, replacement, and exception paths; define commitments and evidence; confirm decision authority; set performance and risk triggers; plan escalation and exit readiness; and create linked actions.\n2. Trace material ratings and decisions to evidence, verify commitments and dates, reconcile inventory and linked records, confirm contrary evidence remains visible, and return unsupported or inconsistent analysis for correction.\n3. For a new vendor, the response is approve, approve with conditions (each condition with an owner and a date), or decline. A declined vendor is not enrolled for monitoring and its open actions are closed.\n\n**Record in AssureSwarm**\n1. Record the decision, rationale, authorized approver, remediation commitments, monitoring indicators and cadence, contract actions, restrictions, contingency or exit steps, linked issues, owners, and due dates. Also record response decision; monitoring plan.\n2. Capture the authorized reviewer, review summary, accepted ratings and response, review effective date, monitoring cadence, provider commitments, linked issues, limitations, owners, and due dates. Also record system risk review summary.\n3. After this step is approved, update the System item: set `System.last_assessment_date` to the approval date and `System.next_reassessment_date` to that date plus `System.reassessment_cadence` (quarterly adds 3 months, semi_annual 6, annual 12, biennial 24; for ad_hoc, leave the next date for the risk owner to set). Set `System.monitoring_status` to `enrolled` when the vendor is approved and `not_enrolled` when it is declined.\n\n**Exit criteria**\nIndependent system-risk reviewer provides approval: An approver accepts that the response follows from risk and criticality, decision authority is confirmed, and monitoring and action commitments are measurable. The authorized reviewer accepts the review as a traceable record of work and decisions, related records can be updated consistently, and closure is not represented as assurance. After approval, the System item's `last_assessment_date` equals the approval date and `next_reassessment_date` follows its `reassessment_cadence`. `monitoring_status` matches the onboarding decision.","kind":"task","label":"Approve system risk review record","requiredApprovals":1},"id":"system-review-closure"}],"sourceTemplateId":"workflow-library:grc-new-vendor-onboarding"}