{"description":"Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. \"ISO 27001 SoA Review 2026-H2\"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.","edges":[{"id":"e-lock-executable-workplan-assess-sampled-controls","source":"lock-executable-workplan","target":"assess-sampled-controls"},{"id":"e-assess-sampled-controls-classify-disposition","source":"assess-sampled-controls","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-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-16","UC-AUDIT-21","UC-RISK-14","UC-GOV-15","UC-ACCESS-19","UC-ASSET-01","UC-ASSET-02","UC-ASSET-03","UC-ASSET-04","UC-ASSET-06","UC-ASSET-07","UC-ASSET-08","UC-ASSET-09","UC-GOV-06","UC-GOV-07","UC-GOV-08","UC-HR-01","UC-HR-02","UC-HR-04","UC-HR-05","UC-HR-07","UC-PHYS-01","UC-PHYS-02","UC-PHYS-03","UC-PHYS-04","UC-PHYS-05","UC-PHYS-06","UC-PHYS-08","UC-PHYS-09","UC-PHYS-10","UC-PHYS-11","UC-PHYS-12"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-iso27001-soa-review","contentDigest":"sha256:8131d31962a4d6bfc7156742399d4a2f6ed9ee12af11daec6dfe1648c3a575d8","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8131d31962a4d6bfc7156742399d4a2f6ed9ee12af11daec6dfe1648c3a575d8","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-iso27001-soa-review"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-iso27001-soa-review","source":"coworkcanvas-gallery","standards":["iso-27001"],"teams":["it","compliance-legal"]},"name":"ISO 27001 SoA Review & Controls Assessment","nodes":[{"data":{"description":"Approve the risk-derived control population, current applicability justifications, sample basis and pre-committed evidence and exception rules.","instructions":"**Objective** — Approve the risk-derived control population, current applicability justifications, sample basis and pre-committed evidence and exception rules.\n\n**Inputs**\n- The handoff package from the upstream ISMS Risk Assessment & Treatment Cycle — attached as a document at this step — carrying the current risk register, the risk treatment decisions, and the required-controls determination that drives which Annex A controls must be applicable; the live risk register itself is the existing Risk items (treatment, residual_rating, risk_owner). No other workflow feeds this one; the trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.\n- The current Statement of Applicability (SoA) version — the prior cycle's approved SoA XLSX pulled from that cycle's publish step (there is no native SoA item type; the SoA lives as a step document version-to-version) — and the ISO/IEC 27001 Annex A / 27002 control baseline as the existing Control items (framework = iso-27001).\n- The control register: existing Control items (control_id, control_owner, domains, control_type, automation, frequency) with Control ↔ Process links, across the Annex A domains in scope — asset management (UC-ASSET-01..12), HR security (UC-HR-01/02/04/05/07), physical security (UC-PHYS-01..12), access control (UC-ACCESS-19), and governance (UC-GOV-06/07/08/15/16).\n- Prior review results — the prior cycle's Audit item (rating, report_date) and its archived workflow instance — plus open corrective actions (open Issue items, source = compliance_review, linked to Controls) and audit/monitoring evidence sources (UC-AUDIT-21).\n- The workplan and applicable-control population established during the planning activities in this checkpoint, to be reconciled before the workplan is locked.\n- The current SoA version (per control: applicable Y/N, justification for inclusion, justification for exclusion, and implementation status).\n- The ISMS Risk Assessment & Treatment Cycle handoff — the risk treatment decisions that require specific controls — and the ISO/IEC 27001 Annex A / 27002 control set.\n- Governance and change records since the last SoA version (UC-GOV-06/07/08/15/16), plus asset, HR, and physical changes (UC-ASSET-01..12, UC-HR-01/02/04/05/07, UC-PHYS-01..12).\n\n**Procedure**\n_This checkpoint absorbs “Reconcile applicability”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Lock executable workplan: Establish the assessment objective and boundary: the ISMS scope (sites, systems, legal entities), the SoA version under review, and the reason for the review (periodic, certification cycle, or triggered by a change).\n2. Derive the applicable-control population from the risk treatment decisions: every control the treatment decisions require must appear applicable in the SoA. List them, and note any control the SoA excludes that treatment implies is needed — a candidate issue for the SoA reconciliation activities in this checkpoint.\n3. Size the assessment per control by risk and frequency: for each applicable control set the evidence to pull, the sample (automated/system controls -> walkthrough + configuration evidence; manual controls -> a sample of operating instances sized to the control's frequency), and the effectiveness test (design + operating).\n4. Assign owners and due dates: name the control owner and the assessor for each control, the evidence-request due dates, and the review checkpoints.\n5. Define the sufficiency and exception standard before results exist: what constitutes sufficient evidence per control, the IPE/completeness checks required, and the expand-or-stop exception policy — pre-committed so conclusions cannot be outcome-shopped later.\n6. Reconcile applicability: Pull the current SoA baseline: retrieve the authoritative SoA version, confirm it is the system of record, and record its version, approval date, and approver.\n7. Reconcile inclusions: for every control the risk treatment decisions require, confirm the SoA marks it applicable with a justification tied to a specific risk or a legal/contractual obligation. Flag any required control the SoA marks excluded.\n8. Reconcile exclusions: for every control the SoA excludes, confirm the exclusion justification is still valid — no new risk, obligation, asset, or system since the last version reintroduces the need. A stale exclusion justification is a finding.\n9. Check justification quality: each applicable control must cite why it applies; each excluded control must cite why it does not. Vague or boilerplate wording (\"not relevant\") is a deficiency to route.\n10. Reconcile against change: map governance, asset, HR, and physical changes since the last version to controls whose applicability may have shifted, and update the register accordingly.\n11. Produce the reconciled applicability register: one row per Annex A control with applicable status, justification, implementation status, and any reconciliation exception.\n\n**Record in AssureSwarm**\n- Create the review-cycle anchor — an Audit item (audit_type: compliance) with scope, period_start, and period_end set to the ISMS boundary and review period — and attach the locked workplan document (XLSX/DOCX) to this step (coach-item-create, coach-document-upload).\n- Create or attach one control-testing workflow directly on each sampled applicable Control, record the review period, tester, and sample-basis rationale on its setup step/custom fields, and link each workflow's result package to the anchor Audit (coach-workflow-attach, coach-items-link); pull the Control baseline and prior-cycle results via coach-query-data.\n- Attach the reconciled applicability register (XLSX — one row per Annex A control with applicable status, justification, implementation status, and any exception) to this step (coach-document-upload). Control has no native applicability field, so the applicable/excluded decision and its justification live on the register document, not on the Control item.\n- Create one Issue per reconciliation exception (issue_type: exception, source: compliance_review, severity, with the required-but-excluded / stale-exclusion / weak-justification gap in its description) (coach-item-create), and link each Issue ↔ its Control and Issue ↔ the Risk or obligation that reintroduces the need (coach-items-link); source the SoA and change data via coach-query-data.\n\n**Exit criteria**\n- The workplan is locked: the applicable-control population is derived from the risk treatment decisions, per-control sample and evidence requirements are set, owners and due dates are assigned, and the sufficiency/exception standard is recorded before fieldwork.\n- Every Annex A control's applicable/excluded decision is reconciled to the risk treatment plan and the current baseline with a valid justification; reconciliation exceptions (required-but-excluded, stale exclusion justifications, weak justifications) are logged for evidence verification and routing.","label":"Lock executable workplan","performedBy":{"agent":"grc-artist","note":"assessment scoping and per-control workplan builder SoA pull and applicability-decision reconciliation against risk treatment","primitives":["coach-document-upload","coach-item-create","coach-items-link","coach-query-data","coach-item-update"]}},"id":"lock-executable-workplan"},{"data":{"description":"Judge authentic complete evidence, design and operating effectiveness under the pre-committed exception policy, and validate and route every real deficiency.","instructions":"**Objective** — Judge authentic complete evidence, design and operating effectiveness under the pre-committed exception policy, and validate and route every real deficiency.\n\n**Inputs**\n- The reconciled applicability register (applicable controls and their claimed implementation status).\n- The workplan's per-control evidence requirements.\n- Evidence sources by domain: policies and governance records (UC-GOV-06/07/08/15/16), asset inventories and handling/custody records (UC-ASSET-01..12), HR security records — screening, terms, awareness, offboarding (UC-HR-01/02/04/05/07), physical security records and access logs (UC-PHYS-01..12), access-control configuration and reviews (UC-ACCESS-19), and audit logs (UC-AUDIT-21).\n- The evidence-completeness map and the attached evidence per control.\n- The workplan's sample basis and effectiveness test per control.\n- The ISO/IEC 27002 implementation guidance / control objective for each control under test, and the risk-register entries the controls mitigate (UC-RISK-14).\n- The assessment conclusions: deficient controls with design/operating classification, root cause, and severity.\n- The reconciliation exceptions from the applicability step (required-but-excluded, stale exclusion justifications, weak justifications).\n- Control owners and the existing corrective-action / findings register.\n\n**Procedure**\n_This checkpoint absorbs “Verify control evidence”, “Route deficient controls”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Verify control evidence: For each applicable control, request or pull the evidence named in the workplan and confirm it is current for the review period — not an artifact carried from a prior cycle.\n2. Verify authenticity and source: evidence comes from the system of record; capture a documented extraction (query, parameters, timestamp) so the pull is reproducible.\n3. Verify completeness (information produced by the entity / IPE): for population-based evidence (access lists, asset registers, training completion), confirm the population is complete for the period — counts tie to the source total. An incomplete population voids downstream sampling; re-pull before assessing.\n4. Map evidence to the SoA claim: confirm the evidence supports the control's stated implementation status. Where the SoA claims \"implemented\" but evidence is missing, partial, or stale, mark an evidence gap.\n5. Classify each control: evidence sufficient / evidence gap / evidence absent, and flag controls needing owner follow-up before assessment.\n6. Assess sampled controls: Assess design: does the control as implemented meet its Annex A / 27002 objective? A control that cannot achieve its objective even when operating is a design deficiency — record it regardless of operating results.\n7. Assess operating effectiveness on the sample: for each sampled instance, reperform or inspect to confirm the control operated as designed throughout the period. Manual controls -> test the sampled operating instances; automated controls -> test the configuration plus a walkthrough.\n8. Apply the pre-committed exception policy: when an exception is found, follow the workplan's expand-or-stop rule; do not change the policy after seeing a result.\n9. Evaluate exceptions: distinguish an isolated exception from systematic failure; compare the deviation rate to the tolerable rate; consider whether a compensating control limits the impact.\n10. Conclude per control — effective, or deficient (design vs operating) — tying each conclusion to the specific evidence and the control objective. Every deficiency carries a root cause and a severity.\n11. Route deficient controls: Consolidate all gaps: assessment deficiencies plus applicability-reconciliation exceptions into a single deficiency list.\n12. Confirm each gap is real, not an evidence artifact: re-check the evidence and the control objective before routing — a false positive wastes owner effort and erodes trust.\n13. Rate and prioritize: severity times exposure, whether the deficiency creates active exposure now, and whether a compensating control bounds it.\n14. Assign each deficiency to a named accountable owner and record interim mitigation for any high-severity gap that cannot wait for the formal action plan.\n15. Open or update a corrective-action item per deficiency with root cause, severity, owner, and the required remediation outcome — the control status the fix must achieve.\n\n**Record in AssureSwarm**\n- Attach the evidence-completeness map (XLSX) to this step and attach the collected evidence files to the evidence step of each Control-hosted testing workflow; its direct Control host already supplies the control association (coach-document-upload, coach-item-document-attach).\n- Record each control's evidence-sufficiency classification (sufficient / gap / absent) with its reproducible extraction reference in that Control-hosted testing workflow's evidence-step result (coach-form-fill); source evidence via coach-query-data.\n- Attach the per-control assessment workpaper (XLSX) to this step (coach-document-upload) and set each Control-hosted testing workflow's Test-step conclusion (operating_effectively | exceptions_noted | not_operating_effectively | not_tested), capturing the design/operating basis, root cause, and severity of any deficiency in that Control-hosted testing workflow's Test-step result (coach-form-fill).\n- Confirm each testing workflow is hosted directly on the Control it covers, and link its result package to the Risk-register entries that Control mitigates (coach-items-link).\n- Create one Issue per assessment deficiency (issue_type: deficiency, source: compliance_review, severity, root_cause, issue_owner, identified_date, target_remediation_date) and update each applicability-exception Issue from the reconciliation step with its accountable issue_owner and severity (coach-item-create, coach-item-update); record interim mitigation for any high-severity gap in the Issue's remediation_plan.\n- Link each Issue ↔ its Control, Issue ↔ the Risk it touches, and Issue ↔ the anchor Audit (coach-items-link), and notify the owners (coach-notify).\n\n**Exit criteria**\n- Every applicable control has evidence pulled, authenticated, and completeness-checked, mapped to its SoA implementation claim, and classified sufficient / gap / absent with a reproducible extraction reference.\n- Every sampled control has a documented design and operating conclusion tied to its objective and evidence; deficiencies carry a design/operating classification, root cause, and severity; the exception policy was applied exactly as pre-committed.\n- Every assessment deficiency and applicability exception is a tracked, owned corrective-action item with severity, interim mitigation where warranted, and a defined remediation outcome; owners are notified.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans each sampled control's design and operating test and records the reperformance results and exceptions as a structured, reperformable workpaper.","label":"Assess sampled controls","performedBy":{"agent":"grc-artist","note":"implementation-evidence collection, authentication, and completeness verification design and operating effectiveness testing of sampled controls deficiency consolidation, ownership assignment, and corrective-action routing","primitives":["coach-query-data","coach-document-upload","coach-item-update","coach-items-link","sox-testing","coach-item-create","coach-notify"]}},"id":"assess-sampled-controls"},{"data":{"decisionField":"disposition_path","description":"Approve and publish the accurate version-controlled SoA and choose the clean, remediation or significant-risk path from its assessment and owned deficiencies.","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** — Approve and publish the accurate version-controlled SoA and choose the clean, remediation or significant-risk path from its assessment and owned deficiencies.\n\n**Inputs**\n- The reconciled applicability register, the assessment conclusions, and the routed deficiency list with owners.\n- The current SoA version and its approval history.\n- The approval authority (ISMS owner / management, per the governance model UC-GOV-15/16).\n\n**Procedure**\n_This checkpoint absorbs “Approve and publish SoA”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Approve and publish SoA: Update the SoA content: for each control set applicable status, justification, implementation status, and reference to related controls/procedures; annotate every control that has an open deficiency with its corrective-action reference.\n2. Version the SoA: increment the version, record the change summary (what applicability or status changed since the prior version and why), and preserve the prior version for the audit trail.\n3. Confirm completeness: every Annex A control has a decision and justification, every applicable control has an implementation status, and every deficiency is cross-referenced to a corrective action.\n4. Route for approval to the ISMS owner / management authority with the change summary and the assessment results; capture the approval decision, approver, and date.\n5. Publish the approved SoA to the controlled document location, supersede the prior version, and notify stakeholders.\n\n**Decision criteria**\n- `clean` (No reportable gap): all applicable controls assessed effective, or the only deficiencies were resolved within the review with validation evidence; the published SoA is accurate and no open gap needs a new action plan. Proceeds straight to the final package.\n- `remediate` (Remediation required): the assessment surfaced control deficiencies now tracked as corrective actions that need an owned remediation plan, and residual risk stays within appetite once remediation executes. Routes to build the action plan.\n- `escalate` (Escalate significant issue): a deficiency is a significant control failure, or residual risk exceeds appetite and needs an accountable authority (system owner, ISMS/authorizing authority) to direct remediation or formally accept the risk. Routes to escalate or accept the risk.\n\n**Record in AssureSwarm**\n- Attach the approved, version-controlled SoA (XLSX) and its change summary to this step (coach-document-upload). There is no native SoA item type, so the published SoA lives as this step document and its version lineage is the chain of archived step documents across cycles — the prior version is preserved on the earlier cycle's publish step.\n- Cross-reference the published SoA version and approval date in the anchor Audit item's description (coach-item-update), link the published SoA to its Controls and the corrective-action Issues that annotate it (coach-items-link), and notify stakeholders on publication (coach-notify).\n- Submit the `disposition_path` SELECT with the chosen branch value (`clean`, `remediate`, or `escalate`).\n- Record the decision rationale and evidence references in the step result, and name the decision owner or approver.\n\n**Exit criteria**\n- An updated, version-controlled SoA reflecting reconciled applicability, current status, and assessment results is approved by the accountable authority, published to the controlled location, and stakeholders are notified; the prior version is preserved.\n- The `disposition_path` form is submitted with a documented rationale and owner, and the two unused branches are prunable because their edge values match the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","note":"SoA finalization, management approval capture, and controlled publication","primitives":["coach-document-upload","coach-item-update","coach-items-link","coach-notify"]}},"id":"classify-disposition"},{"data":{"description":"Build an owned, dated remediation plan that closes the exposed control deficiencies","instructions":"**Objective** — Build an owned, dated remediation plan that closes the control deficiencies the assessment exposed and restores each affected control to its ISO/IEC 27002 objective.\n\n**Inputs**\n- The `remediate` disposition and its rationale.\n- The routed corrective-action items (deficiency, root cause, severity, owner) from the routing step.\n- Control/risk owners and the appetite thresholds remediation must satisfy (UC-RISK-14).\n\n**Procedure**\n1. For each deficiency, state the root cause, the corrective action that restores the control objective, and a named accountable owner — a person, not a team.\n2. Set a due date proportionate to severity; sequence dependencies between actions.\n3. Define interim mitigation for any deficiency that cannot be closed by its due date, so exposure is bounded meanwhile.\n4. Define the validation evidence that will prove each action effective — the specific control test that must pass on retest — and the reporting cadence to the owner and governance.\n5. Confirm the post-remediation residual risk lands within appetite; if it will not, flag the item for escalation instead.\n\n**Record in AssureSwarm**\n- Update each corrective-action Issue from the routing step with its remediation_plan (the corrective action, sequencing, and interim mitigation), management_response, and a target_remediation_date proportionate to severity — capturing the validation evidence (the specific control retest that must pass) in the remediation_plan; where one deficiency needs several discrete actions, open an additional linked Issue per action (coach-item-update, coach-item-create).\n- Link each action Issue ↔ its affected Control and Issue ↔ the Risk whose appetite it must satisfy (coach-items-link).\n\n**Exit criteria** — Every exposed deficiency has an owned, dated action with interim mitigation, validation evidence tied to a control test, and a reporting cadence; post-remediation residual risk is confirmed within appetite or flagged for escalation.","label":"Create action plan","performedBy":{"agent":"grc-artist","note":"owned remediation action-plan builder for exposed deficiencies","primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Bring a significant control failure or above-appetite residual risk to the accountable authority for a governed decision","instructions":"**Objective** — Bring a significant control failure or an above-appetite residual risk to the accountable authority for a governed decision — direct remediation or formally accept the risk — with a defensible decision memo.\n\n**Inputs**\n- The `escalate` disposition and its rationale.\n- Quantified impact and residual risk from the assessment (UC-RISK-14) and the appetite position the item touches.\n- The escalation path: control owner, ISMS/assessment lead, system owner, or authorizing authority per the governance model (UC-GOV-15/16).\n\n**Procedure**\n1. Prepare a decision memo: the deficiency, its quantified impact (operational, regulatory, contractual, financial), root cause, residual risk versus appetite, and the options with a recommendation.\n2. Quantify impact in the organization's own terms so the decision-maker can weigh it.\n3. Route to the correct authority by threshold and capture the decision — direction to remediate, formal risk acceptance with conditions, or further escalation.\n4. If risk is accepted, record the conditions, the acceptance owner, the expiry/review date, and the monitoring trigger that reopens it.\n5. Define follow-up ownership so the item does not stall after the decision.\n\n**Record in AssureSwarm**\n- Attach the decision memo (DOCX/PDF) to this step (coach-document-upload).\n- On a formal risk acceptance, set the affected Risk's treatment: accept, residual_rating, and risk_owner (coach-item-update), and record the acceptance conditions, the expiry/review date, and the monitoring trigger that reopens it in the Risk's description (there is no native acceptance-expiry field) and in the memo.\n\n**Exit criteria** — The memo is delivered, the accountable authority's decision (direction or conditioned acceptance) is recorded with owner and follow-up, and any acceptance carries an expiry and a monitoring trigger.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","note":"significant-issue escalation and risk-acceptance memo","primitives":["coach-document-upload","coach-item-update"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Judge the complete evidence and decision package and approve it or require specific revisions.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge the complete evidence and decision package and approve it or require specific revisions.\n\n**Inputs**\n- The reconciled applicability register, the evidence-completeness map, and the assessment workpapers.\n- The published SoA version and its change summary.\n- The routed corrective actions plus any action plan (remediate path) or decision memo / risk acceptance (escalate path), and the disposition decision with its owner.\n- Open constraints and residual risk outstanding at closure.\n\n**Procedure**\n_This checkpoint absorbs “Prepare final package”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Prepare final package: Compile the package: review summary and period, reconciled applicability, assessment conclusions by control, the deficiency list with dispositions, the published SoA version, the disposition decision with owner, and any action plan or risk-acceptance memo.\n2. Verify completeness against the review records — every applicable control assessed, every deficiency routed and dispositioned, every rationale present. A gap here is a rework signal, not a formatting nit.\n3. State residual risk and open constraints plainly, so the downstream reader and the archive both see what remains.\n4. Note explicitly what the downstream ISO 27001 Certification Readiness workflow should consume (the approved SoA, the assessment evidence, and the open corrective actions) and should NOT repeat — it prepares for certification; it does not re-run this assessment.\n5. Produce the proposed conclusion and route the package for approval.\n\n**Decision criteria**\n- `approved` (Approved): the package is complete, conclusions are supported by evidence, every deficiency has a disposition and owner, and residual risk is within appetite or formally accepted. Routes to record the approval.\n- `revise` (Revision required): evidence is missing, a conclusion is unsupported, a deficiency lacks a disposition or owner, or the reviewer requires changes before sign-off. Routes to resolve the conditions and re-submit.\n\n**Record in AssureSwarm**\n- Render and compile the package (PDF/XLSX) and attach it to this step and to the anchor Audit item (coach-render-package, coach-document-upload).\n- Link the package to the published SoA step document, the assessed Controls, and the corrective-action Issues (coach-items-link).\n- Submit the `approval_path` SELECT with the chosen branch value (`approved` or `revise`).\n- Record the decision rationale and evidence references in the step result, and name the approver.\n\n**Exit criteria**\n- A complete, verified evidence-and-decision package — with residual risk, open constraints, and the downstream-scope note — is attached and ready for approval.\n- The `approval_path` form is submitted with a documented rationale and approver, and the unused branch is prunable because its edge value matches the selected form value.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the reconciled applicability, assessment conclusions, deficiency dispositions, and published SoA into a single reviewable review package.","kind":"decision","label":"Approve or revise package","performedBy":{"agent":"grc-artist","note":"final evidence-and-decision package assembler","primitives":["coach-render-package","coach-document-upload","coach-items-link"]}},"id":"approve-or-revise-package"},{"data":{"description":"Address reviewer comments or approval conditions and document exactly what changed","instructions":"**Objective** — Address the reviewer's comments or approval conditions on the package and document exactly what changed, so the resubmission clears sign-off.\n\n**Inputs**\n- The `revise` decision with the reviewer's specific conditions or comments.\n- The final package and the underlying assessment records the conditions touch.\n- The owners of any evidence or conclusion that must change.\n\n**Procedure**\n1. Triage each condition: missing evidence, unsupported conclusion, undispositioned deficiency, or presentation gap.\n2. Resolve each: pull the missing evidence, revise the conclusion with support, assign and disposition the open deficiency, or correct the package.\n3. Re-run any affected completeness or effectiveness check so the change is validated, not merely asserted.\n4. Document what changed and why, mapping each change back to the specific condition, so the reviewer can confirm resolution quickly.\n5. Update the package and re-submit for the approval decision.\n\n**Record in AssureSwarm**\n- Attach the revised package and a change log mapping each reviewer condition to its resolution to this step (coach-document-upload).\n- Update the affected Control-hosted testing workflow results in place, and link the corrective-action Issues and affected Controls to the anchor Audit (coach-item-update, coach-items-link).\n\n**Exit criteria** — Every reviewer condition is resolved with evidence and documented in a change log tied to the original comments; the revised package is re-submitted for approval.","label":"Resolve approval conditions","performedBy":{"agent":"grc-artist","note":"reviewer-condition resolution and package revision","primitives":["coach-document-upload","coach-item-update","coach-items-link"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Acknowledge ownership of the approved SoA and assessment package, open corrections and residual risk within a clear certification-preparation scope.","instructions":"**Objective** — Acknowledge ownership of the approved SoA and assessment package, open corrections and residual risk within a clear certification-preparation scope.\n\n**Inputs**\n- The `approved` decision (or the re-approved package after conditions were resolved).\n- The approver identity, the date, and any conditions attached to the approval.\n- The open corrective actions and accepted risks that carry follow-up.\n- The approved, locked final package and the published SoA version, with the review record and all its linked evidence, decisions, and corrective actions.\n- The open corrective actions and any accepted risks (what readiness must track), plus risk-acceptance expiries and monitoring triggers still outstanding.\n- The linkage target: the ISO 27001 Certification Readiness workflow.\n- Records-retention requirements and the SoA review cadence for the next cycle.\n\n**Procedure**\n_This checkpoint absorbs “Record approval decision”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Record approval decision: Record the approver, approval date, and the exact scope of what was approved (the SoA version and the assessment package).\n2. Capture any conditions attached to the approval and the owner responsible for each.\n3. Confirm every open corrective action and accepted risk has a named owner and a follow-up/review date, so nothing is orphaned at sign-off.\n4. Set the review status to approved and lock the approved package version against further edits.\n5. Handoff to related workflow: Create or link the downstream ISO 27001 Certification Readiness workflow instance and attach the approved package as its input handoff.\n6. Carry forward what readiness needs: the approved SoA version, the assessment conclusions, the open corrective actions with owners and due dates, and residual risk — not the full evidence corpus.\n7. State the assumptions the package rests on and, explicitly, what the downstream workflow should not repeat — it prepares for certification; it does not re-assess these controls.\n8. Confirm the downstream owner has received and acknowledged the handoff so nothing is dropped at the boundary.\n9. Confirm the remaining closure preconditions: every deficiency is a tracked corrective action with an owner, and the disposition and the approval decision are recorded.\n10. Archive the final package and the approved SoA version and lock the review's evidence per retention policy so the audit trail is immutable (UC-AUDIT-21).\n11. Update linked records — set the review status to closed, confirm the published SoA is the current baseline, and update the controls and risks with the review outcome.\n12. Schedule the next SoA review per cadence, plus validation checkpoints for open corrective actions and review/expiry dates for accepted risks.\n13. Communicate closure and the next-review schedule to control owners, the ISMS owner, and the certification-readiness owner; that closure record on this step ends the review.\n\n**Record in AssureSwarm**\n- Update the anchor Audit item: set rating (satisfactory | needs_improvement | unsatisfactory), report_date, and record the approver, approval date, and any conditions in its description (coach-item-update).\n- Link the anchor Audit ↔ the published SoA step document, the open corrective-action Issues, and any accepted Risks (coach-items-link).\n- Link the approved package document to the downstream ISO 27001 Certification Readiness workflow instance as its input handoff, and link the open corrective-action Issues and the anchor Audit across the boundary (coach-document-link, coach-items-link).\n- Record the downstream owner's handoff acknowledgment and the carried-forward summary in the anchor Audit item's description.\n- Set the anchor Audit item's status to COMPLETED and archive/lock the compiled package and the published SoA step document per retention policy so the audit trail is immutable (coach-item-update, coach-document-upload).\n- Schedule the next cycle — there is no native scheduler object, so each cycle spawns a fresh Audit item and workflow instance per cadence — and link the outstanding corrective-action Issues and accepted-risk review dates to their owners (coach-items-link, coach-workflow-monitor).\n\n**Exit criteria**\n- The final approval is recorded with approver, date, conditions, and follow-up ownership; the review status is set to approved and the approved package is locked.\n- The approved package is linked to the ISO 27001 Certification Readiness workflow with a carried-forward summary and a no-repeat note and the downstream owner has acknowledged receipt; the review is closed with an immutable archived package and SoA version; the published SoA is the current baseline; the next review is scheduled; every open corrective action and accepted-risk review has a scheduled owner and date; closure is communicated.","label":"Handoff to related workflow","performedBy":{"agent":"grc-artist","note":"final approval recording and package lock downstream certification-readiness handoff","primitives":["coach-item-update","coach-items-link","coach-document-upload","coach-workflow-scan"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-iso27001-soa-review"}