{"description":"Internal Audit Engagement Lifecycle: run an IIA-aligned engagement on the existing Audit item (audit_type=internal) created by Audit Engagement Planning — it enriches that item and never creates a duplicate; the workflow instance attaches to the Audit item and is archived on it at close. In scope: evidence requests, fieldwork, finding evaluation, supervisory QA, conclusions per objective, and action-plan registration for the auditable entity and period fixed at planning (Audit.scope, Audit.period_start/period_end). Named deliverables: the evaluated findings register (one Issue item per finding), conclusions per objective (recorded on the Audit item as rating/opinion), and the report-ready handoff package. Out of scope: report wording (owned by Audit Report Drafting) and remediation validation (owned by Finding Remediation & Action-Plan Monitoring). It consumes the approved planning handoff package from Audit Engagement Planning and hands off to BOTH downstream workflows — Audit Report Drafting (the findings register and conclusions) and Finding Remediation & Action-Plan Monitoring (the registered action records) — rather than duplicating their work.","edges":[{"id":"e-issue-document-requests-evaluate-findings","source":"issue-document-requests","target":"evaluate-findings"},{"id":"e-evaluate-findings-obtain-supervisory-review","source":"evaluate-findings","target":"obtain-supervisory-review"},{"id":"e-obtain-supervisory-review-classify-disposition","source":"obtain-supervisory-review","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-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","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-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-AUDIT-13","UC-AUDIT-14","UC-AUDIT-15","UC-AUDIT-16","UC-AUDIT-17","UC-AUDIT-07"],"department":"internal-audit","domains":["audit"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=audit-engagement-lifecycle","contentDigest":"sha256:060ee0bf2ae9cb1b2cc942c83283a92b1205066b5af558c8b6652048467de14e","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:060ee0bf2ae9cb1b2cc942c83283a92b1205066b5af558c8b6652048467de14e","schemaVersion":1,"sourceTemplateId":"workflow-library:audit-engagement-lifecycle"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"audit-engagement-lifecycle","source":"coworkcanvas-gallery","standards":["iia-2024"],"teams":["internal-audit"]},"name":"Internal Audit Engagement Lifecycle","nodes":[{"data":{"description":"Authorize the locked evidence requirements, review chain and external requests and reminders before they are sent.","formData":{"fields":[{"key":"period_covered","label":"Period the evidence covers (from–to)","required":false,"type":"text"},{"key":"source_and_extraction","label":"System of record and how the file was produced (report or query name, parameters, run date)","required":false,"type":"textarea"},{"key":"completeness_statement","label":"Confirmation that the submission is complete and unaltered for the period, with any exclusions named","required":false,"type":"textarea"},{"key":"items_not_provided","label":"Requested items not provided, with the reason and the expected date","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Authorize the locked evidence requirements, review chain and external requests and reminders before they are sent.\n\n**Inputs**\nThe existing engagement record — the anchor Audit item (audit_type=internal) that Audit Engagement Planning already created, carrying scope, lead_auditor, period_start/period_end, and fieldwork_start, with the auditable entity in scope reachable through the Audit ↔ Process relationship. This workflow enriches that item; it does not create one.\n- The approved planning handoff package — a document linked on the same Audit item by Audit Engagement Planning's handoff step: objective, scope, evaluation criteria, engagement risk assessment, procedures mapped to risks, resource plan, and milestones. This node consumes that package.\n- The resource plan and team calendar (the live calendar is an external system; the attached copy is the evidence) plus the auditee's blackout windows (period-end close, releases, peak season) — a document attached at this step.\n- The candidate list of documents (PBC) to request, distilled from each procedure's evidence expectation — a PBC request list (XLSX/CSV) attached at this step.\n\nFor every item you need: a one-sentence description of what is requested, from whom (the auditee contact), by when (the due date), and why it is needed.\n- The originating step's linked controls and risks, so the request stays traceable.\n- Resolve any missing request description, contact, due date or purpose with the engagement auditor in the native workplan/result. Reuse the approved planning package; do not create a requester questionnaire.\n- The locked workplan's per-procedure evidence expectations (which document, which period, what sample).\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement auditor and engagement lead owns the stated judgments and authorizations.*\n\n*Lock executable workplan.* Freeze the work program into the executable baseline — scope, procedures, owners, dates, evidence expectations, review chain — the version fieldwork progress and deviations will be measured against.\n\n1. Run the completeness sweep: every objective is covered by at least one procedure; every procedure carries an owner, a due date, a criteria reference, and a stated evidence expectation — which document, which period, what sample. A procedure whose evidence expectation is blank will produce an unanswerable document request downstream.\n2. Sequence around auditee constraints: keep finance requests out of close week; batch requests per contact so each auditee sees one coherent ask rather than a drip of five.\n3. Fix the review chain: preparer and reviewer differ on every workstep, the supervising reviewer is named, and review is planned to happen as work completes, not as a pre-issuance pile-up (IIA Standard 12.3).\n4. Set change control: after lock, scope and procedure changes require documented approval — name who can approve and where the change log lives.\n5. Version-stamp the locked baseline and store it. Deviation reporting, budget burn, and the supervisory QA pass all measure against this snapshot.\n\n*Issue document requests.* Issue the engagement's document (PBC) requests to auditees so each requested piece of evidence lands on the workflow, linked to the controls and risks it supports, with an accept-or-reject review already queued so nothing sits in limbo, and run the chase loop alongside evidence assessment so open requests keep moving.\n\n*Issue the requests:*\n6. Review the existing evidence workspace and planning package per request line. Obtain missing files and attributable producer completeness statements through document upload and source records. If coverage, extraction or completeness facts are still unresolved, assign only those questions to an auditee source contact outside all preparation, assessment, remediation and approval roles in this workflow. Preserve one identified request-line record for aging and acceptance; no collection form is needed for facts already documented, or for an executor’s own work.\n7. Auto-link the originating step's controls and risks to the request so submitted evidence inherits that traceability.\n8. Assign each request line to its existing independent reviewer and link it to the evidence-sufficiency review retained inside Evaluate findings. Do not create an additional review node. The later reviewer accepts or rejects the received evidence against the locked criteria; request authorization does not itself approve the evidence.\n9. Prepare each request with its evidence-upload location and, only when needed, the targeted missing-fact assignment. Draft the accompanying message for the auditor to approve before sending; nothing is auto-sent.\n\n*Chase loop — run until every request closes:*\n10. Enumerate every identified request line in the versioned PBC register, including document-only requests and lines with an optional missing-fact assignment. Record its original issue date, due date, required evidence and unresolved facts, source/document receipt status, optional assignment link and named independent reviewer. Do not derive the request population from FormAssignments.\n11. Compute each request line’s aging from its recorded original issue date and due date, including lines with no form. Link optional assignment timing for context without resetting or substituting the document-request clock.\n12. Render the chase table from all request-line records: request ID/title, auditee, due date, days open, outstanding documents or facts, receipt status and independent review status. Mark receipt complete only after every required source file and factual response has arrived or an authorized scope change is recorded; a submitted fact form cannot clear missing evidence. Stop reminders only for the received content and continue chasing outstanding requirements. Keep received/pending review separate from independently accepted evidence. The chase reads state only and never changes evidence or reviewer conclusions.\n13. For each open row the auditor picks, draft a reminder nudge the auditor can send as-is — polite, specific to the outstanding items, and screened so no restricted names or data travel in the draft. Drafts only; never auto-send. For rows overdue beyond the methodology's tolerance, draft the escalation to the auditee's manager the same way.\n\n**Record in AssureSwarm**\nStep document: attach the locked work program (with version and date) to this step; record per-procedure owners and due dates on the workflow steps.\n- Step fields: the change-control rule and named approver, and the baseline milestones — the Audit item has no native change-control field, so these live on the step.\n- Item field update on the anchor Audit item: confirm scope and fieldwork_start reflect the locked baseline (Audit.scope, Audit.fieldwork_start).\n\nPreserve source files, actual period and extraction metadata, producer identity and attributable completeness statements in the evidence workspace. Only unresolved coverage, extraction, completeness or unavailable-item facts go into an identified outside-contact request. Link any assignment ID to its request line; auditor and other executor contributions remain native results and documents.\n- Link each request to its Control and Risk items and its retained independent sufficiency review inside Evaluate findings; preserve the reviewer identity and request-line traceability without a new node.\n- Step fields: the auditee contact per request (a text field — there is no Contact item type) and the chase trail — aging snapshots, nudges drafted and sent, escalations.\n\n**Exit criteria**\nThe locked version is attached; no procedure lacks owner, date, or evidence expectation; the review chain contains no self-review; the change-control rule is stated with a named approver.\n\nEvery still-needed item has an identified document request with only any unresolved outside facts assigned separately; all requests retain control/risk links and the existing independent sufficiency reviewer in Evaluate findings. Files, producer statements and request IDs are traceable; open requests have current aging and overdue ones have a drafted nudge or escalation. No duplicate review node or executor questionnaire is created. Human checkpoint: the auditor reviews every drafted request, email, and reminder before anything leaves the system — nothing is auto-sent.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — drafts the auditee request emails and the chase-loop reminder nudges with a logged outreach trail; sending stays with the auditor.\n\n**Form recipient** — Auditee evidence contact outside the audit team. 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. The auditee supplies source evidence and does not prepare, assess or supervise this independent audit workflow. Auditor requests, sufficiency decisions and QA results are native step records.","label":"Issue document requests","performedBy":{"agent":"audit-artist","note":"evidence-request issuance engine","primitives":["coach-form-create","coach-query-data","coach-notify"]}},"id":"issue-document-requests"},{"data":{"description":"Accept or reject source evidence, evaluate four-Cs findings and challenge whether management commitments address the root causes.","instructions":"**Objective** — Accept or reject source evidence, evaluate four-Cs findings and challenge whether management commitments address the root causes.\n\n**Inputs**\nThe originating step's evidence requirement — the free text describing what is expected: document type, period, required signoffs, and sample size. Tenant-specific rules such as 'Q3 vendor logs must be signed by Treasury AND CFO' live in that requirement field, so more specific text there yields a more accurate assessment.\n- The linked controls and risks the evidence supports.\n- The list of documents the auditee uploaded to the paired request.\n\nAccepted evidence linked to each workstep, with test results and exceptions.\n- The approved evaluation criteria from the locked workplan.\n- The entity's issue history, for the repeat-finding check.\n- The methodology's severity scale (for example insignificant, minor, moderate, significant) and its rating definitions.\n\nThe evaluated findings with ratings and root causes.\n- The auditee managers with authority to commit budget and people — not delegates who cannot.\n- The issue-management policy: target-date norms by severity (commonly: significant within 90 days or a documented justification, moderate within 180) and validation requirements.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement auditor and engagement lead owns the stated judgments and authorizations.*\n\n*Assess evidence sufficiency.* For every piece of evidence the auditee submitted against this engagement's document requests, judge whether it satisfies the originating workstep's evidence requirement — relevant, reliable, and sufficient in the sense of IIA Standard 14.1 — and produce a recommendation the auditor can act on. This is a recommendation-only step: the agent never accepts, rejects, or edits evidence on its own; the auditor applies the accept or reject decision on the workflow step.\n\n1. For each submitted document, read its contents and compare it against the evidence requirement on four axes: (1) document type — is it the right kind (log vs report vs screenshot vs signed approval)? (2) period — does it cover the required period? (3) signoff status — is it signed, dated, and approved where the requirement demands it? (4) sample size — does the sample in the document match the workstep's sampling plan?\n2. From that comparison assign exactly one of four verdicts: **accept** (clearly satisfies; brief confirmation, no follow-up ask); **request-more** (relevant but missing something specific; name exactly what to add, phrased politely — for example 'Could you also include the approver signature on page 2?' rather than 'your evidence is incomplete'); **reject** (wrong type, wrong period, or wrong scope; name the correct document — for example 'we need the signed Q2 vendor approval log, not the Q1 version'); or **surface-to-human** (ambiguous, or content that cannot be read).\n3. Apply the safety fallback for unreadable evidence: binary files (PDF, DOCX, XLSX) whose text cannot be extracted at runtime default to surface-to-human with a note that the file could not be inspected. Never invent an accept or reject on content you could not actually read; the auditor inspects those manually.\n4. For each document, draft a polite, specific auditee-facing message the auditor can forward as-is, matched to the verdict.\n\n*Evaluate findings.* Turn accepted evidence and test results into evaluated findings — condition against criteria, root cause, effect — each rated for significance and factually confirmed with the auditee (IIA Standards 14.2–14.3).\n\n5. For each exception or gap, assemble the four Cs: **criteria** (what should be, citing the approved reference), **condition** (what is, with evidence references), **cause** (drive the why-chain until you reach something management can act on — 'human error' is never a root cause; ask what allowed the error to occur and to reach production), and **effect** (actual or potential impact, quantified where possible: dollars, records, users, days of exposure, penalty ranges).\n6. Corroborate the condition with the auditee before rating. Factual disagreements get resolved now, with evidence — not performed at the exit meeting. If their evidence changes the facts, change the finding.\n7. Rate significance against the methodology scale using likelihood, impact, pervasiveness, and compensating controls. Then check aggregation: several minor exceptions in one process can aggregate to a moderate or significant theme — rate the theme, not just the instances.\n8. Flag repeats: the same or substantially similar finding within the prior two engagements raises the rating or an explicit repeat flag per methodology; a repeat with an overdue prior action plan is itself a governance finding.\n9. Screen for indicators beyond this engagement's scope — fraud red flags, pervasive control-environment weakness. Route those to the CAE immediately rather than holding them for the report.\n10. Draft each finding in reportable form: a one-line headline, the four Cs, the rating with rationale, and evidence references a reviewer can walk.\n\n*Agree action plans.* Land a management-owned action plan on every finding — a named owner, a realistic date, and an action that addresses the root cause — or a documented non-concurrence, per IIA Standard 14.4.\n\n11. Present each finding and its root cause to the accountable manager. If the person in the room cannot commit resources, you have the wrong room — reschedule with the owner.\n12. Test every proposed action against the cause: does it prevent recurrence, or only fix the found instances? Push instance-only fixes toward a systemic component; where management declines, record the residual risk explicitly on the action record.\n13. Pin the triple on every action: a named individual owner (never a team), a date within the policy's severity norms (or a written justification for exceeding them), and a verifiable completion definition — the evidence that will prove it done (for example: revised policy approved plus three months of operating evidence). The completion definition is what Finding Remediation & Action-Plan Monitoring will validate against, so write it to be testable.\n14. For significant findings with long remediation timelines, agree interim mitigation: what limits exposure between now and the fix, and who operates it.\n15. Where management declines to act at all, do not soften the rating to close the gap. Record their position verbatim — it routes to the escalate-or-accept-risk path at disposition (IIA Standard 11.5).\n16. Capture agreement as evidence: written concurrence via approval or comment on the action item — verbal agreement is not agreement.\n\n**Record in AssureSwarm**\nStep fields: per document — the verdict, the four-axis reasoning (what matched and what did not), and the drafted auditee message; the accept/reject decision the auditor applies is recorded on this step.\n- Item relationships: link each accepted document to the Control and Risk it supports, and to the Issue (finding) it substantiates once that finding exists.\n\nItem create: one Issue item per finding — issue_type: finding, source: internal_audit, severity (the rating), description (the four Cs: criteria/condition/effect), root_cause, identified_date. Item relationships: Issue ↔ the anchor Audit item, Issue ↔ Control tested, Issue ↔ Risk, and Issue ↔ the accepted evidence documents it rests on.\n- Item fields: severity carries the rating; description and root_cause carry the rationale a reviewer can walk. The auditee factual-confirmation status and date have no native Issue field — record them as a note/comment on the Issue.\n- Step fields: exceptions closed as non-findings recorded on the originating workstep with the reason.\n\nItem field update on each finding Issue: issue_owner (USER — the named owner), target_remediation_date (the agreed date), and remediation_plan (RICHTEXT holding the agreed action, its completion definition, and any interim mitigation with its operator). There is no separate Action-Plan item type, so multiple discrete actions on one finding share that Issue's remediation_plan — the create-action-plan step registers them; here they are agreed.\n- Item field update: management_response (RICHTEXT) captures the written concurrence evidence per finding.\n- Item field: a non-concurrence is recorded verbatim in management_response and flagged on the Issue for the disposition decision.\n\n**Exit criteria**\nEvery submitted document carries a recommendation with reasoning and a drafted auditee message; the auditor has applied accept or reject where they agree — nothing is auto-applied, and the auditee message is a draft the auditor sends, not an auto-send; request-more and reject items are queued back to the auditee; accepted evidence is linked to the controls, risks, and findings it substantiates. Quality bar: every verdict is backed by the four-axis comparison and a concrete reasoning note; every reject or request-more carries a specific, polite corrective ask; unreadable binaries are surfaced to a human rather than guessed; no evidence file is modified.\n\nEvery exception is either closed as a non-finding with a recorded reason or drafted as a four-Cs finding with rating, evidence links, and auditee factual confirmation; aggregation and repeat checks are documented; any fraud indicator is escalated out-of-band.\n\nEvery reportable finding carries either an agreed action (owner, date, completion definition, concurrence evidence) or a documented management non-concurrence routed to disposition; interim mitigation exists for significant findings whose dates run beyond policy norms.","label":"Evaluate findings","performedBy":{"agent":"audit-artist","note":"evidence-sufficiency classification engine","primitives":["coach-query-data","coach-document-upload"]}},"id":"evaluate-findings"},{"data":{"description":"Complete Obtain supervisory review","instructions":"**Objective** — Run a senior-auditor quality-review pass over the completed (or nearly-completed) engagement before the report is issued, producing a structured QA report of severity-graded findings and a blocked_from_close verdict (IIA Standard 12.3 supervision). This is an observation-only review: it surfaces issues for the engagement lead to fix and never edits workpapers, evidence, or conclusions itself.\n\n**Inputs**\n- Every workstep and its status; the tollgate sign-offs.\n- The controls and risks linked to each workstep; the evidence attached to each test workstep.\n- The reviewer and approver fields; the required custom fields for this audit type; every recorded finding or issue.\n\n**Procedure**\n1. Walk the engagement across the five dimensions below, logging every issue with the exact workstep, field, or evidence item it refers to and a concrete recommended fix.\n2. **Tollgate completeness** — planning, fieldwork, draft-report, and final-report tollgates are each complete and signed by both the lead and the reviewer.\n3. **Evidence sufficiency** — every 'test of design' or 'test of effectiveness' workstep has evidence attached; no evidence file is zero-byte or a placeholder; each file is linked to the correct workstep, not a sibling.\n4. **Approver chain** — reviewer fields are populated wherever required; there is no self-review (the reviewer must differ from the assignee on the same workstep); sign-off timestamps are sequential (first reviewer before second).\n5. **Field completeness** — required custom fields are populated per the audit type's schema; no [NEEDS INFO] markers are left in any text field; risk and control linkages are present per workstep.\n6. **Finding integrity** — every issue carries a description, severity, recommendation, owner, and target date, with severity aligned to the issue-management policy.\n7. Grade each issue found: **P0** blocks close (a missing tollgate, an unresolved [NEEDS INFO], or evidence missing on a Pass-marked workstep); **P1** should be fixed before reporting (incomplete fields, a finding missing its recommendation); **P2** is polish (formatting, citation style).\n8. Compute the blocked_from_close verdict: true if any P0 exists, or if the reviewer is running a strict pass and any P1 exists.\n9. Do NOT auto-fix any issue and do NOT propose changes to workpapers or conclusions — quality issues require human judgment. The engagement lead acts on the report, routing each fix through the normal step (for example, re-request missing evidence or complete a field) rather than having the reviewer edit it.\n10. For a partial-cycle review, name every skipped dimension with the reason it was skipped.\n\n**Record in AssureSwarm**\n- Step document: the structured QA report — a summary of P0/P1/P2 counts, then findings grouped by dimension with a specific recommended fix per finding, sorted by severity.\n- Step field: the blocked_from_close verdict on this step.\n- Step field: any explicit override the lead records to close despite an open P0 (there is no native QA-override field on the Audit item — it lives on the step).\n\n**Exit criteria** — The QA report and blocked_from_close verdict are recorded on the step; every P0 is either resolved or explicitly overridden with documented rationale; the engagement is QA-clean (or knowingly overridden) before it hands off to report drafting. Human checkpoint: the supervisory reviewer confirms the QA report, and the engagement lead either clears every P0 (and any P1 they choose to treat as blocking) or records the documented override. Quality bar: all five dimensions were walked or the skipped ones are named with reasons; each finding names the exact workstep, field, or evidence item and a concrete fix; the verdict follows deterministically from the P0 and P1 counts.","label":"Obtain supervisory review","performedBy":{"agent":"audit-artist","note":"supervisory QA review pass","primitives":["coach-query-data","coach-form-fill"]}},"id":"obtain-supervisory-review"},{"data":{"decisionField":"disposition_path","description":"Conclude against the objectives, resolve closing-conference facts and select clean, remediation or escalation from the resulting findings.","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** — Conclude against the objectives, resolve closing-conference facts and select clean, remediation or escalation from the resulting findings.\n\n**Inputs**\nThe QA-cleared findings register with ratings and agreed action plans.\n- The engagement objectives, criteria, and any scope limitations.\n- The methodology's conclusion scale (for example: satisfactory, needs improvement, unsatisfactory) and reporting-timing norms.\n- The stakeholder distribution expectations (who receives the report, in what form, by when) fixed at planning.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement lead with CAE escalation authority owns the stated judgments and authorizations.*\n\n*Issue final report handoff.* Conclude the engagement against its objectives, hold the closing conference, and hand a report-ready package to Audit Report Drafting — conclusions supported, facts confirmed, distribution and timing committed (IIA Standards 14.5 and 15.1).\n\n1. Form a conclusion per engagement objective, supported by the findings in aggregate — the distribution and pervasiveness of ratings, not just the single worst item. State the basis in two or three sentences. Where a scope limitation existed, say what could not be concluded and why.\n2. Hold the closing conference with accountable auditee leadership present: findings, ratings, conclusions, agreed actions. Resolve factual disputes by evidence in the room or immediately after; judgment disputes are recorded as management's perspective alongside the finding — never edited away.\n3. Assemble the handoff package for Audit Report Drafting: the final findings register (four Cs, ratings, agreed actions, management responses), conclusions per objective with basis, scope and limitation wording, the closing-conference record, the distribution list, and the issuance-timing commitment (per methodology — commonly a draft within 10 business days of the closing conference).\n4. Screen the package against the communication quality criteria before it leaves: accurate, objective, clear, concise, constructive, complete, timely. Anything failing gets fixed here, where the evidence is at hand — not in the drafting workflow.\n5. Record commitments made in the conference (dates, follow-ups, out-of-scope requests parked for planning) so they do not evaporate.\n\n*Classify disposition.* Classify the engagement's result so only the relevant closure path stays live: clean, remediation required, or escalation. The engagement lead proposes; escalation routes through the CAE delegate.\n\n\n\n**clean — No reportable gap** when no finding meets the reporting threshold (per methodology — commonly nothing rated moderate or above, with minor items handled as management-letter comments), every objective concludes at least satisfactorily, and no disagreement or scope limitation remains open.\n- **remediate — Remediation required** when one or more reportable findings exist, management concurs, every such finding carries an agreed action plan, and none meets an escalation test below. The follow-through is action-plan registration, not escalation.\n- **escalate — Escalate significant issue** when any of: a finding at the top severity tier or a pervasive control breakdown; suspected fraud or an illegal act; management non-concurrence that leaves risk above the organization's appetite (the IIA Standard 11.5 chain — CAE to senior management, then the board — applies); a scope limitation that prevented concluding on an objective; or a repeat finding overdue beyond audit-committee tolerance.\n\nPick the most severe applicable path: an engagement with agreed actions and one escalation-trigger finding routes to escalate — the escalation step decides what returns to the remediation track.\n\n**Record in AssureSwarm**\nStep document: the closing-conference record — attendees, date, disputes and their resolution.\n- Step fields: the conclusion per objective, with basis. Item field update on the anchor Audit item for the overall engagement result: rating (satisfactory | needs_improvement | unsatisfactory), opinion where applicable, and fieldwork_end.\n- Step documents: the report-drafting handoff package linked as documents; the distribution list and issuance-timing commitment.\n\nSubmit the disposition_path SELECT. The rationale must cite the specific finding ids and ratings that drove the classification; name the decision owner.\n\n**Exit criteria**\nConclusions are recorded per objective and trace to the findings register; the closing conference is documented with disputes resolved or recorded as management perspective; the report-drafting package is complete, quality-screened, and linked.\n\nForm submitted; the rationale references the findings register; unused branches are prunable because the recorded value matches one branch's whenValue.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Register the already agreed actions, policy-based validation methods, links and aging monitors automatically.","instructions":"**Objective** — Register every agreed action as an owned, trackable record with validation criteria, ready for Finding Remediation & Action-Plan Monitoring to run without re-negotiating anything.\n\n**Inputs**\n- The agreed action plans (owner, date, completion definition, interim mitigation) from the agreement step.\n- The finding items with ratings.\n- The issue-management policy: aging thresholds, escalation ladder, validation requirements by severity.\n\n**Procedure**\n1. Create one action record per discrete action, not per finding — a finding remediated by three actions gets three records, each independently verifiable and closable.\n2. Populate each record: named individual owner, due date within the policy's severity norms (or the recorded justification), the completion definition (the evidence that will prove it done), the root cause it addresses, and any interim mitigation with its operator.\n3. Set the validation method by severity per policy: significant findings close only on auditor re-testing; moderate on evidence review; minor may close on owner attestation where policy allows. Write the method on the record so the monitoring workflow inherits it rather than deciding it later.\n4. Arm the aging machinery: a watchlist on due dates, and the escalation ladder recorded — owner, then the owner's manager at overdue, then committee reporting at the policy threshold (commonly 30, 60, and 90 days past due).\n5. Cross-link everything: action to finding, finding to control and risk, so remediation monitoring inherits full context and closure updates flow back into the control's history.\n\n**Record in AssureSwarm**\n- Item field update on each finding Issue: issue_owner (USER), target_remediation_date, and remediation_plan (RICHTEXT holding each discrete action, its completion definition, its validation method, the root cause it addresses, and any interim mitigation with its operator). There is no native Action-Plan item type, so a finding remediated by three actions cannot yet hold three independently closable records — the actions are enumerated inside remediation_plan and, where finer tracking is needed, in a step document attached here.\n- Item relationships: keep each Issue linked to the Control and Risk it addresses so remediation monitoring inherits full context and closure flows back into the control's history.\n- Step fields: the aging watchlist on due dates and the escalation ladder (owner → manager → committee thresholds).\n\n**Exit criteria** — Every reportable finding's actions exist as registered records with owner, date, completion definition, and validation method; links run action-to-finding-to-control; watchlists are active; nothing requires the monitoring workflow to re-decide terms.","label":"Register action plans","requiredApprovals":0},"id":"create-action-plan"},{"data":{"description":"Escalate to engagement lead, CAE delegate, or audit committee delegate or document risk acceptance","instructions":"**Objective** — Put the significant issue in front of the authority matched to its exposure — engagement lead, CAE delegate, or audit-committee delegate — and land a documented decision: remediate anyway, formally accept the risk, or escalate further (IIA Standard 11.5).\n\n**Inputs**\n- The escalation-trigger findings with ratings and evidence links.\n- Management's stated position: the non-concurrence rationale or proposed alternative.\n- The organization's risk-appetite statement and relevant tolerance thresholds.\n- Prior escalation history for this entity (a second trip on the same issue changes the audience).\n\n**Procedure**\n1. Prepare a one-page decision memo: the issue, the weight of evidence, quantified exposure (annualized where possible — dollars, records, regulatory penalty ranges), management's position, internal audit's position, and the options with their consequences. Decision-makers act on quantified exposure; 'control gap' alone does not move a committee.\n2. Route by severity of exposure. An engagement-level disagreement goes to the CAE delegate. Risk accepted by management that may exceed the organization's appetite follows the Standard 11.5 chain: the CAE raises it with senior management and, if unresolved, escalates to the audit-committee delegate. Internal audit escalates — it never accepts risk on management's behalf.\n3. If the decision is risk acceptance, capture: who accepts (name and role, with authority commensurate to the exposure), the scope and expiry of the acceptance (time-bound, re-affirmed at least annually — never perpetual), the conditions attached (compensating controls, monitoring, exposure caps), and where the acceptance is reported (the committee pack).\n4. If the authority decides to remediate, register the agreed actions inside this escalation checkpoint; the separate registration branch is pruned. Record each discrete action in its finding Issue.remediation_plan or a linked action-detail document, with named owner, due date or severity-based justification, completion evidence, root cause, interim mitigation and operator, and validation method. Significant findings require auditor retesting; moderate require evidence review; minor may use owner attestation only where policy permits. Keep Issue.issue_owner and target_remediation_date current, link finding to Control and Risk, and activate the owner → manager → committee aging thresholds from policy. Record the deciding authority and pass the registered commitments to remediation monitoring without a second registration task.\n5. Either way, define follow-up ownership: who monitors the conditions, with a watchlist on the acceptance expiry and on condition breaches.\n\n**Record in AssureSwarm**\n- Step document: the one-page decision memo and the written decision; decider name, role, and date in the step's fields.\n- Item create (risk-acceptance path): an Issue — issue_type: policy_exception, exception_approver (the decider), exception_expiry_date (the time-bound acceptance expiry), description (scope and attached conditions — compensating controls, monitoring, exposure caps). Item relationships: link that Issue to the finding Issue it covers and to the Risk; set treatment: accept on that linked Risk. The exception_expiry_date is the filterable index the watchlist is armed on.\n- Item relationships / step fields: links from the decision to the findings it covers; the committee-reporting note.\n\n**Exit criteria** — A documented decision exists from someone whose authority matches the exposure; any acceptance is time-bound with conditions and a named follow-up owner; the watchlist is active; the committee-reporting entry is made.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Accept the approved conclusions, completion definitions, reporting commitments and monitoring responsibilities with explicit no-repeat boundaries.","instructions":"**Objective** — Accept the approved conclusions, completion definitions, reporting commitments and monitoring responsibilities with explicit no-repeat boundaries.\n\n**Inputs**\nAll workpapers and accepted evidence, linked per workstep.\n- The findings register, action plans, and conclusions.\n- The disposition decision-gate record, with its rationale and owner.\n- Escalation or risk-acceptance memos where that path ran; the QA report and its resolution trail; the closing-conference record.\n\nThe version-stamped final package with its index.\n- The findings register, registered action plans, and conclusions per objective.\n- The closing-conference record and distribution commitments.\n- The unresolved-constraints memo.\n- The record-retention policy for engagement workpapers (commonly seven years, or the strictest applicable regulator).\n- The post-close obligations accumulated on the path: action-plan due-date watchlists and risk-acceptance expiries.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Audit Report Drafting and Finding Remediation workflow owners owns the stated judgments and authorizations.*\n\n*Prepare final package.* Compile the complete, self-supporting engagement package — evidence, analyses, decisions, conclusions, and unresolved constraints — so a reviewer, external assessor, or regulator can re-walk the engagement's logic without asking anyone (IIA Standard 14.6).\n\n1. Assemble in review order: objective, scope, and criteria; the locked work program plus approved changes; per-procedure evidence and results; findings with their four Cs; action plans; conclusions; the disposition rationale.\n2. Verify traceability in both directions: every finding traces back to accepted evidence, and every planned procedure traces forward to a result or a documented, approved deviation. Every decision gate shows its recorded rationale and owner. A package that cannot answer 'why is this finding here' or 'where did that procedure go' is not done.\n3. Sweep for leftovers: draft-marked documents, unresolved comments or suggested changes, placeholder text, superseded versions. Mark superseded items as such and retain them per the record policy — never delete evidence to tidy a package.\n4. Write the unresolved-constraints memo: scope limitations and their effect on conclusions, reliance placed on other assurance providers, open disagreements and where they were escalated. This is the page downstream consumers actually need.\n5. Confirm the index and cross-references resolve, then version-stamp the package with a date.\n\n*Handoff to related workflow.* Hand the engagement's outputs to Audit Report Drafting and Finding Remediation & Action-Plan Monitoring with explicit contents and explicit no-repeat boundaries, and close the engagement on a preserved, reconstructable audit trail with every post-close monitor armed and owned; the human moment is securing each downstream owner's acknowledgment of what they are taking on.\n\n_Items 11–15 close the engagement (folded from the former \"Close and archive\" step); the acknowledged handoff recorded here is the closure, not a separate confirmation._\n\n6. Create or link both downstream workflow instances on the same engagement item, so lineage is navigable from either end.\n7. To Audit Report Drafting, pass: conclusions per objective with basis; the findings register (four Cs, ratings, agreed actions, management responses); scope and limitation wording; the closing-conference record; the distribution list and issuance-timing commitment. State what drafting must not redo: re-rating findings and re-negotiating agreed action text are settled — a drafting-stage change request comes back as a suggested change on the finding, never a silent edit.\n8. To Finding Remediation & Action-Plan Monitoring, pass: the registered action records with owners, dates, completion definitions, validation methods, and armed watchlists. State its boundary: it validates against the completion definitions written here and does not re-litigate root cause or severity.\n9. Record the assumptions each consumer inherits: ratings final as of the closing conference; acceptance expiries and their dates; any constraint from the memo that changes downstream behavior.\n10. Get receipt confirmed: each downstream owner acknowledges the package by approval or comment. A link dropped into a workflow nobody has opened is not a handoff — this acknowledgment is the step's human moment and the trigger for closing out.\n11. Verify completion before archiving: every workstep closed or documented as not performed with a reason and approval; all approvals present; no orphan open comments or unresolved suggested changes anywhere on the workflow.\n12. Archive the final package and workpapers under the retention policy and mark the records read-only per practice. Post-archive corrections are new, dated addenda — never in-place edits; the archived record is what an external assessor or regulator sees (IIA Standard 14.6).\n13. Update the linked records so the next planner starts warm: the auditable entity's last-audited date and conclusion; each tested control's result history; the issue register.\n14. Confirm every post-close monitor has a named owner and is live: action-plan due-date watchlists and risk-acceptance expiry. An unowned monitor is a silent failure a year from now.\n15. Communicate closure: update the CAE record and the committee reporting feed, send the closure note to the auditee, and capture a short team debrief — what should change in the next cycle feeds back to Audit Engagement Planning.\n\n**Record in AssureSwarm**\nStep document: the rendered, indexed engagement package attached to this step.\n- Item relationships: links from the package entries to their source worksteps and the evidence documents, finding Issues, and the disposition record they draw on.\n- Step fields: the package version and date.\n\nWorkflow instances: link both downstream workflow instances — Audit Report Drafting and Finding Remediation & Action-Plan Monitoring — to the same anchor Audit item so lineage is navigable from either end.\n- Handoff package: a handoff note per consumer (contents passed, the no-repeat list, inherited assumptions) attached as a step document.\n- Step field: the receipt acknowledgment (approval or comment) from each downstream owner.\n- Workflow instance: the run itself closed and archived read-only as the durable audit trail; archive confirmation and location recorded, with post-archive corrections captured as new, dated addenda (never in-place edits).\n- Item field update on the anchor Audit item: report_date and the final rating/opinion, so the auditable entity's last-audited state is queryable through the Audit ↔ Process relationship (Process has no native last_audited field — this is satisfied by convention via the Audit item's report_date).\n- Item updates: each tested Control's result history and the Issue register updated, linked with dates.\n- Step fields: the list of active monitors (action-plan due-date watchlists, risk-acceptance expiries) with owners; the closure communication note; the debrief comment.\n\n**Exit criteria**\nThe package renders complete with working cross-references; two-way traceability holds; no drafts, placeholders, or unresolved comments remain; the constraints memo is included; the version stamp is recorded.\n\nBoth downstream workflows are linked and their owners have acknowledged receipt; each handoff note states contents, boundaries, and assumptions; no downstream question requires reopening this engagement's records to answer; the package is archived and immutable per policy; linked records reflect the engagement's results; every monitor is active with a named owner; closure is communicated and the debrief recorded.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — renders the indexed evidence-and-decision package from the workflow's linked items, documents, and form results.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:audit-engagement-lifecycle"}