{"description":"Periodic cryptographic key management review as a decision-aware workflow covering inventory, custody, rotation, algorithm strength, and verified remediation. The workflow instance attaches to the existing Audit item opened for this review cycle (audit_type it_audit or compliance; Audit.scope = the review scope statement; Audit.period_start/period_end = the review period; Audit.lead_auditor = the review owner) — enrich that record, never create a duplicate — and it links to the cryptographic Control items under review (domains cryptography_key_management, e.g. UC-CRYPTO-02, UC-CRYPTO-03). In scope: all managed key stores — cloud KMS, HSM partitions, certificate stores, secrets managers, and code-signing infrastructure — across in-scope environments. Out of scope: application-layer data classification and the identity provider, which are covered by their own reviews. No upstream workflow feeds this review; it is triggered by its periodic cadence, an incident, an audit request, or an algorithm-deprecation notice — scope is set on the Audit at kickoff, not handed off. The named deliverables are the signed cryptographic key management attestation (mapped to ISO 27001 A.8.24 and NIST SP 800-53 SC-12/SC-13) and the indexed, redacted evidence package filed against the anchor Audit; there is no downstream handoff workflow.","edges":[{"id":"e-consolidate-findings-attest-and-report","label":"Compliant","source":"consolidate-findings","target":"attest-and-report","whenValue":"compliant"},{"id":"e-consolidate-findings-remediate-and-verify","label":"Remediate","source":"consolidate-findings","target":"remediate-and-verify","whenValue":"remediation_required"},{"id":"e-remediate-and-verify-attest-and-report","source":"remediate-and-verify","target":"attest-and-report"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CRYPTO-03","UC-CRYPTO-02"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-key-management-crypto-review","contentDigest":"sha256:e11d0a422f1a884d2c193a96e85fc415f71a9fe2547b9f12a600420e0b162bdb","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:e11d0a422f1a884d2c193a96e85fc415f71a9fe2547b9f12a600420e0b162bdb","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-key-management-crypto-review"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-key-management-crypto-review","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001"],"teams":["it"]},"name":"Cryptographic Key Management Review","nodes":[{"data":{"decisionField":"review_outcome","description":"Accept the complete reconciled crypto inventory, assign orphan ownership, judge custody and algorithm/rotation exposure, and decide compliance or remediation.","formData":{"fields":[{"key":"review_outcome","label":"Review outcome","options":[{"label":"Compliant","value":"compliant"},{"label":"Remediation required","value":"remediation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Accept the complete reconciled crypto inventory, assign orphan ownership, judge custody and algorithm/rotation exposure, and decide compliance or remediation.\n\n**Inputs**\n- The review scope statement, recorded on the anchor Audit item at kickoff: `Audit.scope` (the trigger — periodic cadence, incident, audit request, or algorithm-deprecation notice — plus the in-scope store list and exclusions), `Audit.period_start`/`Audit.period_end` (the review period), and `Audit.lead_auditor` (the review owner). This review has no upstream workflow feeding it — scope is decided at kickoff, not handed off.\n- The list of in-scope stores — each cloud KMS instance, HSM partition, certificate store, secrets manager, and code-signing register, with its environment and control owner — enumerated in `Audit.scope`; the authoritative store register is uploaded to this step as evidence, since Studio has no native key-store asset type.\n- The key management policy as a **Policy item** (`policy_type: standard`, `domains: cryptography_key_management`, `framework: iso-27001`/`nist-800-53`, `policy_owner`): approved algorithms and minimum key lengths, maximum key ages / rotation intervals per key type, and the certificate-expiry alerting horizon — attach the governing excerpt to this step and cite the policy clause for each threshold. The governing controls exist as **Control items** in the library (`domains: cryptography_key_management`) — e.g. UC-CRYPTO-02, UC-CRYPTO-03.\n- The prior review's inventory — the inventory workbook on the prior cycle's archived workflow instance, reachable via the prior period's Audit item — for reconciliation.\n- The signed-off findings sheet and consolidated inventory from \"Inventory and analyze keys and certificates\" (documents on that step) — specifically the ownership-gap rows and any keys carrying broad or exportable access.\n- Directory, team, and service registers for owner attribution — external systems (HR directory / CMDB / team registers); dated extracts uploaded to this step as evidence.\n- The access-control lists for each key store — exported from the stores themselves (external) and uploaded to this step as evidence.\n- The custody policy as a **Policy item** (`policy_type: standard`, `domains: cryptography_key_management` / `access_control_identity`): separation of duties, dual control for root/code-signing/HSM-backed keys, exportability rules, and leaver / dormant-account revocation requirements — excerpt attached to this step, clause cited per finding.\n\n**Procedure**\n_This checkpoint absorbs “Inventory and analyze keys and certificates”, “Verify ownership and custody”. 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. Inventory and analyze keys and certificates: Pull a complete listing from every in-scope store, capturing per entry: identifier, platform, purpose, algorithm, key length, creation date, last rotation date, expiry or scheduled-rotation date, and environment. Save each raw dated export as evidence.\n2. Join the listing against ownership and custody records to attach a named owner and custodian to each entry; mark every entry with no owner match as an ownership gap for the next checkpoint.\n3. Reconcile against the prior inventory: list unexplained additions, disappearances, and any keys discovered outside managed stores (shadow crypto).\n4. Compute the rotation-overdue list — entries whose age or last rotation exceeds the policy interval — with days past due per entry.\n5. Compute the expiring list — certificates and keys inside the alerting horizon — with days remaining and whether a renewal is already scheduled.\n6. Flag every entry whose algorithm or key length violates the approved standard: RSA below 2048 bits, SHA-1 signatures, legacy symmetric ciphers (e.g. 3DES), deprecated curves — citing the specific policy clause and noting what data or trust each weak key protects.\n7. Assemble one findings sheet, one row per exception, grouped as custody, rotation/expiry, or algorithm findings, and attach the raw dated exports as evidence.\n8. Verify ownership and custody: For each entry the ownership join left unmatched, search the directory, team, and service registers using naming conventions, deployment metadata, and the consuming application; draft an owner proposal with the evidence trail for each orphan.\n9. Pull the ACLs for each key store and compare against the custody policy: separation of duties enforced; dual control present for root, code-signing, and HSM-backed keys; no departed personnel or dormant service accounts retaining use, export, or administer rights.\n10. List every key with exportable private material or permissions broader than its purpose requires, each as a discrete custody finding citing the policy clause it breaches.\n11. Append the custody and ownership findings to the shared findings sheet and link each key record to its confirmed or proposed owner record.\n12. Consolidate findings and decide outcome: Before the decision, the agent deduplicates the custody, rotation, expiry, and algorithm findings; ranks them by exposure (what each key protects, its environment, how far past threshold it sits); pre-drafts a proposed outcome with a per-finding disposition; and drafts a recommendation in the step result citing findings-register rows for the review owner to judge.\n\n**Decision criteria**\n- Choose **Compliant** (`compliant`) when no open finding in the ranked register exceeds policy tolerance: no over-age or expiring key past its grace threshold without a scheduled fix, no algorithm below the approved minimum in a production trust path, and no unresolved custody or ownership exception.\n- Choose **Remediation required** (`remediation_required`) when any finding must be fixed before attestation. Any open high-exposure finding — a weak algorithm protecting production data or trust (RSA <2048, SHA-1, legacy ciphers), an exportable or dual-control-breaching root/code-signing key, or a materially overdue rotation — forces this branch regardless of the finding count.\n\n**Record in AssureSwarm**\nAttach each raw store export (CSV) and the consolidated inventory + findings sheet (XLSX) to this step as documents (`coach-document-upload`). Record the population counts on the step — store count, total keys/certificates, and exception counts by group (custody / rotation-expiry / algorithm). Studio has no key/certificate asset type, so the per-entry inventory lives entirely in this step's documents rather than as item records; the anchor Audit item remains the durable pointer to this run.\nAppend the custody and ownership findings to the shared findings sheet, re-attaching the updated workbook to the inventory step (`coach-document-upload`). Studio has no key/certificate asset type, so owner attribution is captured in the findings sheet's owner column rather than as item-to-item links; record the residual ownership-gap count in the step notes (target zero) — there is no native field for it. Any custody exception allowed to stand carries its documented reason in the same sheet, and confirmed findings become linked Issues at the remediation step.\nSubmit the `review_outcome` SELECT field via `coach-form-fill`. Record the decision rationale in the step result, citing the inventory and rotation/algorithm evidence rows, and name the step's approver record. The submitted value routes the workflow along the matching branch.\n\n**Exit criteria**\n- Every in-scope store contributed an export dated within the review period; a sample of rows is spot-checked against the source consoles; reconciliation explanations are accepted or corrected; the findings sheet is signed off as the factual basis for the review.\n- Every orphaned key has an accountable owner assigned; the reviewer has ruled on which access grants are excessive and must be revoked; the custody findings list is approved; any exception allowed to stand has a documented reason. No key leaves this step ownerless.\n- The decision form is submitted with an owner and an evidence-cited rationale; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` — pulls each store listing and computes the rotation-overdue and expiry status against the policy thresholds.","kind":"decision","label":"Consolidate findings and decide outcome","performedBy":{"primitives":["coach-query-data","coach-items-link","coach-form-fill"]}},"id":"consolidate-findings"},{"data":{"description":"Agent drafts remediation tickets, tracks execution, and re-queries stores to verify each fix; human approves each closure","instructions":"**Objective** — Fix every confirmed finding and verify each fix from post-change evidence, not execution notes.\n\n**Inputs**\n- The ranked findings register and per-finding dispositions from the \"remediation required\" decision.\n- Application/dependency maps and maintenance-window calendars for sequencing.\n- Policy remediation timelines per finding severity.\n- Access to each affected store to re-query after the change.\n\n**Procedure**\n1. Draft one remediation ticket per finding — rotate, re-issue, restrict access, destroy, or migrate to an approved algorithm — pre-filled with the affected key/certificate, its owner, the policy clause violated, the proposed action, and a due date within policy timelines.\n2. Sequence the tickets around application dependencies and maintenance windows; note where an interim mitigation is needed for an exposure that cannot be fixed immediately.\n3. Track execution, recording change references, replacement key/certificate identifiers, and the disposition of superseded material.\n4. After each action completes, re-query the affected store and compare before/after: the replacement uses an approved algorithm and length; rotation timestamps and automation now meet policy; renewed certificates are deployed and serving; superseded versions are disabled or destroyed per the retention rule; revoked grants no longer appear in the ACLs.\n5. Assemble a before-and-after evidence pair per finding and mark each ticket verified, still failing, or proposed for deferral.\n\n**Record in AssureSwarm** — Create one **Issue item** per confirmed finding (`coach-item-create`): `issue_type: deficiency` (or `exception` for an exposure accepted and tracked rather than fixed), `severity`, `source: compliance_review`, `description`, `recommendation`, `remediation_plan`, `issue_owner`, `identified_date`, `target_remediation_date`. Link each Issue to the anchor Audit and to the breached **Control** item (`domains: cryptography_key_management`) via item relationships. Attach the before/after evidence pair to each Issue as documents. On verified closure set `actual_remediation_date` and `verified_date`; a deferral keeps the Issue open with its `target_remediation_date` and the interim mitigation recorded.\n\n**Exit criteria** — Every drafted ticket was approved before dispatch; no old key was destroyed before its consumers were verified on the replacement; each closure is approved only when post-change re-query evidence shows the finding resolved; each deferral has an accepted interim mitigation, an owner, and a follow-up date.","label":"Remediate and verify","performedBy":{"primitives":["coach-item-create"]}},"id":"remediate-and-verify"},{"data":{"description":"Judge the evidence-backed attestation and indexed redacted package, sign and release the report, and govern live deferrals and expiry/deprecation follow-up.","instructions":"**Objective** — Judge the evidence-backed attestation and indexed redacted package, sign and release the report, and govern live deferrals and expiry/deprecation follow-up.\n\n**Inputs**\n- The submitted decision outcome and rationale.\n- The findings register and, where the remediation branch ran, the verified before/after remediation evidence.\n- The consolidated inventory (population counts by store and key type).\n- The distribution list: security leadership, affected platform owners, and the compliance register.\n- The review scope statement (workflow input).\n- The raw store exports, the consolidated inventory and findings sheet, and the ownership/custody evidence.\n- The submitted decision form and its rationale.\n- The remediation items with their before/after verification pairs (where that branch ran).\n- The signed attestation and stakeholder report, with the references confirming it was distributed.\n- The list of open deferrals and accepted risks carried out of remediation and the decision.\n- The policy review cadence plus the upcoming certificate-expiry and algorithm-deprecation dates.\n\n**Procedure**\n_This checkpoint absorbs “File review evidence”. 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. Attest and report: Draft the attestation stating the period covered, the population reviewed with counts by store and key type, the methodology, the decision outcome, verified remediation results where that branch ran, and any accepted residual risks or open deferrals with owners and dates.\n2. Map the conclusion to ISO 27001 control A.8.24 and NIST SP 800-53 controls SC-12 and SC-13, citing the evidence behind each statement.\n3. Compile the stakeholder report from the attestation and the findings register and stage it for the distribution list.\n4. Cross-check the draft so every open item in the findings register appears in the report and no statement contradicts a verified finding status.\n5. File review evidence: Collect every artifact listed above into one package.\n6. Apply consistent naming and dates and build an index that traces every finding from detection through disposition.\n7. Scan the package for raw secret values or private-key material and redact or restrict them per the classification rules.\n8. Link the indexed package to the review record in the designated evidence repository with the retention label applied.\n9. Before releasing the stakeholder report or archive, the review owner walks the index: every step's outputs are present, every finding traces end to end, no sensitive key material survived redaction, the package is filed under the correct retention policy, and the signed attestation was distributed with its confirmation references listed. Approve the package as complete and archive-ready, or return it naming what is missing or under-redacted.\n10. Draft a carry-forward entry for every open deferral or accepted risk, targeted at the operational risk or issue register, each with an owner, a due date, and a link back to its originating finding.\n11. Compute the next periodic review date from the policy cadence, plus interim checkpoints tied to upcoming certificate expiries and algorithm-deprecation dates, and set the calendar entries.\n12. Export the complete workflow record — steps, decision, evidence links, and sign-offs — as the archive copy, and send the closure notice to stakeholders.\n\n**Record in AssureSwarm**\nAttach the signed cryptographic key management attestation (PDF) and the stakeholder report (DOCX/PDF) to this step as documents (`coach-document-upload`). On the anchor Audit item set `report_date` = the sign-off date and `rating` = `satisfactory` (compliant, no open exposure) or `needs_improvement` (remediation ran or deferrals stand) via `coach-item-update`; the review owner is already `Audit.lead_auditor` on the record.\nLink the indexed, redacted evidence package to the anchor Audit item — the review record — via `coach-document-link`. Studio has no retention-label field, so the retention label is applied in the evidence repository (and the package name) and noted alongside the link. Export the complete workflow instance (steps, decision, evidence links, sign-offs) as the immutable archive copy (`coach-workflow-export`), attached to the anchor Audit item. Rehome every open item: each accepted residual crypto exposure becomes a **Risk item** (`category: cyber_security`, `domains: cryptography_key_management`, `treatment: accept`, `residual_rating` set, `risk_owner` named), and each open deferral stays as its **Issue item** with a live `target_remediation_date` — both linked to the anchor Audit via item relationships (`coach-item-create`). Record the next-review date and interim expiry/deprecation checkpoints in the closure note document on this step — Studio has no scheduler field, so recurrence is operated outside AssureSwarm — and send the closure notice.\n\n**Exit criteria**\n- The review owner has read the draft against the findings register, corrected any statement not supported by evidence, signed the attestation, and released the report to the distribution list; sign-off identity and date are recorded.\n- The index is walked and every step's outputs are present; every finding traces end to end; no sensitive key material survived redaction; the package is filed under the correct retention policy with the archive reference recorded; every open item has a home in a live register with an owner and due date; the next review date and interim checkpoints are approved and calendared; the closure notice is sent; and the owner's approval on this step marks the review closed.","label":"Attest and report","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-workflow-export","coach-item-create"]}},"id":"attest-and-report"}],"sourceTemplateId":"workflow-library:controls-key-management-crypto-review"}