{"description":"Perform an ISO 27005 information security risk assessment and treatment cycle for a defined ISMS scope. The recurring cycle instance attaches to the existing Process item (process_type=security_process) that represents the ISMS scope — enrich that item, never create a duplicate; the risk register it produces is the set of Risk items the run creates and updates. The cycle: establish context and risk criteria, identify information security risks, analyze and evaluate them against the criteria, select treatment options, draft the risk treatment plan, obtain residual-risk acceptance, and retain the documented information. In scope: risk identification through treatment planning and residual-risk acceptance for the ISMS boundary. Out of scope: the Statement of Applicability control-applicability determination and control operating-effectiveness testing, which are handled downstream. This workflow has no upstream workflow — its boundary and inventory are initial inputs: the in-scope business processes are existing Process items, while the asset/information inventory and risk criteria are uploaded documents (no native Asset type). It produces the named deliverables — the current risk register (Risk items), the Risk Treatment Plan (RTP), and the SoA inputs — handed off to the ISO 27001 SoA Review & Controls Assessment workflow.","edges":[{"id":"e-confirm-isms-scope-draft-treatment-plan","source":"confirm-isms-scope","target":"draft-treatment-plan"},{"id":"e-draft-treatment-plan-approve-residual-risk","source":"draft-treatment-plan","target":"approve-residual-risk"},{"id":"e-approve-residual-risk-classify-disposition","source":"approve-residual-risk","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Monitor","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-06","UC-RISK-07","UC-RISK-08","UC-RISK-09","UC-RISK-10","UC-RISK-04"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-isms-risk-assessment-treatment","contentDigest":"sha256:d28392c2f1ee0bffec0f16bf8935ffe4a883954a3dbec02d0f981ced07f5dcee","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:d28392c2f1ee0bffec0f16bf8935ffe4a883954a3dbec02d0f981ced07f5dcee","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-isms-risk-assessment-treatment"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-isms-risk-assessment-treatment","source":"coworkcanvas-gallery","standards":["iso-27001","iso-31000"],"teams":["it","risk-management"]},"name":"ISMS Risk Assessment & Treatment Cycle","nodes":[{"data":{"description":"Establish and lock the risk-assessment context, criteria, owners, and executable workplan for the ISMS boundary","instructions":"**Objective** — Establish and lock the risk-assessment context — boundary, asset/process inventory, risk criteria, risk-acceptance criteria, owners, and the executable workplan — so every downstream risk activity is scoped, criteria-driven, and defensible.\n\n**Inputs**\n- The ISMS scope statement and system boundary (in-scope sites, business processes, information systems, third parties): the ISMS scope itself is the existing Process item (process_type=security_process) this cycle attaches to, and the scope-statement is uploaded as a document at this step. This workflow has no upstream workflow — the boundary is an initial input.\n- Asset / information inventory and business-process catalogue for the boundary: the business processes are existing Process items linked to the run; the asset/information inventory has no native item type, so it is uploaded as a locked asset/process list document at this step.\n- Existing risk criteria and risk-acceptance criteria (impact scale, likelihood scale, risk appetite / acceptance thresholds), if the ISMS already defines them — uploaded as a criteria document (no native fields hold the scales).\n- The prior cycle's risk register and treatment plan, if this is a re-assessment: the prior register is the existing Risk items carrying last cycle's likelihood/impact/inherent_rating/residual_rating/treatment; the prior RTP is a document on the prior cycle's archived workflow instance, re-uploaded here if needed.\n- Named risk owner(s) recorded as Risk.risk_owner on each Risk item; the ISMS manager and the management sponsor who accepts residual risk assigned as step assignees on the workflow instance; the delegation-of-authority matrix uploaded here (also consumed at approve-residual-risk).\n\n**Procedure**\n1. Reconcile the ISMS boundary to the current certified/target scope: match the scope statement against the asset and process inventory and flag any system, site, or third party that is in the boundary but absent from the inventory — an unexplained gap voids completeness.\n2. Establish context per ISO 27005 Clause 7 / ISO 31000 Clause 5.3: internal and external context, interested parties, and the legal/regulatory/contractual obligations that constrain the risk criteria.\n3. Define or confirm the risk criteria: the likelihood scale, the consequence scale across confidentiality, integrity, and availability, and the method for combining them into a risk level (for example a 5x5 matrix). Record the exact scale definitions so scoring is repeatable.\n4. Define or confirm the risk-acceptance criteria: the residual-risk level at or below which management accepts a risk without further treatment, and the delegation of authority for who may accept risk above that level.\n5. Lock the executable workplan: the final in-scope asset/process list, the risk-owner assignment per area, evidence requirements, due dates, and the review/approval expectation for each downstream deliverable.\n\n**Record in AssureSwarm** — Step document: attach the scope statement, the locked asset/process list, and the criteria document (recording the likelihood scale, impact scale, 5x5 combination method, and acceptance thresholds) to this step — context, interested parties, obligations, and the scales have no native item fields, so they live in these documents. Item relationship: link the in-scope Process items to the workflow instance. Item field update: set Risk.risk_owner as each area's owner is assigned. Assign the ISMS manager and management sponsor as step assignees on the workflow instance.\n\n**Exit criteria** — Boundary reconciles to the inventory with zero unexplained gaps; likelihood, impact, and risk-acceptance criteria are documented and approved; every in-scope area has a named risk owner; workplan due dates and evidence requirements are set.","label":"Confirm ISMS scope"},"id":"confirm-isms-scope"},{"data":{"description":"Identify credible CIA scenarios, judge evidence-based risk levels and select feasible treatments with owned actions and justified SoA inputs.","instructions":"**Objective** — Identify credible CIA scenarios, judge evidence-based risk levels and select feasible treatments with owned actions and justified SoA inputs.\n\n**Inputs**\n- The locked scope (in-scope Process items), the asset/process inventory document, and the risk criteria document from the scope step's reviewed output.\n- Threat sources: an ISO 27005-style threat catalogue and known-vulnerability evidence (vulnerability-scan output, penetration-test reports) uploaded at this step; prior audit findings as existing Issue items (source=internal_audit | external_audit | penetration_test | vulnerability_scan); incident history, which has no native item type, uploaded as a document.\n- The existing controls inventory as Control items (framework includes iso-27001), so control absence or weakness can be identified as the vulnerability.\n- The risk register from the identification step's reviewed output.\n- The likelihood scale, impact scale, and risk-acceptance thresholds from the scope step.\n- Effectiveness evidence for existing controls, so likelihood/impact are scored as residual rather than inherent where controls already operate.\n- The evaluated, prioritized risk register (risks flagged \"requires treatment\") from the analysis/evaluation step's reviewed output.\n- The risk-acceptance criteria document and the control catalogue as Control items (the ISO 27001 Annex A reference set is the Control library; control_id = Annex A ID) for selecting controls.\n- Cost, feasibility, and resource constraints for candidate controls.\n\n**Procedure**\n_This checkpoint absorbs “Identify information security risks”, “Analyze and evaluate risks”. 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. Identify information security risks: Choose the identification approach per ISO 27005: asset-based (enumerate assets, then threats, then vulnerabilities) and/or event-based (enumerate risk scenarios directly). Record which approach and why.\n2. For each in-scope asset/process, enumerate credible threats (adversarial, accidental, environmental, structural) and the vulnerabilities each could exploit, using the threat catalogue and incident history so identification is repeatable rather than ad hoc.\n3. State each consequence in CIA terms: which of confidentiality, integrity, or availability is harmed and the business outcome (data breach, service outage, fraud, regulatory penalty).\n4. Assign each risk a unique ID and a risk owner — the party accountable for the risk, not the assessor.\n5. De-duplicate and normalize: merge scenarios that are the same risk under different labels, and confirm every material asset/process has been considered (record an explicit \"no credible risk\" where that is the conclusion).\n6. Analyze and evaluate risks: For each risk, assess likelihood on the defined scale, accounting for existing control effectiveness — a control that reliably operates lowers likelihood or impact, and the supporting evidence must be cited.\n7. Assess consequence/impact on the defined CIA scale; where a risk spans multiple assets, use the worst credible consequence.\n8. Combine likelihood and impact into the risk level using the agreed method (for example the 5x5 matrix) and record the computed level per risk.\n9. Evaluate each risk against the risk-acceptance criteria: mark it \"acceptable as-is\" (at or below the threshold) or \"requires treatment\" (above the threshold), citing the threshold applied.\n10. Prioritize the treat list by risk level and any regulatory/contractual driver so treatment effort targets the highest exposure first.\n11. Draft treatment plan: For each risk requiring treatment, select the ISO 27005 treatment option: modify/reduce (apply or strengthen controls), retain/accept (justify against the acceptance criteria), avoid (eliminate the activity or asset), or share/transfer (insurance, outsourcing). Record the option and its rationale.\n12. For \"modify\" risks, select the specific controls and map them to ISO 27001 Annex A control IDs where applicable; this control selection is the SoA input, so capture each selected control and the justification for its inclusion.\n13. Estimate the residual risk after each treatment by re-scoring likelihood/impact assuming the control operates, and confirm it lands at or below the acceptance threshold; if not, add further controls or escalate.\n14. Assign each treatment action an owner, a due date, the required validation evidence, and an interim mitigation for the exposure window.\n15. Compile the RTP as risk to option to control(s) to owner to due date to target residual level, and compile the SoA inputs list (selected and excluded controls, each with justification).\n\n**Record in AssureSwarm**\nItem create: one Risk item per identified risk (category, e.g. cyber_security; domains; risk_owner), with the threat, vulnerability, and CIA consequence stated in Risk.description — Risk has no native threat/vulnerability/CIA fields, so they live in the description. Item relationship: link each Risk to its Process item (the asset/process at stake — Risk↔asset collapses to Risk↔Process, there being no Asset type) and to any related existing Control item.\nItem field update per Risk item: Risk.likelihood and Risk.impact (scored on the fixed 4-level selects the org's scale maps onto), Risk.inherent_rating as the combined risk level, and the evaluation outcome via Risk.treatment (accept = acceptable as-is; mitigate | transfer | avoid = requires treatment). Priority rank has no native Risk field — record it in Risk.description or on the prioritized treatment-list document attached to this step.\nStep document: attach the Risk Treatment Plan (RTP, as XLSX) and the SoA-inputs list to this step. Item field update per treated Risk item: Risk.treatment (mitigate | accept | transfer | avoid), Risk.residual_rating (the target residual level), and Risk.risk_owner. Item relationship: link each Risk to the selected Control items. Per-action owner and due-date detail has no native Risk field (there is no Action item type) — it lives in the RTP document.\n\n**Exit criteria**\n- Every in-scope asset/process has been through identification; each risk has a unique ID, a stated threat-vulnerability-consequence, and a named owner; duplicates are resolved.\n- Every risk has a documented likelihood, impact, risk level, and an accept/treat evaluation tied to the acceptance threshold; the prioritized treatment list is produced.\n- Every \"requires treatment\" risk has a selected option with rationale; modify risks map to specific controls with SoA justification; each treatment has an owner, due date, and a target residual level at or below the acceptance threshold; the RTP and SoA inputs are compiled.","label":"Draft treatment plan"},"id":"draft-treatment-plan"},{"data":{"description":"Obtain authorized management acceptance of residual risk remaining after planned treatment","instructions":"**Objective** — Obtain documented management acceptance of the residual risk that remains after the planned treatment, from the authority whose delegation covers each residual risk level.\n\n**Inputs**\n- The Risk Treatment Plan with target residual levels from the treatment-plan step's reviewed output.\n- The risk-acceptance criteria and the delegation-of-authority matrix (who may accept which residual level).\n- Any residual risks above threshold that require explicit senior acceptance or further treatment.\n\n**Procedure**\n1. Assemble the residual-risk summary: for each risk, the pre-treatment level, the treatment applied, and the target residual level.\n2. Route each residual risk to the correct acceptor per the delegation matrix — routine residuals to the risk owner, elevated residuals to the ISMS manager or management sponsor.\n3. For any residual risk the acceptor will not accept, loop back by recording the required additional treatment (a note to revisit the treatment plan) rather than forcing acceptance.\n4. Capture, for each accepted residual risk, the acceptor identity, the date, the conditions of acceptance, and any monitoring trigger or review date.\n5. Confirm no residual risk is left ambiguous — every one is either accepted or explicitly returned for more treatment.\n\n**Record in AssureSwarm** — Item field update per accepted Risk item: set Risk.treatment=accept and Risk.residual_rating to the accepted residual level. Item create: raise a policy_exception Issue per accepted residual (issue_type: policy_exception, exception_approver = the acceptor, exception_expiry_date = the review/re-evaluation date, conditions of acceptance in description) and link it to the Risk — Risk carries no acceptor/date/conditions/review-date fields, so the exception Issue is their home. Step document: attach the approved residual-risk summary to this step. Any residual the acceptor will not accept is returned for more treatment (a note to revisit the treatment plan) rather than forced.\n\n**Exit criteria** — Every residual risk is either formally accepted by an authorized approver (with conditions and a review date recorded) or explicitly returned for additional treatment; no residual risk is unresolved.","label":"Approve residual risk"},"id":"approve-residual-risk"},{"data":{"decisionField":"disposition_path","description":"Judge whether the consistent, versioned risk report and treatment records are complete, need corrective action or require senior monitored-risk treatment.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge whether the consistent, versioned risk report and treatment records are complete, need corrective action or require senior monitored-risk treatment.\n\n**Inputs**\n- The final risk register, RTP, SoA inputs, and residual-risk acceptances from the preceding reviewed steps.\n- The organization's documented-information and retention convention (naming, versioning, retention period).\n\n**Procedure**\n_This checkpoint absorbs “Record documented information”. 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 documented information: Compile the risk assessment report: the methodology, the criteria used, the risk register with levels, the evaluation outcomes, and the assessment date and version.\n2. Finalize the Risk Treatment Plan as a controlled document with a version, an owner, and an approval reference to the residual-risk acceptances.\n3. Finalize the SoA inputs (selected and excluded controls with justification) for handoff to the ISO 27001 SoA Review & Controls Assessment workflow.\n4. Apply version control and retention metadata, and supersede the prior cycle's documents rather than deleting them so the trail is preserved.\n5. Verify internal consistency: every treated risk in the register appears in the RTP, and every RTP control appears in the SoA inputs.\n\n**Decision criteria**\n- `complete` — All risks are evaluated, every \"requires treatment\" risk has an accepted target residual level, and no residual risk sits above threshold without acceptance. Nothing further is owed; proceed straight to packaging.\n- `gaps` — One or more risks lack a treatment, a treatment lacks an owner or due date, or a residual risk was returned for additional treatment. An owned action plan is required before packaging.\n- `monitor` — The assessment is complete, but one or more residual risks sit above the routine-acceptance threshold and need senior escalation or a formal risk-acceptance decision with monitoring, rather than immediate remediation.\n\n**Record in AssureSwarm**\nStep document: upload the risk assessment report (DOCX/PDF), the finalized RTP, and the SoA-inputs document to this step, each carrying version and retention metadata. Item relationship / link: link these documents to the workflow instance and to the relevant Risk items.\nSubmit the `disposition_path` SELECT with the chosen value; in the step result cite the specific risks and evidence driving the choice; set the step's approver record to the accountable ISMS manager.\n\n**Exit criteria**\n- The risk assessment report, RTP, and SoA inputs are finalized, versioned, and retained; cross-references between register, RTP, and SoA are internally consistent; prior versions are superseded, not lost.\n- The routing selector is submitted and the step result contains a rationale, and the two unused branches are prunable because the branch edge whenValues match the selected value.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Produce an owned, scheduled action plan that closes the gaps identified at disposition","instructions":"**Objective** — Produce an owned, scheduled action plan that closes the gaps identified at disposition so every unresolved risk reaches an accepted residual state.\n\n**Inputs**\n- The disposition rationale identifying which risks or treatments are the gaps, from the disposition decision's reviewed output.\n- The risk register and RTP entries for the affected risks.\n\n**Procedure**\n1. For each gap, state the root cause: a missing treatment, an unassigned owner, an unaccepted residual, or missing validation evidence.\n2. Define the corrective action, the accountable owner, the due date, and the interim mitigation for the exposure window.\n3. Define the validation evidence that will prove closure: a re-scored residual at or below threshold, the control implemented, or the acceptance obtained.\n4. Set the reporting cadence and the escalation path to follow if a due date slips.\n5. Link each action back to its Risk item so closure updates the register.\n\n**Record in AssureSwarm** — Item create: one Issue item per gap (issue_type: deficiency or observation, source: self_assessment, root_cause, remediation_plan carrying the corrective action and interim mitigation, issue_owner, target_remediation_date; cadence and validation evidence noted in remediation_plan — there is no native cadence field). Item relationship: link each Issue to its Risk item and to this workflow instance.\n\n**Exit criteria** — Every disposition gap has an owned action with a due date, an interim mitigation, and defined validation evidence; all actions are linked to their risks.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Obtain a formal senior risk-acceptance decision or escalate above-threshold residuals held for monitoring","instructions":"**Objective** — For residual risks held for monitoring, either obtain a formal senior risk-acceptance decision or escalate to the authorizing owner, with conditions and monitoring defined.\n\n**Inputs**\n- The disposition rationale and the above-threshold residual risks from the disposition decision's reviewed output.\n- The delegation-of-authority matrix and the residual-risk summary.\n\n**Procedure**\n1. Prepare a decision memo per residual: the risk, the quantified impact, why it is above the routine threshold, and the treatment options considered.\n2. Route the memo to the correct authority per the delegation matrix (ISMS manager, system owner, or authorizing official).\n3. Capture the decision: formal acceptance with conditions and an expiry/review date, or a direction to treat that loops the risk into an action.\n4. Define the monitoring trigger and review date for any accepted residual so it is re-evaluated on schedule.\n5. Assign follow-up ownership so the accepted risk is not orphaned.\n\n**Record in AssureSwarm** — For a formal acceptance: Item field update Risk.treatment=accept and Risk.residual_rating, plus Item create a policy_exception Issue (issue_type: policy_exception, exception_approver = the authority, exception_expiry_date = the review date, conditions in description) linked to the Risk — the exception Issue holds the authority/date/conditions/review-date that Risk has no fields for. For a direction to treat: raise a deficiency/observation Issue (as at create-action-plan) that loops the risk into an owned action. Step document: attach the decision memo per residual to this step.\n\n**Exit criteria** — Every monitored residual has a documented decision (accept with conditions and a review date, or a direction to treat), a named authority, and an assigned follow-up owner.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The documented information (report, RTP, SoA inputs) — reached directly from the disposition decision on the `complete` path, or after action plans (`gaps`) or escalation/acceptance decisions (`monitor`).\n- Any action-plan items (gaps path) and escalation/acceptance memos (monitor path).\n- The reconciled final package (risk register, RTP, SoA inputs, acceptances) from the packaging step's reviewed output.\n- The retention/records convention and the monitoring/review schedule, including any risk-specific review dates set at acceptance.\n\n**Procedure**\n_After the preceding authorized decision, run the packaging, linkage, archival and carry-forward procedure automatically. No additional human approval is required._\n1. Prepare final package: Assemble the package: risk assessment report, risk register with final levels, RTP, SoA inputs, residual-risk acceptances, and open action plans with owners and dates.\n2. Reconcile: confirm every treated risk traces to an RTP entry and every RTP control traces to a SoA input; list any unresolved constraints or dependencies explicitly.\n3. State the proposed conclusion of the cycle and what the downstream SoA Review workflow should and should not repeat — it consumes these SoA inputs and must not re-identify risks.\n4. Verify all documents carry version and retention metadata and are linked to the workflow.\n5. Handoff to related workflow: Create or link the downstream ISO 27001 SoA Review & Controls Assessment workflow instance for this ISMS scope.\n6. Pass the SoA inputs (selected and excluded controls with justification) and the RTP as the handoff package.\n7. Note the assumptions and open constraints the downstream workflow must honor, and state explicitly what it should not repeat — risk identification and analysis are complete; it assesses control applicability and effectiveness.\n8. Confirm receipt or linkage so the handoff is traceable.\n9. Archive the final package and all constituent documents under the retention convention (versioned, immutable copy).\n10. Update linked records: Risk items to their final disposition, action items to their tracking owners, and the workflow status to closed.\n11. Schedule the next monitoring/review: the cycle cadence and any risk-specific review dates set at acceptance.\n12. Communicate the closure and final decisions to the risk owners, the ISMS manager, and the management sponsor; the ISMS manager's closure record on this step ends the cycle.\n\n**Record in AssureSwarm**\nAssemble the package document, attach it to this step, and link the constituent risk register, RTP, SoA inputs, and action items.\nLink the downstream workflow to this one; attach the handoff package; record the assumptions and the no-repeat note on the link. Workflow instance: set the workflow to closed and attach the archived package as the audit trail. Item field update: update linked Risk items to their final treatment/residual_rating and Issue items to their tracking owners. Step document: log the closure communication and the next review date as a note/document on this step — there is no native next-review-date field.\n\n**Exit criteria**\n- A single reconciled package exists with register, RTP, SoA inputs, acceptances, and open actions; cross-references are consistent; the proposed conclusion and downstream scope note are stated.\n- The downstream SoA Review workflow is created or linked with the handoff package attached, assumptions and no-repeat scope recorded, and linkage confirmed; the package is archived under retention; linked risk and action records are updated; the next review is scheduled; closure is communicated to stakeholders.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — compiles the risk register, RTP, SoA inputs, and acceptances into one reconciled package with linked evidence. `/coach-workflow-attach` creates or links the downstream SoA Review workflow and attaches the handoff package; `/coach-workflow-export` exports the closed cycle and its audit trail for archival; `/coach-notify` sends the closure and final-decision communication to stakeholders.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package","coach-workflow-attach","coach-workflow-export","coach-notify"]},"requiredApprovals":0},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-isms-risk-assessment-treatment"}