{"description":"Runs on the existing Audit using approved fieldwork conclusions, findings and management responses. Produces the audit report after management factual confirmation and independent IA management approval of the exact draft, then the issued report, completion announcement and tenant-bound MAR survey dispatch record for remediation monitoring and QAIP.","edges":[{"id":"e-draft-issues-and-ratings-incorporate-management-responses","source":"draft-issues-and-ratings","target":"incorporate-management-responses"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"complete"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-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-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"},{"id":"e-incorporate-management-responses-management-confirm-report-facts","source":"incorporate-management-responses","target":"management-confirm-report-facts"},{"id":"e-management-confirm-report-facts-ia-approve-report-draft","source":"management-confirm-report-facts","target":"ia-approve-report-draft"},{"id":"e-ia-approve-report-draft-classify-disposition","source":"ia-approve-report-draft","target":"classify-disposition"}],"isPublic":true,"itemTypeSlug":"audit","metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AUDIT-16","UC-AUDIT-14","UC-AUDIT-15"],"department":"internal-audit","domains":["audit"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=audit-report-drafting","contentDigest":"sha256:3cbf5a0ef0478f6bd8be09a582416a5e7eb002647bd276ff4f2fbe762d8e397f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:3cbf5a0ef0478f6bd8be09a582416a5e7eb002647bd276ff4f2fbe762d8e397f","schemaVersion":1,"sourceTemplateId":"workflow-library:audit-report-drafting"},"lifecycleContract":{"absorbedNodeIds":{"circulate-draft-report":"incorporate-management-responses","compile-fieldwork-findings":"draft-issues-and-ratings","prepare-final-package":"approve-or-revise-package","record-approval-decision":"handoff-to-related-workflow","write-the-executive-summary":"draft-issues-and-ratings"},"approvalPolicy":"Independent reviewers cannot be the preparer, tester or control owner for the reviewed work. Required approval counts alone do not establish actor independence; verify assignments and exact versions at execution.","bindingRequirements":["Resolve named human roles to actual users and configure native step approvals before execution.","Workstream and Narrative Module are tenant communication/document destinations; verify a supported connector or record manual dispatch by the authorized sender.","EY is the tenant-bound external auditor; preserve its independent methodology and reliance judgments.","MAR meaning, approved survey instrument/version, owner, recipients and channel must be supplied by the tenant; no definition is assumed."],"bindingStatus":"requires-tenant-configuration","checkpoints":[{"contribution":"Set supported finding ratings and the report opinion from the evidence.","interventions":["expertise"],"nodeId":"draft-issues-and-ratings","requiredApprovals":1,"role":"IA engagement lead"},{"contribution":"Judge response adequacy and preserve disputed facts and commitments.","interventions":["expertise"],"nodeId":"incorporate-management-responses","requiredApprovals":1,"role":"IA engagement lead with accountable management respondents"},{"contribution":"Approve report-to-record matches and resolve unmatched findings before release under the two prior approvals.","interventions":["approval","expertise"],"nodeId":"classify-disposition","requiredApprovals":1,"role":"IA engagement lead"},{"contribution":"Choose the supported clean, remediation or escalation disposition; no adverse evidence is hidden.","interventions":["expertise","variance"],"nodeId":"classify-disposition","requiredApprovals":1,"role":"Accountable IA/SOX lead"},{"contribution":"Commit corrective actions, resources, deadlines and acceptance evidence.","interventions":["approval"],"nodeId":"create-action-plan","requiredApprovals":1,"role":"Accountable remediation owner"},{"contribution":"Decide the bounded exposure and follow-up obligations within delegated authority.","interventions":["approval"],"nodeId":"escalate-or-accept-risk","requiredApprovals":1,"role":"Authorized risk acceptance or escalation authority"},{"contribution":"Approve the supported conclusion and package or require specified revisions.","interventions":["approval","expertise"],"nodeId":"approve-or-revise-package","requiredApprovals":1,"role":"Independent IA/SOX package approver"},{"contribution":"Judge evidence resolving each requested revision before reapproval.","interventions":["expertise","approval"],"nodeId":"resolve-approval-conditions","requiredApprovals":1,"role":"Original independent package approver"},{"contribution":"Resolve residual caveats and accept the next phase’s commitments, required coverage and dates.","interventions":["approval","expertise"],"nodeId":"handoff-to-related-workflow","requiredApprovals":1,"role":"IA/SOX accountable lead and receiving owner"},{"contribution":"Authorize issuance of the exact final draft after management factual confirmation.","interventions":["approval","expertise"],"nodeId":"ia-approve-report-draft","requiredApprovals":1,"role":"CAE or authorized IA director independent of preparation"},{"contribution":"Confirm the exact final draft’s facts and management commitments without controlling IA’s opinion.","interventions":["approval","expertise"],"nodeId":"management-confirm-report-facts","requiredApprovals":1,"role":"Accountable business/process management"}],"version":1},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"audit-report-drafting","source":"coworkcanvas-gallery","standards":["iia-2024"],"teams":["internal-audit"]},"name":"Audit Report Drafting","nodes":[{"data":{"description":"Complete Draft issues and ratings","instructions":"**Objective** — Draft each audit issue as a citable five-part finding with an assigned severity, and compose the report's dedicated \"Self-identified issues\" section, so the report presents every deficiency in one consistent, evidence-backed structure and separately highlights the issues the audit team surfaced proactively.\n\n**Human contribution** — IA engagement lead (expertise): Set supported finding ratings and the report opinion from the evidence. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The engagement's existing Audit item — the anchor this workflow runs on, its scope, description, period_start/period_end, and lead_auditor already populated upstream. Every step operates against this record; it is an input, never something this workflow creates.\n- The fieldwork handoff package consumed from the Internal Audit Engagement Lifecycle workflow — exception log, workpapers, root-cause notes, and criteria references — attached as documents to that workflow's handoff step and linked to the Audit item.\n- The engagement's severity rating scale and any aggregation convention: the Issue.severity select (low | medium | high | critical) is the operative scale; any richer rating methodology lives as a document on this step — it has no native field.\n- Prior reports and the open-issue register for this auditee — prior Audit items with their issued-report documents attached, and the open Issue items linked to them via Issue ↔ Audit relationships; repeat findings escalate.\n- Approved audit criteria and fieldwork exceptions from the linked Audit and testing workpapers; compile the candidate-finding list during draft-issues-and-ratings before drafting ratings.\n- The linked workpapers and supporting evidence for each candidate, and each candidate's root-cause narrative and accountable owner.\n- Prior issue history for this auditee — Issue items linked to prior Audit items via Issue ↔ Audit relationships — and the intended stakeholders from the approved engagement plan; record the initial list on draft-issues-and-ratings, then finalize recipient and socialization records at incorporate-management-responses.\n- The engagement's severity rating scale: the Issue.severity select (low | medium | high | critical).\n- The drafted and severity-rated finding Issue items linked to the anchor Audit.\n- The engagement scope and objectives, the approved criteria, and the audit period — Audit.scope, Audit.description, Audit.period_start, and Audit.period_end on the anchor Audit item.\n- The initial stakeholder list established within draft-issues-and-ratings and the overall opinion or rating destined for Audit.opinion and Audit.rating at issuance.\n\n**Procedure**\n*Agent preparation and filing absorb “Compile fieldwork findings”, “Write the executive summary”; the role named below owns the substantive review.*\n1. Separate exceptions from findings. An exception is a single test failure; a finding is a reportable condition. Promote an exception to candidate finding when it is systemic (multiple instances or a design gap), high-impact even as a one-off (for example an unauthorized privileged change), or a repeat of a previously reported issue. Isolated, low-impact, corrected-on-the-spot errors go to a management-letter or verbal list — record that disposition rather than silently dropping them.\n2. Merge duplicates by root cause, not by symptom: five exceptions across three applications that all trace to a missing joiner-mover-leaver process are one finding with five instances, not five findings. The instance count becomes the finding's extent-of-condition evidence.\n3. For each candidate, assemble the drafting bundle: the observed condition with quantification (how many of how many tested, over what period), the criteria citation, the validated root cause, and the effect pathway — what can go wrong because of this, stated in business terms, not control jargon.\n4. Check aggregation in both directions: several moderate exceptions in one process may aggregate to a high-severity theme (a pervasive control weakness), and conversely confirm no exception is double-counted across two candidates.\n5. Sweep for completeness against the workpapers: every exception in the fieldwork handoff package is either inside a candidate finding, on the management-letter list, or documented as not reportable with a reason. An exception that appears nowhere is the classic QA failure in report drafting.\n6. Assign each candidate a preliminary severity view against the rating scale so drafting starts with the worst first; the formal rating follows in this checkpoint.\n\nPart one — findings.\n7. Pull the audit's issues and their supporting evidence from the workspace.\n8. Author one finding per issue, written as five explicit parts: Condition (what was actually observed), Criteria (the standard, policy, or control the condition is measured against), Cause (why the gap occurred), Effect (the risk or business impact), and Recommendation (the corrective action).\n9. Assign each finding a severity on the engagement's rating scale, and propose the owner, severity, and linkage from the issue's process, control, and risk affinity: parse the draft for keywords against the process-and-control taxonomy; match existing controls and risks by topic-tag overlap; treat matched controls' owners as strong owner candidates. Severity starts from the audit lead’s assessment of the compiled fieldwork exceptions and is adjusted for the SOX relevance of the linked controls. The routing proposal informs the rating; the engagement lead's judgment sets it.\n10. Order the findings from most to least severe so the reader meets the highest-impact issues first.\n11. Write in a declarative, evidence-led voice: state what the evidence shows; avoid hedging such as \"we believe\" or \"it appears that\" unless the issue is genuinely inconclusive; never introduce a finding, date, or recommendation the evidence does not support — where a needed fact is missing, flag the gap for follow-up rather than inventing it.\n12. Because a finding is an Issue item in the workspace, create or update one Issue per finding: description carries the condition, criteria citation, and effect narrative; root_cause carries the cause; recommendation carries the corrective action; set severity, issue_type: finding, source: internal_audit, identified_date, and issue_owner. Link each Issue to the anchor Audit item, to the Control it concerns, and to the Risk where one matched, so downstream rendering can cite it.\n\nPart two — the self-identified issues section.\n13. The Issue type carries no dedicated self-identified field — a schema gap — so read each issue's root_cause narrative and treat the issue as self-identified when the narrative contains self-identification markers (for example \"self-identified\" or \"management-identified\"). Select only the issues flagged this way.\n14. For each selected issue, walk back through the workflow steps on this audit that surfaced it — the step-to-item links that connect a workflow step to the issue — and capture the surfacing step's id and title so the section can point back to exactly where the issue was raised.\n15. Group the selected issues by severity, presenting high first, then moderate, then low. Render the section as: a \"Self-identified issues\" heading with a short framing sentence stating that the team identified these issues during fieldwork and raised them to management proactively; a sub-heading for each severity band that has entries; and, under each band, one entry per issue carrying the issue title, its description, its root cause, and its owner, ending with a source citation that names the surfacing workflow step id and the issue id. Cite every entry; invent nothing.\n16. If no issue is self-identified, render a clean \"No self-identified issues this period\" as the section body — a valid result, not an error, and never padded or fabricated.\n17. Human checkpoint: the engagement lead reviews the severity ratings and the criteria linkage, and confirms the self-identified issues section fairly reflects which issues the team raised proactively, before the findings feed the executive summary.\n\n18. Pull the drafted issues and their severity ratings from the workspace — the summary is written from the rated findings, never from memory of fieldwork.\n19. Compose exactly three paragraphs. Paragraph one states the engagement's scope, objectives, and period — what was examined and why. Paragraph two synthesizes the key findings, leading with the highest-severity issues and their aggregate significance rather than restating every finding one by one. Paragraph three gives the overall opinion or conclusion, tied back to the findings and to management's committed direction.\n20. Write in a declarative, evidence-led voice, holding the summary to the communication-quality bar of IIA GIAS 11.2 — accurate, objective, clear, concise, constructive, complete, timely. Keep every statement traceable to a drafted finding or to the scope data, and never assert a conclusion the findings do not support; where a needed fact is missing, flag the gap for follow-up rather than inventing it.\n21. Assemble the report in the standard structure the engagement lead expects: the executive summary (this step); a Scope and Objectives section drawn from the audit's scope and objectives; a Methodology section stating the standard audit approach plus this engagement's sampling approach; the rated findings; the management responses; and a Conclusion synthesized from the findings and the overall opinion.\n22. Once the report has been assembled and rendered, attach the summary and the full report document (DOCX) to this step and link them to the anchor Audit item so reviewers and stakeholders work from the rendered draft rather than loose copies.\n23. Human checkpoint: the engagement lead confirms the summary fairly represents the rated findings and the opinion before the draft is circulated.\n\n**Record in AssureSwarm**\n- The candidate-finding list as a document (XLSX/CSV) on this step: per candidate, its exception references, criteria citation, root cause, instance count, and preliminary severity.\n- The management-letter list and the not-reportable dispositions with reasons, in the same step document.\n- Links from this step to the handoff-package workpapers each candidate cites, so drafting pulls evidence without re-searching.\n- One Issue item per finding — description (condition, criteria citation, effect, and the rating rationale), root_cause, recommendation, severity, issue_type: finding, source: internal_audit, identified_date, issue_owner — with the workpaper evidence documents linked.\n- Item relationships: each finding Issue ↔ the anchor Audit, ↔ the Control it concerns, ↔ the matched Risk.\n- For the self-identified section: the composed section text with each entry's surfacing-step id plus issue id citation, the per-severity grouping, and the count of self-identified issues across severities (or an explicit zero) — recorded on this step; the Issue type has no self_identified field, so this step's record is the section's home.\n- The engagement lead's checkpoint sign-off as an approval or comment on this step.\n- The assembled draft report with its three-paragraph executive summary as a DOCX document on this step, also linked to the anchor Audit item.\n- The findings and scope references each paragraph draws on — links from this step to the finding Issue items cited.\n- The stated overall opinion, noted with the draft; it is written to Audit.opinion and Audit.rating only at issuance, never from a draft.\n\n**Exit criteria** — Every fieldwork exception is dispositioned (candidate, management letter, or not-reportable-with-reason); candidates are deduplicated by root cause with instance counts; each candidate carries condition quantification, criteria citation, root cause, and effect pathway; the preliminary severity ordering is recorded. All findings are drafted in the condition, criteria, cause, effect, and recommendation form, severity-rated, sorted, and evidence-linked, with severities applied consistently with the rating scale; every finding and every self-identified entry is supported by sufficient, relevant, independently reviewable evidence tied to the approved audit criteria, with no unsupported assertion; every self-identified entry ends with a step-and-issue citation pointing to live records; the section is composed (or the clean empty case rendered) and ready for executive-summary synthesis and rendering. A three-paragraph executive summary is written and reconciled to the rated findings; the overall opinion is stated and consistent with the findings and the approved criteria; every claim is independently reviewable and free of anything the evidence does not support; the rendered report is attached and ready to circulate.","label":"Draft issues and ratings","performedBy":{"agent":"audit-artist","note":"findings drafting + self-identified issues section composition","primitives":["coach-query-data","coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]},"requiredApprovals":1},"id":"draft-issues-and-ratings"},{"data":{"description":"Complete Incorporate management responses","instructions":"**Objective** — Incorporate management's responses into the draft report and compose the Management Response section, so every rated finding is presented together with the action management has committed to.\n\n**Human contribution** — IA engagement lead with accountable management respondents (expertise): Judge response adequacy and preserve disputed facts and commitments. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The current rendered report draft — the DOCX at draft-issues-and-ratings — and its version.\n- The engagement's stakeholder distribution list, a document on this step (no native stakeholder type — accountable process owners come from Process.process_owner and Control.control_owner on linked items), and the audit's finding Issue items.\n- Any prior socialization history recorded in this step's earlier cycle records.\n- The response-deadline convention (default three business days).\n- The drafted and severity-rated finding Issue items.\n- Each finding's recorded management response in Issue.management_response, plus missing or inadequate responses supplied by accountable management executors in native results or documents against the identified finding.\n- The accountable owners and the agreed remediation target dates, destined for Issue.issue_owner and Issue.target_remediation_date.\n\n**Procedure**\n*Agent preparation and filing absorb “Circulate draft report”; the role named below owns the substantive review.*\n1. An audit report typically goes through three to five drafts before final issuance, each shared with a different audience in sequence — v1 lead review, v2 director review, v3 CAE review, v4 business-owner review, v5 audit-committee final. For the cycle being run, resolve the audit and the specific draft version, confirm the intended cycle with the engagement lead, and build the recipient distribution list for that cycle's standard audience (or accept an explicit list the lead supplies).\n2. Draft one cover message per cycle, matching the audience's tone: for the lead, director, and CAE reviews, write collegially with specific review asks and a \"please review and respond by <deadline>\" close; for the business-owner review, write professionally, summarize the findings, and request the management response by the deadline; for the audit-committee cycle, write formally with an executive summary framed \"for your review ahead of the meeting on <date>\".\n3. Draft messages only — never send them. The human reviews each draft and clicks send in their own email tool.\n4. Before any message leaves the audit team, run a confidentiality and redaction pass so confidential findings are not over-distributed to a wider audience than the cycle intends.\n5. Record each cycle on this step — there is no native socialization-cycle item type, so this step's data is the cycle register — capturing the cycle name, the version sent, the recipient list, the send timestamp, the response deadline, and an initially-empty responses list, linked to the report document and the anchor Audit item, so later cycles and any audit rollover can see who has already participated.\n6. Follow-up pass: after the response deadline passes, scan the audit's comments and any external responses for entries from the recipient list since the send timestamp, and append each response to that cycle's responses list; for non-responders, draft a reminder message (again, draft only).\n7. When every responder has responded or the lead decides to advance, mark the cycle complete and make the next draft version the focus.\n8. Human checkpoint: the engagement lead confirms the recipient list and approves each cover-message draft before it is sent, and decides whose feedback to incorporate — the workflow never overrules that judgment, never sends on the lead's behalf, and never finalizes or closes the report itself. The audit-committee cycle is the formal final-issuance touchpoint, but recording it does not auto-close the audit; the lead auditor closes it through the normal workspace flow.\n\n9. For every rated finding, pull management's response from the finding record and render it beside the finding: the agreed action, the owner accountable for it, and the target completion date.\n10. Distinguish management's acceptance of a finding from a disagreement or a formal risk-acceptance, and record which it is. A disagreement is presented as management's stated position alongside the audit view; a formal acceptance of risk above appetite is an escalation trigger under IIA GIAS 11.5, not just a paragraph in the report — its durable record is made at the escalate-or-accept-risk step as a policy_exception Issue with treatment: accept set on the linked Risk.\n11. Test each response for adequacy before accepting it into the report: the action addresses the finding's cause, not just the observed instances; the owner is a named person with authority over the process; the target date is proportionate to the severity. Push an inadequate response back to the owner with the specific gap named — have the accountable management executor record the corrected response against the finding in native results or documents, retaining their stated position, action, owner, target date and relevant constraints.\n12. Present the responses per finding, ordered to match the findings section, so a reader sees each issue and its committed remediation together.\n13. Where a finding has no response yet, flag it as outstanding and assign the missing response to its accountable management executor in the existing checkpoint and block issuance until resolved.\n14. Human checkpoint: the engagement lead judges each response's adequacy and confirms every rated finding carries a management response or a documented risk-acceptance before the report advances to finalization.\n\n**Record in AssureSwarm**\n- Each cycle's version, audience, recipients, send date, deadline, and collected responses — recorded as data on this step, which serves as the cycle register (no native socialization-cycle type).\n- Links from this step's cycle records to the report document and the anchor Audit item.\n- Any non-responders still outstanding, listed in the cycle record.\n- Item field updates per finding Issue: the response text in Issue.management_response, the accountable owner in Issue.issue_owner, the agreed target date in Issue.target_remediation_date.\n- Accountable management executors record their position, committed action and cause addressed, action owner, target date, interim mitigation, dependencies and supporting documents in native results against the finding. Reuse existing Issue values, update them only with the owner’s response, and record the IA lead’s adequacy judgment separately; do not issue these executors a collection form.\n- Any findings still awaiting a response, flagged as outstanding on this step.\n- Any formal risk-acceptances, noted here for the monitor branch — the durable acceptance record is the policy_exception Issue (exception_approver, exception_expiry_date) created at escalate-or-accept-risk, with treatment: accept on the linked Risk.\n\n**Exit criteria** — The current cycle's cover-message drafts are staged for the lead to send; the cycle is recorded on the audit with its recipients and deadline; every draft version is traceable to the audience it went to and the responses it drew; no message was sent by the agent and no finding, date, or recommendation was added that the evidence does not support; prior-cycle responses are collected, and either the next cycle is queued or the report is ready to advance to management responses. The Management Response section is composed with every finding answered or its acceptance documented; owners and dates are concrete; each response is tied to its specific finding; the report is ready to finalize.\n\n","label":"Incorporate management responses","performedBy":{"agent":"audit-artist","note":"management-response section composition","primitives":["coach-query-data","coach-item-update","coach-item-create","coach-items-link","coach-notify"]},"requiredApprovals":1},"id":"incorporate-management-responses"},{"data":{"decisionField":"disposition_path","description":"Approve the report-to-record match table before updates, release the twice-approved report, then classify the evidenced reporting outcome and any remaining gaps.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve the report-to-record match table before updates, release the twice-approved report, then classify the evidenced reporting outcome and any remaining gaps.\n\n**Inputs**\nThe approved final report file (Word or PDF).\n- The anchor Audit item these findings belong to and its existing finding Issue items (linked Issue ↔ Audit).\n- Each finding's number and title, and the linked workpapers and evidence.\n- The stakeholder distribution list (the document at incorporate-management-responses) and the reporting expectations.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Accountable IA/SOX lead owns the stated judgments and authorizations.*\n\n*Finalize and issue the report.* Finalize and issue the audit report, then reconcile the workspace's existing issue records so their wording matches the issued report. Once the report is finalized its wording is canonical: the workspace issue records are brought into alignment with the report — never the report changed to match the records.\n\n1. Before release, verify completed native approvals at management-confirm-report-facts and ia-approve-report-draft, both bound to the exact document version being issued. Any substantive change requires renewed confirmation and approval. Prepare and resolve the finding-to-record match table before releasing; unresolved factual corrections return to those gates.\n\n2. Run the report-to-record sync-back so the workspace matches the approved final wording. Extract the finding sections from the approved final draft, where each finding runs from its heading (for example \"Finding 3: <title>\" or \"F-014: <title>\") to the next heading.\n3. Pull the audit's existing issue records and build an index keyed by both finding number and title. Match each report finding to its existing issue record: first by finding number, then fall back to a title match when no number lines up.\n4. For every match, propose the Issue description and recommendation changes using the final report wording; apply them only after the lead approves the complete match table below, and stamp the source of the text in the record (for example \"audit report, <issue date>\") so the audit trail captures where the wording came from; carry the updated recommendation wording through to Issue.remediation_plan where an action plan already references it.\n5. Never create a new issue record from the approved draft. If a report finding has no matching issue record, do not auto-create one; surface it as an unmatched finding for the engagement lead to resolve manually, and treat it as a signal of a process gap — a finding reached the approved draft without an issue record behind it.\n6. Present the proposed changes as a reviewable match table (each finding, its matched issue record ID, and the fields that would change) alongside a separate list of unmatched findings before any record is altered, and never introduce a finding, date, or recommendation the final report does not contain.\n7. Human checkpoint: the engagement lead reviews the match table and the unmatched-finding list, approves the batch of record updates before it is applied, and decides how each unmatched finding is resolved.\n8. Release the locked report to the approved recipient list under the engagement’s recorded sending authority. Attach the issued artifact, actual dispatch record, recipient list and delivery/receipt evidence. An unsent draft is not an issued report; unresolved channel bindings or missing authority block release. Keep the issued file immutable and communicate later corrections to all original recipients.\n\n*Classify disposition.* Classify how Audit Report Drafting ends so the agent keeps only the relevant closure path: everything landed clean, concrete gaps need owned action, or a residual concern warrants escalation or monitored acceptance instead of immediate action. The engagement lead owns the call.\n\n\n\nBase the classification on the issuance and reconciliation evidence from the preceding steps, not on optimism:\n\n- **Complete (`complete`)** — the report is issued and distributed to the full stakeholder list; every rated finding carries a management response or a documented risk-acceptance; the report-to-record sync-back matched every report finding to an issue record with wording reconciled; no unmatched findings remain; no reviewer condition is open. Nothing needs new work — proceed straight to the final package.\n- **Gaps require action (`gaps`)** — something concrete still needs an owner and a date: an unmatched finding surfaced by the sync-back (a finding reached the report without an issue record behind it — a process gap in its own right), a finding issued with its management response still outstanding, distribution incomplete to a required recipient, or record updates the lead rejected during reconciliation. Name each gap in the rationale so the action plan builds from a list, not a recollection.\n- **Monitor without immediate action (`monitor`)** — the report is issued but a concern remains that action cannot yet resolve: management formally accepted a risk the audit team rates above appetite (the IIA GIAS 11.5 escalation pattern), a disputed rating was issued over management's disagreement, or a committed remediation depends on an event outside the process (for example a system cutover). Route to the escalation and risk-acceptance step to put the concern in front of the right authority.\n\n**Record in AssureSwarm**\nThe issued report document (DOCX/PDF) on this step, linked to the anchor Audit item, with its distribution recorded; item field updates on the Audit — Audit.rating, Audit.opinion, Audit.report_date.\n- The sync-back match table — each finding, its matched Issue item ID, and the fields updated (Issue.description, Issue.recommendation) — plus the list of unmatched findings routed for manual resolution, as a document on this step; the source stamp applied to each updated record.\n- Workpaper and criteria linkage, owner accountability, and the reviewer conclusion.\n\nSubmit the decision form: `disposition_path` (the branch), the step result naming the specific evidence behind the classification (issuance record, sync-back match table, response register), and the step's approver record.\n\n**Exit criteria**\nThe final report is issued and attached; every existing issue record's wording matches the issued report with its source stamped; every report finding is either matched-and-synced or explicitly surfaced as unmatched, with no issue records auto-created; each update is tied to a specific finding and its evidence, and the change set is independently reviewable; all unmatched findings are surfaced for manual resolution and the reconciled record set is ready for disposition classification.\n\nThe form is submitted, the rationale names its evidence, and unused branches are prunable because the recorded value matches the selected edge.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — renders the final report package; its --cite mode binds every report claim to its AssureSwarm record and emits [NEEDS INFO] markers where a claim lacks a backing record.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"audit-artist","note":"final-report issuance plus report-to-issue sync-back engine","primitives":["coach-query-data","coach-item-update","coach-document-upload","coach-render-package"]},"requiredApprovals":1},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert each gap from the disposition call into an owned, dated, verifiable action plan so nothing identified at issuance dies in a meeting note.\n\n**Human contribution** — Accountable remediation owner (approval): Commit corrective actions, resources, deadlines and acceptance evidence. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The gap list named in the disposition rationale: unmatched findings, outstanding responses, rejected reconciliations, distribution misses.\n- The finding Issue items and the issued report for context, and the auditee's accountable owners.\n- The organization's issue-management conventions — severity-based target-date bands and the escalation ladder, from the governing Policy item in the policy library where one exists.\n\n**Procedure**\n1. Write one action per gap, not one plan for all of them — a plan that bundles five gaps gets closed when the easiest three finish.\n2. For each action, document the root cause (why the gap exists, not just what it is), the accountable owner — a named person with authority over the process, never \"the team\" and never internal audit itself — and a due date proportionate to severity under the organization's convention (high-severity gaps are measured in weeks, not quarters).\n3. Where the gap leaves live exposure until fixed (for example, a finding issued while its management response is still outstanding), record an interim mitigation and its owner.\n4. Define the validation evidence up front: the artifact that will prove the action closed — an updated issue record, a distribution receipt, a properly created issue for an unmatched finding. An action without pre-agreed closure evidence reopens later.\n5. Set the reporting cadence: when the owner reports progress, to whom, and the escalation trigger for a missed date.\n6. For each unmatched-finding action, include the process-gap question: how did a finding reach the issued report without an issue record behind it — fix the pathway, not just the instance.\n\n**Record in AssureSwarm**\n- Item field updates on each affected finding Issue: the action — root cause, interim mitigation, validation evidence, and reporting cadence — in Issue.remediation_plan, the accountable owner in Issue.issue_owner, the due date in Issue.target_remediation_date.\n- The per-gap action list as a document on this step, linked to the affected Issue items and the anchor Audit; for an unmatched-finding gap, the pre-agreed validation evidence is the properly created Issue record itself.\n- At-risk actions (soft owner, tight date) flagged in the action-list document — there is no native watchlist; Issue.target_remediation_date is the filterable date index.\n\n**Exit criteria** — Every disposition gap has exactly one owned action with root cause, due date, interim mitigation where exposure is live, pre-agreed validation evidence, and a reporting cadence; all actions are linked to their records.","label":"Create action plan","requiredApprovals":1},"id":"create-action-plan"},{"data":{"description":"Escalate to engagement lead, CAE delegate, or audit committee delegate or document risk acceptance","instructions":"**Objective** — Put the monitored concern in front of the right authority — engagement lead, CAE delegate, or audit committee delegate — and land a documented decision: escalate further, or accept the risk with conditions and an owner.\n\n**Human contribution** — Authorized risk acceptance or escalation authority (approval): Decide the bounded exposure and follow-up obligations within delegated authority. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The disposition rationale naming the concern: risk accepted above appetite, a disputed rating issued over disagreement, or an external-event dependency.\n- The affected finding Issue items with severities and management responses, and the linked Risk items with their inherent_rating and residual_rating.\n- The organization's risk-appetite statement and escalation ladder — Policy items in the policy library with the governing documents attached; the operative rating thresholds are the Risk rating scales.\n\n**Procedure**\n1. Frame the decision memo in one page: the concern, the finding or findings behind it, management's position, the audit team's position, and the specific decision requested. A memo that asks for \"awareness\" gets awareness — ask for a decision.\n2. Quantify the exposure as concretely as the evidence allows: amount at risk, process or population affected, and duration until a fix or event resolves it. Where quantification is genuinely impossible, say so and give the bounding scenario instead.\n3. Follow the escalation ladder in order: the engagement lead first; the CAE delegate where management has accepted a risk the audit team rates above appetite — the IIA GIAS 11.5 pattern: discuss with senior management, and if unresolved the CAE escalates to the board; the audit committee delegate only for unresolved above-appetite acceptances or disputes on high-severity ratings.\n4. If the decision is risk acceptance, record it as an Issue with issue_type: policy_exception: the conditions — compensating controls and the re-review trigger — in its description, the accepting authority by name and role in exception_approver, the time limit in exception_expiry_date (the filterable expiry index), and the monitoring owner in issue_owner; link it to the accepted Risk and the affected finding Issues, and set treatment: accept on the Risk. An acceptance without an expiry is a permanent unmonitored exposure.\n5. Assign follow-up ownership: who monitors the conditions and re-raises the item at the review date or on a trigger event.\n\n**Record in AssureSwarm**\n- The decision memo (DOCX/PDF) as a document on this step; the decision, deciding authority, conditions, review date, and follow-up owner recorded with it.\n- For an acceptance: the policy_exception Issue — exception_approver, exception_expiry_date, conditions in description, issue_owner as the follow-up monitor — linked to the accepted Risk and the affected finding Issues, with treatment: accept set on the Risk. The expiry index (policy_exception Issues filtered by exception_expiry_date) is the watchlist.\n\n**Exit criteria** — The decision memo is attached; a named authority decided escalate-or-accept with rationale; acceptance conditions and a review date are recorded where accepted; a follow-up owner is assigned; the watchlist entry exists.","label":"Escalate or accept risk","requiredApprovals":1},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Capture approval from engagement lead, CAE delegate, or audit committee delegate","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** — Capture the formal approval of the closure package by the engagement lead, CAE delegate, or audit committee delegate — the decision that the reporting work is complete and defensible, or that specific revisions are required first.\n\n**Human contribution** — Independent IA/SOX package approver (approval, expertise): Approve the supported conclusion and package or require specified revisions. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The issued report document on classify-disposition, linked to the anchor Audit, and its distribution record.\n- The socialization-cycle records at incorporate-management-responses with collected responses, the management-response register (Issue.management_response across the finding Issues), and the sync-back match-table document with any unmatched-finding resolutions.\n- Action plans on the finding Issues (if the gaps branch ran) and the escalation or risk-acceptance memo on the escalate step (if the monitor branch ran).\n- The assumption log and open constraints carried in with the fieldwork handoff package.\n\n**Procedure**\n*Agent preparation and filing absorb “Prepare final package”; the role named below owns the substantive review.*\n1. Build the package index in review order: issued report; executive summary; findings register with severities and issue links; management responses and risk-acceptances; socialization trail (each cycle's version, audience, and responses); sync-back match table; the action plans or escalation memo from whichever branch ran; open constraints.\n2. Run the tie-out checks reviewers actually perform: the executive summary's finding counts and severities tie to the findings register; every finding in the issued report appears in the match table; every risk-acceptance in the response register appears in the escalation memo when one exists.\n3. Confirm the IIA GIAS 15.1 elements are present in the issued report — objectives, scope, conclusions, findings, and recommendations or action plans. A package missing one bounces at approval.\n4. State the proposed conclusion explicitly: what the engagement found overall, what remains open, and what Finding Remediation & Action-Plan Monitoring inherits.\n5. List unresolved constraints honestly (for example, a finding issued with unvalidated-caveat language). Reviewers approve packages with named constraints; they reject packages that hide them.\n\n**Decision criteria**\nThe approver tests the package; they do not re-perform the engagement:\n\n- **Approved (`approved`)** — the package index is complete and every entry resolves to a live record; the tie-out checks hold (executive summary ties to the findings register, every report finding is matched-and-reconciled or carries a resolution action); the IIA GIAS 15.1 elements are present; every finding is answered or risk-accepted by a named authority; open constraints are stated, bounded, and owned. An approval with trivial conditions may record them with the decision; anything more belongs on the revise branch.\n- **Revision required (`revise`)** — any of: an index entry that does not resolve, a tie-out mismatch, an unmatched finding without a resolution action, a missing response or acceptance, a constraint discovered at review that the package did not state, or reviewer disagreement with the proposed conclusion. Enumerate every condition in the rationale as an addressable item — the resolve step works that list verbatim, so a vague \"tighten the package\" condition is itself a defect.\n\n**Record in AssureSwarm**\n- The package index as a document (PDF/XLSX) on this step, with links to every referenced record: the issued report document, the cycle records, the match table, the finding Issues carrying action plans, any policy_exception Issue, and the memos.\n- The proposed conclusion and the open-constraints list, recorded on this step.\nSubmit the decision form: `approval_path` (the branch), the step result carrying the reviewer's specific observations or enumerated conditions, and the step's approver record naming the approver and role. The workflow approval on this step is the formal sign-off record.\n\n**Exit criteria** — The package is indexed and internally consistent on the tie-out checks; the GIAS 15.1 elements are confirmed present; the proposed conclusion and open constraints are stated; every index entry resolves to a linked live record. The form is submitted by the accountable approver; revise conditions are enumerated if that branch is taken; the unused branch is prunable because the recorded value matches the selected edge.","kind":"decision","label":"Approve or revise package","requiredApprovals":1},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Work the approver's enumerated conditions to closure and document what changed, so re-approval reviews a diff rather than the whole package again.\n\n**Human contribution** — Original independent package approver (expertise, approval): Judge evidence resolving each requested revision before reapproval. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The condition list from the approval decision's rationale.\n- The final package and its linked records.\n- The issued report — already distributed, so its wording is canonical.\n\n**Procedure**\n1. Triage each condition into its fix path: an evidence gap (locate or produce the missing artifact), a record fix (correct a link, register entry, or reconciliation), a conclusion revision (redraft the proposed conclusion), or an action-plan change (owner, date, or scope).\n2. Respect the issuance boundary: the report has been issued, so conditions are resolved by fixing the package and the records — not by quietly editing the report. If a condition reveals a significant error or omission in the issued report itself, that triggers the IIA GIAS 11.4 obligation to communicate corrected information to everyone who received the original — treat it as its own action with the CAE informed, never a silent fix.\n3. Fix, then re-run the specific tie-out check the condition broke — not the full suite; the re-approval reviews the diff.\n4. Keep a change log: the condition, what changed, which record, who changed it. A condition marked resolved with no visible diff is the re-approval red flag.\n5. Where a condition cannot be met (the evidence genuinely does not exist), document why and propose the fallback — a caveat, an open-constraint entry, or an action plan — rather than returning silence.\n\n**Record in AssureSwarm**\n- The change log recorded on this step, each entry linked to the record it altered.\n- The corrected communication attached as a document on this step if the GIAS 11.4 obligation was triggered.\n- The package index document on the approve-or-revise-package step updated where entries changed.\n\n**Exit criteria** — Every enumerated condition is closed with a visible change or a documented cannot-meet fallback; the affected tie-outs re-run clean; the change log is complete; the original independent approver has reapproved the exact revised version or expressly approved the documented fallback before handoff.","label":"Resolve approval conditions","requiredApprovals":1},"id":"resolve-approval-conditions"},{"data":{"description":"Handoff outputs to Finding Remediation & Action-Plan Monitoring and close the reporting phase on the acknowledged handoff","instructions":"**Objective** — Hand the issued findings and their commitments to Finding Remediation & Action-Plan Monitoring as a complete package — so remediation tracking starts from the report's canonical wording and never re-litigates what was issued — and close Audit Report Drafting on a preserved, reconstructable audit trail; the human moment is securing the downstream owner's acknowledgment of the package.\n\n**Human contribution** — IA/SOX accountable lead and receiving owner (approval, expertise): Resolve residual caveats and accept the next phase’s commitments, required coverage and dates. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The submitted approval decision and its rationale, including any conditions carried from the revise loop.\n- The approved final package version.\n- The escalation or risk-acceptance decisions, if any, with their review dates.\n- The approved final package and the recorded approval decision: approver, role, date, pinned package version, and any conditions with their follow-up owners.\n- The package contents: the issued report document, the reconciled finding Issue items, the Issue.management_response entries, the action plans on Issue.remediation_plan, and any policy_exception Issues with their exception_expiry_date review dates.\n- The follow-up owners and cadences recorded at approval.\n- The assumption log and open constraints.\n- The organization's records-retention policy for audit reports and workpapers — a Policy item in the policy library with the governing document attached.\n\n**Procedure**\n*Agent preparation and filing absorb “Record approval decision”; the role named below owns the substantive review.*\n1. Capture the approver's name and role verbatim from the native approval record — approval authority matters later exactly when it was ambiguous at the time (engagement lead versus CAE delegate versus audit committee delegate).\n2. Pin the approved package version: the decision applies to a specific package state, so record the version or date of the index the approver saw. A record changed afterward is not covered by this approval.\n3. Record any conditions attached to the approval and assign each a follow-up owner and date — approval conditions without owners become next year's repeat finding.\n4. Cross-check the approval covers the branch that actually ran: if the monitor branch produced a risk-acceptance, the approval record acknowledges it; if the gaps branch produced action plans, the approval record references their existence (their execution belongs downstream).\n5. Complete the step's workflow approval so the sign-off is machine-readable, not narrative only.\n\n\n6. Create or link the downstream Finding Remediation & Action-Plan Monitoring workflow for this engagement.\n7. Pass the handoff package: the issued report document; every finding Issue with its severity, issue_owner, target_remediation_date, and report-canonical wording (already reconciled at issuance); the management responses (Issue.management_response) and any policy_exception acceptances with their conditions and exception_expiry_date; and the action plans (Issue.remediation_plan) with their validation-evidence definitions.\n8. State the assumptions the downstream workflow inherits: which findings were issued with caveats, which acceptances expire when, and which commitments depend on external events.\n9. Mark explicitly what downstream must not repeat: re-validating findings, re-rating severities, re-collecting management responses, or re-wording issues. Its job is tracking commitments to closure and validating remediation evidence — the IIA GIAS 15.2 follow-up obligation — not re-performing this workflow.\n10. Confirm receipt: the downstream workflow's owner acknowledges the package and its first monitoring dates. That acknowledgment — an outside owner accepting the commitments — is this step's human moment and the trigger for closing out.\n11. Archive the final package as the engagement's reporting record: issued report, findings register, socialization trail, management responses, sync-back match table, and the approval record. Verify each archive entry resolves before declaring it archived — a broken link discovered at retention-years distance is unrecoverable.\n12. Update linked records to their terminal state: the anchor Audit item shows the report issued and reporting closed — Audit.rating, Audit.opinion, and Audit.report_date final; the finding Issue items stay open — they live on under remediation monitoring — but their reporting-phase wording is final. Apply the retention rule from policy (commonly five to seven years for audit reports and workpapers, longer where regulation demands) and note the retention date on the archive.\n13. Confirm the monitoring that survives closure actually exists: risk-acceptance review dates and action-plan cadences are downstream's to run, but verify the date fields that drive them are set — exception_expiry_date on each policy_exception Issue, target_remediation_date on each finding Issue — closure is the moment scheduled follow-ups silently vanish.\n14. Communicate the close: notify the stakeholder list that the reporting phase is complete, where the issued report lives, and that remediation tracking continues under the downstream workflow. Note the obligation that survives archive: a significant error or omission discovered later in the issued report still requires corrected communication to all original recipients (IIA GIAS 11.4).\n\n15. Issue a separate final audit completion email announcement to business leaders and control owners, stating the completed reporting scope, exact final report location, continuing remediation responsibilities, next monitoring dates and contact. Record recipients, authorized actual dispatch, receipt and unresolved delivery issues separately from final-report distribution.\n16. Prepare and submit MAR Audit Survey Requests to business process owners and functional leads using the tenant-approved MAR instrument. MAR remains undefined in the reusable workflow: obtain its approved meaning, instrument/version, survey owner, sender, privacy terms, destination and response deadline from the engagement sponsor. Do not invent an expansion, questions or scoring.\n17. Use existing responses where relevant and request only missing feedback. Survey forms go only to recipients who execute none of this workflow’s checkpoints. Executing business/process owners and functional leads provide their feedback in native results or documents for the same approved instrument; include both channels in the response register. Dispatch the approved instrument through the authorized survey/Workstream channel, recording recipient roles, version, actual send and receipt dates, due date, reminders and response status. If MAR or its channel is not bound, record the request as blocked and give the sponsor an action; do not claim dispatch or survey completion.\n18. Pass the survey request/response register and received feedback to audit-qaip-cycle/run-internal-assessment for assessment and improvement planning. Keep reporting completion, survey dispatch and survey response completion as distinct statuses; outstanding responses retain named follow-up owners.\n\n**Record in AssureSwarm**\n- The approver, role, date, approved package version, and conditions with their follow-up owners, recorded on this step.\n- The workflow approval completed on this step — the machine-readable sign-off — and the decision linked to the anchor Audit item.\n- The downstream Finding Remediation & Action-Plan Monitoring workflow instance linked; the handoff package contents attached to or linked from this step — the issued report document, the finding Issue items, and any policy_exception Issues.\n- The do-not-repeat list and the inherited assumptions, recorded on this step.\n- The downstream owner's acknowledgment, commented on this step with its date.\n- The workflow instance marked complete — the archived run is the durable audit trail — with the archive index attached as a document on this step, its retention date noted.\n- Item field state confirmed terminal on the anchor Audit item (rating, opinion, report_date); surviving review dates verified via exception_expiry_date and target_remediation_date on the relevant Issues.\n- The closing communication and its recipients, commented on this step.\n\n**Exit criteria** — The approval is recorded with approver, role, date, and pinned package version; every condition has an owner and a date; the workflow approval is completed; the decision is linked to the engagement. The downstream workflow is linked and carries the full package; issue records, responses, acceptances, and action plans are transferred with owners and dates; the do-not-repeat boundary is stated; receipt is acknowledged; the archive is complete with every entry resolving and its retention date recorded; the anchor Audit item is terminal; surviving monitoring is confirmed scheduled downstream; the close is communicated to stakeholders.","label":"Handoff to related workflow","requiredApprovals":1},"id":"handoff-to-related-workflow"},{"data":{"instructions":"**Objective** — Authorize the exact final draft for issuance under IA’s independent opinion.\n\n**Human contribution** — CAE or authorized IA director independent of preparation (approval, expertise): Authorize issuance of the exact final draft after management factual confirmation. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs** — Final report draft with incorporated responses, factual confirmation from management-confirm-report-facts, evidence-linked findings, ratings, open disputes and the engagement’s reporting authority.\n\n**Procedure**\n1. Assign the authorized IA management approver: CAE or delegated IA director under the engagement’s authority matrix, independent of report preparation and the audited business. Review scope, methodology, finding support, ratings, overall opinion, management responses and the disclosure/distribution plan.\n2. Resolve IA review notes before approval. Preserve management’s factual confirmation and any disputed facts with the evidence and IA disposition; management cannot veto the independent audit opinion. A missing response remains outstanding and must be resolved before issuance.\n3. Pin the final DOCX/PDF document ID and version or content hash. Approve this exact report through the step’s native approval before classify-disposition can begin. Any later substantive edit invalidates this approval and requires a new management factual confirmation and IA approval for the changed version.\n\n**Record in AssureSwarm** — Put the analysis, exact document version, evidence references, recipients, actual dates, open questions and owners in this step's result. Attach the package and received evidence as step documents. Capture sign-off through native approval.\n\n**Exit criteria** — Authorized IA management has given native approval for the exact final draft, with closed review notes and management factual confirmation for that same version.","kind":"task","label":"Approve final report draft (IA management)","requiredApprovals":1},"id":"ia-approve-report-draft"},{"data":{"instructions":"**Objective** — Obtain accountable management’s factual confirmation of the exact final draft before issuance.\n\n**Human contribution** — Accountable business/process management (approval, expertise): Confirm the exact final draft’s facts and management commitments without controlling IA’s opinion. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs** — The complete final draft from incorporate-management-responses with rated findings, management responses and action commitments.\n\n**Procedure**\n1. Send the exact final draft version to the accountable business/process executive and relevant control owners for factual confirmation through the authorized channel. Identify the document version, relevant sections, response deadline and the limited request: accuracy of facts and management commitments.\n2. Obtain accountable management’s native approval documenting factual confirmation of the exact final version. Record disagreements and the evidence supporting IA’s disposition; a confirmation may acknowledge identified disputed facts but cannot silently certify them as agreed. Management confirmation does not approve or change IA’s independent opinion.\n3. Resolve factual corrections in the draft, retain the prior version and response trail, and obtain confirmation of the corrected version. Missing confirmation blocks issuance. Hand the confirmed version and any disclosed factual disagreements to IA management for its separate final approval.\n\n**Record in AssureSwarm** — Put the analysis, exact document version, evidence references, recipients, actual dates, open questions and owners in this step's result. Attach the package and received evidence as step documents. Capture sign-off through native approval.\n\n**Exit criteria** — Accountable management has recorded native factual confirmation for the exact final draft, with disputed facts and their disposition explicit; missing or obsolete confirmation cannot pass.","kind":"task","label":"Confirm final report facts (management)","requiredApprovals":1},"id":"management-confirm-report-facts"}],"sourceTemplateId":"workflow-library:audit-report-drafting"}