{"description":"Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.","edges":[{"id":"e-lock-executable-workplan-record-findings-and-exclusions","source":"lock-executable-workplan","target":"record-findings-and-exclusions"},{"id":"e-record-findings-and-exclusions-classify-disposition","source":"record-findings-and-exclusions","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-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"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{"UC-AUDIT-12":"operates","UC-AUDIT-13":"operates","UC-AUDIT-14":"operates","UC-AUDIT-16":"operates","UC-AUDIT-23":"operates"},"controls":["UC-AUDIT-12","UC-AUDIT-13","UC-AUDIT-16","UC-AUDIT-23","UC-GOV-15","UC-VULN-01","UC-LOG-04","UC-IR-01","UC-BCDR-13","UC-LOG-01","UC-LOG-03","UC-LOG-05","UC-LOG-08","UC-VULN-05","UC-AUDIT-14"],"department":"internal-audit","domains":["audit"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=audit-cybersecurity-assurance-review","contentDigest":"sha256:b1b1849f755b1bd298e35c5fe4919ba4e021cf217f67943330cb40b47b726828","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b1b1849f755b1bd298e35c5fe4919ba4e021cf217f67943330cb40b47b726828","schemaVersion":1,"sourceTemplateId":"workflow-library:audit-cybersecurity-assurance-review"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"audit-cybersecurity-assurance-review","source":"coworkcanvas-gallery","standards":["iia-2024","nist-800-53"],"teams":["internal-audit","it"]},"name":"Cybersecurity Assurance Review","nodes":[{"data":{"description":"Approve the tiered cyber estate, stable criteria, evidence standards, supervision points and executable test program.","instructions":"**Objective** — Approve the tiered cyber estate, stable criteria, evidence standards, supervision points and executable test program.\n\n**Inputs**\nThe anchor: the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED) — `Audit.scope` holds the boundary summary and `Audit.lead_auditor` is set; the signed engagement memo is a document already attached to it. This step enriches that item; it does not create the engagement.\n- The criteria baseline: the three Topical Requirement domains cross-referenced to the catalog in use — Control items tagged framework nist-800-53 (families AC, AU, CM, CP, IA, IR, RA, SC, SI, PM) and iia-2024.\n- The audit methodology: the severity rating scale, IPE/workpaper standards and naming convention, and the reliance (Standard 9.5) and delegation-of-authority matrices; the resource plan, specialist commitments, and the reporting calendar.\n\nThe locked workplan and boundary.\n- The asset inventory / CMDB export with owner, criticality, and data classification per asset.\n- Network and cloud architecture diagrams; the identity-store inventory (directory, IdP, PAM).\n- Crown-jewel or business-impact analysis; sector threat intelligence and the organization's incident history.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement lead owns the stated judgments and authorizations.*\n\n*Lock executable workplan.* Freeze the work program per Standard 13.6: every planned procedure mapped to criteria, owned, dated, and bound to evidence standards, so fieldwork cannot drift silently.\n\n1. Build the procedure-to-criteria matrix both directions: each work-program procedure cites the Topical Requirement element and catalog control it evidences; each in-scope requirement has at least one procedure. A procedure mapping to nothing is cut; a requirement with no procedure is a coverage gap to close now, not in reporting.\n2. Assign every procedure an owner and due date; sequence the dependencies — governance interviews before control testing, population and evidence requests first (auditee extracts are the calendar's long pole).\n3. Set evidence standards up front: system-generated evidence carries source, extraction date/time, parameters, and completeness checks (IPE discipline); screenshots carry the system clock and URL; configuration exports are hashed or re-pullable. Fix the workpaper naming and indexing convention.\n4. Set supervision points: which workpapers the engagement lead reviews before dependent work proceeds — sampling plans and IPE validations at minimum.\n5. Confirm auditee logistics: the PBC list issued with owners and due dates; audit access provisioned read-only and time-boxed; the walkthrough calendar booked with control owners.\n6. Lock the plan: engagement-lead approval recorded. After lock, scope changes travel through a documented change record with CAE visibility — never silent edits to the work program.\n\n*Scope the cyber review.* Turn the locked boundary into a risk-ranked target list — the systems, data flows, and control populations this review will actually test — with the criteria set pinned and evidence requests already moving.\n\n7. Validate inventory completeness before ranking anything — this is itself a finding source. Reconcile CMDB counts against independent sources: the cloud tenant's native asset export, the EDR console count, and the vulnerability scanner's discovered assets. A variance above roughly 5% between CMDB and scanner discovery indicates an asset-inventory control failure (800-53 CM-8); record it and rank on the reconciled union, not the CMDB alone.\n8. Identify crown jewels: financially significant applications, regulated-data stores (PII, PHI, cardholder data), internet-facing services, single points of failure from the BIA — and always the identity infrastructure (domain controllers, IdP, PAM), because it is every attacker's first target and its compromise is systemic.\n9. Rank by exposure × impact and tier the estate: T1 tested in depth, T2 key controls only, T3 inquiry and analytics. Write the tiering rule down so a reviewer can reproduce the same tiers from the same inputs.\n10. Pin the criteria set: the three Topical Requirement domains cross-referenced to 800-53 Rev 5 as the technical catalog, with CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover) as the aggregation frame for posture reporting; note ISO 27001 Annex A equivalents where the auditee runs an ISMS. Freeze the mapping so findings cite stable criteria.\n11. Define the populations later steps will sample — user and privileged account lists, change tickets, vulnerability scan exports, alert queues, incident tickets, backup job logs — each with its system of record, owner, and as-of date. Issue the extract requests now.\n12. Flag reliance candidates for Standard 9.5 screening: a recent penetration test, SOC 2 CC-series coverage, second-line assessments — so testing effort is not spent where reliance is defensible.\n\n**Record in AssureSwarm**\nStep document — attach the approved work program and the issued PBC list (XLSX/PDF) under the naming and indexing convention fixed here.\n- Workflow instance — assign procedure owners and due dates on the workflow steps.\n- Item relationship — link the Control items (framework nist-800-53 / iia-2024) the procedure-to-criteria matrix references to the anchor Audit item.\n\nStep document (XLSX) — the tiered target list with the tiering rule, the inventory-reconciliation variance, and the frozen criteria mapping. The per-system tiering (T1/T2/T3, crown jewels, identity infrastructure) has no native item type — there is no Asset/System type — so the estate lives in this document, not as items.\n- Item relationship — link the in-scope Process items (process_type it_general_control | security_process) to the anchor Audit item.\n- Step document — record the population definitions and issued extract requests with owners and due dates on this step (populations have no native item type).\n\n**Exit criteria**\nMatrix complete in both directions; every procedure owned and dated; evidence and IPE standards written; supervision points set; approval recorded and the plan locked.\n\nInventory reconciliation documented with its variance; every T1 system has an owner, criteria mapping, and planned populations; criteria set frozen; extract requests issued with due dates.","label":"Lock executable workplan","performedBy":{"primitives":["coach-document-upload","coach-workflow-assign","coach-items-link","coach-query-data"]}},"id":"lock-executable-workplan"},{"data":{"description":"Evaluate governance, preventive/detective and response evidence; resolve factual disputes, calibrate four-Cs findings and the cyber posture conclusion.","formData":{"fields":[{"key":"facts_confirmed","label":"Are the facts as stated correct?","options":[{"label":"Confirmed as stated","value":"confirmed"},{"label":"Partially correct — correction below","value":"partially_confirmed"},{"label":"Disputed — contrary evidence attached","value":"disputed"}],"required":false,"type":"select"},{"key":"factual_correction","label":"Correction or contrary evidence, with the record it comes from","required":false,"type":"textarea"},{"key":"management_response","label":"Committed action, or the stated reason for accepting the risk","required":false,"type":"textarea"},{"key":"response_owner","label":"Named owner accountable for the action, with role","required":false,"type":"text"},{"key":"target_date","label":"Target completion date","required":false,"type":"date"},{"key":"risk_acceptance_intent","label":"This response is a formal risk acceptance rather than a remediation commitment","required":false,"type":"checkbox"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Evaluate governance, preventive/detective and response evidence; resolve factual disputes, calibrate four-Cs findings and the cyber posture conclusion.\n\n**Inputs**\nThe cyber strategy and roadmap; the security policy hierarchy with approval and review dates.\n- The org chart with the CISO mandate and reporting line; the three-lines RACI if one exists.\n- Board and committee packs and minutes for the period; the cyber risk appetite statement and KRI reporting.\n- The risk register's cyber entries; security training and attestation records; security budget and headcount trend.\n\nThe tiered target list and the population extracts requested at scoping, with as-of dates.\n- The procedure-to-criteria matrix (800-53 mapping) and the IPE standards from the locked workplan.\n- Prior findings on these controls (they raise sample sizes) and screened reliance candidates.\n\nThe incident response plan and playbooks (ransomware at minimum); the severity classification matrix and escalation tree.\n- Incident tickets for the period; tabletop and exercise records with after-action reports.\n- Backup architecture documentation, job logs, and restore-test records; the RTO/RPO matrix from the BIA.\n- The forensics/IR retainer contract and the crisis-communications plan.\n\nCandidate findings from the governance, control-testing, and readiness steps, with their evidence references.\n- The severity rating scale from the audit methodology; open prior findings for repeat identification.\n- Control-owner contacts for factual confirmation, and this step's form as the channel that confirmation comes back through.\n\nThe findings register with ratings and management responses.\n- Per-domain conclusions from the governance, control-testing, and readiness steps.\n- The coverage map (tested, relied, excluded); prior review results for trend; the risk appetite statement and KRIs.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Independent cyber audit team and engagement lead owns the stated judgments and authorizations.*\n\n*Assess cyber governance.* Conclude on the Topical Requirement's governance domain: whether accountability, strategy, policy, risk appetite, and board oversight of cybersecurity are designed and operating — the domain whose weaknesses make every control failure systemic.\n\n1. Accountability: a named executive owns cyber risk; the CISO mandate is written; the reporting line does not bury security under the function it must challenge. A CISO reporting to a CIO who owns delivery targets is a structural tension to weigh and document — not an automatic finding, but never an ignorable fact.\n2. Strategy: dated within roughly two years, traceable to business objectives and the threat profile, with funded roadmap items. Test execution, not prose: were the last two roadmap milestones hit or slipped, and does anyone track the slippage?\n3. Policy: hierarchy runs policy → standard → procedure; approval authority sits at the right level; the review cycle is honored (12 months is the common bar); coverage spans access, acceptable use, cryptography, logging, incident response, third parties, and secure development. Test communication with numbers — attestation or training completion at 95%+ within 30 days of hire — and sample five policy-required controls down to the procedures that actually implement them.\n4. Risk management integration: cyber risks live in the ERM register with owners, inherent and residual scores, and treatment dates; appetite is measurable (maximum tolerated critical-vulnerability age, incident-cost tolerance), KRIs report against it, and policy exceptions are time-bound with named acceptors and expiry dates. Undated, ownerless exceptions are how temporary risk becomes permanent.\n5. Board oversight: cadence (quarterly is the prevailing benchmark), content quality (trend and KRI reporting rather than anecdote), and evidence directors engage — questions in minutes, follow-ups tracked. Where disclosure obligations apply, verify management's incident-materiality process exists and is rehearsed: the SEC Form 8-K Item 1.05 clock is four business days from the materiality determination.\n6. Resourcing: budget and headcount against the roadmap and peers; vacancy age of key roles; a skills plan. Then conclude the domain: rate each governance element effective, partially effective, or ineffective, each with evidence citations, and carry candidate findings forward.\n\n*Test preventive and detective controls.* Conclude on the Topical Requirement's control-activities domain by testing design and operating effectiveness of the preventive and detective controls over the tiered estate — reperforming from raw system evidence, never from management dashboards.\n\n7. Design first, for each selected control: walk through one execution end-to-end and confirm the control as designed addresses the risk. Watch for definitional games — a 30-day patching SLA measured from ticket creation instead of vulnerability publication hides discovery lag and will make operating results look better than exposure.\n8. Sampling: automated controls get a test of one instance plus the ITGCs over the enforcing system (change management and admin access); manual controls follow frequency buckets (daily 25, weekly 5–10, monthly 2–5, quarterly 2), expanded 25–50% where prior findings exist. Record draw parameters so every sample is reproducible.\n9. Identity and access (AC-2, IA-2): reperform MFA coverage from the IdP policy export — the target for remote and privileged access is 100%, and every gap is a named account, not a percentage. Sample 25 leavers and compute termination-to-disable elapsed time against policy (24 hours is the common bar). Verify privileged accounts are inventoried and vaulted, and standing admin access carries a documented justification or a just-in-time elevation path.\n10. Hardening, change, and segmentation (CM-2, CM-3, SC-7): configuration baselines exist for T1 platforms with drift detection evidenced by an actual drift alert and its resolution; segmentation between user, server, and OT zones is evidenced by firewall rule review or penetration-test results — architecture diagrams are intent, not evidence.\n11. Vulnerability and patch management (RA-5, SI-2): pull the raw scanner export and recompute SLA compliance yourself — critical within 15 days, high within 30, or the organization's own SLA if stricter. Age the open criticals. Check CISA KEV-listed vulnerabilities separately: they are exploited in the wild, and any KEV item open past its due date on an internet-facing asset is a finding on its own. Then verify scan coverage against the reconciled inventory — the unscanned estate is the real exposure.\n12. Encryption (SC-8, SC-28): restricted data encrypted in transit and at rest on sampled T1 stores; key custody separated from the data's administrators.\n13. Logging and monitoring (AU-2, AU-6, AU-8): reperform log-source coverage — the SIEM's source list against the T1 inventory; retention meets policy (12 months is typical, with 90 days searchable); clocks synchronized. Sample 25 alerts across severities for triage timeliness against SLA and disposition quality, and map detection content against the organization's top threats (an ATT&CK-style coverage mapping exposes blind spots fast). Verify EDR deployment against the policy floor (98% coverage is a common bar) with time-bound exceptions.\n14. Integrity and egress (SI-7): file-integrity monitoring on critical configurations; trace one recent DLP event from alert to disposition.\n15. Apply IPE discipline to every population: completeness (record counts tie to source), accuracy (sampled rows trace back to the system), parameters captured. A compliance dashboard is a management assertion; the export it claims to summarize is the evidence.\n16. Rate each control effective or deficient with condition–criteria–cause–effect notes as you go. Where a conclusion needs adversarial or exploit-level evidence (does segmentation actually hold?), do not improvise — record the limitation as a candidate for a separate Technical Security Testing & Pentest Engagement and leave that control's operating conclusion open until such evidence exists.\n\n*Evaluate response readiness.* Conclude whether the organization can move from detection to recovery at the speed its obligations demand: incident response and backup/recovery capabilities tested against plan, clock, and evidence of real exercise.\n\n17. Plan quality (800-53 IR family): approved within 12 months; severity levels defined by concrete thresholds (what exactly makes a SEV-1); roles named with deputies; the 24×7 contact tree current — call one number and see. The legal branch must reflect the actual obligations: SEC Form 8-K Item 1.05 within four business days of the materiality determination, GDPR authority notification within 72 hours, plus applicable state and sector rules. Confirm the IR retainer is active with a response SLA.\n18. Exercise evidence (IR-3, CP-4): at least one tabletop in the last 12 months that included executives, not only the SOC; a realistic scenario (ransomware with backup compromise beats generic phishing); after-action items tracked to closure. An AAR with no closed actions is theater — say so.\n19. Real-incident replay: take every SEV-1 and SEV-2 in period plus a sample of lower severities and reperform the timeline — detection-to-triage and triage-to-containment against plan targets, classification correctness, evidence preservation (forensic images, chain of custody), post-incident review held, root cause fed back into controls, and the materiality/disclosure assessment documented where it applied.\n20. Backup posture (CP-9, CP-10): 3-2-1 with at least one immutable or offline copy — the ransomware assumption is that online backups are targets, not protection. Job success rates at or above the policy floor with failures re-run and evidenced; backup scope reconciled so every T1 system is actually covered.\n21. Restore proof: last successful restore test per T1 system within policy (quarterly is a strong bar, annual the minimum), restoring to a usable state with time measured against RTO; at least one full recovery exercise or verified DR failover within 24 months. A backup that has never been restored is a hope, not a control.\n22. Conclude per element — plan, people, exercise, backup, restore — effective, partial, or ineffective, quantifying gaps (\"8 of 22 T1 systems lack an in-period restore test\"), and carry candidate findings forward.\n\n*Record findings and exclusions.* Convert candidate findings into a defensible findings register — each with condition, criteria, cause, and effect, and a severity that survives challenge — and make untested areas explicit so the report cannot overstate coverage.\n\n23. Write each finding in four-Cs discipline. Condition: what is, with counts and dates (\"14 of 60 sampled critical vulnerabilities exceeded the 15-day SLA; oldest 143 days\"). Criteria: the Topical Requirement element, the catalog control (800-53 reference), and the internal policy breached. Cause: the root cause reached by a why-chain down to process, resource, or design — never the condition restated. Effect: plausible business impact tied to real threat scenarios, quantified where honest and not theatrical.\n24. Rate on impact × likelihood, then calibrate against floor rules: an internet-facing KEV vulnerability past due on a crown jewel rates high or critical regardless of portfolio averages; a repeat finding moves up one level; findings on identity infrastructure or backup immutability rarely rate below high, because those failures are systemic enablers.\n25. Aggregate by root cause: several mediums sharing one cause (say, absent asset-inventory discipline) may constitute a single high-rated thematic finding — rate the theme, not the fragments, and cross-reference the fragments to it.\n26. Confirm facts with control owners in writing before ratings go final. For a contact who executes none of this workflow’s checkpoints, issue one form assignment per identified finding, carrying its Issue ID, draft condition and source evidence in the request context. If the contact is also assigned a checkpoint, commitment approval or risk-authority role here, record their response in native results/documents instead of sending a form. Disagreement about facts is resolved with evidence; disagreement about ratings is recorded, not negotiated away.\n27. Record exclusions and not-tested areas with the same rigor: what was descoped or covered by reliance (with the Standard 9.5 memo reference), and what that means for the assurance statement. This trail is what Topical Requirement conformance is assessed against.\n28. Collect the named owner, committed action and target date through that external form only for nonexecuting contacts; use native results/documents for anyone executing or approving a checkpoint here. Refusals and risk-acceptance intents are captured verbatim — they feed the disposition decision next.\n\n*Report cyber posture.* Aggregate results into the posture message the board and audit committee will act on: an overall conclusion per Standard 14.5, domain-by-domain coverage, trend, and the comparison against risk appetite — the substance the downstream Audit Report Drafting workflow will format.\n\n29. Form the engagement conclusion on the house scale (effective, effective with exceptions, ineffective) for each Topical Requirement domain and overall. The conclusion must be mechanically derivable from the register — no finding-free \"needs improvement\", no \"effective\" over an open critical.\n30. Build the coverage picture honestly: for each domain and each CSF 2.0 function (Govern, Identify, Protect, Detect, Respond, Recover), state what this review tested, what it relied on (with the source and period), and what went untested. This is what prevents the committee hearing \"audited\" when a third of the estate was reliance.\n31. Trend against the prior review: findings opened, closed, and repeated; control ratings that moved; KRI trajectory. Name repeat findings as repeats — the age of a risk is board-relevant information.\n32. Compare to appetite: which results breach stated appetite or KRI thresholds (critical-vulnerability age beyond tolerance, restore-test coverage below floor). Breaches are the raw material for the escalate branch at the disposition decision.\n33. Draft the posture summary at two to three pages: the conclusion, top themes by root cause, the numbers that matter (coverage fractions, SLA compliance rates, exercise recency), fixes management completed in-flight (validated fixes only — an unverified fix is a response, not a result), and the forward risk statement.\n34. Pressure-test with the engagement lead: every sentence traceable to a workpaper; adjectives that cannot cite evidence get cut.\n\n**Record in AssureSwarm**\nStep document (DOCX/PDF) — the governance assessment matrix with per-element conclusions, plus the key evidence extracts (board minutes, appetite and KRI reporting).\n- Item (existing) — the security policy hierarchy as Policy items (policy_type policy | standard | procedure, policy_owner, approved_by, version, framework, domains, review_frequency, next_review_date — the review-cycle test reads next_review_date); the cyber risk-register entries as Risk items (category cyber_security, risk_owner, inherent_rating, residual_rating, treatment). Enrich these; do not recreate them.\n- Step notes — log candidate findings on this step (they carry forward to the findings register at record-findings-and-exclusions); the governance-domain conclusion lives in the assessment matrix document.\n\nStep document (XLSX) — per-control test workpapers with sample lists, draw parameters, raw extracts, IPE checks, and the effective/deficient rating per control. Control items carry no per-engagement test-rating field, so the rating lives in the workpaper (cycle-specific ICFR ratings live on Control-hosted SOX testing workflow results, while this non-SOX engagement's ratings stay in its workpaper).\n- Item relationship — link the tested Control items (framework nist-800-53; the AC/AU/CM/CP/IA/IR/RA/SC/SI families) to the anchor Audit item.\n- Step notes — log candidate findings with the four Cs on this step.\n\nStep document (DOCX/PDF) — the readiness assessment with per-element conclusions; attach the exercise AARs, incident-replay workpapers, and restore-test evidence as step documents.\n- Item relationship — link the in-scope incident-response and BCDR Control items (families IR, CP) to the anchor Audit item.\n- Step notes — log candidate findings on this step (they carry forward to the findings register).\n\nThe form on this step, answered by the affected control owner, uses the linked finding as request context and captures whether the facts are confirmed, disputed, or partly correct with the correction and its evidence, the committed action or stated risk acceptance, the named response owner, and the target date. Transcribe its values onto the finding Issue below; the auditor's rating and its calibration go in the step result.\n- Item create — one Issue per finding: severity, issue_type finding, source internal_audit, description (condition + criteria + effect), root_cause, recommendation, management_response, issue_owner, identified_date.\n- Item relationship — link each finding Issue to the anchor Audit item and to the tested Control items; where several fragments share one root cause, cross-link them to the thematic Issue (Issue ↔ Issue).\n- Step document — the exclusions / not-tested register with its Standard 9.5 reliance references on this step (no native register item — a document on the step).\n\nStep document (DOCX/PDF) — the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions and the tested/relied/excluded coverage map.\n- Item field update — set Audit.rating (satisfactory | needs_improvement | unsatisfactory) and Audit.opinion on the anchor Audit item from the overall conclusion.\n- Dashboard — build or refresh the engagement dashboard off the finding Issue items linked to the Audit: findings by severity and domain, SLA compliance, coverage fractions, trend versus prior review.\n- Item relationship — link the findings-register Issue items to this step.\n\n**Exit criteria**\nEvery governance-domain requirement carries a documented conclusion with evidence references; structural conflicts and appetite gaps explicitly dispositioned; candidate findings logged.\n\nEvery in-scope control has a design and operating conclusion with reperformable evidence; SLA recomputations tie to raw exports; scan, EDR, and log coverage reconciled to the inventory; candidate findings logged with the four Cs.\n\nAll elements concluded with evidence; every SEV-1/2 incident replayed; restore-test coverage stated as a fraction of T1; notification-clock compliance checked against the period's actual incidents.\n\nEvery finding carries the four Cs, a criteria citation, written owner confirmation of facts, and a calibrated rating; repeats flagged; exclusions register complete; management responses or refusals captured.\n\nConclusions recorded per domain and overall, each traceable to the register; coverage map explicit about reliance and exclusions; appetite breaches enumerated; summary attached and lead-reviewed.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans each control test, draws samples with recorded seeds, and assembles the evidence workpaper; `/sox-python` makes the SLA and coverage recomputations deterministic and reproducible.\n\n**Form recipient** — Affected auditee control owners assigned no execution or approval responsibility anywhere in this workflow. Check the complete preparation, execution, review and approval roster first: anyone assigned a role anywhere in this workflow contributes through native results, documents and approvals instead. Read current evidence and declarations before requesting anything. Select only unresolved questions for the identified scope and period; known facts remain linked context, and no request is needed if nothing is missing. The catalog fields are optional so known or unasked facts need not be repeated; every question actually required by the assignment must have an attributable response or a recorded unresolved gap before the dependent judgment. A negative or declined affirmation remains visible; it must never be converted to a positive statement. Resolve the full assignee and approver roster before collecting. Control owners who also execute a checkpoint, approve a management commitment or act as risk authority here use native results/documents. Only other auditee contacts receive the identified finding request for missing facts and proposed commitments.","label":"Record findings and exclusions","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-items-link","sox-testing","sox-python","coach-item-create","coach-dashboard-create"]}},"id":"record-findings-and-exclusions"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Cybersecurity Assurance Review so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Classify the review's outcome so closure follows exactly one path — clean package, owned remediation, or escalation. The engagement lead decides, with CAE visibility on any escalation.\n\n**Decision criteria**\n\nVerify against the findings register before picking — counts, ratings, and appetite comparisons, not recollection.\n\n- **No reportable gap (`clean`)** — the register holds nothing above low-severity observations, and those already carry validated fixes; all three Topical Requirement domains concluded effective; no appetite breach; no rejected reliance. One open medium disqualifies this branch — clean means no remediation obligation of any kind survives the engagement.\n- **Remediation required (`remediate`)** — medium or high findings exist and management is engaged: facts confirmed in writing, owners nameable, remediation feasible on normal cycles. No active-exploitation exposure, no appetite breach management refuses to address, no unresolved disclosure question. This is the common branch; its work product is the action-plan step next.\n- **Escalate significant issue (`escalate`)** — any of: a critical finding with a plausible active exploitation path (a KEV vulnerability open on an internet-facing crown jewel, an identity-infrastructure compromise vector); systemic governance failure (no accountable executive, the board materially misinformed); an appetite breach management declines to act on — under Standard 11.5 the CAE must carry unacceptable risk acceptance to the board; a potential disclosure obligation (SEC materiality question in play); or repeat critical/high findings surviving multiple cycles. On this path, remediation commitments are captured inside the escalation outcome — the escalate branch rejoins at the final package, not at the action-plan step.\n\n**Record in AssureSwarm**\n- Submit the decision form: `disposition_path`; the step result citing finding IDs and the specific trigger condition met; the step's approver record — engagement lead, or CAE for escalations.\n\n**Exit criteria** — Form submitted; rationale reconciles to the findings register's counts and top severities; unused branches prunable.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-form-fill","coach-query-data"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert each reportable finding into an owned, dated, verifiable action plan per Standard 14.4 — root cause addressed, interim risk held down, and closure evidence defined before work starts.\n\n**Inputs**\n- The findings register with confirmed facts, ratings, and management responses.\n- The organization's remediation SLA policy by severity, if one exists (defaults below).\n- Open prior action plans, to link rather than duplicate.\n\n**Procedure**\n1. One plan per root cause, not per symptom: five findings caused by absent asset-inventory discipline get one structural plan plus per-finding tactical fixes cross-referenced to it.\n2. The owner is a named individual with authority over the fix — never a team name — with an executive sponsor for cross-functional causes.\n3. Dates proportional to severity: critical — interim mitigation within 30 days and full fix within 90; high within 90; medium within 180. Anything longer carries a written justification visible to the CAE. Interim mitigation is mandatory for critical and high (compensating control, exposure reduction, monitoring lift) — the risk does not wait for the project plan.\n4. Define done as evidence, now: the artifact that proves closure (a re-scan showing zero past-SLA criticals, the IdP export showing 100% MFA on privileged accounts, a passed restore test on the named systems). Plans whose closure is \"process improved\" are returned to the owner.\n5. Set follow-up per Standard 15.2: validation method (re-test versus evidence review), checkpoint cadence for long plans, and the slip rule — one extension with owner justification; a second slip goes to the CAE.\n6. Obtain written acceptance from each owner. A refusal or a watered-down plan is an escalation trigger for the engagement lead — record it and raise it; do not book a weak plan to close the step.\n\n**Record in AssureSwarm**\n- Item field update — on each reportable finding's Issue item: remediation_plan (root-cause fix, interim mitigation, and the closure-evidence definition), issue_owner (a named individual), target_remediation_date proportional to severity. There is no Action Plan item type — the plan lives on the Issue.\n- Item relationship — a structural plan spanning several findings is one thematic Issue with the tactical fixes cross-linked to it (Issue ↔ Issue), rather than duplicated per finding.\n- Notify — notify owners of accepted plans and dates, and set the follow-up checkpoints.\n\n**Exit criteria** — Every reportable finding maps to an accepted plan or a documented escalation; critical/high plans carry interim mitigations; closure evidence defined per plan; checkpoints scheduled and owners notified.","label":"Create action plan","performedBy":{"primitives":["coach-item-update","coach-item-create","coach-items-link","coach-notify"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to engagement lead, CAE delegate, or audit committee delegate or document risk acceptance","instructions":"**Objective** — Put the significant issue in front of the authority the delegation-of-authority matrix requires, with a decision-grade memo, and land one of two documented outcomes: a commitment to act, or a formal, bounded risk acceptance.\n\n**Inputs**\n- The escalation-triggering findings with their evidence.\n- Quantified exposure: affected assets, plausible loss scenarios, exposure window to date.\n- The delegation-of-authority matrix (who may accept how much risk); the risk appetite statement.\n- Disclosure counsel's contact where a materiality question is in play.\n\n**Procedure**\n1. Draft the decision memo at two pages: the issue in business terms, the exposure quantification, what management proposed, the options with costs, internal audit's recommendation, and the decision needed by a stated date. Attach the decisive evidence — not the whole file.\n2. Route by trigger: control-level criticals go to the engagement lead plus CISO/CIO; an appetite breach management will not address goes to the CAE, who under Standard 11.5 must communicate unacceptable risk acceptance to the board; a potential disclosure materiality question goes to the CAE and counsel immediately — the SEC Form 8-K clock runs four business days from the materiality determination, so the assessment cannot queue.\n3. If the outcome is act: capture the commitment — what, who, when, and the interim mitigation effective immediately. On this path the commitment record substitutes for the standard action-plan step; it rides into the final package with the same ownership and date discipline.\n4. If the outcome is risk acceptance: the acceptor must hold authority for the quantified exposure under the DoA matrix; the acceptance is written, time-bound (12 months maximum before re-decision), condition-bound (the change that voids it stated), and monitored via a watchlist on the accepted-risk item with the re-review date. Internal audit records the acceptance without concurring, and the CAE reports beyond-appetite acceptances to the board.\n5. Either way, set follow-up ownership and the re-review trigger before leaving the step.\n\n**Record in AssureSwarm**\n- Step document — attach the decision memo and the signed outcome (commitment to act, or formal risk acceptance).\n- Item field update — update the escalation-triggering Issue items' management_response with the disposition.\n- Item create (risk acceptance) — record a formal acceptance as an Issue with issue_type policy_exception, exception_approver (the DoA-authorized acceptor), and exception_expiry_date (the time-bound re-review date, 12 months maximum), linked to the accepted Risk item — and set treatment accept on that Risk. exception_expiry_date is the filterable re-review index; the Risk type itself has no acceptance-expiry field, so the memo carries the voiding condition in prose.\n- Notify — notify the accountable parties of the recorded outcome.\n\n**Exit criteria** — Memo delivered to the DoA-required authority; outcome signed, time-bound, and condition-bound; board-communication trail exists for beyond-appetite acceptances; follow-up owner and date set.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-item-create","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Independently approve the frozen and reconciled assurance package or return specific substantive conditions.","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** — Independently approve the frozen and reconciled assurance package or return specific substantive conditions.\n\n**Inputs**\nAll step workpapers; the findings register and action plans; the posture summary and coverage map.\n- Decision forms with rationales (disposition and approval); reliance memos where prior assurance was relied upon; the exclusions register.\n- Escalation or risk-acceptance records where the escalate path ran.\n- The engagement QA checklist from the audit methodology.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Engagement lead, CAE delegate or audit committee delegate owns the stated judgments and authorizations.*\n\n*Prepare final package.* Assemble the complete, internally consistent engagement package — evidence, findings, decisions, reliance memos, action plans, posture conclusion — so the approver can verify any statement without leaving the package.\n\n1. Index everything: workpapers numbered per the convention fixed at workplan lock, cross-referenced from findings and conclusions — a reviewer must trace any sentence to its evidence in two clicks.\n2. Run the self-QA before the approver does: every finding has the four Cs, a criteria citation, written owner confirmation, and a response or plan; every conclusion traces to workpapers; every sample has draw parameters; every IPE population has completeness and accuracy checks; every reliance has a Standard 9.5 memo; every decision form has rationale and owner.\n3. Reconcile the numbers across artifacts: finding counts, ratings, and coverage fractions must match between the register, the posture summary, and the dashboard. Mismatched counts are the fastest way to lose an approver's confidence in everything else.\n4. State unresolved constraints plainly: evidence never provided (with the chase trail), scope reductions, and any open dependency on a separate engagement's results — each with the engagement's position on what it means for the conclusion.\n5. Confirm the Topical Requirement conformance trail: each of the three domains concluded or exclusion-documented, visible enough that an external quality assessor could verify conformance from the package alone.\n6. Freeze the version submitted for approval; subsequent edits happen as tracked revisions on a new version, never as silent replacement.\n\n*Approve or revise package.* The approver of record — engagement lead, CAE delegate, or audit committee delegate, per the engagement's authority level — either approves the frozen package or returns it with specific, closable conditions.\n\n\n\nThe approver verifies rather than assumes, sampling into the package itself.\n\n- **Approved (`approved`)** — all of: conclusions supported by cross-referenced evidence; findings carry the four Cs, written owner confirmation of facts, and ratings that survive the calibration rules; action plans owned, dated, with closure evidence defined; escalation or acceptance documentation complete where that path ran; the Topical Requirement three-domain trail present; numbers reconcile across register, posture summary, and dashboard; constraints disclosed with positions. Approval with minor editorial notes is still `approved` when nothing changes a conclusion, a rating, or a scope statement.\n- **Revision required (`revise`)** — any of: a conclusion not traceable to evidence; a rating that fails calibration; a finding lacking owner confirmation; reliance used without a Standard 9.5 memo; coverage claims exceeding what was tested; QA checklist exceptions left open; or substantive reviewer questions unresolved. The dividing rule: if fixing it would change what the audit committee reads, it is `revise`; if not, it is an editorial note under `approved`.\n\nConditions on a revise decision must be enumerated and specific — each names the workpaper or finding, the defect, and what closure looks like. \"Tighten the report\" is not a condition.\n\n**Record in AssureSwarm**\nStep document — render and attach the compiled package (PDF) and the completed QA checklist; record the package version identifier on this step.\n- Workflow instance — export the workflow record for the package appendix.\n- Item relationship — link the findings-register Issue items, the action-plan Issues, and the tested Control items the approver needs from this step.\n\nSubmit the decision form: `approval_path`; the step result listing what was verified (approved) or the enumerated conditions with workpaper references (revise); the step's approver record — the approver of record, named.\n\n**Exit criteria**\nPackage indexed and internally reconciled; QA checklist complete with no open exceptions; constraints stated with positions; version frozen and routed to approval.\n\nForm submitted by the named approver; any conditions are specific and closable; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the indexed evidence, findings register, and decision trail into the reviewable package with cross-references intact.","kind":"decision","label":"Approve or revise package","performedBy":{"primitives":["coach-render-package","coach-document-upload","coach-workflow-export","coach-form-fill"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Close every returned condition with evidence at the original standard, and show exactly what changed so the approver's re-review is a delta review, not a full re-read.\n\n**Inputs**\n- The approver's enumerated condition list from the decision form.\n- The frozen package version the conditions reference.\n- The underlying workpapers, populations, and evidence needed to close each condition.\n\n**Procedure**\n1. Triage each condition into one of four kinds and assign an owner and date: evidence gap (re-pull or re-test), analysis gap (re-perform and re-conclude), rating challenge (re-calibrate against the scale and document the reasoning either way), or presentation defect (fix without touching substance).\n2. Re-obtained evidence meets the original bar: IPE completeness and accuracy checks, recorded draw parameters, the workpaper convention. A condition closed with weaker evidence than the original standard is not closed.\n3. When a closure changes a conclusion, rating, or scope statement, update the findings register, posture summary, and dashboard together — the package-prep reconciliation must survive revision. Notify the affected management owner whose finding text or plan changed; no surprises in the final report.\n4. Maintain the revision log: condition → what changed → where (workpaper reference) → who → when. Produce the next package version with the log as its cover; the frozen prior version stays intact.\n5. Where a condition is contested rather than closable, resolve it with the approver directly and record the agreed disposition — do not resubmit a package with a silently ignored condition.\n6. Resubmit for the approval decision.\n\n**Record in AssureSwarm**\n- Step document — attach the revision log and the new package version.\n- Item field update — update the changed finding Issue items in place (description, severity, remediation_plan as the condition requires).\n- Step notes — record per-condition closure with workpaper references on this step.\n\n**Exit criteria** — Every condition closed at original evidence standards or explicitly re-dispositioned with the approver; revision log complete; affected owners notified; new version submitted.","label":"Resolve approval conditions","performedBy":{"primitives":["coach-document-upload","coach-item-update"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Accept responsibility for the approved substantive package, report boundary and reporting deadline; transfer every surviving condition and follow-up owner.","instructions":"**Objective** — Accept responsibility for the approved substantive package, report boundary and reporting deadline; transfer every surviving condition and follow-up owner.\n\n**Inputs**\nThe approved package version and the approval form with its rationale.\n- Any conditions attached to the approval.\n- The surviving obligations: action-plan checkpoints, acceptance re-review dates, handoff commitments.\n\nThe approved, versioned package and the approval record with its surviving conditions.\n- The findings register with management responses and action plans; the posture summary; the coverage and reliance map; the engagement decision log.\n- Reporting expectations from the engagement memo: committee date, distribution list, format constraints.\n- The records-retention schedule (internal audit workpapers are commonly retained seven years, or per the organization's policy and regulatory drivers).\n- Acceptance re-review dates and the lessons and scope observations noted during fieldwork.\n\n**Procedure**\n*The agent prepares the combined evidence and performs the recordkeeping below. Audit Report Drafting workflow owner and engagement lead owns the stated judgments and authorizations.*\n\n*Record approval decision.* Make the approval an immutable engagement record: who approved which package version, when, under what authority and conditions, and who owns every surviving obligation.\n\n1. Record the approver's identity and role authority (engagement lead, CAE delegate, or audit committee delegate), the decision date, and the exact package version approved. An approval of \"the package\" without a version identifier is not reperformable — pin it.\n2. Enumerate conditions that survive approval (for example, \"issue the final report only after counsel reviews the disclosure paragraph\"), each with a named owner and due date. A condition without an owner evaporates.\n3. Close the supervision trail: every workpaper review signed at the supervision points set in the workplan; no open review notes. Open coaching notes at approval are a quality-assessment finding waiting to be written — clear them or convert them to owned conditions.\n4. Snapshot the engagement decision log: the disposition and approval decisions — each with rationale and owner. This log is the first thing an external quality assessment reads; make it self-standing.\n5. Verify follow-up obligations transferred to named people with calendar dates — action-plan validations and acceptance re-reviews owned by individuals, not by \"the team\".\n\n*Handoff to related workflow.* Hand the approved package to the Audit Report Drafting workflow so report writing starts from settled substance — findings, ratings, conclusions, and plans that will not move under the writer's hands — and close the engagement on that acknowledged handoff, with the trail archived under retention controls and every follow-up obligation owned.\n\n_Items 11–16 close the engagement (folded from the former \"Close and archive\" step); the acknowledged handoff recorded here is the closure, not a separate confirmation._\n\n6. Create or link the Audit Report Drafting workflow and attach the handoff package: the approved findings register, the posture summary with domain conclusions, the coverage map (tested, relied, excluded), action plans with owners and dates, escalation or acceptance records, and the approval record with its surviving conditions.\n7. State the do-not-redo boundary explicitly: the drafting workflow formats and communicates — it does not re-derive findings, re-rate severities, or reopen negotiated management responses. Substance changes route back to this engagement as revisions, never as edits made inside the report.\n8. Flag the drafting-sensitive items: disclosure-related language requiring counsel review before issuance; accepted risks the board must see under Standard 11.5; repeat findings that must be labeled as repeats; and any anonymization or data-handling constraints on report distribution.\n9. Transfer the reporting calendar: the committee meeting date, management-response deadlines already agreed during fieldwork, and the issuance target from the engagement memo — with slack called out if the calendar is already tight.\n10. Obtain acknowledgment: the drafting workflow's owner confirms receipt of the package and the boundary. Writer questions come back as comments on this workflow, keeping one source of truth for substance. This acknowledgment is the step's human moment and the trigger for closing out.\n11. Confirm the engagement is actually closable: approval recorded with a version, handoff acknowledged, and no unresolved condition except those transferred with named owners. An engagement with an unowned open condition escalates to the CAE — it does not close.\n12. Export the workflow record and archive it with the final package in the designated evidence repository under retention and immutability controls; record the archive location and reference identifier; verify retrievability by opening the archived copy — the upload receipt is not verification.\n13. Update the audit-plan record: engagement complete, dates, conclusion, and coverage delivered versus planned. This feeds the CAE's plan-performance reporting and the next annual risk assessment.\n14. Schedule follow-up per Standard 15.2: action-plan validation checkpoints and risk-acceptance re-reviews created as dated items with named owners; critical and high validations take calendar priority over new work.\n15. Seed the next cycle: systems added or retired during fieldwork, criteria updates pending (catalog revisions, new Topical Requirement guidance), estimate-versus-actual effort, and what the next review should test first — attached as the next-cycle seed note.\n16. Communicate closure to the CAE, auditee leadership, and any related-engagement owners — and practice the control you just tested: confirm the review team's provisioned read-only access is disabled, and record that confirmation.\n\n**Record in AssureSwarm**\nItem field update — confirm the final Audit.rating and Audit.opinion and set Audit.report_date on the anchor Audit item; advance the Audit status. Record approver, authority, decision date, and the exact approved package version on this step.\n- Step document — attach the engagement decision log.\n- Item field update — verify each surviving obligation Issue item carries its owner (issue_owner) and date (target_remediation_date, or exception_expiry_date on an acceptance) so no obligation is left unowned.\n\nHandoff package — link the downstream Audit Report Drafting workflow to the same anchor Audit item; attach the handoff package manifest.\n- Step notes — the drafting workflow owner's acknowledgment and the transferred reporting calendar; the assumptions, do-not-redo boundary, and drafting-sensitive flags passed downstream.\n- Step document — the closure record with the archive location and reference; the next-cycle seed note and the access-deprovisioning confirmation on this step.\n- Item field update — set Audit.fieldwork_end and advance the anchor Audit item's status to closed; update the audit-plan record with coverage delivered versus planned.\n- Item create — the follow-up Issue items (action-plan validation checkpoints, acceptance re-reviews) with issue_owner and target_remediation_date.\n- Workflow instance — export and archive the workflow record with the final package under retention and immutability controls.\n\n**Exit criteria**\nApproval recorded with version and authority; every surviving condition owned and dated; supervision trail closed with no open review notes; decision log attached.\n\nDownstream workflow linked and acknowledged; manifest complete; do-not-redo boundary and drafting-sensitive flags documented; reporting calendar transferred; archive verified retrievable with its reference recorded; audit-plan record updated; every follow-up exists as an owned, dated item; team access deprovisioned and confirmed; closure communicated.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-item-update","coach-document-upload","coach-workflow-attach","coach-notify","coach-workflow-export","coach-item-create"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:audit-cybersecurity-assurance-review"}