{"description":"Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.","edges":[{"id":"e-confirm-report-scope-classify-disposition","source":"confirm-report-scope","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-21","UC-TPRM-04"],"department":"procurement","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-vendor-soc-cuec-review","contentDigest":"sha256:31af594ee8aeb5af01927dcc0e95bf6ea9f05a8d45fd1524d012709768b688e0","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:31af594ee8aeb5af01927dcc0e95bf6ea9f05a8d45fd1524d012709768b688e0","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-vendor-soc-cuec-review"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-vendor-soc-cuec-review","source":"coworkcanvas-gallery","standards":["soc1","soc2"],"teams":["procurement","it"]},"name":"Vendor SOC 1/SOC 2 Report Review & CUEC Mapping","nodes":[{"data":{"description":"Judge the report’s relevant coverage, actual exceptions, operating CUECs and bridge evidence, documenting objective-level assurance limitations.","formData":{"fields":[{"key":"material_changes","label":"Unresolved material control-environment changes in the specified gap period","required":false,"type":"textarea"},{"key":"incidents_in_period","label":"Unresolved service-affecting incidents in the specified gap period","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge the report’s relevant coverage, actual exceptions, operating CUECs and bridge evidence, documenting objective-level assurance limitations.\n\n**Inputs**\nThe vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow: vendor name, risk tier, the business process(es) that depend on the vendor, and the assurance requirement (SOC 1 vs SOC 2, and which Trust Services Criteria or ICFR-relevant processes must be covered).\n- The service organization's latest SOC report PDF(s) and any subservice-organization reports referenced inside them.\n- Your organization's reliance date / audit period (the period for which you need assurance).\n- The existing Vendor item that arrived in the upstream handoff (Vendor.tier, business_owner, risk_owner) — an input, not something this workflow seeds — plus the anchor Audit item (audit_type: vendor_review) this instance runs on, which doubles as the SOC Report record.\n\nThe confirmed SOC report and scope from the report-scope step (report kind/type, period, in-scope services).\n- Section IV of the report (the service auditor's tests of controls and results) and the opinion letter (Section I).\n- The control objectives / Trust Services Criteria relevant to the services you consume.\n- Your control dependency map (which vendor controls your process actually relies on).\n\nThe confirmed SOC report and scope; specifically the CUEC section (usually Section III or an appendix listing \"complementary user entity controls\").\n- Any subservice-organization expectations (complementary subservice organization controls) surfaced by the carve-out/inclusive analysis.\n- Your internal control library / RCM (item type \"Control\") for the affected processes.\n- CUEC-relevant exceptions flagged during the opinion/exception review.\n\nThe confirmed report period end date and your reliance date (from the report-scope step).\n- The service organization's bridge letter / gap letter, if provided.\n- The coverage gap noted during scope confirmation.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. SOC assurance analyst owns the stated judgments and authorizations.*\n\n*Confirm report scope.* Confirm exactly which service-organization report(s) this review relies on and pin down their kind, type, period, and boundary so every downstream analysis works from the same current, in-scope artifact.\n\n1. Match the report kind to the need: SOC 1 (ICFR / financial-reporting controls) vs SOC 2 (security, availability, and the other Trust Services Criteria). A SOC 2 does not support financial-statement reliance and a SOC 1 does not support security/availability reliance — if the kind does not match the dependency, stop and request the correct report.\n2. Confirm Type I vs Type II. Type I opines on design at a point in time only; Type II opines on operating effectiveness over a period and is what control reliance requires. A Type I alone cannot support operating-effectiveness reliance — flag it and plan a bridge or alternative procedure.\n3. Record the report period (start and end dates) and compare it to your reliance period. Note any portion of your period the report does not cover; that gap feeds the bridge-period analysis.\n4. Map the report boundary: which systems, services, and locations are in scope, and which services you consume fall outside it. Services you use that the report excludes get no reliance.\n5. Resolve subservice organizations: determine carve-out vs inclusive method. For each carved-out subservice org, note that you need its own SOC report (log it as an Issue item, issue_type: observation); the CUEC section will also list expectations passed down to it.\n6. Confirm the report is current and authentic: issued by a licensed CPA firm, dated, and the latest available version. Record the CPA firm and report date.\n\n*Review opinion and exceptions.* Read the service auditor's opinion and every noted exception/deviation, then determine what each means for your reliance so the reliance conclusion rests on the actual test results, not just the opinion letter.\n\n7. Read the opinion type: unqualified (clean), qualified (specific controls were not designed or did not operate effectively), adverse, or disclaimer. Anything other than unqualified narrows or voids reliance on the affected objectives — record which.\n8. Extract every exception, deviation, and \"control did not operate effectively\" note from Section IV. For each, capture the control objective/TSC, the control tested, the nature of the deviation, and the deviation count vs sample size.\n9. Assess each exception's impact on your reliance: does the affected control support a control objective your process depends on? If not, impact is low or none — document why. If yes, evaluate severity: isolated vs pervasive, whether management responded, and whether a compensating control (yours or the vendor's) covers the risk.\n10. Check management's response and the service auditor's follow-up for each exception; a remediated, retested exception carries less residual risk than an open one.\n11. Determine, per relevant control objective, a reliance verdict: rely, rely-with-compensating-control, or cannot-rely. Tie each verdict to the evidence (opinion plus the specific exception).\n12. Flag any exception whose mitigation depends on a control on your side, and pass that flag to the CUEC mapping analysis.\n\n*Map CUECs.* Map each complementary user entity control (CUEC) the report assigns to you against a real control on your side, and identify any CUEC that is unmet, so the reliance conclusion reflects your own obligations and not just the vendor's.\n\n13. Extract the full list of CUECs from the report. Each CUEC is a control the service organization assumes YOU perform for its controls to be effective (e.g., \"user entities are responsible for provisioning and de-provisioning their own users' access\").\n14. For each CUEC, locate the matching internal control in your control library. Record the mapped control id, owner, and whether it is a key control.\n15. Classify each mapping as Implemented (a real control covers it), Partial (covered but with a gap), or Unmet (no control exists). For Partial and Unmet, describe the exposure created.\n16. For access-related CUECs, confirm the control genuinely operates (e.g., periodic access reviews, timely de-provisioning) — a CUEC that exists on paper but no one performs is Unmet. Reference control UC-ACCESS-21 where the CUEC concerns user-entity access administration.\n17. Cross-reference the CUEC-flagged exceptions: if the report noted a deviation whose mitigation depends on a user-entity control, the corresponding CUEC must be Implemented; if it is Unmet, escalate the combined exposure.\n18. Summarize residual exposure from all Partial and Unmet CUECs; this feeds the reliance conclusion and any action plan. Tag UC-TPRM-04 for the third-party dependency this mapping evidences.\n\n*Evaluate bridge period.* Determine whether the SOC report's coverage extends to your reliance date and, where it falls short, evaluate the bridge/gap letter so no uncovered period is silently relied upon.\n\n19. Compute the gap: the number of days between the report period end date and your reliance date. No gap → note \"fully covered\" and record; the bridge analysis is trivially satisfied.\n20. If a gap exists, request the signed bridge letter from the vendor’s assurance contact by document upload, and confirm the returned letter is signed by service-organization management, references the specific SOC report, and explicitly covers the gap dates through (at least) your reliance date.\n21. Evaluate the bridge letter's assertions: it should state that no material changes to the control environment occurred and no control failures are known during the gap. A bridge letter that merely restates the report period, or is unsigned or undated, does not close the gap.\n22. Assess gap length and risk: use the organization’s approved methodology, gap length and known changes rather than treating 90 days as an automatic safe harbor. A management bridge letter supplies assertions, not independent operating-effectiveness tests and does not turn a Type I report into Type II assurance. A longer gap (for example, over 90 days) or one spanning a known change (system migration, M&A, incident) warrants additional procedures — request an updated report or perform alternative testing.\n23. For any gap not closed by an acceptable bridge letter, define the residual coverage exposure and the alternative procedure needed; this feeds the reliance conclusion and any action plan.\n\n**Record in AssureSwarm**\nUpdate the anchor Audit item: set `external_firm` = CPA firm, `period_start`/`period_end` = the report coverage period, and `report_date`; record the report kind (SOC 1/2), type (I/II), carve-out/inclusive method, and in-scope services in `Audit.scope` (no native field exists for these).\n- Attach the report PDF(s) to this step (document upload) and link the anchor Audit to the dependent Process items.\n- Create an Issue item (issue_type: observation) for any coverage gap vs your reliance period and for each missing subservice-org report, each linked to the anchor Audit.\n\nCreate an Issue item per noted deviation (issue_type: exception, source: external_audit, severity, description = affected control objective + deviation rate, management_response = management's response and your impact verdict), linked Issue ↔ affected Control and Issue ↔ anchor Audit.\n- Set `Audit.opinion` (unqualified/qualified/adverse/disclaimer) and attach the marked-up opinion and Section IV excerpts as a step document.\n- Tag any Issue whose mitigation requires a complementary user entity control for the CUEC mapping step.\n\nBuild the CUEC mapping matrix as an XLSX step document (upload to this step) — one row per report CUEC with its text, mapped internal control, owner, and status (Implemented/Partial/Unmet); there is no native CUEC item type.\n- Materialize only the Partial/Unmet rows as Issue items (issue_type: deficiency, root_cause = CUEC gap), each linked to the matched internal Control item and the anchor Audit; tag UC-ACCESS-21 and UC-TPRM-04 where relevant.\n- Note residual exposure for every Partial and Unmet CUEC in its Issue.\n\nRead the report and signed bridge letter first, extracting dates, signer and assertions. Only if private change or incident facts remain unresolved, assign the attached factual request to an outside vendor assurance contact. State the known report and exact gap dates in the assignment and identify which unresolved questions need a response; unasked fields may stay blank, but every requested uncertainty must be resolved or carried into an explicit assurance limitation. The analyst’s evaluation and approvals remain native results.\n- Record the bridge-period evaluation as an adequacy-note step document (gap days, bridge-letter received, adequacy, residual exposure) — no item type has native fields for these.\n- Attach the bridge letter to this step and link it to the anchor Audit.\n- Create an Issue item (issue_type: observation) for any uncovered period, with the planned alternative procedure in `recommendation`.\n\n**Exit criteria**\nReport kind and type match the assurance need; period, boundary, and subservice-org method are recorded; the report PDF is attached and linked; any coverage gaps or missing subservice reports are logged.\n\nOpinion type recorded; every exception captured with an impact verdict tied to evidence; per-objective reliance verdicts documented; CUEC-relevant exceptions flagged for the mapping step.\n\nEvery report CUEC is mapped to an internal control with a status; Partial/Unmet CUECs carry a documented exposure; access CUECs are confirmed as operating; the matrix is attached and linked.\n\nGap computed; bridge letter evaluated for signature, scope, and assertions; adequacy recorded; any uncovered period carries a documented residual exposure and alternative procedure.\n\n**Form recipient** — Send only missing private facts to a vendor assurance contact outside the full workflow executor and approver roster, after reviewing existing artifacts. If the proposed contact executes or approves a checkpoint, record that person’s contribution in native workflow results instead.","label":"Confirm report scope","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-item-update","coach-document-upload","coach-items-link","coach-query-data"]}},"id":"confirm-report-scope"},{"data":{"decisionField":"disposition_path","description":"Authorize the evidence-backed overall reliance conclusion and select complete, corrective action or monitored-risk treatment.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Authorize the evidence-backed overall reliance conclusion and select complete, corrective action or monitored-risk treatment.\n\n**Inputs**\nThe per-objective reliance verdicts and exception impacts from the opinion/exception review.\n- The CUEC mapping matrix with statuses and residual exposures.\n- The bridge-period adequacy result and any uncovered-period exposure.\n- The vendor's risk tier and dependent processes from the scope step.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Control owner or third-party-risk reliance lead owns the stated judgments and authorizations.*\n\n*Document reliance conclusion.* Synthesize the opinion/exception verdicts, CUEC mapping, and bridge-period evaluation into a single, evidence-backed reliance conclusion so a reviewer can see, in one place, whether and how far the organization may rely on the service organization's controls.\n\n1. Consolidate the three analyses into a reliance summary per relied-upon control objective / Trust Services Criterion: state rely / rely-with-compensating-control / cannot-rely, with the driving evidence (opinion, exception, CUEC status, bridge coverage).\n2. Roll up to an overall reliance conclusion: Full reliance, Qualified reliance (reliance subject to named compensating controls or open items), or No reliance (assurance insufficient — alternative procedures or vendor remediation required).\n3. List every open exposure feeding the conclusion: qualified-opinion areas, unremediated exceptions on relied-upon objectives, Partial/Unmet CUECs, and uncovered bridge periods. Each exposure gets an owner and a proposed disposition.\n4. Weigh the conclusion against the vendor's risk tier: a high-tier vendor with qualified reliance and open exposures generally cannot be dispositioned as complete — it drives gaps or monitoring.\n5. Draft the reliance memo: purpose, report(s) reviewed, method, per-objective results, overall conclusion, open exposures, and recommended disposition. Write it so the disposition decision and any downstream regulatory-assurance workflow can consume it without re-reading the raw report.\n\n*Classify disposition.* Decide how to close out this SOC review — clean, gaps requiring action, or monitor — and record who owns the call so the workflow keeps only the relevant closure path. Owned by the control owner / third-party-risk lead accountable for vendor reliance.\n\n\n\n**complete (Complete)** — The overall reliance conclusion is Full reliance, or Qualified reliance whose conditions are already satisfied: an unqualified opinion on relied-upon objectives, no unremediated exceptions on those objectives, all CUECs Implemented, and the bridge period fully covered. No follow-up work is required beyond archiving.\n- **gaps (Gaps require action)** — One or more open exposures need remediation before or during reliance: a qualified/adverse opinion on a relied-upon objective, an unremediated exception, a Partial/Unmet CUEC, or an uncovered bridge period. Pick this whenever an exposure has a concrete corrective owner and due date.\n- **monitor (Monitor without immediate action)** — Reliance holds for now but a residual risk must be watched rather than fixed (e.g., a low-severity exception on a non-critical objective, a subservice-org report still pending, or a change expected next period). Pick this to route to a risk-acceptance/escalation decision rather than a corrective action plan.\n\n**Record in AssureSwarm**\nSet the anchor Audit's `rating` as the overall reliance verdict (satisfactory = full reliance | needs_improvement = qualified reliance | unsatisfactory = no reliance); the per-objective summary rides in the reliance memo.\n- Attach the reliance memo (document upload) to this step.\n- Ensure each open exposure is a linked Issue item with `issue_owner` set.\n\nSubmit the `disposition_path` SELECT with the chosen value; record the decision owner/approver in the step's approver record; write the rationale and evidence references (which exposures drove the call) in the step result.\n\n**Exit criteria**\nPer-objective and overall reliance conclusions recorded with evidence; all open exposures listed with owners; the reliance memo is attached and links back to the source analyses; the recommended disposition is stated.\n\nThe SELECT is submitted with a rationale and owner; exactly one branch remains active and the unused branches are prunable.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"classify-disposition"},{"data":{"description":"Turn each open exposure into an owned, dated corrective action plan","instructions":"**Objective** — Turn each open exposure from the reliance review into an owned, dated corrective action plan so gaps are remediated and re-validated rather than merely noted.\n\n**Inputs**\n- The open exposures list from the reliance conclusion (qualified opinions, unremediated exceptions, Partial/Unmet CUECs, uncovered bridge periods).\n- The disposition rationale (why \"gaps\") and the decision owner.\n- Internal control owners for the affected processes.\n\n**Procedure**\n1. For each exposure, state the root cause: a vendor control failure, a user-entity (CUEC) gap on your side, or a coverage/evidence gap.\n2. Propose an accountable owner and a due date proportionate to severity and vendor risk tier, and obtain the owner’s native acceptance before recording the commitment. CUEC gaps are yours to fix directly; vendor control failures require a vendor remediation request tracked to closure.\n3. Define an interim mitigation for each exposure that leaves live risk open until the fix lands (e.g., heightened monitoring, manual reconciliation, restricting the vendor-supported process).\n4. Specify the validation evidence that will close each item (retest, updated CUEC operation proof, updated or bridged SOC report) and the reporting cadence to leadership.\n5. Set a re-review trigger: the date or event (next SOC report, remediation completion) that reopens this workflow or hands the item to monitoring.\n\n**Record in AssureSwarm**\n- Update each exposure's Issue item with `remediation_plan` (root cause, interim mitigation, validation evidence), `issue_owner` (USER), and `target_remediation_date`; link each Issue ↔ affected Control.\n- Note the open action items against the anchor Audit.\n\n**Exit criteria** — Every \"gaps\" exposure has an owned, dated action item with interim mitigation and defined validation evidence; items are linked to their exposures; a re-review trigger is set.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — routes each action item to its owner with the exposure, due date, and validation evidence attached.","label":"Create action plan","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-items-link","coach-item-update","coach-notify"]}},"id":"create-action-plan"},{"data":{"description":"Escalate the monitored residual risk to the accountable authority or document a formal risk acceptance","instructions":"**Objective** — For a \"monitor\" disposition, either escalate the residual reliance risk to the accountable authority or document a formal risk acceptance, so watched exposures have an explicit owner and revisit trigger rather than drifting.\n\n**Inputs**\n- The reliance conclusion's residual exposures marked for monitoring (not immediate fix).\n- The disposition rationale (why \"monitor\") and the decision owner.\n- The vendor risk tier and the organization's risk-acceptance authority matrix.\n\n**Procedure**\n1. For each monitored exposure, quantify the residual risk: likelihood, potential impact on the dependent process, and the assurance shortfall (e.g., a pending subservice report, a low-severity exception).\n2. Determine the required authority: route to the control owner, assessor lead, system owner, or authorizing official per the risk-acceptance matrix and the vendor's tier. Higher tier or higher impact demands higher authority.\n3. Prepare the decision memo: the exposure, residual risk, why immediate remediation is not warranted, the conditions of acceptance, and the monitoring plan (what is watched, how often, by whom).\n4. Obtain and record the acceptance decision, or the escalation outcome if the authority declines. For declined acceptance, record the required owned corrective commitments, interim mitigation and validation evidence within this escalation result before handoff; do not try to execute the already-pruned corrective branch.\n5. Set the revisit trigger: the date or event (next SOC report, subservice report receipt, incident) that reopens the exposure for reassessment.\n\n**Record in AssureSwarm**\n- Create or update a Risk item per monitored exposure (category: third_party, residual_rating, risk_owner = the accountable authority; actual decision, conditions, monitoring plan, and revisit trigger in `description`). Set treatment to accept only after authorized acceptance; otherwise record the actual escalated treatment. Link Risk ↔ anchor Audit and Risk ↔ affected Control.\n- Attach the decision memo to this step and capture the approver.\n\n**Exit criteria** — Each monitored exposure has a recorded acceptance (or escalation outcome) by the correct authority, a monitoring plan, and a revisit trigger; the decision memo is attached.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-items-link","coach-document-upload","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Accept the final reliance package and transferred exposure/action ownership before archival and the next review are recorded.","instructions":"**Objective** — Accept the final reliance package and transferred exposure/action ownership before archival and the next review are recorded.\n\n**Inputs**\nThe reliance conclusion memo and linked exposures.\n- The CUEC mapping matrix, exception records, and bridge-period evaluation.\n- Any action-plan items (gaps path) or risk-acceptance memo (monitor path).\n- The confirmed SOC report and scope record.\n\nThe final reliance package and one-page summary from the package step.\n- The disposition and any open action items or risk acceptances.\n- The Vendor record and the anchor Audit (which carries the SOC Report and Reliance Conclusion) to link into the downstream workflows.\n- The retention policy for vendor assurance evidence.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Receiving regulatory-assurance and ISCM owners owns the stated judgments and authorizations.*\n\n*Prepare final package.* Assemble the complete, reviewable SOC-reliance package — report, analyses, CUEC matrix, reliance conclusion, and any action items or risk acceptances — so a single artifact supports the decision and hands cleanly to downstream workflows.\n\n1. Compile the package contents: scope confirmation, the marked-up opinion/exception analysis, the CUEC matrix, the bridge-period result, the reliance conclusion, and the disposition with its rationale and owner.\n2. Attach the corrective action plan (if disposition = gaps) or the risk-acceptance/escalation memo (if disposition = monitor); for a clean disposition, note explicitly that no open items remain.\n3. Verify internal consistency: the overall reliance conclusion matches the per-objective verdicts, every open exposure has an owner and a disposition, and no analysis referenced in the memo is missing from the package.\n4. Confirm evidence completeness: the report PDF, bridge letter, and CUEC matrix are all attached and version-stamped, and links to Vendor and Control records resolve.\n5. Produce the reviewer-ready one-page summary: vendor, report reviewed, overall reliance, key exposures, and disposition — the artifact a reviewer signs and a downstream workflow consumes.\n\n*Handoff to related workflow.* Pass the completed reliance package to the downstream workflows that consume it — Third-Party ICT Vendor Regulatory Assurance and the Continuous Controls Monitoring (ISCM) Cycle — and close the SOC review in the same motion with a complete, immutable audit trail; the human moment is confirming the downstream owners have accepted the transferred exposures and action items.\n\n_Items 11–14 close the workflow (folded from the former \"Close and archive\" step); the reliance decision handed off here is the closure — there is no separate confirmation._\n6. Identify the correct downstream consumers: Third-Party ICT Vendor Regulatory Assurance (for regulated-dependency reporting) and the Continuous Controls Monitoring Cycle (for ongoing monitoring of the residual exposures and revisit triggers).\n7. Create or link the downstream workflow instance for this vendor and attach the final package as its input handoff.\n8. Write the handoff note: the reliance conclusion, the exposures and their revisit triggers, and an explicit \"do not repeat\" list — the scope confirmation, opinion/exception analysis, CUEC mapping, and bridge evaluation are done, so downstream should consume them rather than redo them.\n9. Confirm ownership transfer: name who owns the monitored exposures and action items in the downstream workflow so nothing is dropped at the boundary.\n10. Notify the downstream owners that the package is ready, and verify the closure preconditions — the disposition is recorded with owner and rationale, the package is complete, and the downstream owners have acknowledged the handoff.\n11. Archive the final package and all source artifacts (SOC report, bridge letter, CUEC matrix, memos) to the retention location with the applicable retention period; mark records read-only where the platform supports it.\n12. Update linked records to closed/archived status: Vendor reliance status, the SOC Report record, and the Reliance Conclusion.\n13. Schedule the next review: set the re-review date to the next expected SOC report (typically annually) and carry forward open action items and monitored exposures with their revisit triggers.\n14. Communicate the final reliance decision and any conditions to the control owner and the stakeholders who depend on the vendor.\n\n**Record in AssureSwarm**\nAssemble the package as a linked document set on the workflow; upload the compiled package and the one-page summary to this step.\n- Update the Reliance Conclusion record status to \"packaged / pending close\".\n- Confirm all referenced records (exceptions, CUECs, action items) are linked.\n\nLink this workflow's reliance package to the downstream workflow instance(s); record the handoff note and the \"do not repeat\" list.\n- Confirm each transferred exposure/action item is linked and owned in the downstream workflow.\n- Set the anchor Audit's status to closed/complete and note the next-review date in `Audit.description` (there is no native next-review field); mark the package read-only/archived. The SOC Report and Reliance Conclusion are this same anchor Audit, so closing it archives them.\n- Log the final communication and confirm carried-forward Issue/Risk items remain open under their owners in their owning workflow.\n\n**Exit criteria**\nPackage compiled with all analyses, evidence, and the disposition; internal consistency and evidence completeness verified; a one-page reviewer summary is attached and the package links resolve.\n\nDownstream workflow instance(s) exist and reference this package; the handoff note and \"do not repeat\" list are recorded; every transferred item has a named downstream owner and the owners are notified; the package and source evidence are archived under the retention policy; the review and its artifacts are closed/archived while open remediation Issues and monitored Risks remain open under their owners; the next review is scheduled with open items carried forward; the final decision is communicated and the audit trail is complete.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — compiles the scope, analyses, CUEC matrix, reliance memo, and disposition into a single reviewer-ready package with resolved links.","label":"Handoff to related workflow","performedBy":{"agent":"grc-artist","primitives":["coach-render-package","coach-document-upload","coach-items-link","coach-item-update","coach-workflow-attach","coach-notify"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-vendor-soc-cuec-review"}