{"description":"Standing operator workflow for identity issuance and ownership, shared-identifier exception handling, the dormancy and non-reuse sweep, identity proofing and credential binding, and the full authenticator lifecycle from verified issuance through protection, exposure scanning, and scheduled rotation or revocation. Each monthly cycle runs as a new workflow instance attached to the existing identity & authenticator lifecycle Control item (the UC-ACCESS-06/07/08 family; domains=access_control_identity, frequency=monthly) — the run enriches that standing control's evidence trail, never creating a duplicate control. It consumes no upstream workflow: its inputs are the prior cycle's own carry-forward Issue items (open corrective actions, pending shared-ID review dates, deferred rotations, each linked to the anchor Control) plus current request, source, and inventory extracts. Named deliverables: the issuance & ownership register, the dormancy/non-reuse sweep log, the shared-ID exception disposition and its compensating-control Control items, the identity-proofing evidence package with credential-binding records, the authenticator issuance/strength/default-change log, the protection/exposure-scan disposition, the rotation-and-revocation log, and the identity & authenticator lifecycle-health dashboard — all rolled into an archived, immutable operating record. Because no Identifier/Authenticator/Credential item type exists in the schema, per-identifier, per-binding, and per-authenticator records live as rows in these step-attached registers and logs; only exceptions, gaps, and carry-forwards are promoted to Issue items linked to the anchor Control, and approved shared-identifier waivers are recorded as compensating-control Control items plus a policy_exception Issue. In scope: unique-identifier issuance and ownership mapping for users, services, and devices; shared/group-identifier exceptions; the monthly dormancy and non-reuse sweep; identity proofing proportional to assurance level and credential binding; and authenticator issuance, hardening, protection, exposure remediation, rotation, and revocation across passwords, tokens, keys, and certificates. Out of scope: access authorization and entitlement reviews, joiner/mover/leaver approval routing, and privileged-session management, which are operated by their own workflows. There is no downstream handoff workflow — corrective actions and carry-forward items are tracked to closure within this cycle and seed the next monthly instance of the same control.","edges":[{"id":"e-issue-and-harden-authenticators-compile-lifecycle-metrics-and-log-gaps","source":"issue-and-harden-authenticators","target":"compile-lifecycle-metrics-and-log-gaps"},{"id":"e-evaluate-shared-id-exception-requests-document-compensating-controls","label":"Approved","source":"evaluate-shared-id-exception-requests","target":"document-compensating-controls","whenValue":"approved_with_compensating_controls"},{"id":"e-evaluate-shared-id-exception-requests-compile-lifecycle-metrics-and-log-gaps","label":"Denied","source":"evaluate-shared-id-exception-requests","target":"compile-lifecycle-metrics-and-log-gaps","whenValue":"denied_reissue_individual"},{"id":"e-document-compensating-controls-compile-lifecycle-metrics-and-log-gaps","source":"document-compensating-controls","target":"compile-lifecycle-metrics-and-log-gaps"},{"id":"e-verify-protection-and-scan-for-exposure-remediate-embedded-credential-exposure","label":"Exposure found","source":"verify-protection-and-scan-for-exposure","target":"remediate-embedded-credential-exposure","whenValue":"exposure_found"},{"id":"e-verify-protection-and-scan-for-exposure-compile-lifecycle-metrics-and-log-gaps","label":"Clean","source":"verify-protection-and-scan-for-exposure","target":"compile-lifecycle-metrics-and-log-gaps","whenValue":"clean_no_exposure"},{"id":"e-remediate-embedded-credential-exposure-compile-lifecycle-metrics-and-log-gaps","source":"remediate-embedded-credential-exposure","target":"compile-lifecycle-metrics-and-log-gaps"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-06","UC-ACCESS-07","UC-ACCESS-08"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-identity-authenticator-lifecycle-administration","contentDigest":"sha256:f80ac3091ec1ebb2c841e32384473adbffab3d5b1bc43189934663886e04428b","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:f80ac3091ec1ebb2c841e32384473adbffab3d5b1bc43189934663886e04428b","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-identity-authenticator-lifecycle-administration"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-identity-authenticator-lifecycle-administration","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","iso-27001"],"teams":["it"]},"name":"Identity & Authenticator Lifecycle Administration","nodes":[{"data":{"decisionField":"shared_id_disposition","description":"Agent compiles pending shared or group identifier requests with proposed compensating controls; human decides whether each is approved with compensating controls or denied","formData":{"fields":[{"key":"shared_id_disposition","label":"Shared Id Disposition","options":[{"label":"Approved with compensating controls","value":"approved_with_compensating_controls"},{"label":"Denied, reissue individual identifiers","value":"denied_reissue_individual"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide, per shared or group identifier request, whether to grant an exception to the individual-identifier rule with documented compensating controls, or to deny it and require individual identifiers. Owned by the control owner. A shared identifier breaks individual accountability, so denial is the default.\n\n**Decision criteria**\n- `approved_with_compensating_controls` — the business justification names a genuine technical constraint (for example a legacy service account that cannot support per-user credentials) AND documented, sufficient compensating controls are defined: session-level logging that attributes actions to a real person, physical or procedural access restriction, supervised use, and a defined expiry/review date (log the exception per NIST 800-53 IA-4 / AC-2).\n- `denied_reissue_individual` — no valid technical constraint exists, or the proposed compensating controls do not restore attribution; the requester must instead receive individual identifiers. This branch requires no compensating-control record and proceeds directly to metrics roll-up.\n\nAgent preparation before the human decides: (1) pull pending shared or group identifier requests with coach-query-data, including the requesting system, the business justification, and the individuals who would share the identifier; (2) scan for existing shared identifiers past their review date or lacking documented compensating controls with coach-workflow-scan and fold them into this batch; (3) draft candidate compensating controls per request; (4) attach the exception case file and the prior-cycle shared-ID register with coach-document-upload.\n\n**Record in AssureSwarm** — Submit `shared_id_disposition`. Record the decision rationale and evidence references in the step result, and the approver in the step's approver record.\n\n**Exit criteria** — The disposition routing selector is submitted and the step result contains a rationale and named approver; the unused branch is prunable.","kind":"decision","label":"Evaluate shared-ID exception requests","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload"]}},"id":"evaluate-shared-id-exception-requests"},{"data":{"description":"Agent records the approved shared-ID compensating controls and links them to the exception case; human confirms the controls are implemented, not just documented","instructions":"**Objective** — Convert each approved shared-identifier exception into a recorded, implemented compensating control with a review date, so an exception that lacks a unique identifier still carries attribution and a defined expiry (NIST 800-53 IA-4; AC-2).\n\n**Inputs**\n- The approved shared-ID exceptions and their proposed compensating controls (the approved branch of the shared-identifier disposition), with the disposition owner and rationale from the decision form.\n- The shared identifier register rows and the requesting systems that will implement the controls.\n- The prior-cycle shared-ID register, for review-date continuity.\n- The anchor Control item and the governing access-control Policy item the exception waives against.\n\n**Procedure**\n1. For each approved exception, create a compensating-control Control item with coach-item-create — control_type detective or preventive, control_category administrative or technical, domains=access_control_identity, control_owner set — capturing the specific control (enhanced or session-level logging, supervised use, restricted scope), the implementing system, and the review/expiry date in the description. A compensating control that restores attribution IS a control, so it lives as a real Control item, not a document row.\n2. Record the exception itself as a policy_exception Issue with coach-item-create (issue_type: policy_exception, exception_approver = the disposition owner, exception_expiry_date = the review date, source: self_assessment, issue_owner) — a Control item has no native expiry field, and exception_expiry_date is the filterable expiry index that surfaces the waiver on the register before it lapses.\n3. Link each compensating-control Control item and the policy_exception Issue to the anchor Control item and to the governing Policy item with coach-items-link, so the control's item view shows its full exception history.\n4. Set the review date so the shared identifier re-enters exception evaluation before the expiry lapses; a shared identifier with no future review date is itself a finding.\n5. Attach the updated shared-ID register (identifier, controls, owner, review date) with coach-document-upload.\n\n**Record in AssureSwarm**\n- Create one compensating-control Control item per approved exception (control_type, control_category, domains=access_control_identity, control_owner; review/expiry in description) (coach-item-create).\n- Create the policy_exception Issue for the exception (issue_type: policy_exception, exception_approver, exception_expiry_date, source: self_assessment) (coach-item-create).\n- Link both to the anchor Control and the governing Policy item (coach-items-link).\n- Attach the updated shared-ID register (coach-document-upload).\n\n**Exit criteria** — Every approved shared identifier has a compensating control confirmed live in the target system (not merely documented), a policy_exception Issue carrying a filterable exception_expiry_date, and a future review date set.","label":"Document compensating controls","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"document-compensating-controls"},{"data":{"description":"Verify authoritative unique ownership and assurance-proportional proofing before credential binding, then authorize only hardened authenticators for activation.","instructions":"**Objective** — Verify authoritative unique ownership and assurance-proportional proofing before credential binding, then authorize only hardened authenticators for activation.\n\n**Inputs**\n- Pending identifier requests (user, service, device), each with subject type and requested assurance level — pulled from the IdP/ITSM request queue and attached as the request extract at this step.\n- The authoritative source of record — HR feed for people, the service-account catalog for services, the device inventory for devices — cycle-dated extracts uploaded here as the evidence copy.\n- The full historical identifier register (active and retired), carried forward as the prior cycle's issuance & ownership register document, for the uniqueness check. No Identifier item type exists in the schema, so the register is a rolling XLSX rather than AssureSwarm items.\n- The existing Control item this monthly instance attaches to, and the prior cycle's carry-forward Issue items (open corrective actions) linked to it. These plus the request and source extracts are the cycle's initial inputs; this checkpoint is a parallel entry and needs no other node's output to start.\n- Pending initial-credential issuances, credential-recovery cases, and flagged high-risk changes (role change, re-issuance after suspected compromise), each with its requested assurance level.\n- The identifier register rows issued this cycle (the bind targets).\n- The organization's identity-proofing practice by assurance level — the governing Policy item (policy_type: procedure or standard, domains=access_control_identity), whose document attaches here.\n- Pending authenticator issuance requests tied to this cycle's credential-binding records.\n- The authenticator type per request (password, token, key, certificate) and the target system's default configuration.\n- The minimum-strength policy and the configuration baseline — Policy items (policy_type: standard, domains=access_control_identity), attached here.\n\n**Procedure**\n_This checkpoint absorbs “Issue and map unique identifiers”, “Proof identity and bind credentials”. 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. Issue and map unique identifiers: Pull all pending identifier requests with coach-query-data and bucket them by subject type — each type resolves to a different authoritative source.\n2. For each request, cross-check the proposed identifier against the authoritative source (confirm the subject actually exists and is authorized) and against the full identifier history, active and retired, to confirm it has never been used. Reject any collision outright.\n3. Record each cleared request as a row in the issuance & ownership register, capturing subject type, issuance source, assigned identifier, requested assurance level, and the accountable owner; carry the authoritative-source reference in the row's source column so provenance is traceable end to end. No Identifier item type exists, so identifiers are register rows, not items.\n4. Draft the owner mapping: name the accountable person or team for each identifier. Flag any request with no determinable owner, and any proposed identifier that duplicates an existing one — do not issue either; escalate instead.\n5. Compile the issuance and ownership register (one row per identifier: identifier, subject, source, owner, assurance level) and attach it with coach-document-upload.\n6. Proof identity and bind credentials: Pull the assurance level for each pending case with coach-query-data.\n7. Compile the evidence-check results required at that level — identity-document verification, in-person or supervised-remote verification, and knowledge-based or biometric checks — against the proofing-practice Policy on file, and flag any subject missing required evidence for its level.\n8. Treat recovery and high-risk-change cases as re-proofing events: they get the same evidence bar as initial proofing, never a waiver.\n9. Record each credential binding as a row in the binding/evidence package, linking the proofed identity to the specific credential. No Credential item type exists, so bindings are package rows keyed to the identifier's register row, not items.\n10. Attach the identity-proofing evidence-check package and the credential-binding records with coach-document-upload.\n11. Issue and harden authenticators: Pull pending authenticator issuances tied to bound identities with coach-query-data, including the authenticator type and the target system's default configuration.\n12. For every system or device provisioned with a vendor-default authenticator, draft the default-credential change action and verify against the configuration-baseline Policy that no default remains active.\n13. Check each issued authenticator against the minimum-strength Policy for its type — length and complexity for passwords, key length and algorithm for keys and certificates, entropy for tokens — with coach-query-data, and flag any shortfall.\n14. Record each authenticator issuance as a row in the issuance and default-change log, keyed to its credential-binding row and capturing type, strength-check result, and default-change status. No Authenticator item type exists, so these are log rows, not items.\n15. Attach the issuance and default-change log with coach-document-upload.\n\n**Record in AssureSwarm**\n- Attach the issuance & ownership register as a step document — one row per issued identifier (identifier, subject, source, owner, assurance level); no Identifier item type exists, so these are register rows, not items (coach-document-upload).\n- For every withheld unowned or duplicate request, create an Issue item (issue_type: exception, source: self_assessment, severity per risk, identified_date, issue_owner) and link it to the anchor Control item so the control's item view carries the exception (coach-item-create, coach-items-link).\n- Attach the identity-proofing evidence-check package with the credential-binding records as a step document — one binding row per case (proofed identity to credential); no Credential item type exists, so bindings are package rows, not items (coach-document-upload).\n- For any subject missing evidence required for its assurance level, create an Issue item (issue_type: exception, source: self_assessment, severity, identified_date) linked to the anchor Control (coach-item-create, coach-items-link).\n- Attach the authenticator issuance, strength, and default-change log as a step document — one row per authenticator (type, strength check, default-change status) keyed to its credential-binding row; no Authenticator item type exists, so these are log rows, not items (coach-document-upload).\n- For any authenticator failing the minimum-strength Policy or found still on a vendor default, create an Issue item (issue_type: exception, source: self_assessment, severity per gap, identified_date) linked to the anchor Control (coach-item-create, coach-items-link).\n\n**Exit criteria**\n- Every issued identifier is unique against active and retired history, traces to the authoritative source, and carries a named owner; every unowned or duplicate request is flagged and withheld — raised as an Issue against the control — rather than issued.\n- Evidence on file is proportional to and sufficient for the requested assurance level; recovery and high-risk cases were re-proofed rather than waved through; every binding record is complete before any authenticator is issued.\n- Every vendor default was changed before use; every authenticator meets the minimum-strength requirement; no issuance bypassed the verified process.","label":"Issue and harden authenticators","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"issue-and-harden-authenticators"},{"data":{"decisionField":"protection_scan_disposition","description":"Agent checks storage, transmission, and entry-masking protections and scans code and script repositories for embedded credentials; human decides whether the cycle is clean or exposure requires remediation","formData":{"fields":[{"key":"protection_scan_disposition","label":"Protection Scan Disposition","options":[{"label":"Clean, no exposure found","value":"clean_no_exposure"},{"label":"Exposure found, remediation required","value":"exposure_found"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether authentication information is fully protected this cycle — at rest, in transit, and at entry — with no authenticator embedded in code or scripts, or whether an exposure requires remediation. Owned by the control owner. This is a standing environmental check that runs against storage configuration and repositories every cycle, independent of this cycle's new issuances.\n\n**Decision criteria**\n- `clean_no_exposure` — storage protections hold (passwords salted and hashed; other authenticators encrypted at rest), transmission enforces encryption in transit, entry fields mask input, AND no embedded credential or hard-coded secret was found in source code, configuration, scripts, or infrastructure-as-code.\n- `exposure_found` — any protection gap (plaintext at rest, cleartext transmission, unmasked entry) OR any embedded or hard-coded authenticator; treat it as suspected compromise requiring immediate remediation (NIST 800-53 IA-5(7); IA-6).\n\nAgent preparation before the human decides: (1) query the authenticator storage configuration for every in-scope system with coach-query-data and confirm salted-and-hashed or encrypted-at-rest storage plus encrypted-in-transit paths; (2) verify entry-point configurations mask authenticator input rather than displaying it; (3) scan source-code repositories, configuration files, scripts, and infrastructure-as-code with coach-workflow-scan and coach-query-data for embedded credentials and plaintext secrets; (4) attach the protection-verification and exposure-scan results with coach-document-upload.\n\n**Record in AssureSwarm** — Submit `protection_scan_disposition`. Record the findings and evidence references in the step result, and the approver in the step's approver record.\n\n**Exit criteria** — The disposition routing selector is submitted and the step result contains a rationale and named approver; the unused branch is prunable.","kind":"decision","label":"Verify protection and scan for exposure","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload"]}},"id":"verify-protection-and-scan-for-exposure"},{"data":{"description":"Agent drives immediate rotation of exposed authenticators and removal from code and scripts; human verifies exposure is fully closed","instructions":"**Objective** — Close every protection gap and embedded-credential exposure immediately — rotate the exposed authenticator, purge the secret from code and history, and harden the unprotected path — so no finding carries into the next cycle as a live weakness.\n\n**Inputs**\n- The exposure findings from the protection and exposure disposition (the exposure-found branch): each embedded-credential location, affected system, and discovering scan.\n- The authenticator issuance-log rows for the affected authenticators.\n- The secrets-manager reference pattern for replacements.\n\n**Procedure**\n1. Create an Issue item for each exposure finding with coach-item-create (issue_type: finding, severity high or critical, source: self_assessment, root_cause, remediation_plan), capturing the embedded-credential location, affected system, and discovering scan in the description; reference the affected authenticator's issuance-log row and link the Issue to the anchor Control with coach-items-link.\n2. Draft the immediate-rotation action for every exposed or under-protected authenticator — exposure equals suspected compromise for rotation urgency, with no grace period.\n3. Draft the removal action for each embedded credential: purge it from source history, not just the current tip, and replace it with a secrets-manager reference; draft the storage or transmission hardening action for any unprotected configuration found.\n4. On closure, set actual_remediation_date on each Issue; attach the remediation log and the re-run scan results (which must come back clean) with coach-document-upload.\n\n**Record in AssureSwarm**\n- Create one Issue item per exposure finding (issue_type: finding, severity high or critical, source: self_assessment, root_cause, remediation_plan, actual_remediation_date on closure) (coach-item-create).\n- Link each Issue to the anchor Control item, referencing the affected authenticator's issuance-log row in the description (coach-items-link).\n- Attach the remediation log and clean re-scan (coach-document-upload).\n\n**Exit criteria** — Every exposed authenticator was rotated; every embedded credential was removed from code and source history and replaced with a managed reference; the re-run scan comes back clean.","label":"Remediate embedded credential exposure","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"remediate-embedded-credential-exposure"},{"data":{"description":"Judge timely dormancy deactivation, non-reuse, rotation and revocation with all lifecycle results, and commit every remaining gap and carry-forward.","instructions":"**Objective** — Judge timely dormancy deactivation, non-reuse, rotation and revocation with all lifecycle results, and commit every remaining gap and carry-forward.\n\n**Inputs**\n- Every active identifier with its last-activity timestamp.\n- The authoritative source's current roster and separation/decommission records.\n- The non-reuse register of previously deactivated identifiers.\n- This cycle's newly issued identifiers, taken from the issuance and ownership register, for the collision check.\n- The authenticator inventory with its rotation schedule and event triggers (role change, approaching certificate expiry).\n- This cycle's dormancy-sweep deactivations and any confirmed-compromise cases — the source of the revocation list.\n- The issuance and ownership register; the shared-ID exception dispositions and any compensating-control records; the dormancy sweep log; the identity-proofing evidence package; the authenticator issuance, strength, and default-change log; the protection and exposure-scan disposition and any remediation log; and the rotation-and-revocation log.\n- Pending shared-ID exception review dates and any deferred rotations carried by this cycle.\n- The evidence-repository retention configuration and the monthly sweep calendar.\n- This checkpoint joins all upstream branches — it waits for all of them before computing metrics.\n\n**Procedure**\n_This checkpoint absorbs “Run dormancy and non-reuse sweep”, “Rotate and revoke per schedule”. 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. Run dormancy and non-reuse sweep: Query active identifiers against last-activity timestamps with coach-query-data and flag any with no activity past the dormancy threshold (state the threshold applied, e.g. 30 / 60 / 90 days per policy).\n2. Query the current roster and separation/decommission records and flag identifiers belonging to separated users, retired services, or decommissioned devices.\n3. Record a deactivation row per flagged identifier in the dormancy/non-reuse sweep log, capturing detection reason, last-activity date, and deactivation deadline. No Identifier item type exists, so deactivations are log rows keyed to the identifier's register row, not items.\n4. Run the non-reuse check: confirm none of this cycle's newly issued identifiers collides with any identifier still inside its non-reuse period. Block and escalate any collision — a reissued identifier inside the non-reuse window must be revoked and re-drawn.\n5. Compile the sweep log (deactivations executed, non-reuse checks passed, collisions blocked) and attach it with coach-document-upload.\n6. Rotate and revoke per schedule: Query the authenticator inventory against the rotation schedule and event triggers with coach-query-data and compile the due-for-rotation list.\n7. Cross-check this cycle's dormancy-sweep deactivations and any confirmed-compromise cases against the authenticator inventory and compile the due-for-revocation list.\n8. Record the rotation action for each due authenticator and the revocation action for each compromised or separation-triggered authenticator as rows in the rotation-and-revocation log, keyed to the authenticator's issuance-log row and capturing the action, trigger, and completion date. No Authenticator item type exists, so these routine actions are log rows, not items.\n9. Compile the rotation-and-revocation log and attach it with coach-document-upload.\n10. Compile lifecycle metrics and log gaps: Compute the cycle metrics with coach-query-data: identifier uniqueness and ownership completeness; shared-ID exceptions with documented compensating controls; dormancy-sweep and non-reuse results; identity-proofing evidence completeness by assurance level; authenticator strength and default-change compliance; protection and exposure-scan results; rotation and revocation timeliness.\n11. Build the identity & authenticator lifecycle-health dashboard with coach-dashboard-create showing each metric against its threshold and the trend against prior cycles.\n12. Create a corrective-action Issue item with coach-item-create for every metric outside tolerance (issue_type: finding, source: self_assessment, issue_owner, root_cause, target_remediation_date); link each to the anchor Control with coach-items-link, referencing the driving register/log in the description.\n13. Draft the cycle summary and attach it with coach-document-upload.\n14. Export the full operating record with coach-workflow-export as the workflow-instance audit trail and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n15. Create carry-forward Issue items with coach-item-create for open corrective actions, pending shared-ID exception review dates, and any deferred rotations (issue_type: finding or exception, target_remediation_date = review or rotation deadline, issue_owner); link each to the anchor Control with coach-items-link so it arrives as an explicit input to the next cycle's instance.\n16. Update the control execution log with the cycle result and key metrics and confirm the next monthly sweep date is scheduled.\n17. The control owner reviews the dashboard, the gap list, and the carry-forward set and signs the cycle closed — nothing out of tolerance without a named owner and due date, nothing open without a carry-forward. Attach the closure record with coach-document-upload.\n\n**Record in AssureSwarm**\n- Attach the dormancy/non-reuse sweep log as a step document — one row per deactivation (identifier, detection reason, last-activity date, deactivation deadline) plus non-reuse checks passed and collisions blocked; no Identifier item type exists, so deactivations are log rows, not items (coach-document-upload).\n- For any blocked non-reuse collision (a reissued identifier inside its non-reuse window), create an Issue item (issue_type: exception, source: self_assessment, severity, identified_date) and link it to the anchor Control (coach-item-create, coach-items-link).\n- Attach the rotation-and-revocation log as a step document — one row per affected authenticator (action: rotate or revoke, trigger, completion date) keyed to its issuance-log row; no Authenticator item type exists, so these are log rows, not items (coach-document-upload).\n- For any rotation or revocation overdue and not completed this cycle, create an Issue item (issue_type: finding, source: self_assessment, target_remediation_date, issue_owner) linked to the anchor Control and carried forward (coach-item-create, coach-items-link).\n- Build the identity & authenticator lifecycle-health dashboard (coach-dashboard-create).\n- Create one corrective-action Issue item per out-of-tolerance metric (issue_type: finding, source: self_assessment, issue_owner, root_cause, target_remediation_date) and one carry-forward Issue item per open thread (issue_type: finding or exception, target_remediation_date, issue_owner); link each to the anchor Control, referencing the driving register/log in the description (coach-item-create, coach-items-link).\n- Export and archive the operating record as the workflow-instance audit trail (coach-workflow-export).\n- Attach the cycle summary and the closure record (coach-document-upload).\n\n**Exit criteria**\n- Every dormant or separation-triggered identifier is deactivated by its deadline; no newly issued identifier violates the non-reuse period; no still-needed identifier was deactivated in error.\n- Every authenticator due for rotation was rotated; every compromised or separation-triggered authenticator was revoked without delay; nothing overdue remains active.\n- The dashboard renders every metric against its threshold; every gap has a named owner and due date; the archived record is immutable and retrievable; the next monthly sweep is scheduled; nothing remains open without a tracked carry-forward owner; the control owner has formally declared the cycle closed.","label":"Compile lifecycle metrics and log gaps","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create","coach-workflow-export"]}},"id":"compile-lifecycle-metrics-and-log-gaps"}],"sourceTemplateId":"workflow-library:controls-identity-authenticator-lifecycle-administration"}