{"description":"Finding Remediation & Action-Plan Monitoring runs on the EXISTING parent Audit item — the issued engagement whose report findings are being followed up — enriching that Audit and its linked findings rather than creating a new engagement; the workflow instance attaches to that Audit item, and each report finding is an Issue item linked to it. It tracks issued-report findings and their agreed management actions from registration through evidence validation, closure, extension, risk acceptance, escalation, and committee reporting, and produces a verified disposition register and a signed final evidence-and-decision package. In scope: all open findings from the engagement plus any prior-cycle findings still open against the same auditee. Out of scope: re-performing engagement fieldwork and re-wording report findings (both belong to the upstream Audit Report Drafting workflow) and assembling the board pack (the downstream Quarterly Board & Audit-Committee GRC Reporting workflow consumes this cycle's outputs). It consumes the issued final report and findings register handed off from Audit Report Drafting and hands its verified outputs to Quarterly Board & Audit-Committee GRC Reporting.","edges":[{"id":"e-validate-remediation-close-or-escalate","source":"validate-remediation","target":"close-or-escalate"},{"id":"e-close-or-escalate-route-risk-acceptance","source":"close-or-escalate","target":"route-risk-acceptance"},{"id":"e-route-risk-acceptance-classify-disposition","source":"route-risk-acceptance","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-17","UC-RISK-14","UC-AUDIT-18"],"department":"internal-audit","domains":["audit"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=audit-finding-remediation-monitoring","contentDigest":"sha256:3f25c4f56f6bd3454122d83cee380036bbb55544d974354073ba34475463976d","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:3f25c4f56f6bd3454122d83cee380036bbb55544d974354073ba34475463976d","schemaVersion":1,"sourceTemplateId":"workflow-library:audit-finding-remediation-monitoring"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"audit-finding-remediation-monitoring","source":"coworkcanvas-gallery","standards":["iia-2024"],"teams":["internal-audit"]},"name":"Finding Remediation & Action-Plan Monitoring","nodes":[{"data":{"description":"Assess the actual remediation evidence, apply policy-based pre-close QA and resolve owner-level or SLA exceptions without overwriting reviewer work.","instructions":"**Objective** — Assess the actual remediation evidence, apply policy-based pre-close QA and resolve owner-level or SLA exceptions without overwriting reviewer work.\n\n**Inputs**\nThe issued final report and its findings register — the DOCX/PDF handoff package this workflow consumes from Audit Report Drafting (the upstream workflow): finding IDs, ratings, agreed management actions, owners, target dates. The report's issuance date also lives on the anchor Audit item as `Audit.report_date` (with `Audit.fieldwork_end` alongside).\n- The issue-management policy — a Policy item (`policy_type: standard` or `procedure`, `framework: iia-2024`): severity scale, SLA maximum days by rating, owner-level expectations.\n- The HR or people directory (external HRIS), to confirm each named owner resolves to an active tenant user for `Issue.issue_owner`.\n- Issue history — the existing open Issue items already in the tenant, for predecessor links on repeats.\n\nThe registered action records: owner, agreed action verbatim, target date, rating, validation depth.\n- Escalation contacts (each owner's manager, the engagement lead) and the status-cadence policy.\n\nThe source finding or issue record and its already-captured fields — issue description, severity or rating, root cause, target remediation date, owner, recommendation — together with its linked risks, linked controls, and parent audit engagement.\n- The remediation evidence the owners provided.\n- The organization's configured IM policy: owner-level thresholds by severity and maximum SLA days by rating. Read these from the configured policy, never hardcode them — a customer policy may override the defaults below.\n- The organization's HR people directory, needed to look up each owner's role level.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Independent remediation validator owns the stated judgments and authorizations.*\n\n*Register agreed action.* Convert each accepted finding into tracked finding and agreed-action records carrying the fields monitoring runs on, so nothing about the commitment lives only inside the report document.\n\n1. Create one Issue item per report finding (`issue_type: finding`, `source: internal_audit`), capturing the agreed action verbatim in `Issue.remediation_plan`. Where a finding carries several distinct actions with different owners or dates, either enumerate them inside `remediation_plan` or split them into separate linked Issues — the schema has no dedicated agreed-action sub-record, so pick the split when per-action owner and date tracking matters, and state which convention you used. A finding closes only when all of its actions close, and partial progress must stay visible.\n2. Populate the monitoring-critical Issue fields: finding ID cross-referenced to the report; `description` (condition); `root_cause` as stated in the report (if the report gave a symptom rather than a cause, note that now — root cause defines what \"closed\" will mean); `severity` (rating); `identified_date` set to the report issue date, not today (SLA clocks run from identification); `issue_owner`; `target_remediation_date`; `recommendation`; and the agreed action text verbatim in `remediation_plan` — paraphrase drift is how closure disputes start.\n3. Set validation depth per policy at registration: High and Medium-High findings require independent re-testing at closure, Medium requires evidence review, Low may close on owner attestation where policy allows. Recording this now tells the owner what evidence standard they are working toward.\n4. Compute the SLA position at registration: days from identified date to target date against the policy maximum for the rating (defaults where no policy overrides: High 90, Medium-High 270, Medium 540, Low 720 days). Raise breach flags now, not at the first status report.\n5. Link each finding to its risks, its controls, and the parent engagement — committee reporting aggregates along these links, and an unlinked finding vanishes from every roll-up.\n6. Run the registration sanity checks: no duplicate registration against issue history (link repeats to predecessors instead of re-creating them); every owner resolves in the directory; no action text is empty or \"TBD\"; registered count equals the issued findings-register row count.\n\n*Notify owners.* Put every action owner on formal, evidenced notice of what they own, the closure evidence standard, and the dates — and capture explicit acknowledgment, so \"nobody told me\" is impossible at escalation time.\n\n7. Build per-owner packages, not per-finding blasts: one owner may hold several actions and should see all of them together — for each, the agreed action verbatim, the target date, the rating, and the validation depth it implies at closure.\n8. State the closure evidence expectation concretely per action, now rather than at the deadline: a design fix expects the revised procedure or configuration plus its approval; an operating-effectiveness fix expects evidence the control has operated over a sustained period — typically at least one full cycle, so a monthly control needs two to three operated instances before validation can test it. Owners who learn this on day one capture evidence as they remediate instead of reconstructing it archaeologically later.\n9. Require explicit acknowledgment with a deadline (five business days is a common convention): the owner confirms acceptance of the action, the date, and the evidence expectation. Non-acknowledgment escalates to the owner's manager, then the engagement lead — an unacknowledged action is an unowned action, and it is treated as an exception rather than left pending.\n10. Set the status cadence: when owners must report progress (monthly, or at half of elapsed SLA for long-dated actions) and in what form — a status value plus evidence-so-far, not free-text reassurance.\n11. Log every send, reminder, acknowledgment, and escalation. The chase trail is itself follow-up evidence under IIA Standard 15.2 — the monitoring process must be demonstrable, not asserted.\n\n*Validate remediation.* Validate that each agreed remediation actually closed its finding, and run the issue-management (IM) policy pre-close QA gate over every issue and agreed-action record, before any record is marked remediated and advanced to closure. Two complementary checks live in this step and both must clear: remediation genuinely happened, and the record is policy-conformant. A record that fails either check must not be marked final until it is corrected.\n\n12. Pre-populate the validation step from existing data so the validator never re-types what was already captured: pull the finding's fields from the record rather than re-entering them, then create or refresh a per-finding entry in this checkpoint’s validation workpaper with the source finding ID, description, root cause and named validator. Link its risks and controls and let the validator specify the evidence that proves closure. Review the entries within this existing checkpoint; do not add a node or an executor-input form per finding.\n13. Never clobber the validator's work: before writing, check whether a validation workpaper entry for this finding already exists. If the validator has already started editing it, stop and report \"validation already in progress; not overwriting\". Only refresh an untouched workpaper entry; create a new entry only when none exists.\n14. Confirm remediation is effective: the evidence is sufficient, relevant, independently reviewable, tied to the approved criteria, and demonstrates the gap is closed — or bounce it back to the owner naming exactly what is still missing.\n15. Run the IM policy pre-close QA gate over each in-scope issue and action-plan record. Default thresholds, used only when the configured policy does not override them: owner level — High and Medium-High severity require the owner to be Senior Director or above, while Medium and Low require Senior Manager (level 27) or above; SLA maximum days from the record's identified date to its target remediation date — High within 90 days, Medium-High within 270, Medium within 540, Low within 720. For each record run three checks: (a) required-fields completeness — description, severity or rating, owner, target date, and recommendation are all populated; (b) owner level — look up the assigned owner in HR data and compare their role level to the policy threshold for the record's severity; if HR data is unavailable, mark this check verify-manually rather than passing or failing it, and never invent an owner's level; (c) SLA compliance — compute the days between identified date and target date and compare to the policy maximum for the rating. Build a per-record verdict of pass or fail with a list of failures, each naming the check, the value found, the value expected, and whether it is auto-fixable.\n16. Disposition the failures: an SLA target date that is off by 7 days or fewer is treated as a rounding or truncation error and is auto-fixable — propose the corrected date as a suggested change for the record owner to approve. Every other failure — a wrong owner level, a missing required field, an SLA breach greater than 7 days — is not auto-fixable and is surfaced to the record owner for manual correction.\n17. Reviewer checkpoint: the reviewer confirms remediation is effective, confirms the QA report, approves or rejects each auto-fix suggestion, and confirms that all failing records are corrected or carry an owned, dated correction plan before this step advances to Close or escalate.\n\n**Record in AssureSwarm**\n**Item create** — one Issue per finding: `issue_type: finding`, `source: internal_audit`, `severity`, `description`, `root_cause`, `recommendation`, `remediation_plan` (agreed action verbatim), `issue_owner`, `identified_date` (= report issue date), `target_remediation_date`. Multi-action findings follow the split-or-enumerate convention above — there is no native agreed-action sub-record.\n- **Item relationship** — each Issue ↔ its Risks, ↔ its Controls, ↔ the parent Audit item (the anchor), and Issue ↔ Issue predecessor links for repeats.\n- **Step comment** — a registration summary: count registered, SLA-at-registration flags raised, any directory misses. Issue has no native SLA-flag or cumulative-age field, so the flag rides in the comment.\n\n**Step document** — the per-owner notification packages attached to this step.\n- **Step comment** — the full chase trail (sends, reminders, acknowledgments with dates, escalations) logged with timestamps. This trail is the IIA Standard 15.2 demonstrability evidence; Issue has no native acknowledgment or cadence field, so acknowledgment status and the status cadence live on the step, not the item.\n\n**Validation workpaper and assignment** — retain each source finding ID, existing `severity` and `root_cause`, and named validator in this checkpoint’s workpaper and native assignment. Reuse source values without a collection form.\n- **Step document** — the QA report (XLSX/CSV): per-record pass or fail with the failure list, attached to this step as the workpaper.\n- **Item field update** — approved auto-fix date corrections write the corrected `Issue.target_remediation_date`; the proposals ride as suggested changes for owner approval before they are applied.\n- **Item relationship** — criteria linkage and the linked Risks and Controls carried into the validation workpaper; the evidence the validator ultimately relied on and workpaper references recorded.\n- **Step comment** — the owner accountable for each open correction, and the reviewer conclusion.\n\n**Exit criteria**\nEvery accepted finding and action exists as a linked, fully populated record; SLA-at-registration flags are raised; repeat links are in place; registered count equals the issued findings-register row count.\n\nEvery action has a delivered notification and a recorded acknowledgment, or a live escalation for non-response; closure evidence expectations are stated per action; the status cadence is set on every record.\n\nThe validation workpaper names the validator and references the finding’s existing data, with pre-populated fields matching the source exactly (no re-keyed drift) and no validator edits overwritten; remediation is confirmed effective or returned to the owner; every in-scope record has a recorded verdict and is either a clean pass or carries an owned correction — no record advances with an open fail; owner-level checks that fell back to verify-manually were genuinely verified by a person, never silently passed; the thresholds used trace to the configured policy; and the QA report, evidence references, accountable owners, residual constraints, and gate outcome are documented so the closure decision in the next step is made only on policy-conformant records.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the per-owner packages, the reminder sequence, and the non-response escalations with a logged chase trail.","label":"Validate remediation","performedBy":{"agent":"audit-artist","note":"Pre-populate and assign the validation step from finding data, confirm remediation is effective, then run the IM policy pre-close QA gate before closure.","primitives":["coach-notify","coach-query-data","coach-workflow-build","coach-workflow-assign","coach-form-fill","coach-items-link","coach-document-upload"]}},"id":"validate-remediation"},{"data":{"description":"Complete Close or escalate","instructions":"**Objective** — Disposition every record that came out of validation: close what validation confirmed, return what fell short with the gap named, and start extension, risk-acceptance, or escalation handling for the rest — so no record sits ambiguously between \"validated\" and \"reported\".\n\n**Inputs**\n- Validation outcomes and the QA-gate report from the previous step.\n- Each record's target date, cumulative age, extension history, and rating.\n- The issue-management policy: extension limits and approval levels, overdue-escalation thresholds.\n- Issue history, for repeat status on slipping records.\n\n**Procedure**\n1. Close confirmed records: set status closed-validated with the closure date, the evidence relied on, and the validator's identity. Above Low rating, closure without linked validation evidence is prohibited; Low may close on owner attestation only where policy says so, and the record states that basis explicitly.\n2. Return insufficient-evidence records to their owners with the specific gap named and a resubmission date. The target date does not move — insufficient evidence is a quality problem, not grounds for an extension.\n3. Apply extension governance to records past target or requesting more time: a first extension is approvable by the engagement lead with a revised, SLA-checked date and a stated reason; a second escalates to the CAE delegate; beyond the policy limit (commonly two), a further request is treated as de facto non-remediation and routes to risk acceptance or escalation, not to another date change. Root-cause every slip — resourcing, dependency, or evidence the action was never feasible; the last one means the plan gets rebuilt, not extended.\n4. Identify genuine risk-acceptance candidates: the owner states an intent not to remediate, or remediation cost demonstrably exceeds the exposure. Route these to the risk-acceptance step — auditors never accept risk on management's behalf.\n5. Flag for escalation: High-rated records overdue beyond the policy threshold (30 days is a common default), repeat findings slipping again, unacknowledged actions, and any record where management disputes the finding itself. Assemble the fact base as you flag — dates, chase trail, extension history — so the escalation step does not re-investigate.\n6. Recompute aging for everything still open: days open and days past target, feeding the status report.\n\n**Record in AssureSwarm**\n- **Item field update** — for closed records set the Issue status plus `actual_remediation_date` and `verified_date`; the other dispositions (returned, extension-pending, risk-acceptance-routed, escalation-flagged) ride on the Issue status with a dated rationale comment — the schema has no native disposition, extension-count, or cumulative-age field.\n- **Step comment** — extension approvals with approver and level; return comments naming the exact evidence gap; recomputed aging (days open, days past target) captured here since there is no stored aging field.\n\n**Exit criteria** — Every validated record carries exactly one disposition with a dated rationale; no closure lacks linked evidence; extension approvals sit at the policy-required level; risk-acceptance and escalation candidates are queued with their fact bases assembled.","label":"Close or escalate"},"id":"close-or-escalate"},{"data":{"description":"Complete Route risk acceptance","instructions":"**Objective** — Take each finding management declines to remediate through a formal, time-bound risk-acceptance decision at the authority level the rating requires, and apply the IIA Standard 15.2 test: accepted risk that may exceed the organization's appetite goes to senior management and, if unresolved, to the board.\n\n**Inputs**\n- The risk-acceptance candidates from the disposition step, with their ratings and linked Risk items.\n- The organization's risk-appetite statement and acceptance-authority matrix — Policy items (`policy_type: charter` or `policy`) recording who may accept what by rating or exposure.\n- Compensating-control detail from the owner: what mitigates the exposure while it stands.\n\n**Procedure**\n1. Verify the request is genuine acceptance, not disguised slippage: management states in writing that it will not remediate (or not fully), with a business rationale — remediation cost versus exposure, planned system retirement, or an alternative mitigation. \"We have not gotten to it yet\" is delinquency and goes back to the disposition step.\n2. Quantify what is being accepted: the finding's impact restated in business terms (financial range, regulatory consequence, operational effect), the likelihood given compensating controls, and the residual exposure. Audit validates that the quantification has an evidentiary basis; audit does not make the acceptance decision.\n3. Check the signatory against the authority matrix: acceptance authority scales with rating — typically the process owner's management for Low, the function head for Medium, an executive owner for High and Medium-High, with audit-committee visibility for the top band. A memo signed below the required level is not an effective acceptance; send it up.\n4. Make it time-bound and conditional: an expiry or re-affirmation date (12 months is a common maximum), the compensating controls that must remain operating, and the trigger events that void it early — an incident, a failure of the compensating control, a relevant system change. A perpetual acceptance is a finding hidden in a drawer.\n5. Apply the Standard 15.2 escalation test and record its outcome: if the accepted risk level may exceed the organization's appetite, the CAE or delegate discusses it with senior management, and if unresolved, communicates it to the board. Document that the test was applied even when the answer is \"within appetite\".\n6. Re-status the record: risk-accepted with its expiry date and a scheduled re-affirmation review. The finding does not vanish from reporting — it moves to the accepted-risk section of the committee view.\n\n**Record in AssureSwarm**\n- **Step document** — the signed acceptance memo (PDF) attached: rationale, quantification, conditions, compensating controls, expiry, signatory and level.\n- **Item field update** — on the accepted finding Issue set `exception_approver` (the signatory) and `exception_expiry_date` (the filterable expiry index and re-affirmation deadline); on the linked Risk set `treatment: accept` and refresh `residual_rating`. The Issue↔Risk and Issue↔Control relationships are preserved.\n- **Step comment** — the Standard 15.2 appetite-escalation test outcome (recorded even when \"within appetite\") and the scheduled re-affirmation follow-up with a named owner.\n\n**Exit criteria** — Every accepted record carries a signed, time-bound memo at the correct authority level; expiry and re-affirmation are scheduled with owners; the appetite-escalation test is documented; the committee-reporting flag is set.","label":"Route risk acceptance"},"id":"route-risk-acceptance"},{"data":{"decisionField":"disposition_path","description":"Review the reconciled finding dispositions and current reporting metrics and select clean, plan rebuilding or senior escalation.","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** — Review the reconciled finding dispositions and current reporting metrics and select clean, plan rebuilding or senior escalation.\n\n**Inputs**\nThe population of audits in scope: a single audit, a portfolio, or every audit whose report was issued on or after a chosen cutoff date.\n- For each audit: its fieldwork-end date, its report-issued date, and any KPI status field already stored on the audit record.\n- The target: 30 days is the industry-standard default, overridden only by a documented firm policy.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement lead owns the stated judgments and authorizations.*\n\n*Report follow-up status.* Compute and publish the report-issuance cycle-time KPI across the audits under follow-up — the interval from each audit's fieldwork-end date to its report-issuance date, measured against a 30-day target — so timeliness breaches are visible on a live status dashboard. This is the single most-watched audit-operations KPI.\n\n1. Pull the in-scope audits together with their fieldwork-end and report-issued dates.\n2. For each audit, compute the interval as a whole number of days (report-issued minus fieldwork-end) and classify it: met when the interval is at or below the 30-day target, breached when it exceeds it.\n3. Never fabricate, infer, or zero-fill a missing date, and never treat an absent date as an interval of zero. When either date is missing, record the audit's status as not-measurable-yet, name which date is absent, and exclude that audit from the met and breached counts rather than computing a false interval.\n4. Persist only what the schema can hold: the source dates already live on `Audit.fieldwork_end` and `Audit.report_date`, so the interval and classification are computed live on the dashboard from those two fields rather than written back — the Audit item has no stored KPI field (no interval or cycle-time-status field exists in the schema). Do not invent one; the computed values live on the dashboard and, for exceptions, in the step document below.\n5. Assemble the portfolio status view: every audit with its two dates, its interval, and its status, with each breach highlighted.\n6. Refresh on a recurring cadence (for example weekly): the underlying dates change as new reports issue, and the dashboard must stay current across the whole portfolio.\n7. Human checkpoint before the refreshed KPI is published: the audit lead confirms the fieldwork-end and report-issued date sources are correct and reviews every breached and every not-measurable audit — a breach or a missing date is an operational signal that needs a named owner.\n\n*Classify disposition.* Classify where this monitoring cycle stands so exactly one closure path continues: straight to final packaging when nothing remains open, action-plan rebuilding when remediation gaps persist, or escalation when a significant issue must move up the chain. The engagement lead owns the call, made on the validation outcomes, the disposition register, and the current status report.\n\n\n\nBefore branching, confirm the decision basis is complete: every in-scope record carries a post-validation disposition, the QA gate shows no unresolved open fail, and the status report reflects the latest data.\n\n- **No reportable gap (`clean`)** — every in-scope finding is either closed-validated with linked evidence or risk-accepted under a signed, in-force, time-bound memo; no action is overdue; no return or extension is pending; no QA-gate failure is open. Clean means nothing remains to chase — a single pending return or unsigned acceptance disqualifies this branch.\n- **Remediation required (`remediate`)** — at least one finding failed validation, was returned for insufficient evidence, or needs its plan rebuilt because the original action proved infeasible or the root cause was mis-identified. Pick this branch when the fix is a better action plan under existing governance: the authority already in place suffices, and it is the plan that is defective.\n- **Escalate significant issue (`escalate`)** — any of: a High-rated finding overdue beyond the policy threshold with no credible path; a repeat finding slipping again; management disputing the finding or declining remediation where the exposure may exceed appetite (engaging the IIA Standard 15.2 chain to senior management and the board); or extension requests beyond the policy limit. When both remediate and escalate conditions exist, escalate wins — the escalation forum decides whether a rebuilt plan or a senior-level acceptance follows, and pre-empting that decision undercuts the authority structure.\n\n**Record in AssureSwarm**\n**Dashboard** — the live report-issuance cycle-time dashboard, computing each audit's interval and met/breached/not-measurable classification directly from `Audit.fieldwork_end` and `Audit.report_date` (no stored KPI field exists — the dashboard computes live).\n- **Step document** — the breach list with owners and the not-measurable list naming the specific missing date for each audit, plus the target used and any documented override, attached to this step.\n- **Item field update** — none of the computed KPI values persist per-audit; only the two source dates (`Audit.fieldwork_end`, `Audit.report_date`) live on the Audit item, and this step reads them rather than writing anything back.\n\nSubmit the decision form: `disposition_path` (the branch); the step result with the counts that justify it — closed, returned, risk-accepted, overdue by rating — plus references to the validation QA report and the status dashboard; the step's approver record.\n\n**Exit criteria**\nEvery in-scope audit carries a current interval and classification or an explicit not-measurable flag; no interval was computed from a missing or inferred date; every breach and every not-measurable case is attributable to a named audit with an owner; the intervals derive only from `Audit.fieldwork_end` and `Audit.report_date` with no invented stored field; the live report-issuance cycle-time dashboard reflects the latest data.\n\nForm submitted; the rationale counts reconcile to the disposition register; unused branches are prunable because the branch edge values match the selected form value.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` pulls the in-scope audits and their dates for the interval computation; `/coach-dashboard-create` builds and refreshes the live cycle-time dashboard.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"audit-artist","note":"report-issuance cycle-time KPI engine","primitives":["coach-query-data","coach-dashboard-create"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Rebuild the action plan for every finding on the remediation path so each re-enters monitoring with a credible, owned, evidence-testable route to closure instead of a rolled-forward promise.\n\n**Inputs**\n- The remediation-path findings with their failure specifics: what evidence fell short at validation, what the QA gate flagged, why the original plan stalled.\n- The original action and its history: extensions taken, returns, cumulative age since the identified date.\n- The root cause recorded on the finding; the owner and their actual resourcing position.\n- The issue-management policy: SLA maximums by rating and extension-approval levels.\n\n**Procedure**\n1. Re-verify root cause before writing anything: a failed remediation frequently means the original action treated a symptom. Work it down with a structured method (five-whys, or a fishbone across process, system, and people causes) until the cause is something an action can eliminate. If the root cause changes, update the finding record and say so plainly — the original plan was mis-targeted, and pretending otherwise invites the same failure.\n2. Write the corrective action to a verifiable end-state: specific, measurable, assigned to a named individual, realistic against their resources, time-bound. Apply the one-question test — \"what evidence will prove this is done?\" If the closure evidence cannot be named now, the action is not yet plannable.\n3. Name the interim mitigation for exposure that stays open during the rebuild — mandatory for High and Medium-High findings: the compensating control or manual measure operating meanwhile, and the person running it.\n4. Set the new target date honestly: check it against the SLA maximum for the rating measured from the original identified date — re-planning does not reset the SLA clock, and cumulative age keeps accruing. A new date beyond policy needs extension-governance approval at the required level now, at planning time, not when it breaches.\n5. Add dated interim milestones to any plan longer than 90 days, so the next cycle detects slippage mid-flight rather than at the end date.\n6. Obtain the owner's explicit re-acknowledgment of the rebuilt plan — the same discipline as first registration: action, date, and evidence expectation confirmed in writing.\n\n**Record in AssureSwarm**\n- **Item field update** — on the Issue: `remediation_plan` (new action text + interim mitigation + milestone dates), `target_remediation_date` (the honest new date), and `root_cause` where it was revised. There is no native milestone or cumulative-age field — milestones live inside `remediation_plan` and cumulative age stays computed, not stored.\n- **Step comment** — a note that the plan was rebuilt and why (mis-targeted root cause, infeasible action); the extension approval and level where the new date exceeded policy; the owner's re-acknowledgment; the reporting cadence.\n\n**Exit criteria** — Every remediation-path finding has a rebuilt, re-acknowledged, evidence-testable plan; interim mitigation is named for open High and Medium-High exposure; SLA and extension governance are satisfied at the correct level; cumulative aging is preserved, not reset.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to engagement lead, CAE delegate, or audit committee delegate or document risk acceptance","instructions":"**Objective** — Put each escalated issue in front of the right authority — engagement lead, CAE delegate, or audit-committee delegate — with a decision memo that forces one of two documented outcomes: a directed remediation commitment with resources and dates, or a formal senior-level risk acceptance.\n\n**Inputs**\n- The escalated findings with their assembled fact bases: validation failures, extension history, chase trail, dispute correspondence.\n- The quantified exposure per finding and the organization's risk-appetite statement.\n- The escalation-authority matrix: which forum decides at which rating and exposure level.\n- Prior escalation attempts and their outcomes, if any.\n\n**Procedure**\n1. Choose the escalation level by rating and history, not convenience: engagement lead for overdue Medium findings and plan defects; CAE delegate for High findings overdue beyond threshold, repeats slipping again, and contested findings; audit-committee delegate where management declines remediation at an exposure that may exceed appetite or is non-responsive at executive level — that top band is the IIA Standard 15.2 chain (the CAE discusses with senior management; unresolved, it goes to the board).\n2. Write the decision memo tight and factual: the finding and rating; what was agreed and when; what happened instead, carried by dates, the extension record, and the chase trail — facts, not frustration; the quantified impact with its basis; the options (directed remediation with a resource commitment, acceptance with conditions, a re-scoped action) and audit's recommendation with reasoning.\n3. Present for decision and capture the outcome verbatim, with conditions. For directed remediation: the commitment, the resources attached, the new date, and the consequence language for a further miss. For acceptance: the same discipline as any risk acceptance — time-bound, conditional on named compensating controls, expiry set, signed at the level the authority matrix requires.\n4. Define follow-up ownership explicitly: who monitors the escalated commitment, at what cadence, and the automatic re-escalation trigger — one further missed milestone commonly goes straight to the committee without a new memo cycle.\n5. Close the loop with the finding owner and the auditee sponsor in writing: the decision, its conditions, and their obligations. An escalation outcome that never reaches the process owner changes nothing.\n\n**Record in AssureSwarm**\n- **Step document** — the decision memo (PDF/DOCX) attached: forum, date, signatory, outcome, conditions.\n- **Item field update** — on the finding Issue: status updated to the directed-remediation or accepted outcome; for a risk-accepted outcome set `exception_approver` and `exception_expiry_date`, and set `treatment: accept` on the linked Risk.\n- **Step comment** — the follow-up owner, cadence, and re-escalation trigger; links to the chase-trail evidence preserved.\n\n**Exit criteria** — The decision is captured in writing at the correct authority level with conditions and dates; follow-up ownership and the re-escalation trigger are set; the finding status reflects the outcome; the owner and sponsor have written notice.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Sign the evidence-bounded remediation conclusion and accept the data cut, required disclosures and carry-forward responsibilities for committee reporting.","instructions":"**Objective** — Sign the evidence-bounded remediation conclusion and accept the data cut, required disclosures and carry-forward responsibilities for committee reporting.\n\n**Inputs**\nThe disposition register and validation QA report; closure evidence links.\n- Risk-acceptance memos and escalation decision records.\n- The status dashboard export (cycle-time KPI, aging) and the intake assumptions log.\n- The carry-forward candidates: everything still open at cycle end.\n\nThe signed final package from the preceding procedure in this checkpoint, with its reconciliation table and metrics roll-up.\n- The committee reporting calendar and the downstream workflow instance for the relevant quarter (or the trigger to create it).\n- Every step record and submitted decision form in this workflow.\n- The records retention policy for audit workpapers.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement lead and quarterly board/GRC reporting owner owns the stated judgments and authorizations.*\n\n*Prepare final package.* Compile the cycle's defensible record — what was monitored, what closed on what evidence, what was accepted or escalated, what carries forward — into a single package that committee reporting and the archive can rely on without reopening workpapers.\n\n1. Build the population reconciliation first and make it arithmetic: findings at intake = closed-validated + risk-accepted + escalated + carried-forward. If it does not reconcile, fix the register, never the summary — a package whose numbers were massaged at the top is unusable as evidence.\n2. Write the per-finding lines: for each closed finding, one line stating what was validated, the evidence type, the validator, and the date; for each acceptance, the memo reference, expiry, and conditions; for each escalation, the decision and who owns the next move; for each carry-forward, cumulative age, the revised date, and why it remains open.\n3. Roll up the metrics the committee pack will quote: on-time closure rate, overdue count by rating, repeat-finding rate, extensions granted, acceptances in force with the nearest expiry, and the report-issuance cycle-time summary from the status step.\n4. Write the exceptions narrative — everything a skeptical reader would challenge, stated plainly: any validation waived, owner-level checks that fell to verify-manually, disputed findings, intake assumptions that did not hold. Volunteering these here is credibility; having them discovered later is a finding about audit itself.\n5. Run the traceability pass: every claim and number in the package resolves to a linked record or attached document; no orphan figures; each intake assumption is either discharged or restated as a carry-forward assumption.\n6. Draft the proposed conclusion — a short, evidence-bounded statement of the remediation posture — and route it to the engagement lead for sign-off.\n\n*Handoff to related workflow.* Hand this cycle's verified outputs to Quarterly Board & Audit-Committee GRC Reporting and close the monitoring cycle in the same motion — locked audit trail, every surviving obligation scheduled — so the committee pack aggregates what monitoring already proved and nothing open silently dies with the cycle; the human moment is securing the downstream owner's acknowledgment that the package is sufficient to build from.\n\n_Items 13–18 close the workflow (folded from the former \"Close and archive\" step); the acknowledged handoff recorded here is the closure — there is no separate confirmation._\n7. Locate or create the downstream Quarterly Board & Audit-Committee GRC Reporting workflow for the target quarter and link the two workflows.\n8. Deliver the package with a manifest naming its contents: the reconciled disposition register; the cycle metrics (on-time closure rate, overdue by rating, repeat rate, extensions, acceptances in force with expiries, cycle-time KPI summary); the escalation decisions requiring committee visibility; and the exceptions narrative.\n9. State what downstream must not redo: dispositions were validated in this workflow — the committee pack formats and aggregates, it does not re-open closures. Anything needing re-examination comes back through a new monitoring cycle, not through edits in the reporting pack.\n10. State what downstream must decide: which escalations and accepted risks are named individually in the committee pack — every High-rated acceptance and every unresolved Standard 15.2 escalation is a non-optional disclosure — and the presentation materiality for the rest.\n11. Stamp the data cut: the as-of date of the register and KPI data, what may change before the committee date (late closures, expiring acceptances), and who refreshes it if the gap between handoff and meeting is long.\n12. Obtain the downstream owner's acknowledgment that the package is sufficient to build from — an unacknowledged handoff is not a handoff.\n13. Run the completeness sweep before locking anything: the disposition-classification decision form submitted with its rationale; every closure linked to its validation evidence; every acceptance memo signed and time-bound; every escalation decision recorded; no record left in returned or extension-pending status — each either resolved during the cycle or appearing explicitly on the carry-forward register.\n14. Build the carry-forward register: each still-open finding with its cumulative age and revised date; each acceptance with its expiry and re-affirmation date; each escalated commitment with its follow-up cadence and re-escalation trigger. Schedule the next monitoring cycle or a discrete follow-up against every entry — an acceptance whose expiry passes unwatched becomes permanent by default, which is exactly what time-bounding was meant to prevent.\n15. Archive the final package and the workflow record under the retention policy — audit workpapers commonly carry five-to-seven-year retention, longer where a regulator requires it — and verify the archived copy matches the version handed off at item 8, not a later edit.\n16. Update the linked records to their final states: finding items carry their end-of-cycle status; the engagement item shows follow-up complete; risk and control links remain intact for future aggregation and repeat detection.\n17. Send the closure communication: the engagement lead and CAE delegate receive the closure note with the carry-forward register; each carried owner gets their next date restated.\n18. Lock the workflow against further edits. Post-archive corrections happen by documented addendum with its own approval — never by silent modification of the record.\n\n**Record in AssureSwarm**\n**Step document** — the rendered final evidence-and-decision package (PDF/DOCX) attached to this step, with the reconciliation table inside and the signed proposed conclusion.\n- **Item relationship / links** — links from this step to every referenced record: the Issue findings, the acceptance memos, the QA report, and the cycle-time dashboard.\n\n**Workflow link** — the link to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow instance.\n- **Handoff package** — the signed final package plus a manifest (comment or attached document) naming its contents, the do-not-repeat list, and the must-decide list.\n- **Step comment** — the as-of data-cut date and the downstream owner's acknowledgment.\n- **Step document** — the archived final package and closure note; the carry-forward register (XLSX: still-open Issues with cumulative age and revised `target_remediation_date`, acceptances with `exception_expiry_date`, escalated commitments with triggers) with scheduled follow-ups and owners.\n- **Item field update** — final status on all linked Issue, Audit, Risk, and Control records; the anchor Audit shows follow-up complete (status/comment); Issue↔Risk/Control links preserved for future aggregation and repeat detection.\n- **Workflow instance** — the run marked complete and locked as the archived audit trail.\n\n**Exit criteria**\nThe population reconciles arithmetically; every claim traces to a linked source; the exceptions narrative is included; the conclusion is signed; the package renders cleanly for handoff.\n\nDownstream instance linked; manifest delivered naming contents, non-repeatable work, and required decisions; the data cut is stamped and the acknowledgment recorded; the completeness sweep passed; every carry-forward obligation has a scheduled date and a named owner; the archive is stored per retention and matches the handed-off version; linked records are final; closure is communicated; the record is locked.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the compiled evidence-and-decision package from the linked records and documents, ready for sign-off and handoff.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:audit-finding-remediation-monitoring"}