{"description":"One control, one record: intake, author, classify, link, publish, review, retire — the library that audit RCM and SOX scoping read from.","edges":[{"id":"e-publish-decision-periodic-review-attestation","label":"Publish","source":"publish-decision","target":"periodic-review-attestation","whenValue":"publish"},{"id":"e-publish-decision-rework-and-resubmit","label":"Rework","source":"publish-decision","target":"rework-and-resubmit","whenValue":"rework"},{"id":"e-rework-and-resubmit-periodic-review-attestation","source":"rework-and-resubmit","target":"periodic-review-attestation"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-16","UC-GOV-07","UC-AUDIT-25","UC-FIN-01","UC-BCDR-14"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-control-library-lifecycle","contentDigest":"sha256:a76117c6573b51cec4f270fddb377e68b43540928702251450b81533f50ac57a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a76117c6573b51cec4f270fddb377e68b43540928702251450b81533f50ac57a","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-control-library-lifecycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-control-library-lifecycle","source":"coworkcanvas-gallery","standards":["coso-ic","sox","iso-27001","nist-800-53"],"teams":["risk-management","finance"]},"name":"Control Library Lifecycle","nodes":[{"data":{"decisionField":"publish_path","description":"Control library owner with proposing owner and classification team: Judge whether a complete, nonduplicate control has accepted ownership, supported key/regional/SOX classifications and correct links before admitting it to the library.","formData":{"fields":[{"key":"publish_path","label":"Publish decision","options":[{"label":"Publish to library","value":"publish"},{"label":"Return for rework","value":"rework"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Obtain the owner’s proposal in native results, resolve duplication, draft and classify the control, and approve publication or require specific rework.\n\n**Decision criteria**\nInputs for preparation: - The proposer's description of the control activity: what it prevents or detects, who performs it, how often, and the evidence it leaves — recorded by the proposing owner in the native step result.\n- The triggering driver: a new risk, a policy requirement, an audit or SOX finding, a regulatory obligation, or a process change.\n- The current library slice for the same process/domain (search by process, owner, and keywords).\n- The approved intake proposal from intake within the publication checkpoint, with its dedup outcome and accepted owner.\n- The library's attribute conventions: description style, owner roles, frequency vocabulary (continuous/daily/weekly/monthly/quarterly/annually/ad hoc), preventive vs detective, manual vs automated.\n- The current ICFR scoping decisions (in-scope processes and financial-statement line items) when SOX classification is in play.\n- Regional/regulatory applicability notes from the compliance team.\n- The drafted and classified control record with its classification rationale.\n- The risk register, policy library, and process inventory slices relevant to this control.\n- The intake-stage dedup outcome, so a duplicate cannot be published as new.\n\n*Autonomous preparation incorporates Intake control proposal; Classify the control; Control library owner with proposing owner and classification team reviews the combined evidence.*\n1. Have the participating proposer record their own proposal in the native step result: control activity, purpose (prevent/detect what), performer role, frequency, evidence produced, the driver, the proposed owner, and expected SOX relevance. Do not author the proposal on the proposer's behalf — the description in their words is what the dedup screen and the record authoring during classification work from.\n2. Search the library for overlapping controls on the same process or risk. If an existing control already covers the objective, route the proposer to an UPDATE of that control instead of a new record — one control, one record.\n3. Confirm the proposed owner role exists and accepts ownership; a control without an accountable owner does not enter the library.\n4. Note whether the proposal is expected to be SOX-relevant (touches a financial-statement line item or ICFR process) — the classification step will settle it.\n5. Draft the control record: title (imperative, activity-first), description (what is done, by whom, how often, on what population), owner, frequency, preventive/detective, manual/automated, and the evidence the control produces (evidence_description).\n6. Keep the control id immutable once assigned — ids are never renumbered or reused; updates patch attributes on the same record.\n7. Write the test approach note: what a tester would inspect or reperform to conclude the control operated.\n8. Carry the draft as a proposed change, never a direct write — the library owner's publish decision is what admits it to the library.\n9. Set key vs non-key: key controls are the ones whose failure plausibly permits a material error to occur undetected — be conservative; key drives testing intensity.\n10. Set regional codes where the control applies only in specific jurisdictions.\n11. Set is_sox_relevant when the control supports an in-scope ICFR process or financial-statement line item; record the FSLI linkage that justifies the flag. This flag is set during ICFR scoping and reviewed each cycle — it routes the control into the SOX testing population.\n12. Record the rationale for each classification on the record — classifications without rationale do not survive review.\n13. Link each risk the control mitigates; a control with no risk linkage needs an explicit reason to exist — record that orphan justification on the record where it applies.\n14. Link the governing policy or policies the control implements.\n15. Link the operating process where the control runs.\n16. Where an audit universe entity or SOX cycle references the same process, confirm the linkage is visible from those views — the library is one graph with several lenses, not parallel lists.\n\n- `publish` (Publish to library) when: attributes complete and conventionally written; owner accepted; classifications carry rationale (and FSLI linkage when SOX-relevant); risk/policy/process links present or an orphan justification recorded; no unresolved duplicate.\n- `rework` (Return for rework) when: any attribute or rationale is missing, ownership is unaccepted, the record duplicates an existing control, a required link is absent without justification, or a classification looks wrong (for example key/non-key inconsistent with the risk it mitigates).\n\n**Record in AssureSwarm**\n- The proposer’s native result captures the control activity, its preventive or detective purpose, the performer role, the frequency, the evidence produced, the driver, the proposed owner and their acceptance, and expected SOX relevance.\n- The dedup-search outcome noted in the step result (new / duplicate-of / update-of), with a link to the driving item (risk, policy, issue, or process) when one exists.\n- One draft control item carrying the full attribute set and a stated test approach, submitted as a suggestion for the library owner to approve.\n- Classification fields proposed on the same record (key flag, regional codes, is_sox_relevant, FSLI linkage) with rationale text.\n- Propose the relationship links (control-to-risk, control-to-policy, control-to-process) on the record before deciding.\n- Submit the `publish_path` SELECT; record the rationale and the deciding library owner in the step result either way, and the step's approver record carries the owner.\n\nRecord in the native step result or attached source documents: The control activity: what is done, by whom, and on what population (control_activity); What the control prevents or detects if it operates as intended (control_purpose); Role that performs the control (performer_role); How often the control is performed (frequency); Evidence the control leaves behind that a tester could inspect (evidence_produced); What triggered this proposal (proposal_driver); Proposed accountable control owner, and confirmation they have accepted ownership (proposed_owner); Does the control touch a financial-statement line item or ICFR process? (expected_sox_relevance). Use native approvals for sign-off.\n\n**Exit criteria**\nJudge whether a complete, nonduplicate control has accepted ownership, supported key/regional/SOX classifications and correct links before admitting it to the library.\n- Owner proposal recorded and complete with owner and driver; dedup screen documented; disposition (new vs update) chosen.\n- Draft control record exists with every required attribute populated and a stated test approach; every classification set with a written rationale; SOX-relevant controls carry their FSLI linkage; the record is pending the publish decision.\nThe form is submitted and the unused branch is prunable because each branch edge value matches the selected value; every claimed mitigation or implementation is represented as a link, with no orphan control left without a stated justification.","kind":"decision","label":"Publish decision","performedBy":{"agent":"grc-artist","note":"intake + dedup screen is_sox_relevant is the ICFR scoping input","primitives":["coach-form-fill","coach-query-data","coach-item-update","coach-item-create","coach-items-link"]}},"id":"publish-decision"},{"data":{"description":"Fix the gaps the publish decision named and resubmit the record","instructions":"**Objective** — Close every gap the publish decision named — attributes, rationale, links, or dedup — and resubmit the record so the library only ever contains publishable controls.\n\n**Inputs**\n- The publish decision's rationale (what was missing or wrong).\n- The draft record and its pending suggestions.\n\n**Procedure**\n1. Address each named gap on the record: complete attributes, add classification rationale, fix links, or merge into the duplicate's record when the decision found one.\n2. If the rework materially changes the control's intent, re-confirm ownership with the named owner.\n3. Resubmit the corrected record as a new proposed change referencing the decision's rationale — never resubmit the identical proposal.\n\n**Record in AssureSwarm**\n- Corrected fields/links proposed on the control record, with the change note referencing the publish decision.\n\n**Exit criteria**\n- Every named gap closed and the corrected record pending approval.","label":"Rework and resubmit","performedBy":{"agent":"grc-artist","primitives":["coach-item-update","coach-items-link"]}},"id":"rework-and-resubmit"},{"data":{"description":"Named control owner with control library oversight: Attest actual current operation, resolve classification and linkage drift, and establish whether a stopped control can be retired without active dependencies.","instructions":"**Objective** — Schedule and perform the owner’s operating review, propose drift corrections and retire a ceased control only when dependency and successor checks permit it.\n\n**Inputs**\n- The published control record (owner, frequency, classification).\n- The library's review-cadence policy (for example key/SOX controls annually, others every two years, plus on process or organizational change).\n- The control record and its linked risks/policies/processes.\n- Operating evidence since the last review (test results, incidents, issues touching the control).\n- The owner’s native review result and approval.\n- The retirement driver (superseding control, decommissioned process, or retired risk).\n- The control's open linkages and any in-flight testing.\n\n**Procedure**\n*Autonomous preparation incorporates Schedule the periodic review; Archive a retired control; Named control owner with control library oversight reviews the combined evidence.*\n1. After publication is actually approved (including corrected proposals returned from rework), set review_cadence_months and the next review date per the cadence policy — key and SOX-relevant controls get the shortest cadence.\n2. Register the trigger-based reviews too: owner change, process change, incident or audit finding touching the control.\n3. Stand up the supervisory sweep over the library's review workflows so overdue reviews and unowned controls surface to the library owner without anyone remembering to look.\n4. Have the named control owner record their own native review and attestation: is the activity still performed, by that role, at that frequency, leaving that evidence? The attestation must come from the owner — an attestation completed on their behalf is not one.\n5. Re-confirm classifications — especially is_sox_relevant against the current ICFR scope — and the risk/policy/process links.\n6. Correct any drift the attestation reveals as proposed changes on the record; material redesigns route back through intake as a change proposal.\n7. Chase non-responders; a missed attestation escalates to the library owner rather than lapsing.\n8. Perform the retirement stages only when the review establishes that the control has ceased to operate because of a decommissioned process, superseding control or retired risk. Otherwise retain the active record and scheduled review. Before retirement, confirm nothing active depends on the control: no open issues, no in-flight tests, and a successor identified where the risk still needs mitigation.\n9. Archive the record (soft retire) — testing history, attestations, and links are preserved; the id is never reused or renumbered.\n10. Where a successor exists, link successor and predecessor so lineage is traceable.\n11. Notify the audit and SOX views that reference the control so their scoping picks up the change at the next cycle.\n\n**Record in AssureSwarm**\n- Cadence fields set on the record; the review schedule visible on the library view.\n- The named control owner’s native review result and approval capture whether the control still operates as described, the performer role and frequency in force today, the evidence it leaves and where it is retained, changes since the last review, the owner's signed attestation, and its date — that response is the attestation of record.\n- Drift corrections proposed on the control record, and the next review date advanced on it.\n- The record archived with the retirement rationale; successor linkage recorded when one exists.\n\nRecord in the native step result or attached source documents: Does the control still operate exactly as the record describes? (still_operating_as_described); Role that performs the control today (performer_role_confirmed); Frequency the control is performed at today (frequency_confirmed); Evidence the control leaves today, and where it is retained (evidence_confirmed); Changes since the last review: owner, process, systems, population, or scope (changes_since_last_review); I attest that the record matches how this control operates, to the best of my knowledge (owner_attestation); Date of attestation (attestation_date). Use native approvals for sign-off.\n\n**Exit criteria**\nAttest actual current operation, resolve classification and linkage drift, and establish whether a stopped control can be retired without active dependencies.\n- Next review date set; overdue-review monitoring in place.\n- Attestation submitted by the owner and recorded; record matches operating reality; next review date advanced; non-responses escalated to the library owner.\n- If retired, control history remains intact and dependents are re-pointed or consciously closed; otherwise the active control retains its next review date.","label":"Periodic review and attestation","performedBy":{"agent":"grc-artist","note":"supervisory sweep = the workflow monitor","primitives":["coach-item-update","coach-workflow-scan","coach-form-fill","coach-items-link"]}},"id":"periodic-review-attestation"}],"sourceTemplateId":"workflow-library:grc-control-library-lifecycle"}