{"description":"Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.","edges":[{"id":"e-lock-executable-workplan-evaluate-vendor-control-environment","source":"lock-executable-workplan","target":"evaluate-vendor-control-environment"},{"id":"e-evaluate-vendor-control-environment-classify-disposition","source":"evaluate-vendor-control-environment","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"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-evaluate-vendor-control-environment-approve-or-revise-package","source":"evaluate-vendor-control-environment","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"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-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AUDIT-12","UC-AUDIT-13","UC-AUDIT-16","UC-TPRM-01","UC-TPRM-02","UC-TPRM-04"],"department":"internal-audit","domains":["audit"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=audit-third-party-assurance-engagement","contentDigest":"sha256:559830dd60ca4ef7406b72e8d19e4c47cc75cede6d875886681f1bf77abddf64","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:559830dd60ca4ef7406b72e8d19e4c47cc75cede6d875886681f1bf77abddf64","schemaVersion":1,"sourceTemplateId":"workflow-library:audit-third-party-assurance-engagement"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"audit-third-party-assurance-engagement","source":"coworkcanvas-gallery","standards":["iia-2024"],"teams":["internal-audit","procurement"]},"name":"Third-Party Vendor Assurance Engagement","nodes":[{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Freeze the engagement's work program — scope, criteria, procedures, owners, dates, and evidence standards — so fieldwork executes commitments (Standard 13.6) instead of chasing a moving target.\n\n**Inputs**\n- The engagement's confirmed scope and criteria on the anchor Audit item — `Audit.scope` and `Audit.description` (objective, vendor tiers, lifecycle stages, entities, period, and the evaluation-criteria set) — handed off from Audit Engagement Planning; the full criteria set attached as a document at this step.\n- The engagement calendar on the anchor Audit — `Audit.period_start`/`period_end`, `Audit.fieldwork_start`/`fieldwork_end`, `Audit.report_date` — plus PBC issue date, fieldwork window, and closing meeting; per-PBC due dates recorded here when the calendar is locked.\n- The TPRM vendor register extract that will define test populations — the existing Vendor items, with a system extract uploaded at the inventory step.\n\n**Procedure**\n1. Write the work program: for each scope area (inventory and tiering, governance, reliance evaluation, monitoring controls, exclusions) state the procedures, the population and sample basis, the criteria referenced, and the auditor assigned. A procedure that cannot name its evidence in advance is not executable — fix it now.\n2. Fix the calendar backwards from the reporting date: evidence due dates per PBC item, fieldwork milestones, review windows, closing meeting. If the arithmetic does not fit the budget, cut scope explicitly with the engagement lead — planned overtime is not a strategy.\n3. Set evidence standards up front (Standard 14.1 — sufficient, reliable, relevant, useful): system extracts carry visible run dates and parameters; contracts come from the contract repository, not owner desktops; SOC reports are the issued PDFs with the service auditor's opinion, never summaries or vendor slide decks; screenshots show source and timestamp.\n4. Confirm the review chain: preparer, then in-charge, then engagement lead (Standard 12.3 supervision), plus a QA layer where the function's methodology requires one for high-risk engagements.\n5. Issue the PBC list with due dates and named owners on the management side; agree the escalation path for late items at issuance, not at breach.\n6. Lock it: from here, scope or date changes are logged change events with the engagement lead's concurrence — not quiet edits.\n\n**Record in AssureSwarm**\n- Attach the locked work program and PBC list as documents on this step (XLSX/DOCX).\n- Write the locked calendar to the anchor Audit fields (`Audit.period_start`/`period_end`, `Audit.fieldwork_start`/`fieldwork_end`, `Audit.report_date`); record the review chain and evidence standards on this step (they have no native Audit field).\n\n**Exit criteria** — Work program, calendar, review chain, evidence standards, and PBC list are locked and attached; the calendar closes against the reporting date; any later change requires a logged concurrence.","label":"Lock executable workplan"},"id":"lock-executable-workplan"},{"data":{"description":"Judge the integrated vendor population, governance, assurance reliance and monitoring evidence; concur on exclusions and determine supported findings and the scoped conclusion.","formData":{"fields":[{"key":"services_and_locations","label":"Missing service, system or location facts identified in this request; omit facts already evidenced in the contract or report","required":false,"type":"textarea"},{"key":"qualifications_and_exceptions","label":"Current remediation status for the identified qualifications or exceptions where the supplied artifacts do not establish it","required":false,"type":"textarea"},{"key":"subservice_organizations","label":"Missing subservice coverage or assurance facts identified in this request","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge the integrated vendor population, governance, assurance reliance and monitoring evidence; concur on exclusions and determine supported findings and the scoped conclusion.\n\n**Inputs**\nThe vendor register — the existing Vendor items (`Vendor.tier`, `Vendor.business_owner`, `Vendor.data_classification`, `Vendor.category`, `Vendor.contract_end_date`) — plus a system extract of them uploaded here with the run date and parameters recorded (this is IPE; treat it as such).\n- Independent completeness sources: twelve months of AP spend by payee from the ERP, the contract repository index, SSO and integration inventories for system-connected vendors, and corporate-card or expense payees for shadow spend.\n- Management's tiering methodology and the last tier-refresh evidence.\n\nThe TPRM policy and procedures — the existing Policy items (`Policy.policy_type` = policy/procedure, `Policy.framework`, `Policy.domains` = third_party_supply_chain_risk, `Policy.policy_owner`, `Policy.next_review_date`) — with approval and refresh history.\n- Governance artifacts: risk-committee or board materials and minutes covering third-party risk for the period, the program's KRIs, and concentration reporting.\n- The standard contract template and clause library; the sampled critical-vendor contracts from the frozen population.\n- Organization charts for first-line vendor owners and the second-line TPRM function.\n\nThe frozen vendor sample — the sampled Vendor items (`Vendor.data_classification`, `Vendor.category`, `Vendor.business_owner`) — with the services consumed and data classes per vendor.\n- Each vendor's assurance artifacts on file: SOC 1 and SOC 2 reports, bridge letters, ISO 27001 certificates with scope statements, completed questionnaires (SIG, CAIQ), penetration-test attestations.\n- The organization's CUEC mappings and management's SOC review sign-offs, where they exist.\n\nThe monitoring-control inventory per the TPRM policy — the existing Control items (`Control.domains` = third_party_supply_chain_risk, `Control.frequency`, `Control.control_owner`): annual assurance-report review with sign-off, SLA and scorecard reviews (monthly or quarterly by tier), questionnaire refresh, financial-health checks, vendor incident and issue management, contract-renewal gates, access recertification for vendor personnel, offboarding checklists.\n- The frozen vendor sample and period; the SLA reports, review sign-offs, and issue logs for that period (IPE — capture run parameters).\n\nThe locked work program and the actual fieldwork trail (planned versus executed).\n- Register population counts by tier and spend, to quantify what exclusions leave out.\n- Reliance decisions made during fieldwork: second-line work or reusable SOC-review workflow outputs used in place of direct testing.\n\nFinding candidates from every fieldwork step: completeness and tiering, governance and contracts, reliance evaluations, monitoring tests, and reusable SOC-review workflow outputs.\n- The function's severity scale and the criteria set from the workplan.\n- Management responses gathered during fieldwork validation sessions.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Independent IA assessors and engagement lead; CAE delegate for constrained scope owns the stated judgments and authorizations.*\n\n*Inventory and risk-tier vendors.* Establish that the vendor population management manages is the population that exists, and that risk tiering puts the right vendors under the heaviest oversight — the two facts every downstream test depends on.\n\n1. Reconcile the register against at least two independent sources, diffing both directions: payees with material spend absent from the register are shadow-vendor finding candidates (set a screening floor, such as aggregate spend above $25–50k, or any system integration regardless of spend); registered vendors with no spend and expired contracts are staleness. Quantify both rates.\n2. Evaluate the tiering methodology on its face: criteria should cover data sensitivity (PII, PHI, material nonpublic information), business criticality (the outage the business could tolerate; single-point-of-failure services), financial materiality, regulatory reach (ICFR-relevant processing, DORA-critical ICT), substitutability, and subcontracting depth. A methodology keyed on spend alone under-tiers the low-cost data processor holding the customer file.\n3. Reperform tiering for a stratified sample (20–30 vendors across tiers, weighted to the boundary between high and critical). Score each from source facts — contract, data flows, service description — not from the register's own fields. Every mis-tier is a finding datapoint; the critical vendor sitting in medium tier is the one that escaped all monitoring.\n4. Check tier hygiene: refresh cadence per policy (annually and on contract or service change), and whether vendors onboarded since the last refresh were tiered at all.\n5. Freeze the audit populations from the reconciled register — all critical-tier vendors, the high-tier sample, and any additional in-scope segments — recording the draw parameters so the selection is reproducible.\n\n*Assess vendor governance.* Conclude whether the TPRM program's governance layer — policy, ownership, oversight, and contract standards — is designed to direct the vendor lifecycle, or whether vendor risk is managed by habit and heroics.\n\n6. Test policy adequacy against the criteria set: the policy should cover the full lifecycle — planning, due diligence and selection, contracting, ongoing monitoring, termination (the interagency-guidance lifecycle is the common frame) — with tier-differentiated requirements, defined roles across the three lines, and board-level oversight. Note gaps by lifecycle stage.\n7. Verify ownership is real: every critical vendor has a named, current first-line business owner (check owners against HR status — departed employees still \"owning\" vendors is a classic), and the second-line function has a charter and headcount plausible for the register size.\n8. Read a period of oversight materials: does the committee see tier distributions, monitoring status, concentration (including fourth-party and cloud), incidents, and overdue remediations — and do minutes evidence challenge (questions asked, actions assigned), not just receipt?\n9. Test contract standards on the critical-vendor contract sample against the clause set: right-to-audit or an assurance-report delivery obligation, SLAs with remedies, security and data-protection terms with breach notification inside a defined window (24–72 hours is the common band), subcontracting notification or consent, termination assistance with data return and destruction, and insurance. Score clause presence per contract — legacy contracts predating the template are where the gaps live.\n10. Check escalation design: what happens on a failed assessment or a refused questionnaire — the policy should force an exception with an owner and expiry, not a shrug.\n\n*Evaluate vendor control environment.* Evaluate, vendor by sampled vendor, whether the organization's reliance on the vendor's control environment is earned — the right assurance artifact, covering the right services and period, with exceptions, CUECs, and carve-outs actually dispositioned — rather than a PDF filed unread.\n\n11. Match artifact to service: SOC 1 (controls relevant to user entities' ICFR) for financially significant processing — payroll, claims, custody, billing; SOC 2 on the Trust Services Criteria for the security, availability, and confidentiality of technology services. A SOC 2 does not support ICFR reliance on the payroll processor; an ISO certificate is a scope statement, not control detail — it never substitutes for a Type II where operating-effectiveness reliance is claimed.\n12. Apply type and period discipline: Type I evidences design at a point in time only; reliance on operating effectiveness requires Type II over a period covering the majority of the organization's reliance window. Where the report period ends more than about three months before the review date, require a bridge letter — a management representation, not audited assurance; it narrows the gap, it does not close it. A gap beyond about six months, or a missing bridge letter, means the artifact is stale: reliance needs compensating procedures or becomes a finding.\n13. Read the opinion and the testing-results section, not the cover: for qualified opinions, determine what is qualified and whether it touches the services consumed; for testing exceptions relevant to those services, verify management's SOC review dispositioned each one — accepted with rationale, covered by a compensating control, or followed up with the vendor. An unread exception in a filed report is the textbook reliance failure.\n14. Verify CUEC mapping: every relevant complementary user entity control in the report maps to a named internal control with an owner and a current test status. An unmapped CUEC breaks the reliance chain at the organization's own end — the service auditor's opinion assumed a control nobody here operates.\n15. Chase subservice carve-outs: list the carved-out subservice organizations (the fourth parties). For each carrying services the organization consumes, verify management either obtained the subservice organization's own report or evaluated the vendor's monitoring of it, and that complementary subservice-organization controls were considered. Carve-outs nobody chased are silent scope holes.\n16. Confirm scope match: the report's system description covers the actual services, systems, and locations consumed — a report on the vendor's US data centers does not cover the EU instance the business uses.\n17. For missing, stale or unreadable artifacts, request the current report and any bridge letter from the identified vendor contact through document upload. Extract type, reporting period, issue date, qualifications, exceptions and carve-outs from the artifact; do not ask the contact to retype them. Compare those facts with the contract and service inventory. Use this step’s optional clarification form only when a specific consumed-service fact, current remediation fact or subservice-coverage fact remains missing, and only for a vendor contact who executes none of this workflow’s checkpoints. Name the vendor, service, artifact and precise unresolved questions in the assignment; require answers to those questions while leaving already-evidenced fields unused. If no facts are missing, skip the form. Then assess the accompanying due diligence: questionnaire, site visit or exercised right-to-audit. A critical vendor with no assurance coverage and sensitive data is an immediate finding candidate and a severity input at disposition.\n18. Where a report warrants deep per-report work (dense CUEC inventories, multiple internal consumers), flag it for the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow instead of grinding it inline — record the flag with the report and its open questions so it can be routed to that workflow.\n\n*Test monitoring controls.* Test whether management's ongoing vendor monitoring actually operates — on cadence, by the right people, acting on what it finds — because a monitoring control that files reports without consequences is decoration.\n\n19. For each key monitoring control, confirm design first: performer, frequency, input, what \"review\" concretely means (defined checks, not initials), and the escalation path when the review finds something.\n20. Draw attribute samples sized to control frequency using the standard buckets — monthly 2–5 instances, quarterly 2, annual 1, plus 25–50% where the engagement's assessed risk is elevated — spread across the vendor sample so both cadence and breadth are covered. Record the draw parameters.\n21. Test attributes per instance: performed by the assigned performer (not the vendor's own relationship manager where policy requires independent review), on time against the policy calendar (for example, SOC review completed within 60–90 days of report receipt), evidence of substantive review (exceptions noted, questions raised), and disposition of what was found.\n22. Trace consequences end-to-end for every flagged instance in the sample: an SLA breach should show a remedy invoked or a credit claimed; a failed questionnaire answer should show a remediation task or a formal risk acceptance with authority and expiry; a missed review should show escalation. The gap between \"logged\" and \"acted on\" is where this test earns its keep.\n23. Validate the IPE feeding monitoring: the vendor list driving the monitoring calendar reconciles to the register tested earlier — monitoring run off a stale list inherits the completeness problem.\n24. Log exceptions with condition, criteria, and cause per instance; never net them against passes.\n\n*Document exclusions.* Make every in-engagement scope exclusion explicit — which vendor segments, domains, or procedures were deliberately not covered, at what residual risk — so the report's scope-limitation language is written from a record, not reconstructed from memory.\n\n25. Enumerate exclusions by class: population (vendors below the spend floor, intercompany service providers, fourth parties beyond direct contracts), domain (vendor security testing covered by the separate Cybersecurity Assurance Review; exit strategies deferred), geography or entity, and period.\n26. Quantify each: how many vendors, how much annual spend, which tiers. \"Low-tier vendors excluded\" means something different when low tier holds a mis-tiered payment processor — cross-check exclusions against the tiering reperformance results before blessing them.\n27. State the basis per exclusion: risk-based (documented in the plan), covered elsewhere (name the engagement or workflow and its period), or constraint-driven (access, time). Constraint-driven exclusions are the ones that must surface in the report as scope limitations rather than quiet trims.\n28. Where IA relied on second-line or external work instead of testing directly, attach the reliance assessment — scope match, competence, objectivity (Standard 9.5) — for each relied-upon piece.\n29. Obtain engagement-lead concurrence on the consolidated exclusion register; flag anything constraint-driven to the CAE delegate for the report's limitation paragraph.\n30. Set revisit triggers where an exclusion defers risk (fourth-party mapping deferred, for example, triggers on the next concentration report).\n\n*Report vendor assurance results.* Convert fieldwork into rated findings and an engagement conclusion whose facts management has already seen — the substance Audit Report Drafting will consume, produced here while the evidence is at hand.\n\n31. Draft each finding as condition, criteria, cause, and effect (Standard 14.2): the condition cites specific evidence (vendor, artifact, instance); the criteria cites the policy clause or standard; the cause goes past the first answer — an unmapped CUEC's cause is rarely \"oversight\", it is usually that no role owns reliance review; the effect states exposure in service and data terms, not adjectives.\n32. Rate significance per the function's scale (Standard 14.3), weighing the tier of the vendors affected, data sensitivity, pervasiveness (one vendor versus a pattern), and compensating controls that were themselves verified. A pattern of unread testing exceptions across critical vendors outranks any single clause gap.\n33. Aggregate: cluster findings into root themes — register completeness, tiering discipline, reliance discipline, monitoring follow-through, contract hygiene. Themes are what the board reads; item lists are what gets argued.\n34. Validate facts with management before ratings harden — no surprises: the owner confirms the condition is factually right (not that they like it). Log disputes with the evidence that resolves them.\n35. Form the engagement conclusion against the objective (Standard 14.5) as a scoped statement — for example, \"governance is adequately designed; reliance on vendor assurance reports is not operating effectively: X of Y critical vendors had unmapped CUECs or stale coverage\" — never an unscoped \"adequate overall\".\n36. Pair each finding with management's response and proposed action (Standard 14.4); unresolved responses carry forward to the disposition decision, flagged as such.\n\n**Record in AssureSwarm**\nAttach the reconciliation workbook, the tiering reperformance matrix, and the register extract with run parameters as documents on this step (XLSX).\n- Record population counts, shadow and stale rates, the mis-tier rate, and the frozen sample with draw parameters on this step; mis-tier and shadow-vendor candidates carry forward as finding candidates (Issue items created at reporting) referencing `Vendor.tier`.\n- Link the sampled Vendor items to this workflow and to the anchor Audit (item relationship).\n\nAttach the policy assessment, the oversight-materials review notes, and the contract-clause scoring matrix as documents on this step (XLSX/DOCX).\n- Record clause-coverage rates on this step, and log each governance gap as a finding candidate (Issue item created at reporting) linked to the TPRM Policy item and the affected Vendor items (item relationships).\n\nUse uploaded assurance artifacts and existing contracts first. The optional vendor clarification form captures only unresolved service scope, current exception remediation or subservice coverage identified in its request; the contact must be outside the complete executor roster. Supply known identity and artifact details in the assignment. The auditor extracts report facts and records its own reliance judgment in the matrix, not in a respondent form.\n- Attach the per-vendor reliance evaluation matrix as a document on this step (XLSX): artifact, type, period, gap and bridge status, opinion, exception disposition, CUEC coverage, carve-out follow-up, scope match. The per-vendor reliance conclusion has no native Vendor field, so it lives on this matrix, not a `Vendor.*` value.\n- Record per-vendor conclusions (reliance earned, conditional, or not supported) on the matrix, and link finding candidates (Issue items created at reporting) to the affected Vendor items (item relationship).\n- Note on this step which reports are flagged for the reusable SOC review workflow.\n\nAttach the test matrices with per-instance attributes and results, plus the evidence files, as documents on this step (XLSX).\n- Record pass and fail rates per control, timeliness statistics, and the consequence-tracing results on this step; link exceptions as finding candidates (Issue items created at reporting) to the affected Control and Vendor items (item relationships).\n\nAttach the exclusion register as a document on this step (XLSX/DOCX): class, quantification, basis, residual-risk note, concurrence, revisit trigger. It has no native item type.\n- Record the scope-limitation candidates for the report handoff on this step.\n\nCreate one Issue item per finding (`issue_type` = finding, `source` = internal_audit, `severity` = the rating, `description` = condition/criteria/effect, `root_cause` = cause, `recommendation`, `management_response`, `identified_date`); link each Issue to the anchor Audit, to the affected Vendor items, and to the relevant unified Control items (UC-AUDIT-12/13/16, UC-TPRM-01/02/04) (item relationships).\n- Record the draft engagement conclusion and the fact-validation trail (who confirmed what, when) on this step; the scoped conclusion is proposed in the package; publish rating/opinion only after its supervisory approval and retain final report issuance/date authority downstream.\n\n**Exit criteria**\nRegister completeness quantified against independent sources; tiering methodology assessed and reperformed on a recorded sample; audit populations frozen with reproducible draws; every anomaly explained or carried as a finding candidate.\n\nPolicy, ownership, oversight, and contract standards each carry a documented conclusion with evidence references; clause coverage is quantified on the sample; every gap is a finding candidate with condition and criteria stated.\n\nEvery sampled vendor has a reliance conclusion supported by the matrix; period gaps, exceptions, CUECs, and carve-outs are dispositioned or carried as findings; module flags are explicit; no artifact counted as coverage without being read.\n\nEach key monitoring control carries a documented design conclusion and an attribute-tested sample with recorded draws; every flagged instance is traced to a consequence or logged as an exception; the IPE reconciliation is documented.\n\nEvery gap between planned and executed scope is either closed or on the exclusion register with quantification, basis, and concurrence; reliance assessments attached where claimed; revisit triggers set where risk is deferred.\n\nEvery finding candidate is either dropped with a recorded reason or drafted, rated, fact-validated, and carrying a management response; the conclusion is scoped and traceable to the findings; themes are identified for reporting.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` runs the mechanical tick-and-tie — sample draws with a recorded seed, evidence-to-attribute matching, and the results matrix — leaving the auditor the judgment calls.\n\n**Form recipient** — Vendor assurance contacts outside the complete IA/TPRM workflow executor roster. Check the complete preparation, execution, review and approval roster first: anyone assigned a role anywhere in this workflow contributes through native results, documents and approvals instead. Read current evidence and declarations before requesting anything. Select only unresolved questions for the identified scope and period; known facts remain linked context, and no request is needed if nothing is missing. The catalog fields are optional so known or unasked facts need not be repeated; every question actually required by the assignment must have an attributable response or a recorded unresolved gap before the dependent judgment. A negative or declined affirmation remains visible; it must never be converted to a positive statement. Vendor contacts supplying private facts do not execute IA assessment, business remediation or approval checkpoints. Compare the whole executor roster before sending. Obtain artifacts through document upload and extract their contents before deciding any clarification is missing.","label":"Evaluate vendor control environment","performedBy":{"primitives":["coach-query-data","coach-document-upload","sox-testing"]}},"id":"evaluate-vendor-control-environment"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Third-Party Vendor Assurance Engagement 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** — Classify the engagement's result — clean, remediation-track, or escalation — so the right closure path runs and stakeholders see the program's condition at its true size. Proposed by the engagement lead; the CAE delegate owns the call at escalation severity.\n\n**Decision criteria**\nWeigh the rated findings in aggregate: the tier and data sensitivity of affected vendors, pervasiveness (isolated instances versus themes across the program), whether claimed compensating controls were verified, and management's response posture.\n- **clean** (No reportable gap) — no findings above the observation line: the register reconciles within tolerance, tiering reperformance is clean, reliance discipline is operating (reports read, exceptions dispositioned, CUECs mapped, coverage current or bridged), and monitoring runs on cadence with consequences traced. The affirmative, scoped conclusion is the deliverable.\n- **remediate** (Remediation required) — real findings with workable management ownership at moderate-to-significant severity: unmapped CUECs or stale coverage on some vendors, contract-clause gaps, missed monitoring cadences, a bounded set of mis-tiered or shadow vendors — where exposure is limited by verified compensating controls or non-critical data, and management commits to act. Route to the action-plan step. Significant-rated findings still ride the board-reporting track; say so in the rationale.\n- **escalate** (Escalate significant issue) — any of: a critical vendor holding sensitive or ICFR-relevant data with no supportable assurance coverage and no compensating control; register completeness broken at scale (material shadow-vendor spend); an active vendor incident or suspected breach surfaced by fieldwork (immediate security and legal referral, not just reporting); management declining to remediate where the implied risk acceptance may exceed appetite — the Standard 11.5 path to senior management and the board; or probable regulatory exposure (DORA, interagency expectations). Route to the escalation step.\n\n**Record in AssureSwarm** — Submit this step's form: `disposition_path` = the chosen branch; the step result = the aggregate severity reasoning (findings, tiers, data classes, compensating-control status, response posture) with references; the step's approver record = the engagement lead, or the CAE delegate at escalation severity.\n\n**Exit criteria** — Form submitted; the rationale shows the severity weighing rather than asserting a label; unused branches are prunable.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Turn each remediation-track finding into an owned, dated, verifiable action plan that fixes the cause — with interim risk cover while the fix lands and a closure standard the follow-up can test against.\n\n**Inputs**\n- The rated findings with causes and management responses.\n- The disposition rationale; the function's action-plan conventions (due-date bands by severity, escalation on overdue).\n- The affected vendor and contract records.\n\n**Procedure**\n1. Re-test the root cause before writing the action: \"the analyst missed it\" is a symptom. Unmapped CUECs usually trace to no role owning reliance review; shadow vendors trace to procurement bypass channels; stale bridge letters trace to no trigger firing on report expiry. The action must change the mechanism, not exhort people to try harder.\n2. Define each action concretely: what changes (a CUEC-mapping step added to the SOC review procedure, a payment block for unregistered payees above the floor, clause remediation at next renewal with an interim security rider), who performs it, and what evidence completion will produce.\n3. Assign ownership to management — the vendor's business owner or the TPRM lead — never to IA (Standard 14.4; IA later validates the fix, and owning it would be self-review). Named individuals, not departments.\n4. Set due dates by severity band (significant findings typically within 90 days; moderate by next quarter or the next contract-renewal cycle where the fix is renewal-bound) and sanity-check them against real dependencies: a clause fix gated on a renewal ten months out needs interim mitigation now, not a long due date.\n5. Define interim mitigation for exposure that persists until the fix: heightened monitoring of the affected vendor, a contractual attestation, restricted data flows — each with its own owner.\n6. State the closure standard per action: exactly what Finding Remediation & Action-Plan Monitoring will verify (the artifact produced, the recurrence check), so \"done\" is testable rather than declared.\n\n**Record in AssureSwarm**\n- Action plans are not separate items — write each plan onto its finding Issue: `Issue.remediation_plan` (the action, interim mitigation, and closure standard), `Issue.issue_owner` (the named management owner), and `Issue.target_remediation_date` (the severity-consistent due date); the Issue stays linked to its Vendor items.\n- Record the reporting cadence (status to the TPRM oversight committee until closure) on this step.\n\n**Exit criteria** — Every remediation-track finding has an action attacking its stated cause, a named management owner, a severity-consistent due date, interim mitigation where exposure persists, and a testable closure standard.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to engagement lead, CAE delegate, or audit committee delegate or document risk acceptance","instructions":"**Objective** — Put the escalated issue in front of the people accountable for the risk — with quantified exposure and options — and land a documented decision: treat it at senior-management or board level, or accept a bounded risk with authority, conditions, and an expiry.\n\n**Inputs**\n- The disposition rationale and the underlying findings and evidence.\n- Exposure facts: affected vendors, services, data classes, spend, substitutability, regulatory reach.\n- The escalation chain: CAE, senior management, board or audit committee; legal and compliance contacts for notification questions.\n\n**Procedure**\n1. Draft the decision memo: the issue in one paragraph; quantified exposure (which critical services and data are effectively un-assured, for how long, with what fallback); how it was found; the options with costs and timelines (accelerated remediation, alternate assurance such as an exercised right-to-audit, service migration, formal acceptance); and a recommendation.\n2. Route by severity and type. A suspected breach or active incident: immediate referral to security incident response and legal — the engagement does not sit on it pending the report. Management declining remediation where the implied acceptance may exceed risk appetite: the CAE escalates to senior management and, unresolved, to the board (Standard 11.5). Probable regulatory exposure: flag to compliance and legal for the notification analysis — IA flags; it does not notify.\n3. Apply risk-acceptance discipline: acceptance is available only where exposure is bounded, and never for suspected fraud or active incidents. It requires a named acceptor with authority over the exposure per the delegation-of-authority matrix, the verified compensating controls named in the acceptance, an expiry or re-review date, and the conditions that void it (a vendor incident, a tier change, expiry of the relied-upon report).\n4. Capture the decision: decider, date, decision, conditions, and follow-up ownership — who re-verifies, who reports to the committee, who tracks the acceptance to its expiry.\n5. Feed the outcome back into the disposition record and the finding items so the final package reflects the decision, not just the recommendation.\n\n**Record in AssureSwarm**\n- Attach the decision memo as a document on this step (DOCX/PDF); record the decider, date, decision, conditions, and expiry on this step.\n- A formal risk acceptance is an Issue (`issue_type` = policy_exception, `exception_approver`, `exception_expiry_date`, `description` = the accepted exposure and voiding conditions) linked to the third-party Risk item and the affected Vendor items; also set `Risk.treatment` = accept and `Risk.residual_rating` on that Risk item.\n- Create the follow-up items (re-verification, acceptance-expiry review) as Issue items (`issue_type` = observation, `issue_owner`, `target_remediation_date`) linked here.\n\n**Exit criteria** — A dated decision by someone with authority exists — escalated with board-track visibility, or accepted with named authority, verified compensating controls, conditions, and an expiry — and follow-up ownership is assigned.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Approve the reperformable package, scoped conclusion, findings and reliance dispositions or specify supported revisions.","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** — Approve the reperformable package, scoped conclusion, findings and reliance dispositions or specify supported revisions.\n\n**Inputs**\nEverything produced upstream: scope and criteria, reconciliation and tiering workbooks, governance assessment, the reliance matrix (with reusable-workflow outputs by reference), monitoring test matrices, the exclusion register, rated findings with responses, and the action plans or escalation memo.\n- The disposition decision and its rationale.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Independent engagement supervisor or CAE delegate owns the stated judgments and authorizations.*\n\n*Prepare final package.* Assemble the single self-sufficient evidence-and-decision package for the engagement — what the approver signs, what Audit Report Drafting consumes, and what a QAIP reviewer or external assessor could reperform from.\n\n1. Compile in workpaper order: (1) objective, scope, period, criteria; (2) population and tiering work; (3) governance and contract results; (4) per-vendor reliance evaluations; (5) monitoring test results; (6) the exclusion register and reliance-on-others assessments; (7) rated findings with management responses; (8) action plans or the escalation decision; (9) the engagement conclusion; (10) the review trail.\n2. Run the reperformability check (Standard 14.6): a competent stranger reaches the same conclusions from this package alone — samples regenerate from recorded draws, each finding's condition traces to attached evidence, each conclusion cites its support, and reusable-workflow outputs are linked, not paraphrased.\n3. State the conclusion once, precisely scoped — which program areas are effective and which are not, based on which populations and period. Ambiguity here becomes the report's problem downstream.\n4. List unresolved constraints honestly: evidence never produced (with the PBC escalation trail), assumptions inherited from reusable workflows, coverage thinned by exclusions — the approver signs with eyes open.\n5. Verify navigation: vendor items, finding items, action plans, and the unified controls are all linked from this workflow.\n\n*Approve or revise package.* Capture the supervisory verdict of the engagement lead or CAE delegate on the final package (Standard 12.3): sign it, or send it back with conditions specific enough to be resolved without a meeting.\n\n\n\n**approved** (Approved) — the package passes the supervisory screen: every finding's condition ties to attached evidence and its rating is consistent with the function's severity scale; the conclusion's scope matches what was actually tested (no program-wide opinion off a critical-tier-only sample); reliance evaluations disposition period gaps, exceptions, CUECs, and carve-outs rather than merely noting them; exclusions and reliance-on-others carry their assessments; management responses and action plans (or the escalation decision) are in place; review notes are closed; the package reperforms.\n- **revise** (Revision required) — any of: a finding rests on evidence not in the package or overstates its support; severity ratings are inconsistent across similar findings; the conclusion overreaches or underreaches its scope; the reliance matrix has open dispositions (an unresolved carve-out, an unread qualification); constraint or exclusion language hides a scope limitation the report must disclose; or review notes remain open. Return it with actionable conditions — \"tie finding 3's condition to the report's testing exception, or re-rate it\" beats \"tighten finding 3\".\n\nA judgment disagreement between reviewer and preparer that survives discussion is resolved per the function's difference-of-opinion procedure and documented — never settled silently by seniority.\n\n**Record in AssureSwarm**\nAttach the compiled package, or an index document pointing at each attached component, as a document on this step (PDF/XLSX).\n- Stage the scoped conclusion and open constraints in the package. After supervisory approval, record its approved assessment rating/opinion on the Audit with that version reference; final report issuance and Audit.report_date remain the downstream report owner’s responsibility.\n\nSubmit this step's form: `approval_path` = the verdict; the step result = the conditions (for revise) or the supervisory basis (for approved), with references; the step's approver record = the approver and role.\n\n**Exit criteria**\nThe package reads standalone and reperformable; the conclusion is scoped; constraints are explicit; every referenced record is navigable from this workflow.\n\nForm submitted; revision conditions are specific and actionable; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the linked evidence, findings, and decisions into the ordered package with an index — the engagement lead reviews the assembly.","kind":"decision","label":"Approve or revise package","performedBy":{"primitives":["coach-render-package","coach-document-upload"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Close every revision condition with a documented change — evidence obtained, rating adjusted, language re-scoped, or the point rebutted with support — so re-approval reviews deltas, not the whole package again.\n\n**Inputs**\n- The itemized revision conditions from the approval decision.\n- The final package and the underlying workpapers and evidence.\n\n**Procedure**\n1. Triage conditions by type: evidence gaps (go get it — reopen the PBC line with a hard due date), rating inconsistencies (re-run the severity reasoning and align, in whichever direction the evidence points), scope and language problems (re-scope the conclusion or add the limitation), and judgment disagreements (argue from evidence; unresolved ones go to the difference-of-opinion procedure, not into silent edits).\n2. Make each change in the package and in its source workpaper together — a conclusion edited in the package but not in the workpaper is a future QAIP finding.\n3. Where a condition kills a finding (the evidence cannot be obtained), withdraw it explicitly with the reason recorded — a finding that quietly disappears is worse than one withdrawn on the record.\n4. Keep the change log: condition, what changed, where, by whom. Use suggested changes and comments on the affected items so the trail lives with the records.\n5. Check for ripple: a re-rated finding can change the disposition rationale, the themes, or the conclusion itself — re-verify aggregate statements before resubmitting.\n6. Resubmit to the approver with the change log as the cover.\n\n**Record in AssureSwarm**\n- Record the condition-by-condition change log on this step; attach the revised package as a new document version on this step, superseding rather than overwriting.\n- Update the affected finding Issue items — `Issue.severity` (rating), `Issue.description`, and their relationships — to match the resolved conditions.\n\n**Exit criteria** — Every condition shows a resolution (changed, withdrawn with reason, or escalated per the difference procedure); package and workpapers agree; ripple effects re-checked; the original independent supervisor has approved the exact revised package with its change log before it reaches the final handoff.","label":"Resolve approval conditions"},"id":"resolve-approval-conditions"},{"data":{"description":"Accept the approved findings, scope limitations, caveats and reporting/monitoring calendar before the engagement record closes.","instructions":"**Objective** — Accept the approved findings, scope limitations, caveats and reporting/monitoring calendar before the engagement record closes.\n\n**Inputs**\nThe approval decision and any conditions attached at sign-off.\n- The approved package version and its change history.\n\nThe approved final package, the approval record, and the handoff acknowledgments.\n- The finding items with ratings, management responses, and action plans; the exclusion register's scope-limitation candidates.\n- Distribution expectations: report recipients, board-reporting flags, external-sharing constraints (vendor names, NDA-restricted material).\n- The function's retention schedule for engagement workpapers (five to seven years is the common band; longer where regulation or litigation holds apply).\n- The forward obligations: action-plan due dates, acceptance expiries, reusable-workflow residuals, exclusion revisit triggers.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Receiving audit-report and remediation-monitoring owners with the IA lead owns the stated judgments and authorizations.*\n\n*Record approval decision.* Fix the final approval on the record — who approved exactly what version, when, with which conditions — so the authority trail is unambiguous when the report publishes and when QAIP samples this engagement.\n\n1. Record the approver's identity and role (engagement lead, CAE delegate) and confirm it matches the authority the function's methodology requires for this engagement's risk level — an approval by someone without that authority is a QAIP finding, not an approval.\n2. Pin the approved artifact: the exact package version and attachment approved, so later edits cannot masquerade as approved content. Superseded drafts stay marked superseded.\n3. Log conditions attached at approval (distinct from the revision conditions already resolved) — for example, \"issue subject to legal review of the regulatory paragraph\". Each becomes a tracked item with an owner and a date; approval conditions nobody tracks are how reports publish with unmet caveats.\n4. Record the date and the approval scope statement: what the approval covers (findings, ratings, conclusion, action plans) and what it does not — final report wording is approved downstream in Audit Report Drafting.\n5. Notify the report owner and the CAE delegate that the package is approved and frozen.\n\n*Handoff to related workflow.* Hand the approved results to Audit Report Drafting complete enough that drafting starts from substance — with explicit boundaries on what the report team must not re-litigate — and close the engagement on that acknowledged handoff with an immutable trail, updated program records, and every forward obligation owned.\n\n*The receiving owner’s acceptance completes the engagement handoff; archive and forward-trigger procedures run under that recorded decision.*\n\n6. Create or link the Audit Report Drafting workflow and pass the package: the scoped conclusion, the rated findings (condition, criteria, cause, effect, with responses and action plans), the themes for the executive summary, the scope and exclusion or limitation language, and the fact-validation trail showing management has already seen the facts.\n7. State what downstream must not repeat: severity ratings are approved (drafting adjusts language, not ratings — new facts reopen the disposition here, not in wording); facts are validated (no re-negotiating conditions during draft circulation); scope statements are fixed by the approval.\n8. State what downstream owns: report structure and wording to the communication criteria — accurate, objective, clear, concise, constructive, complete, timely (Standard 11.2); distribution per Standard 11.3, including the board track for significant items; and handling of NDA-constrained vendor detail (generic descriptors in the distributed report, specifics in a restricted appendix).\n9. Route the action plans to Finding Remediation & Action-Plan Monitoring so tracking starts at report issuance, not after it — pass owners, due dates, interim mitigation, and closure standards.\n10. Transfer the caveats: open constraints and approval conditions that touch report language, flagged to the drafter explicitly.\n11. Confirm receipt: the report owner acknowledges the package and the reporting calendar. That acknowledgment is this step's human moment and the trigger for closing out.\n12. Verify closability honestly: every step finished or explicitly dispositioned, both decision forms submitted, review notes closed, handoffs acknowledged. Closing over an open item is how audit trails grow holes.\n13. Archive the final package as the immutable record: export the workflow record, mark superseded drafts, and confirm nothing final lives only in mailboxes. Apply the retention basis and verify retrievability by opening the archived copy — retained-but-unfindable fails the same test as deleted.\n14. Update the program records: the unified controls this engagement assessed (UC-TPRM-01, UC-TPRM-02, UC-TPRM-04) get the assessment date, result, and links; the audit-universe entry for third-party risk gets the conclusion and the next-coverage input; vendor items link to the reliance-conclusion matrix and their findings; do not invent a Vendor field for the auditor’s opinion.\n15. Seed the forward triggers as watchlist entries with owners: next SOC report due dates and bridge-letter expiries per critical vendor, risk-acceptance expiries, tier-refresh checkpoints, exclusion revisit triggers, and the follow-up verification dates (Standard 15.2 — confirming implementation is a scheduled obligation, not an aspiration).\n16. Communicate closure to the CAE delegate, the TPRM lead, and the vendor owners: conclusion issued, action plans in tracking, next touchpoints set.\n17. Lock the workflow record; post-closure changes happen as documented amendments, never silent edits.\n\n**Record in AssureSwarm**\nRecord approver, role, date, the approved (pinned) package version reference, conditions, and follow-up owners on this step.\n- Track each approval condition as an Issue item (`issue_type` = observation, `issue_owner`, `target_remediation_date`) linked here — there is no native Task type, so the Issue observation is the honest home.\n\nLink the Audit Report Drafting workflow instance — and the Finding Remediation & Action-Plan Monitoring workflow for the action plans — to the anchor Audit and to the finding Issue items (the Issues carrying `remediation_plan`/`target_remediation_date` ARE the routed action plans).\n- Record the handoff date, the do-not-repeat boundaries, and the receiving owner's acknowledgment on this step.\n- Export and archive the Workflow instance on the anchor Audit as the immutable audit trail; record the retention basis, archive reference, and communication recipients with dates on this step.\n- Update the program records: link the assessed unified Control items (UC-TPRM-01/02/04) to the anchor Audit (item relationship) with the assessment result, update `Risk.residual_rating` on the third-party Risk item where the conclusion moves it, and link sampled Vendor items to their reliance-conclusion matrix and findings rather than inventing an unsupported Vendor field.\n- Create the watchlist / forward-trigger entries as Issue items (`issue_type` = observation, `issue_owner`, `target_remediation_date`) — no native Task/Watchlist type, so the Issue observation is the honest fallback.\n\n**Exit criteria**\nApprover with confirmed authority, date, and a pinned package version recorded; every approval condition exists as a tracked item with an owner and date; downstream owners notified.\n\nDownstream workflows linked and acknowledged; package, boundaries, caveats, and calendar recorded; action plans are in the tracking pipeline; nothing left for downstream to rediscover; all steps dispositioned; the package is archived, retrievable, and immutable; program and vendor records are updated; every forward obligation exists as an owned, dated item or watchlist entry; closure is communicated and the record locked.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-workflow-attach","coach-workflow-export","coach-item-create"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:audit-third-party-assurance-engagement"}