{"description":"Authorized Software & Component Integrity Control run as a decision-aware monthly cycle that enriches the existing \"Authorized Software & Component Integrity\" Control item in the control library (control_id UC-CONFIG-05/UC-CONFIG-06, frequency monthly, domains secure_configuration_change_management + third_party_supply_chain_risk) — each run is a workflow instance attached to that Control item, never a newly created control. It originates on its own (parallel entry threads consuming the cycle's own software-inventory, catalog/allowlist, install-rights, supplier-intake, and telemetry feeds) and also carries forward the prior cycle's still-open Issue items linked to the same Control. In scope: reconciling installed software across the in-scope endpoints, servers, and system images against the approved catalog and technical allowlist (the discrepancy register), triaging unauthorized installations to catalog-update / removal / escalation, verifying installation rights stay restricted to the authorized-installer roster from trusted sources (the install-rights and trusted-source exception list), tracking usage against license entitlements (the license-position report), and verifying supplier trust and signature integrity for every component acquired this cycle (the component verification register). Named deliverables — the discrepancy register, triage dispositions, catalog/allowlist change record, per-host removal evidence, install-rights and trusted-source exception list, component verification register, blocked-component investigation findings, and license-position report — are archived as the signed monthly cycle record on the workflow instance. Out of scope: incident containment and forensics — any suspected-malicious component is handed off, evidence intact, to the incident-response workflow, which owns that containment; this control cycle does not duplicate it.","edges":[{"id":"e-triage-unauthorized-installations-close-and-archive","source":"triage-unauthorized-installations","target":"close-and-archive"},{"id":"e-triage-unauthorized-installations-update-catalog-and-allowlist-entries","label":"Catalog update","source":"triage-unauthorized-installations","target":"update-catalog-and-allowlist-entries","whenValue":"catalog_update_approved"},{"id":"e-triage-unauthorized-installations-remove-and-remediate-unauthorized-software","label":"Removal","source":"triage-unauthorized-installations","target":"remove-and-remediate-unauthorized-software","whenValue":"removal_required"},{"id":"e-triage-unauthorized-installations-escalate-suspected-malicious-components","label":"Escalate","source":"triage-unauthorized-installations","target":"escalate-suspected-malicious-components","whenValue":"escalate_to_incident_response"},{"id":"e-update-catalog-and-allowlist-entries-close-and-archive","source":"update-catalog-and-allowlist-entries","target":"close-and-archive"},{"id":"e-remove-and-remediate-unauthorized-software-close-and-archive","source":"remove-and-remediate-unauthorized-software","target":"close-and-archive"},{"id":"e-escalate-suspected-malicious-components-close-and-archive","source":"escalate-suspected-malicious-components","target":"close-and-archive"},{"id":"e-verify-supplier-trust-and-signature-integrity-investigate-blocked-components","label":"Failed","source":"verify-supplier-trust-and-signature-integrity","target":"investigate-blocked-components","whenValue":"failed_block_and_investigate"},{"id":"e-verify-supplier-trust-and-signature-integrity-close-and-archive","label":"Cleared","source":"verify-supplier-trust-and-signature-integrity","target":"close-and-archive","whenValue":"verified_cleared"},{"id":"e-investigate-blocked-components-close-and-archive","source":"investigate-blocked-components","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CONFIG-05","UC-CONFIG-06"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-authorized-software-component-integrity-control","contentDigest":"sha256:b53f505729c73529b0c617f56c09fe8bc6d9c256b403c66b164c684e8fed5372","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b53f505729c73529b0c617f56c09fe8bc6d9c256b403c66b164c684e8fed5372","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-authorized-software-component-integrity-control"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-authorized-software-component-integrity-control","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001","soc2","nist-csf-2"],"teams":["it"]},"name":"Authorized Software & Component Integrity Control","nodes":[{"data":{"decisionField":"unauthorized_software_disposition","description":"Classify reconciled software discrepancies as legitimate catalog omissions, unauthorized installations or suspected malicious components, including mixed-batch separation.","formData":{"fields":[{"key":"unauthorized_software_disposition","label":"Unauthorized Software Disposition","options":[{"label":"Approvable, add to catalog","value":"catalog_update_approved"},{"label":"Unauthorized, remove/quarantine","value":"removal_required"},{"label":"Suspected malicious, escalate to IR","value":"escalate_to_incident_response"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Classify reconciled software discrepancies as legitimate catalog omissions, unauthorized installations or suspected malicious components, including mixed-batch separation.\n\n**Inputs**\n- Endpoint and server software-inventory feeds (installed applications, executables, running services) for every in-scope host, with the host's last check-in time; the expected in-scope host count for coverage math.\n- The approved software catalog (current version) and the technical allowlist ruleset, including any time-boxed allowlist exceptions and their expiry dates.\n- Anti-malware and endpoint-detection-and-response (EDR) telemetry for the same period (unauthorized-execution blocks, quarantines, malware detections).\n- The anchor: the existing \"Authorized Software & Component Integrity\" Control item (control_id UC-CONFIG-05/UC-CONFIG-06) this monthly run enriches — its Control.framework (nist-800-53, iso-27001, soc2, nist-csf-2) sets the governing standards. Prior-cycle carry-forward Issue items linked to this Control (open catalog changes, unresolved investigations, open escalations, queued true-ups) arrive as existing-item inputs to reconcile against.\n- This node is a parallel entry: it consumes the cycle's own initial inputs, not another node's output, and no separate upstream workflow feeds it.\n\n**Procedure**\n_This checkpoint absorbs “Reconcile estate against catalog and allowlist”. 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. Reconcile estate against catalog and allowlist: Pull the installed-software inventory from every in-scope endpoint and server, capturing host, package name, version, install source, and install date. Record which hosts reported and which did not.\n2. Reconcile each installed item against the approved catalog and the allowlist ruleset, tagging every discrepancy by type: installed-but-not-cataloged (unknown software), cataloged-but-blocked-by-allowlist (policy conflict), and allowlist-exception-past-expiry (a temporary approval that should have lapsed).\n3. Cross-reference the flagged items against anti-malware/EDR telemetry, joining any execution block, quarantine, or malware detection to the discrepancy list by host and file hash so a security signal travels with the discrepancy it belongs to.\n4. Compute coverage: agents reporting divided by expected in-scope hosts. Treat any host that has not checked in within the cycle window as a coverage gap, not a clean host, and list it explicitly — an unreported host is an unknown, not an implied pass.\n5. Compile the discrepancy register: one row per finding with host, software, version, source, discrepancy type, any joined security signal, and the coverage summary. Do not disposition anything here — that is the triage decision.\n\n**Decision criteria**\n- Before deciding, the agent enriches each discrepancy: business-justification history, requester, and any prior approval (coach-query-data); the hash and behaviour signature of every anti-malware/EDR-flagged item checked against threat-intelligence and known-malware indicators; and a scan of open workflows (coach-workflow-scan) to detect any incident-response case a flagged item already belongs to, so no duplicate escalation is raised.\n- Pick `catalog_update_approved` when the software is a legitimate, business-justified tool merely missing from the approved catalog or blocked by a stale allowlist rule, with no malware signal — the fix is to formally catalog and allowlist it.\n- Pick `removal_required` when the software is unauthorized and has no legitimate business justification but shows no evidence of malice (e.g. unsanctioned utilities, personal software, an unapproved but benign application) — the fix is removal plus active allowlist blocking.\n- Pick `escalate_to_incident_response` when any item carries a malware detection, a matched malicious indicator, or behaviour consistent with tampering or compromise — this must reach incident response immediately with evidence intact; do not attempt removal first, which can destroy evidence.\n- When a batch spans more than one disposition, split it and record a rationale per group; never force mixed findings under a single disposition.\n\n**Record in AssureSwarm**\n- Query the software inventory, the approved catalog/allowlist ruleset, and anti-malware/EDR telemetry from their source systems with coach-query-data — Studio has no native Software-Asset or Catalog type, so these stay in the external systems and the reconciled extract is the AssureSwarm evidence copy.\n- Attach the **discrepancy register** (XLSX/CSV, one row per finding with host, software, version, source, discrepancy type, joined security signal) and the coverage summary to this step with coach-document-upload. This run is a workflow instance on the existing Control item (UC-CONFIG-05/UC-CONFIG-06), so the register is the cycle's primary evidence artifact — do not create catalog items for it.\n- Submit this step's decision form: the `unauthorized_software_disposition` SELECT field with the chosen value, the step result (evidence references per group), and the step's approver record.\n- Attach the **triage recommendation** (document on this step) grouping the register's discrepancies by proposed disposition, with coach-document-upload.\n\n**Exit criteria**\n- Coverage is complete or every gap is listed as an explicit exception; every installed item is reconciled and each discrepancy is typed; the register with joined security signals is attached and ready for triage.\n- The `unauthorized_software_disposition` field is submitted with a documented rationale and owner; each discrepancy group is routed to exactly one disposition; branches not taken are prunable.","kind":"decision","label":"Triage unauthorized installations","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-workflow-scan"]}},"id":"triage-unauthorized-installations"},{"data":{"description":"Agent drafts and routes the catalog/allowlist change for approvable software; human confirms change-control approval before enforcement updates","instructions":"**Objective** — Bring legitimate-but-uncataloged software formally into the approved catalog and allowlist under change control so future reconciliation cycles recognise it instead of re-flagging it.\n\n**Inputs**\n- The triage decision groups marked `catalog_update_approved`, with the business justification, requester, and evidence references carried from triage.\n- The approved software catalog and allowlist ruleset (the records to be amended) and the organisation's change-control / CAB process.\n\n**Procedure**\n1. Draft a catalog-and-allowlist change request for each approvable item as an **Issue item** with coach-item-create (issue_type: exception, source: management_identified, description = the software, publisher, business justification, requester, and proposed catalog category, identified_date set) — Studio has no native Change-Request or Software-Catalog type, so the change request is carried as a management-identified exception Issue.\n2. Link each change-request Issue to the anchor Control item with coach-items-link (Issue ↔ Control) so the audit trail from this cycle's finding to the approved change is unbroken.\n3. Route each change request through the standard change-control / CAB process; do not amend the catalog or the enforcement allowlist before a named approver signs off.\n4. On approval, record the named approver in the Issue's exception_approver field and update the approved catalog and allowlist ruleset (in the external enforcement system) with the new entries and their effective date.\n5. Attach the updated catalog/allowlist extract and the approval evidence with coach-document-upload.\n\n**Record in AssureSwarm**\n- Create change-request Issue items (coach-item-create — issue_type: exception, source: management_identified, exception_approver set on sign-off) and link each to the anchor Control item (coach-items-link, Issue ↔ Control).\n- Attach the updated **catalog/allowlist extract** and change-control approval evidence (named approver + effective date) as documents on this step (coach-document-upload); the authoritative catalog lives in the external enforcement system, this is its AssureSwarm evidence copy.\n\n**Exit criteria** — Every catalog and allowlist update carries a named change-control approver and effective date; each is linked to its source discrepancy; the enforcement ruleset is amended only after approval and the updated extract is attached.","label":"Update catalog and allowlist entries","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"update-catalog-and-allowlist-entries"},{"data":{"description":"Agent tickets removal, drives allowlist enforcement, and re-scans to verify; human confirms every flagged installation is verifiably gone","instructions":"**Objective** — Eliminate unauthorized, non-malicious software from the estate and reinforce technical enforcement so it cannot silently return, with per-host proof of removal.\n\n**Inputs**\n- The triage decision groups marked `removal_required`, with host, software, and version per finding.\n- Access to the owning system administrators and the allowlist enforcement ruleset.\n\n**Procedure**\n1. Create a removal/quarantine ticket for each unauthorized installation as an **Issue item** with coach-item-create (issue_type: finding, source: management_identified, severity per host exposure, issue_owner = the owning system administrator, description = host + software + version + required action, target_remediation_date set), and link it to the anchor Control item with coach-items-link (Issue ↔ Control) — Studio has no native Ticket type, so the removal ticket is a finding Issue.\n2. Route tickets to the owning system administrators for execution, and confirm the allowlist ruleset is set to actively block re-execution and reinstallation of the removed software across the whole estate — not just on the host where it was found.\n3. After remediation, re-query each affected host with coach-query-data to confirm the software no longer appears in the installed inventory or in running processes.\n4. Compile before/after evidence per host. On a clean re-scan, set the removal Issue's actual_remediation_date and verified_date with coach-item-update. Any host still showing the software after remediation is not closed — send it back through step 1 and re-verify; closure requires a clean re-scan.\n\n**Record in AssureSwarm**\n- Create removal Issue items (coach-item-create — issue_type: finding, issue_owner = owning sysadmin, target_remediation_date set) and link each to the anchor Control (coach-items-link, Issue ↔ Control).\n- Re-query affected hosts (coach-query-data); on a clean re-scan update Issue.actual_remediation_date + Issue.verified_date (coach-item-update) and attach the **per-host before/after removal evidence** as documents on this step (coach-document-upload).\n\n**Exit criteria** — Every flagged installation is verified removed by a clean re-scan and is actively blocked by the allowlist; no in-scope host still reports the software; before/after evidence is attached for each host.","label":"Remove and remediate unauthorized software","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-query-data","coach-item-update","coach-document-upload"]}},"id":"remove-and-remediate-unauthorized-software"},{"data":{"description":"Agent packages evidence and hands the finding to incident response without attempting containment here; human confirms the handoff was accepted with evidence intact","instructions":"**Objective** — Get every suspected-malicious finding into the incident-response process quickly with a clean chain of custody, without this control cycle duplicating containment that belongs to the incident-response workflow.\n\n**Inputs**\n- The triage decision groups marked `escalate_to_incident_response`, with file hashes, host telemetry, anti-malware detection detail, and discovery timeline.\n- The security-operations on-call contact and the incident-response case queue.\n\n**Procedure**\n1. Package the evidence for each suspected-malicious component as an **Issue item** with coach-item-create (issue_type: finding, severity: critical, source: management_identified, description = file hashes, affected hosts, anti-malware/EDR detection detail, and discovery timeline, identified_date set) — preserving chain-of-custody metadata (who found it, when, from where).\n2. Scan for or open the linked incident case with coach-workflow-scan, then link this finding Issue to that case's anchor item with coach-items-link so it is tracked as an input to incident response, not a duplicate case; also link it to the anchor Control item.\n3. Notify the security-operations on-call contact of the escalation and the evidence location; do not perform containment (isolation, deletion, reimaging) here — that is the incident-response workflow's job, and acting first can destroy evidence or collide with their response.\n4. Attach the evidence package and the escalation record with coach-document-upload.\n\n**Record in AssureSwarm**\n- Create the evidence-package Issue item (coach-item-create — issue_type: finding, severity: critical), scan for and link the incident case (coach-workflow-scan, coach-items-link — to the incident case's anchor item and to this Control), notify on-call (coach-notify), and attach the **suspected-malicious evidence package + escalation record** as the handoff document on this step (coach-document-upload) — the incident-response workflow's intake step consumes this package with chain of custody intact.\n\n**Exit criteria** — Incident response has accepted the handoff with the evidence package intact and linked to a tracked case; no containment action has been performed twice; the escalation record is attached.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` routes the escalation and evidence location to the security-operations on-call contact and records the notification.","label":"Escalate suspected malicious components","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload","coach-notify"]}},"id":"escalate-suspected-malicious-components"},{"data":{"decisionField":"component_verification_disposition","description":"Agent checks every software, firmware, and update acquired this cycle against the trusted-supplier list and signature/integrity evidence; human decides disposition for each","formData":{"fields":[{"key":"component_verification_disposition","label":"Component Verification Disposition","options":[{"label":"Verified, cleared for installation","value":"verified_cleared"},{"label":"Failed verification, block and investigate","value":"failed_block_and_investigate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide, for everything entering the estate this cycle, whether every component passed supplier-trust and signature/integrity verification (cleared for installation) or any component failed either check (blocked for investigation). The control owner owns this decision.\n\n**Decision criteria**\n- Before deciding, the agent builds the verification register: it queries the intake log of software, firmware, and updates acquired or staged this cycle (coach-query-data), capturing supplier, acquisition channel, and intended install targets; verifies each item's supplier against the trusted-supplier list — the **Vendor register** (Vendor items: category e.g. saas_software/hardware_supplier, tier, monitoring_status), which is the Studio home for approved suppliers — flagging any component sourced outside an enrolled/approved Vendor or channel; and verifies the digital signature, checksum, or equivalent integrity evidence on each component against the publisher's published reference before installation, recording pass/fail for every item including firmware and update packages.\n- Pick `verified_cleared` only when every intake component sourced from a trusted supplier/channel AND passed signature/integrity verification against the publisher reference — no failures, no unresolved unknowns.\n- Pick `failed_block_and_investigate` when any component was sourced outside an approved supplier or channel, or failed signature/checksum/integrity verification, or cannot be verified against a publisher reference at all. A single failed or unverifiable component sends the batch down this branch; a passing subset does not override a failure.\n\n**Record in AssureSwarm**\n- Submit this step's decision form: `component_verification_disposition` (the SELECT value), the step result (per-component supplier and signature results), and the step's approver record.\n- Attach the **component verification register** (XLSX/CSV, one row per intake component with supplier-trust result and signature/integrity pass-fail) as a document on this step (coach-document-upload); supplier trust is checked against the Vendor register, but the per-component result set has no native field and lives in this register document.\n\n**Exit criteria** — The `component_verification_disposition` field is submitted with a documented rationale and owner; every intake component has a recorded supplier-trust and signature result; branches not taken are prunable.","kind":"decision","label":"Verify supplier trust and signature integrity","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-supplier-trust-and-signature-integrity"},{"data":{"description":"Agent quarantines the failed component and drives supplier/tamper investigation; human confirms disposition before the component is destroyed, returned, or escalated","formData":{"fields":[{"key":"published_artifact_hash","label":"Published hash / checksum of the authentic artifact for this version","required":false,"type":"text"},{"key":"artifact_authenticity","label":"Is the artifact as received the one you published?","options":[{"label":"Yes — published by us exactly as received","value":"published_as_received"},{"label":"No — repackaged or redistributed by a third party","value":"repackaged_by_third_party"},{"label":"No — we did not publish this artifact","value":"not_published_by_us"},{"label":"Unable to confirm","value":"unable_to_confirm"}],"required":false,"type":"select"},{"key":"signing_certificate_status","label":"Status of the signing certificate used for this release","options":[{"label":"Valid and current","value":"valid"},{"label":"Expired at time of signing or since","value":"expired"},{"label":"Revoked","value":"revoked"},{"label":"Not a certificate we control","value":"not_ours"}],"required":false,"type":"select"},{"key":"known_signing_or_packaging_issue","label":"Known signing, packaging or distribution issue affecting this release","required":false,"type":"textarea"},{"key":"corrected_artifact_reference","label":"Reference or download location of a corrected, re-verifiable artifact (if one exists)","required":false,"type":"text"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Contain and investigate every component that failed supplier-trust or signature verification so a tampered, counterfeit, or unauthenticated component is never installed and its source is understood.\n\n**Inputs**\n- The verification-register entries marked failed, with supplier, channel, and the specific failure (untrusted source, signature mismatch, checksum failure, unverifiable).\n- The trusted-supplier contact channel and the incident-response / vendor-risk escalation paths.\n- The supplier's provenance confirmation for each failed component, collected on this step's form.\n\n**Missing-input gate** — Before any form request below, inspect the existing source records, reports and correspondence. Reuse every established fact and record its source. Send a form only when a listed fact remains genuinely unresolved and the named respondent is outside the complete roster of people executing or approving any checkpoint in this workflow. If the respondent is on that roster, record their contribution in native results and approvals. Ask only the unresolved fields; leave known, unasked or inapplicable fields optional and blank. Skip the form entirely when no missing facts remain. Attach evidence documents and record sign-off through native approval. References below to form answers or completion also accept the existing authoritative record or native participant contribution.\n\n**Procedure**\n1. Quarantine each failed component out of deployment staging by raising an **Issue item** with coach-item-create (issue_type: finding, source: management_identified, description = component, supplier, and the specific failure), blocking it from every installation target, and link it to the anchor Control item with coach-items-link (Issue ↔ Control).\n2. Investigate the failure: re-check the signature/checksum against an independent reference copy of the publisher's artifact; send this step's provenance form to the supplier through the trusted-supplier contact channel to confirm whether the artifact as received is what they published and what the signing certificate's status is; and determine whether the failure indicates tampering, a counterfeit component, or a benign signing/packaging error (e.g. an expired certificate, a re-packaged installer). A supplier who cannot confirm provenance is treated as an unconfirmed artifact, not a pass.\n3. Where tampering or counterfeiting is confirmed, escalate to incident response and to vendor / supply-chain risk management with coach-items-link. Where the failure is a benign publisher-side error, request a corrected, re-verifiable copy from the supplier and route it back through supplier-trust and signature verification — it may not be installed until it passes.\n4. Record the tamper / counterfeit / benign determination in each Issue's root_cause field, and document the investigation findings and final disposition per component with coach-document-upload.\n\n**Record in AssureSwarm**\n- Raise quarantine Issue items (coach-item-create — issue_type: finding, root_cause = tamper/counterfeit/benign determination); link each to the anchor Control and to any incident-response or vendor-risk case's anchor item (coach-items-link); attach the **blocked-component investigation findings** and disposition as a document on this step (coach-document-upload).\n- The form on this step, answered by the supplier's product security or release-engineering contact, captures only the publisher-authentic hash, received-artifact authenticity, signing-certificate status, known signing or packaging issues and any corrected-artifact reference. The failed verification record supplies component/version, and the trusted assignment and response timestamp supply attribution — it is the provenance evidence behind the tamper / counterfeit / benign determination.\n\n**Exit criteria** — Every blocked component has a confirmed disposition — destroyed, returned to supplier, or escalated — and none proceeds to installation without re-passing verification; each determination is supported by the supplier's provenance response or by a recorded non-response; findings are attached and linked to their register entry.\n\n**Form recipient** — The supplier's product security or release-engineering contact supplies only publisher-authentic artifact hash; authenticity of the received artifact; signing-certificate status; known signing or packaging issue; corrected artifact reference when available only when this gate permits the assigned form. The workflow executor records their own analysis in the step result.","label":"Investigate blocked components","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"investigate-blocked-components"},{"data":{"description":"Judge install privileges and repository restrictions against the approved roster, and decide true-up versus removal for license over-deployment before recording the cycle outcome.","instructions":"**Objective** — Judge install privileges and repository restrictions against the approved roster, and decide true-up versus removal for license over-deployment before recording the cycle outcome.\n\n**Inputs**\n- Local-administrator and software-install-privilege grants across the in-scope estate (account, host/scope, grant date, last-used).\n- The authorized-installer roster (the definitive list of who may install software) and the HR/joiner-mover-leaver feed for detecting stale grants.\n- The approved trusted-source / repository configuration (which package sources systems may install from).\n- This node is a parallel entry: it consumes the cycle's initial inputs, not another node's output.\n- The reconciled installed-software inventory produced by the estate-reconciliation step (the authoritative install picture for this cycle), plus usage/activation telemetry.\n- The license and contract entitlement register: entitled quantities, editions, and renewal/expiry dates per product.\n- All outputs of this cycle's threads: the discrepancy register, triage decisions, catalog/allowlist updates, removal and escalation evidence, the install-rights and trusted-source exception list, the verification register, blocked-component investigation findings, and the license-position report.\n- The designated evidence repository (under retention controls) and the control execution log.\n\n**Procedure**\n_This checkpoint absorbs “Verify installation rights restricted”, “Track license and entitlement compliance”. 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. Verify installation rights restricted: Query install-privilege grants across the estate with coach-query-data and cross-reference each grant holder against the authorized-installer roster.\n2. Flag every account holding install rights that is not on the roster, including stale grants for departed or transferred personnel (join against the leaver/mover feed), and every service or shared account with standing install rights that lacks an owner.\n3. Flag every system configured to accept packages from a source other than the approved trusted repositories.\n4. Verify technical enforcement is genuinely active — not merely policy on paper — on a representative sample of in-scope systems: policy-level restriction of user-installed software, and package-manager/repository configuration pinned to trusted sources.\n5. Compile the install-rights and trusted-source exception list, each exception tagged with a recommended remediation (revoke, re-scope, or repoint to a trusted source).\n6. Track license and entitlement compliance: Query the reconciled inventory together with usage/activation telemetry (coach-query-data) and aggregate installation and active-use counts by product and edition — distinguish installed-but-idle from actively used, since some agreements meter on use rather than install.\n7. Compare the counts against the license/contract entitlement register, computing entitled quantity, deployed quantity, and variance per product. Flag every over-deployment (deployed > entitled) and every entitlement within its renewal/expiry window.\n8. Draft a true-up or renewal action for each over-deployment or expiring entitlement as an **Issue item** with coach-item-create (issue_type: exception, source: management_identified, issue_owner set, target_remediation_date = the due date, description = product, variance, and estimated cost impact), and link it to the anchor Control item with coach-items-link (Issue ↔ Control) — Studio has no native License/Entitlement type, so the entitlement register stays external and the true-up is tracked as an exception Issue. Where an over-deployment is cheaper to remediate by removing installs than by buying licenses, note the removal option.\n9. Compile the license-position report: per-product entitled/deployed/variance, expiring entitlements, and queued actions.\n10. Close and archive: Export the full operating record of this workflow instance — every artifact listed above — with coach-workflow-export and archive it in the designated evidence repository under retention controls, recording the archive location and reference. The workflow instance itself is the audit trail.\n11. Compile the control execution log for the cycle — discrepancy count, removal and escalation counts, install-rights exceptions, verification pass rate, and license variance — as a document; Control has no native metric fields, so this KPI log is attached to the anchor Control item as evidence rather than stored as item fields.\n12. Create carry-forward **Issue items** with coach-item-create for anything still open — pending catalog changes, unresolved blocked-component investigations, escalations still with incident response, and queued license true-ups — and link each to its source Issue and to the anchor Control with coach-items-link so it arrives as an explicit existing-item input to next month's run.\n13. Confirm the next monthly cycle is scheduled and attach the closure record with coach-document-upload.\n\n**Record in AssureSwarm**\n- Query grants and enforcement config with coach-query-data — the install-privilege grants, roster, and trusted-source config live in the external IdP/endpoint/HR/repo systems (no native Studio type), so the reconciled result is the AssureSwarm evidence.\n- Attach the **install-rights and trusted-source exception list** (XLSX/CSV, each exception tagged revoke / re-scope / repoint-to-trusted-source) as a document on this step with coach-document-upload.\n- For any material exception that needs tracked remediation, raise an **Issue item** (coach-item-create — issue_type: exception, source: management_identified, description = the account/system and remediation direction) linked to the anchor Control (coach-items-link, Issue ↔ Control).\n- Query the reconciled inventory and usage (coach-query-data — the entitlement register is external, no native Studio type); create true-up/renewal Issue items (coach-item-create — issue_type: exception, issue_owner + target_remediation_date set) and link each to the anchor Control (coach-items-link, Issue ↔ Control); attach the **license-position report** (XLSX) as a document on this step (coach-document-upload).\n- Export and archive this workflow instance's cycle record (coach-workflow-export) — the run is the audit trail.\n- Create carry-forward Issue items (coach-item-create) and link each to its source Issue and the anchor Control (coach-items-link, Issue ↔ Control).\n- Attach the **control execution log** (KPI metrics document, on the anchor Control) and the closure record as documents on this step (coach-document-upload).\n\n**Exit criteria**\n- Install rights reconcile to the authorized-installer roster with every off-roster or stale grant listed; installation sources are confirmed pinned to trusted repositories on the sampled systems; each exception carries a remediation direction and is attached.\n- The license position is reconciled per product with variance computed; every over-deployment has a queued true-up or removal action and every expiring entitlement has an owner and due date; the report is attached.\n- The archived record is immutable and retrievable under retention controls; the execution log carries the cycle metrics; nothing remains open without a tracked owner and a link into the next cycle; the control owner has declared the cycle closed.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` exports the full signed cycle record — registers, decisions, and evidence — as the archival package under retention controls.","label":"Close and archive","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-workflow-export"]}},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-authorized-software-component-integrity-control"}