{"description":"Runs on the existing Control item for UC-ACCESS-02 (user access review) — with UC-ACCESS-03 linked by item relationship — enriching that Control, never creating a duplicate; each quarterly or event-triggered cycle is a workflow instance attached to it, so archived instances accumulate as the de-facto control execution log. A decision-aware workflow covering entitlement extraction, manager certification, revocation, and independent verification. Consumes at start the prior cycle's scope-change carry-forward Issues and prior signed report (both attached to the same Control) plus the period's source-of-record entitlement extracts and period-end HR roster. Produces a signed, audit-ready recertification evidence package and control-owner report as the named deliverable. In scope: SOX-significant applications, systems holding data classified Confidential or above, identity infrastructure (directory, SSO, PAM), and privileged-reach platforms, across all account populations (standard, privileged, service, shared, emergency break-glass, third-party); triggered on scheduled cadence or by event (post-incident, auditor request). Out of scope: lifecycle provisioning and the privileged-access model itself — systemic findings hand off to the Joiner-Mover-Leaver Access Lifecycle (lifecycle gaps) and Privileged Access & Authorization Model Management (privileged-model findings) workflows.","edges":[{"id":"e-extract-and-validate-entitlements-adjudicate-results","label":"Reliable","source":"extract-and-validate-entitlements","target":"adjudicate-results","whenValue":"reliable"},{"id":"e-extract-and-validate-entitlements-rework-extract","label":"Rework","source":"extract-and-validate-entitlements","target":"rework-extract","whenValue":"rework_required"},{"id":"e-rework-extract-adjudicate-results","source":"rework-extract","target":"adjudicate-results"},{"id":"e-adjudicate-results-compile-evidence-and-report","label":"Clean","source":"adjudicate-results","target":"compile-evidence-and-report","whenValue":"certified_clean"},{"id":"e-adjudicate-results-process-and-verify-revocations","label":"Revoke","source":"adjudicate-results","target":"process-and-verify-revocations","whenValue":"revocations_required"},{"id":"e-process-and-verify-revocations-compile-evidence-and-report","source":"process-and-verify-revocations","target":"compile-evidence-and-report"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-02","UC-ACCESS-03"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-user-access-review","contentDigest":"sha256:a7af16f97073e073ad464ca1ec5c0736dae8db8ef2ccdbccf8da2c2700053e2d","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a7af16f97073e073ad464ca1ec5c0736dae8db8ef2ccdbccf8da2c2700053e2d","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-user-access-review"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-user-access-review","source":"coworkcanvas-gallery","standards":["sox","iso-27001","nist-800-53"],"teams":["it","finance"]},"name":"User Access Review & Recertification","nodes":[{"data":{"decisionField":"extract_quality","description":"Agent pulls entitlements from every source of record and drafts the IPE quality memo; human decides whether the extracts are reliable","formData":{"fields":[{"key":"extract_quality","label":"Extract quality","options":[{"label":"Extracts reliable","value":"reliable"},{"label":"Rework required","value":"rework_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Produce the entitlement population for every in-scope system and decide whether it is complete and accurate enough to certify against. The control owner, or the delegate running the cycle, owns the call; every certification downstream inherits this data's quality.\n\n**Decision criteria**\n\nThe branch rests on evidence produced in this step, per system: pull all accounts with entitlement detail (roles, groups, permissions), account status, creation date, and last logon from the source of record as of period end; capture generation metadata for every extract — system, report or query name, parameters, run date-time, run by, row count; reconcile the extract row count to the source's own total (admin-console count or equivalent); filter the file to prove every agreed population is present — standard, privileged, service, shared, emergency, third-party; and join to an HR roster of the same date to tag terminated users still active, transfers, dormant accounts (no logon in 90+ days), and orphans with no HR match. One action does not wait for the branch: an account belonging to a user terminated before period end is disabled immediately on discovery, then still flows through certification for the record.\n\n- **Extracts reliable (`reliable`)** — every in-scope system passes all five checks: as-of date equals period end; row count reconciles with zero unexplained variance; all account populations verified present by filtering, not assumption; generation metadata complete (the completeness-and-accuracy bar auditors apply to system-generated evidence); HR tie-out run with every non-match dispositioned. Findings are not defects: terminated-still-active accounts, orphans, and dormancy flags ride into certification tagged for decision — they indict the access, not the data.\n- **Rework required (`rework_required`)** — any system fails a check: unexplained count variance; an account population silently missing from the export (service accounts are the classic miss); as-of date outside the period; truncated or corrupt file; entitlement detail too coarse to certify (group names without membership or meaning); or missing generation metadata. Name each failing system and its specific defect in the rationale — the rework step executes from that list, and clean systems are not re-pulled.\n\n**Record in AssureSwarm**\n- Submit the decision form: `extract_quality` (the branch), the step result citing the per-system reconciliation results and where each check's evidence lives, and the step's approver record.\n- Attach every extract and the IPE quality memo — per-system generation metadata, count reconciliations, HR tie-out results, and the anomaly register — to this step (document upload).\n\n**Exit criteria** — Form submitted with a rationale that disposes every in-scope system as pass or fail; findings separated from defects so findings reach certification and only data-quality failures reach rework; immediate terminations actioned and noted.","kind":"decision","label":"Extract and validate entitlements","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"extract-and-validate-entitlements"},{"data":{"description":"Agent re-pulls the deficient extracts with corrected parameters; human re-verifies reliability before certification proceeds","instructions":"**Objective** — Correct the specific extract defects named at validation so certification proceeds on reliable data, without re-pulling clean systems or silently shifting the population.\n\n**Inputs**\n- the step result from the validation decision: the failing systems and the defect per system.\n- The original extracts and IPE quality memo attached to the validation step.\n- Source-of-record access, or the administrator contact, for each failing system.\n- The period-end as-of date for the cycle.\n\n**Procedure**\n1. Restate each defect as a testable claim before re-pulling anything: wrong parameters, missing account population, stale as-of date, truncated export, missing metadata. If an item on the list is actually a finding (a terminated user still active, an orphan account), it does not belong here — push it forward to certification; rework is for data quality only.\n2. Re-pull only the failing systems, keeping the original period-end as-of date: a re-pull \"as of today\" changes the population and breaks comparability with the systems already validated. If a source cannot reproduce a historical as-of, record the new date, the drift in days, and the joiner-leaver delta in the gap as a known limitation.\n3. Capture fresh generation metadata for every replacement extract: system, report or query name, parameters, run date-time, run by, row count.\n4. Re-run the full validation battery on each replacement — count reconciliation, population-coverage filters, HR roster tie-out at the same date, dormancy and orphan tagging — not just the check that failed; a corrected parameter can break something that previously passed.\n5. Write a short rework addendum to the IPE quality memo mapping each original defect to its correction and its passing re-check, and version the files so superseded extracts stay in the record but cannot be certified against by mistake.\n\n**Record in AssureSwarm**\n- Attach the corrected extracts and the rework addendum to this step (document upload), marking superseded files as replaced.\n- Record which systems were re-pulled and the defect-to-resolution mapping.\n\n**Exit criteria** — Every defect in the rationale has a named resolution with a passing re-check; replacement extracts carry full generation metadata; as-of consistency preserved or its drift documented; exactly one authoritative file per system is unambiguous for distribution.","label":"Rework extract","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"rework-extract"},{"data":{"decisionField":"review_outcome","description":"Make evidence-backed per-entitlement retain/revoke/modify decisions and judge their coverage, high-risk justifications and plausibility before selecting the revocation path.","formData":{"fields":[{"key":"review_outcome","label":"Review outcome","options":[{"label":"Certified clean","value":"certified_clean"},{"label":"Revocations required","value":"revocations_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Make evidence-backed per-entitlement retain/revoke/modify decisions and judge their coverage, high-risk justifications and plausibility before selecting the revocation path.\n\n**Inputs**\nThe released extracts (validated or reworked) with HR-join flags: terminated, transferred, dormant, orphan.\n- The reviewer roster and assignment rules for the cycle: manager versus system-owner split, no-self-review routing.\n- Certification window dates and escalation contacts.\n- Entitlement descriptions in business language — raw group names like `APP_FIN_GL_WRT` are not certifiable.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Independent entitlement certifiers and control owner owns the stated judgments and authorizations.*\n\n*Distribute and collect certifications.* Put an enriched package in front of the right certifier for every account and entitlement, and collect an explicit retain, revoke, or modify decision on every line.\n\n1. Split the population into per-reviewer packages per the assignment rules: line managers get their reports' business access; system owners get privileged, service, shared, and emergency accounts; orphans go to security, not to a manager who will guess. Verify no row's certifier is the account holder or its administrator; re-route hits to their manager.\n2. Enrich every line so the reviewer can decide without leaving the package: user name, title, department, entitlement in business terms, last logon, and flags for privileged, terminated, dormant 90+ days, and segregation-of-duties conflicts. A flagged line should force a justification for retention, not a reflex approval.\n3. Assign each identified package to its authorized certifier as workflow work, with a versioned per-line certification workpaper and native approval. Record retain, revoke or modify for every line (modify states the exact target), the certifier, actual decision date and any high-risk retention justification. Use known system and population context in the assignment, with the deadline and escalation contact; do not create a collection form for these executors. The test the certifier applies is least privilege for the person's current job, not \"do I recognize this name\".\n4. Chase to completion: reminder before the due date, manager escalation after it, a non-responder list for the control owner. Where policy allows, state up front: access left uncertified at the deadline is treated as revoke.\n5. Screen returns for rubber-stamping: all-retain responses returned minutes after receipt, zero revocations from teams with known movers, identical timestamps across hundreds of lines. Reject and re-perform any certification with no evidence of line-level review — a rubber-stamped review means the control did not operate.\n6. Consolidate accepted responses into a response register: every line, its decision, certifier identity, decision date.\n\n*Adjudicate results.* Classify the certified population so the cycle takes exactly one closure path: straight to evidence compilation when no access change remains, or through revocation processing when any does. The control owner decides on the consolidated response register.\n\n\n\nVerify three things from the register before picking a branch: (1) coverage — certified lines equal distributed lines, with every non-response resolved or dispositioned under the stated default-revoke rule; (2) flag disposition — every pre-flagged high-risk line (terminated, orphan, privileged, dormant, segregation-of-duties conflict) carries its own explicit decision rather than an inherited blanket approval; (3) plausibility — compare the revoke rate to prior cycles; a zero-revoke result on a large population with known transfers usually signals review-quality failure, and those certifications get re-performed before the cycle is classified, not explained away.\n\n- **Certified clean (`certified_clean`)** — zero revoke and zero modify decisions, 100% coverage, and every flagged line explicitly retained with a stated justification. Pending default-revokes, uncertified lines, or unresolved flags disqualify this branch: clean means no access change of any kind remains to execute.\n- **Revocations required (`revocations_required`)** — one or more revoke or modify decisions exist, or default-revoke non-responses remain to execute. State in the rationale exactly how many revokes and modifies, in which systems, and how many touch privileged or non-human accounts — the revocation step sizes SLAs and special handling from those counts.\n\n**Record in AssureSwarm**\nExport the per-reviewer packages and attach the issued versions (item export plus document upload).\n- Preserve each certifier’s versioned line-level workpaper and native approval: system/package context, account and entitlement, retain/revoke/modify outcome, reason and exact modification, privileged-access justification, certifier identity and actual decision date. Aggregate these native executor records into the response register. A blanket population sign-off cannot replace per-line evidence; distribution and chasing stay in the owner’s native result.\n- Attach the response register and the chase-and-escalation trail.\n- Record coverage: distributed, certified, escalated non-responders, rejected certifications.\n\nSubmit the decision form: `review_outcome` (the branch), the step result with decision counts by system and risk level plus a reference to the adjudication summary, and the step's approver record.\n- Attach the adjudication summary; build or refresh the results dashboard (coverage, decision mix by system, prior-cycle comparison) linked to this step.\n\n**Exit criteria**\nEvery distributed line has an explicit decision from an authorized certifier with a date; zero self-certified rows; rubber-stamp screening documented; non-responders resolved or escalated with the default-revoke position stated.\n\nForm submitted; rationale counts reconcile to the response register; every high-risk flag's disposition is verifiable; the not-taken branch is prunable because the taken branch fully describes the remaining work.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends assignments, reminders, and escalation notices with a logged chase trail; `/coach-workflow-scan` surfaces per-reviewer status and overdue certifications.\n\n","kind":"decision","label":"Adjudicate results","performedBy":{"primitives":["coach-export-package","coach-form-create","coach-workflow-scan","coach-document-upload","coach-notify","coach-query-data","coach-dashboard-create"]}},"id":"adjudicate-results"},{"data":{"description":"Agent tickets every revocation, tracks execution, and re-queries systems to prove removal; human approves closure of each revocation","instructions":"**Objective** — Convert every revoke and modify decision into an executed, independently verified access change inside SLA, with evidence of removal that stands alone in an audit.\n\n**Inputs**\n- The adjudicated decision list: every revoke and modify with system, account, entitlement, certifier, decision date.\n- Revocation SLAs from policy; typical: terminated-user access immediately, privileged in 2–5 business days, standard in 10–15 business days of certification.\n- Administrator or ticket-queue contacts per system; directory and PAM teams for privileged and service accounts.\n\n**Procedure**\n1. Create one tracker item per revoke or modify decision, linked to the certification line that drove it, carrying system, account, entitlement, decision date, SLA due date, executing owner. One decision, one traceable unit — batching hides misses.\n2. Raise the change in the ticketing or identity-governance system stating exactly what was certified: the entitlement to remove or the modify target state — the administrator should execute, not interpret.\n3. Handle special populations: shared accounts get credential rotation and the departing user removed from the authorized-user list (an account others use cannot be deleted); service accounts need an owner check for hard-coded credentials before any change; emergency break-glass accounts are re-sealed (rotate, re-vault, re-verify the checkout list); prefer disable-then-delete with a quarantine (commonly 30 days) so mistakes are reversible.\n4. Track every ticket against its SLA date and escalate breaches while open — a breach caught mid-flight is management; one discovered at closure is a finding.\n5. Verify independently: re-query each affected system of record and compare post-change entitlements line by line against the decisions. A closed ticket is a claim, not evidence — the post-change extract is the evidence. Send still-present lines back to execution until verification passes.\n6. Where the business wants to keep certified-out access, do not quietly retain it: an exception requires documented justification, risk acceptance by the risk owner (not the certifier), compensating controls, and an expiry. A perpetual exception is standing risk.\n7. Assemble before-and-after evidence per decision: pre-change line, decision, ticket reference, post-change line, verification date and verifier.\n\n**Record in AssureSwarm**\n- Create the tracker items, link each to its certification line, and update statuses through executed, verified, closed (or excepted).\n- Attach the post-change verification extracts, before-and-after evidence, and exception approvals with expiry dates.\n- Record SLA performance: on-time count, breaches with cause, escalations.\n\n**Exit criteria** — Every revoke and modify decision is verified removed, formally excepted with an expiry date, or explicitly escalated; no still-present line without a tracked path; verification evidence is the system re-extract, not the ticket note; SLA breaches logged with cause.","label":"Process and verify revocations","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-query-data","coach-document-upload","coach-item-update"]}},"id":"process-and-verify-revocations"},{"data":{"description":"Agent assembles the audit-ready evidence package, drafts the control-owner report, archives it under retention and seeds the next cycle; human approves and signs off the cycle, and that signature is the closure","instructions":"**Objective** — Assemble a self-contained evidence package an auditor can re-perform the cycle from without asking for anything else, obtain the control owner's signed acceptance of the results, and close the cycle under retention with the next one seeded.\n\n**Inputs**\n- Every artifact produced upstream: the confirmed cycle scope (systems, populations, roster, calendar); extracts with generation metadata and the IPE quality memo (plus the rework addendum if that branch ran); issued certification packages; the consolidated response register with certifier identities and dates; revocation trackers with before-and-after verification evidence; exception approvals with expiry dates.\n- The review calendar, SLA commitments, and the access-review policy cadence, for timeliness reporting and next-cycle scheduling.\n- The prior-cycle report, for trend comparison.\n- The records-retention schedule; SOX-relevant access-review evidence is commonly retained seven years, ISO 27001 evidence per the ISMS schedule.\n- Open follow-up actions, approved exceptions with expiry dates, and scope-change notes gathered during the cycle.\n\n**Procedure**\n*The control owner’s signed results authorize the subsequent archive, execution-log and next-cycle updates.*\n1. Link every artifact to the workflow step that produced it and index the package in step order, so the narrative order is the evidence order. Then test it against the re-performance bar: could a reviewer holding only this package reproduce the population, the decisions, and the removals? Any external reference (\"see the ticket system\") fails the bar — pull the artifact in.\n2. Compute cycle metrics from the register and trackers, spot-checking each figure against its source before publishing: population per system, certification coverage, revoke and modify counts and rates, verification rate, SLA performance, exception count with expiries, and cycle duration against the calendar.\n3. Draft the control-owner report: results by system; every exception with its approval and expiry; SLA breaches with cause; and the systemic read — repeat offenders across cycles, chronic over-provisioning in particular roles, terminations that reached this review before the leaver process caught them, recurring segregation-of-duties conflicts. Route lifecycle gaps to the Joiner-Mover-Leaver Access Lifecycle workflow and privileged-model findings to Privileged Access & Authorization Model Management — this report is those workflows' input.\n4. Cross-reference every figure in the report to its source artifact, then obtain the control owner's sign-off with date, plus agreed follow-up actions with named owners and due dates. Before signing, confirm the cycle is actually closable: every revocation verified or formally excepted, no certification outstanding. A cycle with open revocations does not close — it escalates.\n5. Export the full workflow record so the package carries the process trail itself, not just the outputs.\n6. Archive the exported record with the signed package in the designated evidence repository under retention and immutability controls; record the archive location and reference identifier. Verify retrievability by opening the archived copy, not by trusting the upload confirmation.\n7. Update the control execution log for UC-ACCESS-02 and UC-ACCESS-03 with the cycle period, completion date, result, and key metrics — this log is what demonstrates on-cadence operation when an auditor samples the control.\n8. Create carry-forward items so the next cycle starts with explicit inputs, each with a named owner and due date: follow-up actions from the report; every approved exception, due at its expiry for re-decision (exceptions that renew silently are how temporary risk becomes permanent); and scope changes — systems to add or retire — for the next cycle's scope.\n9. Confirm the next review period is scheduled at the policy cadence.\n10. Issue the closure notice to stakeholders, citing the signed report and the archive reference.\n\n**Record in AssureSwarm**\n- Link each evidence artifact to its producing step (document link); attach the signed report and the sign-off record (document upload).\n- Attach the metrics workpaper with its source cross-references.\n- Export the workflow record into the package and attach the closure record with the archive location and reference.\n- Create the carry-forward items — follow-ups, exception re-reviews at expiry, scope changes — with owners and due dates.\n- Record the control execution log update and the next cycle's scheduled date on this step.\n\n**Exit criteria** — Package passes the re-performance test with no external references; every reported figure traces to an attached artifact; sign-off captured with date and follow-up actions carry named owners and due dates; the archived package is verified retrievable and immutable with its reference recorded; the control execution log is updated; every open thread exists as a carry-forward item with owner and due date; the next cycle is on the calendar.","label":"Compile evidence and report","performedBy":{"primitives":["coach-document-upload","coach-workflow-export","coach-item-create"]}},"id":"compile-evidence-and-report"}],"sourceTemplateId":"workflow-library:controls-user-access-review"}