{"description":"Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.","edges":[{"id":"e-recertify-and-decide-disposition-process-revocations-and-separate-accounts","label":"Exceptions found","source":"recertify-and-decide-disposition","target":"process-revocations-and-separate-accounts","whenValue":"exceptions_found"},{"id":"e-recertify-and-decide-disposition-close-and-archive","label":"Certified clean","source":"recertify-and-decide-disposition","target":"close-and-archive","whenValue":"certified_clean"},{"id":"e-process-revocations-and-separate-accounts-close-and-archive","source":"process-revocations-and-separate-accounts","target":"close-and-archive"},{"id":"e-update-role-and-attribute-model-close-and-archive","source":"update-role-and-attribute-model","target":"close-and-archive"},{"id":"e-update-role-and-attribute-model-spot-test-enforcement-across-estate","source":"update-role-and-attribute-model","target":"spot-test-enforcement-across-estate"},{"id":"e-spot-test-enforcement-across-estate-log-remediation-actions","label":"Gaps found","source":"spot-test-enforcement-across-estate","target":"log-remediation-actions","whenValue":"gaps_found"},{"id":"e-spot-test-enforcement-across-estate-close-and-archive","label":"Enforcement verified","source":"spot-test-enforcement-across-estate","target":"close-and-archive","whenValue":"enforcement_verified"},{"id":"e-log-remediation-actions-close-and-archive","source":"log-remediation-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-04","UC-ACCESS-05"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-privileged-access-authorization-model-management","contentDigest":"sha256:929cca1040eecb0875f57a15e62e68431ed65478947bd97305d9eb7d9d79544f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:929cca1040eecb0875f57a15e62e68431ed65478947bd97305d9eb7d9d79544f","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-privileged-access-authorization-model-management"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-privileged-access-authorization-model-management","source":"coworkcanvas-gallery","standards":["iso-27001","nist-800-53","nist-csf-2","gdpr"],"teams":["it"]},"name":"Privileged Access & Authorization Model Management","nodes":[{"data":{"decisionField":"recertification_disposition","description":"Agent compiles and enriches the full privileged-account population across IAM/PAM systems, runs the recertification attestations, and checks separate-account distinctness; human decides whether the population is certified clean or exceptions require remediation","formData":{"fields":[{"key":"recertification_disposition","label":"Recertification Disposition","options":[{"label":"Certified clean, no exceptions","value":"certified_clean"},{"label":"Exceptions found","value":"exceptions_found"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Build the complete privileged-account population, recertify every account against its business justification and time bound, confirm administrators hold separate accounts distinct from their daily-use identity, and decide — owned by the IAM Operations Lead — whether the population is certified clean or exceptions require remediation.\n\n**Inputs**\n- The anchor privileged-access Control item in the control library (control_id UC-ACCESS-04, with UC-ACCESS-05 linked) whose operating cycle this instance is — read for scope, framework, and the linked Risk context.\n- The in-scope privileged-account population for this quarterly cycle: standing and just-in-time privileged grants across IAM, PAM, and directory systems for the covered applications, databases, and infrastructure — pulled live from those external systems (AssureSwarm holds no per-account item; there is no Account type).\n- Each account's on-file business justification, granted date, time-bound expiry, and assigned holder, from the same IAM/PAM records.\n- The prior cycle's inventory register — the inventory-register XLSX on the previous quarter's archived workflow instance — and any carryover exceptions, which are the still-open Issue items (issue_type: exception) from the prior cycle linked to the anchor Control.\n- The account owners and sponsoring managers who must answer the recertification attestations.\n- This step starts from the standing account stores and the anchor Control; no other workflow step feeds it. (Control references: NIST CSF PR.PS-05; ISO 27001 A.8.2, A.8.18; NIST 800-53 AC-3, AC-6.)\n\n**Procedure**\n_Items 1–9 are agent-run (items 1–5 folded from the former \"Compile privileged account inventory\" step); the human moment is the disposition call in item 10._\n1. Pull the full privileged-account population from IAM, PAM, and directory systems with coach-query-data, covering both standing grants and just-in-time or time-boxed elevation records. Reconcile the three sources against each other: an account present in the directory as privileged but absent from PAM (or the reverse) is itself a finding.\n2. Enrich each account with its business justification on file, granted date, time-bound expiry (flag if unbounded), assigned human holder, and an account-type flag distinguishing a dedicated privileged account from a shared or daily-use identity that carries privileged rights.\n3. Flag every account that is missing a business justification, missing a time bound, unowned or orphaned (no active holder), or shared across multiple humans. These become the recertification exception candidates.\n4. Capture one row per privileged account in the inventory register — account, holder, business justification, granted date, time-bound expiry, account-type flag, and the exception flags — since the eight-type schema has no native Privileged Account item; the register is the row-level system of record.\n5. Compile the inventory register (counts by system, by account type, and by flag) and attach it with coach-document-upload. Every privileged account across all in-scope systems must appear exactly once before packets go out — a partial export voids the cycle.\n6. Use existing sponsor recertification records where current. For missing continued business need or expiry, create a short request with coach-form-create for the account sponsor or manager outside the IAM execution team; prefill the known account inventory and request only those missing facts.\n7. Distribute the attestations and track completion with coach-workflow-scan, escalating non-responders ahead of the cycle deadline.\n8. Compile responses with coach-query-data, classifying each account as renewed, not renewed, or expired, and separately flag any account where privileged rights ride on a daily-use identity.\n9. Draft the recertification summary listing every exception with its type and attach it with coach-document-upload.\n10. IAM Operations Lead: pick the disposition against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- Choose **certified_clean** only when every privileged account in the inventory was recertified by its owner or manager, each carries a current business justification and an appropriate time bound, and every administrator's privileged rights sit on a dedicated account distinct from their daily-use identity — zero exceptions.\n- Choose **exceptions_found** when any account was not renewed by its sponsor, has passed or lacks a time bound, remains unjustified, or violates the separate-account requirement (privileged rights riding on the same identity used for daily work). A single unresolved exception forces this branch.\n\n**Record in AssureSwarm**\n- Step form — submit the `recertification_disposition` SELECT (certified_clean or exceptions_found); record the decision rationale with evidence references in the step result and the approver in the step's approver record.\n- Step documents — the inventory register (XLSX, one row per privileged account with the flag columns missing-justification, unbounded, orphaned, and shared) and the recertification summary listing every exception with its type, both attached to this step (coach-document-upload). There is no native Privileged Account item type, so the register rows are the honest home for per-account records rather than one item each.\n- No exception Issue items are opened here; flagged accounts are exception candidates that become Issue items at the revocation step on the exceptions_found branch. The exceptions_found branch routes to revocation and separate-account remediation; certified_clean drains straight to cycle close.\n\n**Exit criteria** — Every privileged account across all in-scope systems appears exactly once in the inventory with no orphaned, undocumented, or unowned account unaccounted for; the register and the recertification summary are attached; the `recertification_disposition` field is submitted with a rationale and named owner; the unused branch is prunable.","kind":"decision","label":"Recertify accounts and decide disposition","performedBy":{"primitives":["coach-form-create","coach-workflow-scan","coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"recertify-and-decide-disposition"},{"data":{"description":"Agent revokes lapsed privileged access and splits shared identities into distinct privileged and daily-use accounts; human confirms every exception is resolved","instructions":"**Objective** — Resolve every recertification exception so no unjustified, expired, or improperly shared privileged account remains active after the cycle.\n\n**Inputs**\n- The recertification summary and its exception list from the recertify-and-decide-disposition decision, reached only on the exceptions_found branch: non-renewed accounts, expired or missing time bounds, and separate-account violations.\n- The privileged-account inventory items to update.\n- Change-management and de-provisioning tooling for revocation and new-account issuance. (Control references: ISO 27001 A.8.2; NIST 800-53 AC-2, AC-6.)\n\n**Procedure**\n1. Pull the exception list with coach-query-data, bucketed into (a) non-renewed or expired access to revoke and (b) separate-account violations to split.\n2. Open one Issue per confirmed exception with coach-item-create — issue_type: exception, source: management_identified, severity set to the account's risk, issue_owner, and identified_date — and link each Issue to the anchor Control with coach-items-link. For each non-renewed or expired account, revoke or downgrade the privileged access and capture the account, action taken, timestamp, and actor as a row in the revocation-and-remediation log.\n3. For each separate-account violation, initiate issuance of a dedicated privileged account distinct from the individual's daily-use identity, migrate the privileged entitlements onto it, strip the elevated rights from the daily-use identity, and record the remediation on the same log row and its Issue.\n4. As each exception is resolved, set actual_remediation_date (and verified_date once confirmed) on its Issue, and re-attach the inventory register as a new revision reflecting closed entries and newly issued separate accounts — the register rows, not items, are the per-account record.\n5. Attach the consolidated revocation-and-remediation log with coach-document-upload.\n\n**Record in AssureSwarm**\n- Item create — one Issue per exception (issue_type: exception, source: management_identified, severity, issue_owner, identified_date) (coach-item-create).\n- Item relationship — each exception Issue linked to the anchor Control (coach-items-link).\n- Item field update — actual_remediation_date and verified_date set on each Issue as it closes.\n- Step document — the consolidated revocation-and-remediation log, plus the revised inventory register reflecting the end state (coach-document-upload); account-level revocation/issuance rows live in the log because there is no native privileged-account item type.\n\n**Exit criteria** — Every exception on the list is resolved — access revoked or downgraded, or a compliant separate account issued and the daily-use identity de-privileged — with a linked record, and the inventory reflects the closed-out state.","label":"Process revocations and separate accounts","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"process-revocations-and-separate-accounts"},{"data":{"description":"Review unauthorized or unlogged utility use, policy-approved allowlist changes and organizational role/attribute changes as one authorization package.","instructions":"**Objective** — Review unauthorized or unlogged utility use, policy-approved allowlist changes and organizational role/attribute changes as one authorization package.\n\n**Inputs**\n- The logged usage history for every control-overriding utility program in the cycle period: data-editing utilities, direct database override tools, and OS-level bypass utilities.\n- The current authorized-administrator list for those utilities.\n- System change and session records for corroboration. This step starts from these standing logs; no other workflow step feeds it. (Control references: ISO 27001 A.8.18; NIST 800-53 AC-6, AU-2, AU-6.)\n- The queue of pending application-allowlist change requests: additions, removals, and vendor or version updates, each with a requester and approval evidence — pulled live from the allowlist tooling / ITSM queue.\n- The software-approval policy defining what may be allowlisted and who approves — the Policy item in the policy library (policy_type: policy or standard, policy_owner), read as the governing reference.\n- Allowlist-control detection logs from managed endpoints. This step starts from the change queue and the governing Policy; no other workflow step feeds it. (Control references: ISO 27001 A.8.19; NIST 800-53 CM-7, CM-10, SI-7.)\n- The current role and security-attribute definitions and their mappings to sensitive data, source code, and administrative functions — the authorization-model document from the prior quarter's archived workflow instance (there is no native Role item type).\n- This quarter's organizational changes: joiners, movers, leavers, new systems, reorganizations, and decommissioned roles — pulled live from the HR and identity system of record.\n- The HR and identity system of record for organizational-change events. This step starts from the prior model document and org-change feed; no other workflow step feeds it. (Control references: ISO 27001 A.8.3, A.8.4; NIST 800-53 AC-3, AC-16, AC-24.)\n\n**Procedure**\n_This checkpoint absorbs “Review utility program usage”, “Process application allowlist changes”. 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. Review utility program usage: Confirm that utility programs capable of overriding system or application controls were used only by authorized administrators and that every use was logged, capturing any anomaly as a tracked exception.\n2. Pull the logged usage history for every control-overriding utility program with coach-query-data across the cycle period.\n3. Cross-reference each logged use against the current authorized-administrator list; flag any use by an identity not on that list as an unauthorized-use exception.\n4. Independently check system change and session records for evidence of utility-program invocation with no corresponding usage-log entry — unlogged use is a control failure even by an authorized admin. Open one Issue per anomaly with coach-item-create (issue_type: exception, source: management_identified, severity, issue_owner, identified_date) and link each to the anchor Control with coach-items-link, citing the source log or session record in the Issue description.\n5. Assess whether the logging control itself is complete and tamper-evident — were logs disabled or gapped during the period — and open a coverage-gap Issue the same way.\n6. Compile the utility-usage review register (uses by utility, by admin, and exceptions) and attach it with coach-document-upload.\n7. Process application allowlist changes: Keep the application allowlist current so unauthorized software stays blocked from installation and execution on managed systems, with every change properly approved.\n8. Pull the pending allowlist change queue with coach-query-data.\n9. Validate each request against the governing software-approval Policy item: confirmed business need, named approver, and evidence of approval. Reject or hold any request lacking approval; never execute an unapproved change.\n10. Execute the approved changes in the allowlist tooling, then capture one row per request in the allowlist change log — request, requester, approval evidence, and action taken — since the schema has no native change-request item type; the log rows are the per-change record.\n11. Scan managed endpoints with coach-workflow-scan for execution or installation attempts blocked or flagged by the allowlist control since the last cycle; compile the detections and open an Issue with coach-item-create (issue_type: observation, source: management_identified, severity, issue_owner, identified_date) for any that indicate attempted use of unauthorized software, linking each to the anchor Control with coach-items-link.\n12. Compile the allowlist change log plus the blocked-execution detection summary and attach it with coach-document-upload.\n13. Update role and attribute authorization model: Maintain the role and security-attribute authorization model that enforcement points rely on, keeping role definitions and attribute mappings current with this quarter's organizational change.\n14. Pull the current role and attribute definitions and the quarter's organizational-change events with coach-query-data.\n15. For each change, determine the model impact: a mover may need role reassignment, a decommissioned function may orphan a role, and a new system may require new roles or security attributes to represent access to sensitive data, source code, or administrative functions.\n16. Draft the updated role definitions and attribute mappings, retiring roles no longer backed by an organizational function and adding those newly required. Check for toxic combinations (segregation-of-duties conflicts) introduced by the changes.\n17. Record each changed role definition and attribute mapping as an entry in the authorization-model document — the model of record between cycles — since the schema has no native Role item type. Open an Issue with coach-item-create (issue_type: exception, source: self_assessment, severity, issue_owner, identified_date) for any unresolved SoD conflict and link it to the anchor Control with coach-items-link.\n18. Compile the updated authorization-model document (role catalog, attribute mappings, change log) and attach it with coach-document-upload.\n\n**Record in AssureSwarm**\n- Item create — one Issue per anomaly (issue_type: exception, source: management_identified, severity, issue_owner, identified_date) (coach-item-create).\n- Item relationship — each anomaly Issue linked to the anchor Control (coach-items-link).\n- Step document — the utility-usage review register attached to this step (coach-document-upload).\n- Step document — the allowlist change log (one row per change request, no native change-request item type) plus the blocked-execution detection summary, attached to this step (coach-document-upload).\n- Item create — one Issue per unauthorized-software detection warranting follow-up (issue_type: observation, source: management_identified) (coach-item-create).\n- Item relationship — each detection Issue linked to the anchor Control (coach-items-link).\n- Step document — the updated authorization-model document (role catalog, attribute mappings, change log) attached to this step (coach-document-upload); role definitions live as entries here because there is no native Role item type.\n- Item create — one Issue per unresolved SoD conflict (issue_type: exception, source: self_assessment) (coach-item-create).\n- Item relationship — each SoD Issue linked to the anchor Control (coach-items-link).\n\n**Exit criteria**\n- Every logged utility-program use is matched to an authorized administrator, no unlogged use remains unexplained, and every anomaly is captured as a linked exception item before the cycle closes.\n- Every executed allowlist change traces to a policy-compliant approval, no unapproved change was applied, and the blocked-execution detections are triaged with follow-ups noted before closing this control area.\n- The role and attribute model reflects every relevant organizational change, no role is left without a backing function, SoD conflicts are resolved or flagged, and the approved model is attached so it can be relied on for the enforcement spot tests.","label":"Update role and attribute authorization model","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-workflow-scan"]}},"id":"update-role-and-attribute-model"},{"data":{"decisionField":"enforcement_test_disposition","description":"Agent samples applications, databases, and infrastructure and executes enforcement spot tests against the updated model; human decides whether enforcement is verified or gaps exist","formData":{"fields":[{"key":"enforcement_test_disposition","label":"Enforcement Test Disposition","options":[{"label":"Enforcement verified","value":"enforcement_verified"},{"label":"Gaps found","value":"gaps_found"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide — owned by the IAM Operations Lead — whether enforcement points across applications, databases, and infrastructure consistently apply the approved authorizations from the updated role and attribute model, or whether gaps exist that require remediation.\n\n**Decision criteria**\n- Choose **enforcement_verified** when every sampled enforcement point mediated access through the enforcement mechanism, could not be bypassed or disabled through an unprivileged path, and granted access only to identities explicitly authorized under the current role and attribute model — no failures.\n- Choose **gaps_found** when any sampled point failed to enforce, was bypassable, granted access to an unauthorized identity, or left the enforcement mechanism disablable. Even one failure forces this branch.\n\nBefore deciding, the agent runs: (1) select a representative sample of applications, databases, and infrastructure components covering sensitive data stores, source code repositories, and administrative functions with coach-query-data, weighted toward components that changed this quarter; (2) execute spot tests against each sampled component with coach-workflow-scan, confirming access is mediated by the enforcement mechanism, that the mechanism is always invoked and tamper-resistant, and that only identities authorized under the current model gain access; (3) record a pass or fail per test as a row in the enforcement test log — component, authorization checked, and evidence — since the schema has no honest per-component result type (a Control-hosted SOX testing workflow is per-control-per-fiscal-year ICFR granularity, not per-component quarterly self-testing); (4) build a results dashboard with coach-dashboard-create and attach the full test log with coach-document-upload.\n\n**Record in AssureSwarm**\n- Step form — submit the `enforcement_test_disposition` SELECT (enforcement_verified or gaps_found); record the rationale citing evidence references in the step result and the approver in the step's approver record.\n- Step document — the full enforcement test log (XLSX), one row per test (no native per-component result item type), attached to this step (coach-document-upload).\n- Dashboard — the enforcement-results dashboard built at this step (coach-dashboard-create).\n- Confirmed gaps become corrective-action Issues at the log-remediation step; the gaps_found branch routes to remediation logging while enforcement_verified drains to cycle close.\n\n**Exit criteria** — The results dashboard and test log are attached, the `enforcement_test_disposition` field is submitted with a rationale and named owner, and the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans and executes the enforcement spot tests against the sampled components and records reperformable pass-or-fail evidence for each authorization checked.","kind":"decision","label":"Spot-test enforcement across the estate","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-item-create","coach-items-link","coach-dashboard-create","coach-document-upload","sox-testing"]}},"id":"spot-test-enforcement-across-estate"},{"data":{"description":"Agent converts every enforcement gap into an owned corrective action; human confirms nothing is left untracked","instructions":"**Objective** — Convert every enforcement-test gap into an owned, tracked corrective action so no failure in privileged-access or authorization-model enforcement goes unaddressed.\n\n**Inputs**\n- The failed enforcement tests from the spot-test-enforcement-across-estate decision, reached only on the gaps_found branch: each with tested component, authorization checked, and failure evidence.\n- Optionally, open exception items the reviewer elects to consolidate here; utility-usage anomalies and allowlist detections are otherwise tracked to closure at their own steps.\n- The corrective-action or issue register and its ownership model. (Control references: ISO 27001 A.5.36; NIST 800-53 CA-5, PL-2.)\n\n**Procedure**\n1. Pull every failed enforcement test with coach-query-data, plus any open exception the reviewer has chosen to consolidate here rather than close inline at its originating step.\n2. Create one Issue per gap with coach-item-create — issue_type: deficiency (finding for the most serious), source: self_assessment, root_cause, issue_owner, target_remediation_date, and severity — recording interim mitigation in remediation_plan; link each Issue to the anchor Control with coach-items-link (and to any consolidated open exception Issue as related).\n3. Escalate any gap touching sensitive data, source code, or administrative-function access to the accountable security owner ahead of the standard due date — these are the highest-severity enforcement failures.\n4. Set severity and target_remediation_date consistent with the organization's issue-management SLA (for example, a critical enforcement bypass remediated within days, lower-risk role drift within the next cycle).\n5. Attach the remediation register with coach-document-upload.\n\n**Record in AssureSwarm**\n- Item create — one Issue per gap (issue_type: deficiency or finding, source: self_assessment, root_cause, issue_owner, target_remediation_date, severity, remediation_plan) (coach-item-create).\n- Item relationship — each corrective-action Issue linked to the anchor Control, and to any consolidated open exception Issue as related (coach-items-link).\n- Step document — the remediation register attached to this step (coach-document-upload).\n\n**Exit criteria** — Every enforcement gap (and any consolidated open exception) has a named owner, due date, and severity; high-risk gaps are escalated; and nothing is left untracked before the cycle closes.","label":"Log remediation actions","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-remediation-actions"},{"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- All cycle deliverables draining into this step: the recertification summary and disposition, the revocation and separate-account log (if the exceptions branch ran), the utility-usage review register, the allowlist change log and detections, the updated authorization-model document, the enforcement test results and dashboard, and the remediation register (if the gaps branch ran).\n- The designated evidence repository and its retention controls.\n- The control execution log for metrics. (Control references: ISO 27001 A.5.36; NIST 800-53 AU-11, CA-7.)\n\n**Procedure**\n1. Export the full operating record with coach-workflow-export — recertification sign-offs, the utility-usage review, allowlist change records, the updated role and attribute model, and the enforcement test results — and archive it in the designated evidence repository under retention controls.\n2. Confirm every parallel thread has drained: recertification disposition recorded, utility review closed, allowlist changes applied, model updated, enforcement tested, and any open corrective actions assigned. Nothing may close with an untracked exception.\n3. Leave every open corrective-action and exception Issue open as the cross-cycle carry-forward — each already carries its target_remediation_date and its link to the anchor Control, so the next quarterly instance on that same Control picks them up; record the next scheduled recertification and enforcement-testing dates in the closure record document. Where the reviewer needs an explicit tracking item for a next-cycle commitment with no existing Issue, create one with coach-item-create and link it to the anchor Control with coach-items-link.\n4. Update the control execution log with the cycle result and key metrics: recertification exception rate, utility-usage anomalies, allowlist detections, and enforcement test pass rate.\n5. Attach the closure record with coach-document-upload.\n\n**Record in AssureSwarm**\n- Workflow instance — the full operating record exported and archived under retention controls (coach-workflow-export); the archived run is the cycle's operating-effectiveness evidence for the anchor Control.\n- Item relationship — open corrective-action and exception Issues remain open and linked to the anchor Control as the carry-forward; any new next-cycle tracking Issue is created and linked the same way (coach-item-create, coach-items-link).\n- Step document — the updated control execution log and the closure record (with next-cycle dates) attached to this step (coach-document-upload).\n\n**Exit criteria** — The archived record is complete and retrievable, no exception remains open without a tracked owner and due date, carry-forward items and next-cycle dates are seeded, and the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-privileged-access-authorization-model-management"}