{"description":"This instance runs against the Control item it creates: drafted at the objective step and committed to the Risk & Control Matrix (RCM) at record-the-control, so the archived instance is that control's design audit trail. It consumes no upstream workflow — a control is motivated by an existing Risk item or an audit Issue (finding/deficiency), which it links to rather than rebuilds. Design one new control end to end: control objective and attributes, risk mapping to the register, evidence and test-approach design, RCM record creation, disposition, packaging, and archival. The named deliverable is a new, uniquely identified control record in the RCM (a Control item) carrying a design determination statement, plus its test plan. In scope: designing and recording a single new control so it is operable and testable. Out of scope: executing the control's operating-effectiveness tests and remediating deficiencies, which are handed off downstream to the Security Control Assessment & POA&M Remediation workflow.","edges":[{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"action_required"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clear"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-15"],"department":"operations","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-design","contentDigest":"sha256:362c8362a87fd9c6ed9bbc66ac1f6bf55e7701d605a4f7fce99f08d6b1c1206f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:362c8362a87fd9c6ed9bbc66ac1f6bf55e7701d605a4f7fce99f08d6b1c1206f","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-design"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-design","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001"],"teams":["operations","risk-management"]},"name":"Control Design","nodes":[{"data":{"decisionField":"disposition_path","description":"Judge a complete, non-duplicative control design: objective and attributes, honest risk coverage, IPE-aware testability and the authoritative RCM determination.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Ready to close","value":"clear"},{"label":"Action required","value":"action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge a complete, non-duplicative control design: objective and attributes, honest risk coverage, IPE-aware testability and the authoritative RCM determination.\n\n**Inputs**\n- The authorization/system boundary the control protects, including the assets and data in scope. Where the boundary is a genuine auditable IT/security process it is an existing **Process item**; otherwise there is no native System/Boundary item type, so it arrives as a boundary-definition document uploaded at this step.\n- The framework requirement driving the control — the specific NIST 800-53 control it implements (e.g., AC-2 Account Management) and/or the ISO 27001 Annex A control (e.g., A.9 Access Control). This lives in the external standard; capture the exact identifier to persist onto the Control's `framework` and `family` fields.\n- The risk, audit finding, or design gap that motivated the control — an existing **Risk item** from the register or an **Issue item** (`issue_type` finding/deficiency), which this control links to rather than restates.\n- The proposed control owner (persisted to `control_owner`) and the operating team.\n- The existing control library (the RCM — the tenant's **Control items**), searched to confirm this control is not a duplicate.\n- The draft Control item (objective, `control_type`, `automation`) from the classify-disposition step.\n- The organization's risk register — the tenant's **Risk items** with their `taxonomies`, `domains`, and `risk_owner`.\n- The candidate risks' inherent ratings — `likelihood`, `impact`, and `inherent_rating` on those Risk items.\n- Any other **Control items** already linked to those risks, to judge reliance and overlap.\n- The draft Control item: `control_type`, `automation`, `frequency`, activity description, and system of record.\n- The population the control acts on, and whether it is system-generated (which creates an IPE completeness-and-accuracy dependency).\n- The org's sampling policy — a **Policy item** (`policy_type` standard/procedure) where one exists in the library.\n- Assessment-method standards uploaded at this step: NIST 800-53A (examine / interview / test) and the ISO 27001 internal-audit approach are external standards, so they arrive as documents on this step.\n- The draft Control item (objective and attributes) from the classify-disposition step.\n- The Control ↔ Risk mappings from the classify-disposition step.\n- The test-plan document (evidence inventory and test approach) from the classify-disposition step.\n- The existing Control library (the RCM) and its control-numbering convention — a **Policy item** (`policy_type` standard) or a step-referenced document.\n\n**Procedure**\n_This checkpoint absorbs “Define the control objective”, “Map to risks”, “Define evidence and test approach”, “Record the control”. 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. Define the control objective: Draft the control objective in one or two sentences: state the specific undesirable outcome the control prevents or detects, tied to the framework requirement. Example: \"Only authorized, provisioned accounts can reach the production boundary; unauthorized or orphaned accounts are detected and removed within one review cycle.\" Express it for this environment rather than restating the framework text verbatim.\n2. Classify the control type: preventive (stops the event), detective (identifies it after the fact), or corrective (remediates it). Access controls often pair a preventive activity with a detective review; if so, record both and mark which is primary.\n3. Classify the operating mode: automated (system-enforced, no human judgment), manual, or IT-dependent manual (a human acts on system-generated information). For IT-dependent manual, flag the report/IPE dependency, because the completeness and accuracy of that source must itself be controlled.\n4. Set the frequency: continuous, daily, weekly, monthly, quarterly, or annual. Frequency later drives sample sizing, so record the true operating cadence, not an aspiration.\n5. Write the control activity description: who does what, to which population, using which system, and what evidence the activity leaves behind. One paragraph, active voice, naming the system of record.\n6. Assign the accountable owner and the operator who performs the control — they may differ.\n7. Rate the control key vs non-key: key if its failure could allow a material undesirable outcome with no compensating control. Record the rationale.\n8. Confirm non-duplication: search the RCM for a control already meeting this objective; if one exists, stop and reconcile rather than create a redundant control.\n9. Map to risks: Identify each risk the control addresses from the risk register. Do not invent risks — link to existing register items, creating a new risk item only if a genuine gap exists (and flag it for the risk owner).\n10. For each risk, classify the control's role: primary mitigant, secondary/compensating, or monitoring. Record the assertion linkage (for access risk, typically confidentiality and integrity of the boundary).\n11. State the mitigation strength: how much of the inherent risk this control addresses (high/medium/low or a residual-risk delta) with a one-line justification. Be honest — a quarterly detective review does not fully mitigate a real-time access risk.\n12. Check for residual gaps: if the mapped controls together still leave material residual risk, note the gap and the compensating control (or its absence) so the risk owner can accept it or add controls.\n13. Check for over-control: if several controls redundantly cover the same risk with no added assurance, flag it for rationalization.\n14. Confirm the mapping is bidirectional — the risk item lists this control and this control lists the risk.\n15. Define evidence and test approach: Specify the evidence the control leaves: the artifact (ticket, log, approval record, review sign-off, exception report), where it lives, and its retention. If the control produces no durable evidence, redesign it — an untestable control is a design deficiency.\n16. Choose the assessment method(s): examine (documents/config), interview (operator), and test/reperform (re-execute the control). NIST 800-53A frames these; for a key control, plan to reperform, not merely inquire.\n17. Design the test of design (TOD): confirm that the control, if operating as described, would prevent or detect the risk. Write the specific attributes a reviewer checks.\n18. Design the test of operating effectiveness (TOE): define the population, the sample-sizing rule from frequency (standard buckets: daily to 25; weekly to 5-10; monthly to 2-5; quarterly to 2; annual to 1; increase 25-50% at elevated risk), the selection method (random / monetary-unit / judgmental with a stated reason), and the pass/fail attributes per item.\n19. Pre-commit the exception policy now, before any result exists: what counts as a deviation, and whether an exception expands the sample or stops for evaluation.\n20. For IT-dependent manual controls, add an IPE step: how the completeness and accuracy of the source report will be established.\n21. Record the control: Assemble the complete record: pull the objective, attributes, risk links, and test approach into one control record and verify nothing is left as a placeholder.\n22. Assign the control identifier per the RCM numbering convention and confirm it is unique.\n23. Verify internal consistency: the objective matches the mapped risks; the frequency matches the test sampling; the mode matches the assessment method (an automated control cited as manually reviewed is a contradiction to resolve).\n24. Confirm every cross-link resolves: boundary/system, risks, owner, and framework reference(s) (NIST 800-53 / ISO 27001 Annex A).\n25. Set the control lifecycle status (e.g., \"designed — pending first test\") and the effective date.\n26. Capture the design determination statement: one line concluding that the control, as recorded, addresses its objective and mapped risks.\n\n**Decision criteria**\n- **Ready to close** (`clear`): the control record is complete and internally consistent, its objective maps to register risks with adequate coverage, the test approach is defined and reperformable, and no open design gap or unaccepted residual risk remains. Nothing needs to happen before the control can go into operation.\n- **Action required** (`action_required`): a design gap remains — for example an untestable activity, missing IPE handling, an unmapped material risk, an unassigned owner, or residual risk the risk owner has not accepted. An owned action plan is needed before closure.\n\n**Record in AssureSwarm**\n- **Item create** — the draft **Control item**: `description` (objective + control-activity paragraph + the operator, since there is no separate operator field), `control_type` (preventive/detective/corrective), `automation` (automated / manual / hybrid — map IT-dependent manual to `hybrid`), `frequency`, `control_owner`, `key_control` (true/false with the rationale folded into `description`), `framework` (nist-800-53 and/or iso-27001), `family` (the framework control id, e.g. AC-2), `domains`, and `control_category`. Leave `control_id` for the classify-disposition step to assign per the numbering convention.\n- **Item relationship** — Control ↔ the motivating Risk (or Issue) item; and Control ↔ the boundary **Process item** where the boundary is a real process, otherwise attach the boundary-definition document to this step (no native System/Boundary type).\n- **Item relationship** — Control ↔ each mapped **Risk item** (the relationship is bidirectional, so this satisfies both directions of the RCM mapping).\n- Role (primary/secondary/monitoring) and mitigation strength have no link-level field in AssureSwarm, so record them in `Control.description` and in the test-plan document (they live there, not on the relationship).\n- **Item field update** — reflect honest coverage on each mapped Risk via `Risk.residual_rating`, and set `Risk.treatment: mitigate` where this control is the mitigant.\n- Where mapped controls still leave material residual risk that the risk owner accepts, set `Risk.treatment: accept` on that Risk and raise an **Issue** with `issue_type: policy_exception`, `exception_approver`, and `exception_expiry_date`, linked to the Risk. A genuinely new, unregistered gap becomes a **new Risk item** (Item create) flagged to its `risk_owner`.\n- **Step document** — a test-plan (DOCX or XLSX) attached to this step, capturing the evidence inventory, the assessment method(s), the TOD attributes, the TOE population / sample size and basis / selection method / pre-committed exception policy, and any IPE step. These have no native Control fields, so they live in the test-plan document rather than on the item; `Control.frequency` (already set) is what drives the sample sizing.\n- **Item field update** — finalize the Control item: assign `control_id` per the numbering convention, and confirm `description` (now carrying the one-line design determination statement), `control_type`, `automation`, `frequency`, `control_owner`, `key_control`, `framework`, `family`, `domains`, and `control_category` are all populated (no placeholders). The lifecycle state 'designed — pending first test' has no native field, so record it in `description` and via the item status.\n- **Item relationship** — confirm Control ↔ boundary (Process) and Control ↔ each Risk resolve live, and the framework references are set on `framework`/`family`.\n- **Step document** — re-attach the test-plan document to this step so the committed record carries it.\nSubmit the `disposition_path` SELECT with the chosen branch; record the decision rationale and evidence references in the step result; name the approver in the step's approver record.\n\n**Exit criteria**\n- The objective states a concrete prevent/detect outcome tied to a named framework control; `control_type`, `automation`, `frequency`, `control_owner`, and `key_control` are all set; the control is confirmed non-duplicative against the RCM; the draft Control item is created and linked to its boundary and motivating risk.\n- Every risk the control addresses is linked (Control ↔ Risk) to a register item; role and strength are captured on the control/test-plan; residual gaps carry an honest `residual_rating` and any acceptance is recorded as `treatment: accept` plus a policy_exception Issue; over-control is documented; mappings are bidirectional.\n- Evidence artifacts are named and locatable; TOD and TOE are documented with population, reproducible sample sizing, and a pre-committed exception policy; any IPE dependency has a completeness/accuracy step.\n- The Control item is complete, uniquely identified via `control_id`, internally consistent, fully linked, status-set, and carries a design determination statement in `description`.\n- The SELECT is submitted; the unused branch is prunable because its edge whenValue no longer matches the recorded value; rationale and owner are captured.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans the control's test of operating effectiveness and draws a reproducible, frequency-sized sample. `/coach-item-create` writes the control record and `/coach-items-link` binds it to its risks, boundary, and owner in one pass.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update","sox-testing","coach-form-create"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan to close the design gaps that blocked disposition","instructions":"**Objective** — Produce an owned, time-bound plan to close the design gaps that blocked disposition, so the control can reach an operable state.\n\n**Inputs**\n- The disposition decision rationale naming the specific gap(s), from the classify-disposition Step result (the step result).\n- The Control item and its open items (unmapped risk, IPE gap, missing owner, untestable activity).\n- Any remediation/POA&M policy governing due-date and severity conventions — a **Policy item** where the org maintains one.\n\n**Procedure**\n1. For each gap, state the root cause — the design shortfall itself, not the symptom.\n2. Define the corrective action that removes the root cause (e.g., add an automated exception report so a manual review becomes testable).\n3. Assign a single accountable owner and a due date per action, sizing the due date to severity.\n4. Specify interim mitigation if the control must operate before the gap closes, and record the added residual risk the risk owner accepts in the meantime.\n5. Define the validation evidence that will prove each action complete and the retest that confirms it.\n6. Set a reporting/tracking cadence and, if the org tracks POA&M items, assign a POA&M ID.\n\n**Record in AssureSwarm**\n- **Item create** — one **Issue item** per design gap: `issue_type: deficiency`, `source: self_assessment`, `severity`, `root_cause`, `remediation_plan` (the corrective action plus interim mitigation, validation evidence, retest, and any POA&M ID), `issue_owner`, `identified_date`, and `target_remediation_date`.\n- **Item relationship** — Issue ↔ Control for each gap.\n- Where the control must operate before a gap closes and the risk owner accepts the added residual risk, set `Risk.treatment: accept` on that Risk and raise a policy_exception **Issue** (`issue_type: policy_exception`, `exception_approver`, `exception_expiry_date`) linked to the Risk.\n- Scope these Issues strictly to design-gap fixes needed before the control is operable; operating-effectiveness remediation POA&Ms belong to the downstream Security Control Assessment & POA&M Remediation workflow — do not double-own them here.\n\n**Exit criteria** — Every disposition gap has a linked deficiency Issue with a root cause, single `issue_owner`, `target_remediation_date`, and validation evidence (plus a POA&M ID where used); interim mitigation and any accepted residual risk (`treatment: accept` + policy_exception Issue) are documented.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Accept receipt and ownership of the designed control and first operating-effectiveness test and POA&M responsibilities.","instructions":"**Objective** — Accept receipt and ownership of the designed control and first operating-effectiveness test and POA&M responsibilities.\n\n**Inputs**\n- The finalized control record and its links, from the classify-disposition step.\n- The disposition decision and rationale, from the disposition decision.\n- Any action-plan / POA&M items, if the control took the action-required branch.\n- The ready-for-handoff package document, from the handoff-to-related-workflow step.\n- The target workflow: Security Control Assessment & POA&M Remediation.\n- Any open deficiency Issues to carry forward.\n- Records-retention and archival policy, and the first-test / monitoring schedule to set.\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: control record, risk mappings, evidence inventory and test approach, disposition decision with rationale, and any action plan.\n2. State the proposed conclusion: the control is designed and either ready to operate or operable with tracked remediation.\n3. List unresolved constraints and accepted residual risks explicitly, with their owners — do not bury them.\n4. Note the assumptions the downstream assurance work should not re-litigate, and clearly mark what it must still do (the first operating-effectiveness test).\n5. Run a completeness check against the exit criteria of every prior step and fix any gap before packaging.\n6. Handoff to related workflow: Create or locate the Security Control Assessment & POA&M Remediation workflow instance for this control.\n7. Pass the package and link the control record so the downstream workflow reads the objective, attributes, risk mappings, and test approach rather than rebuilding them.\n8. State the assumptions carried forward and name explicitly what the downstream workflow must NOT repeat (control design, risk mapping) versus what it owns (the first TOE and POA&M closure).\n9. Confirm receipt and ownership on the downstream side and record the linkage both ways.\n10. Archive the final package and freeze the design artifacts (control record snapshot, decisions, evidence and test approach) per the retention policy.\n11. Update linked records: set the control status (e.g., \"designed — handed to assessment\") and refresh the risk-register links.\n12. Schedule the follow-up: the first operating-effectiveness test date and any ongoing monitoring cadence.\n13. Communicate the final design decision and hand-off to the control owner and stakeholders.\n14. Confirm the audit trail is complete and tamper-evident — who decided what, when, and on which evidence — before closing the run.\n\n**Record in AssureSwarm**\n- **Step document** — the assembled hand-off package (DOCX or PDF) attached to this step, bundling the Control record, risk mappings, evidence inventory and test approach, disposition decision with rationale, and any action plan. There is no native package-status field, so mark ready-for-handoff in the step note; the Control item remains the durable home the package references.\n- **Workflow instance** — create or locate the downstream Security Control Assessment & POA&M Remediation instance for this control, then close this run; the archived instance is the design audit trail (who decided what, when, on which evidence).\n- **Item relationship** — link the Control item to that downstream instance's subject so it reads the objective, attributes, risk mappings, and test approach rather than rebuilding them, and refresh the Control ↔ Risk relationships.\n- **Step document** — attach the hand-off package (frozen at closure) to this step and note the downstream owner. This package is the handoff payload the downstream workflow's first step consumes.\n- **Item field update** — set the Control's status and record 'designed — handed to assessment' in `description` (no native lifecycle field). The first-test date is noted on this step, as there is no native next-test scheduling field.\n\n**Exit criteria**\n- A single package captures the control record, decisions, evidence/test approach, action items, open constraints, and proposed conclusion; completeness is verified against every prior step's exit criteria.\n- The downstream Security Control Assessment & POA&M Remediation workflow is created/linked, holds the package, and has an accountable owner; the non-duplication boundary is recorded; the package is archived under the retention policy with control and risk records updated; the first test and monitoring cadence are scheduled; closure is communicated and the audit trail is complete and tamper-evident.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the control record, decisions, and evidence into a single hand-off package.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-design"}