{"description":"Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).","edges":[{"id":"e-reconcile-discovery-against-inventory-investigate-and-remediate-discrepancies","label":"Investigation required","source":"reconcile-discovery-against-inventory","target":"investigate-and-remediate-discrepancies","whenValue":"investigation_required"},{"id":"e-reconcile-discovery-against-inventory-confirm-inventory-attributes-and-scope","label":"Corrections applied","source":"reconcile-discovery-against-inventory","target":"confirm-inventory-attributes-and-scope","whenValue":"corrections_applied"},{"id":"e-investigate-and-remediate-discrepancies-confirm-inventory-attributes-and-scope","source":"investigate-and-remediate-discrepancies","target":"confirm-inventory-attributes-and-scope"},{"id":"e-confirm-inventory-attributes-and-scope-determine-relabeling-scope","source":"confirm-inventory-attributes-and-scope","target":"determine-relabeling-scope"},{"id":"e-determine-relabeling-scope-refresh-labels-and-handling-markings","label":"Relabel required","source":"determine-relabeling-scope","target":"refresh-labels-and-handling-markings","whenValue":"relabel_required"},{"id":"e-determine-relabeling-scope-compile-reconciliation-and-classification-record","label":"Labels current","source":"determine-relabeling-scope","target":"compile-reconciliation-and-classification-record","whenValue":"labels_current"},{"id":"e-refresh-labels-and-handling-markings-compile-reconciliation-and-classification-record","source":"refresh-labels-and-handling-markings","target":"compile-reconciliation-and-classification-record"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ASSET-01","UC-ASSET-03","UC-ASSET-02","UC-CONFIG-10"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-it-asset-inventory-classification-upkeep","contentDigest":"sha256:2cd86cbfcb83530b6da3ecc02e70ac2401a88e640f6f935ee49a6a938e2b709d","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:2cd86cbfcb83530b6da3ecc02e70ac2401a88e640f6f935ee49a6a938e2b709d","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-it-asset-inventory-classification-upkeep"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-it-asset-inventory-classification-upkeep","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","iso-27001","soc2"],"teams":["it"]},"name":"IT Asset Inventory & Classification Upkeep","nodes":[{"data":{"decisionField":"reconciliation_disposition","description":"Agent assembles the inventory, discovery, and change-log baseline, compares discovery results to the register, and scores each discrepancy; human decides whether corrections can be applied directly or an investigation is required","formData":{"fields":[{"key":"reconciliation_disposition","label":"Reconciliation Disposition","options":[{"label":"Corrections applied, no investigation needed","value":"corrections_applied"},{"label":"Investigation required before correcting record","value":"investigation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Assemble the complete comparison baseline (inventory register, independent discovery evidence, change log, and prior carry-forward items), reconcile the register against it, and decide whether the discrepancies can be corrected directly or an investigation must open first; owned by the IT asset manager.\n\n**Inputs**\n- The current inventory register: every in-scope hardware, software, system, and service with owner, location, and security attributes (criticality, environment, network zone). Studio has no Asset item type — the authoritative register lives in the external ITAM/CMDB; AssureSwarm holds it as the baseline extract document attached to this step.\n- Latest discovery-scan results from each source class (network, endpoint, cloud, SaaS) — external scanner extracts uploaded to this step.\n- Install, removal, and change records logged since the last reconciliation — a CSV extract from the change/ticketing system, folded into the baseline extract document.\n- The prior cycle's carry-forward items — Issue items created at the prior run's closure (source: management_identified) linked to the anchor Control, covering open investigations, deferred corrections, and next scheduled scan/review dates — plus the prior run's archived workflow instance and closure record. This workflow has no upstream workflow; its inputs are the org's live inventory and discovery systems.\n- The anchor Control item and its related Control items (matched via control_id / framework / domains in the control library): the scope reference for this cycle — which asset categories and business units are in scope, restated in the anchor Control.description — and the control references it operates (CM-8 / PM-5; NIST CSF ID.AM-01, ID.AM-02, ID.AM-05; ISO 27001 A.5.9).\n\n**Procedure**\n_Items 1–9 are agent-run (items 1–5 folded from the former \"Compile inventory and discovery baseline\" step); the human moment is the disposition in item 10._\n1. Pull the current inventory register with coach-query-data, covering every in-scope asset record with its owner, location, and security attributes.\n2. Pull the latest discovery-scan results across all four source classes with coach-query-data, and pull every install, removal, and change record logged since the last reconciliation.\n3. Cross-index inventory ↔ discovery ↔ change log by a stable asset identifier (serial / hostname / asset tag / software SKU). Normalize identifiers first so the same asset seen by two scanners is not double-counted.\n4. Detect silent gaps: flag any discovery source that returned zero or far fewer records than last cycle — a missing feed must be caught now, not mistaken for a clean scan. Record each source's record count against the prior cycle's.\n5. Compile the baseline extract: total in-scope population count, per-source counts, and the prior carry-forward items folded in so nothing open from last cycle is dropped.\n6. Compare discovery results to the register and classify each discrepancy as discovered-not-registered (possible unauthorized/shadow asset), registered-not-discovered (possible undocumented decommission), or attribute-mismatch (owner, location, or security attribute drifted).\n7. Cross-check each discrepancy against the install/removal/change records to see whether a logged-but-unposted change already explains it.\n8. Build a discrepancy dashboard with coach-dashboard-create showing counts by type, age, and business unit, separating change-log-explained items from unexplained ones.\n9. Draft the reconciliation recommendation and attach it with coach-document-upload.\n10. The IT asset manager reviews the baseline (every source reported, no silent gap, carry-forward items represented) and the discrepancy set, then submits the disposition below. A silent gap is grounds to withhold the decision until the missing feed is re-pulled — a partial baseline cannot support a `corrections_applied` call.\n\n**Decision criteria**\n- **corrections_applied** — Choose when every discrepancy is fully explained by a logged change (a decommission, install, or move already in the change log but not yet posted to the register) or another routine cause, and no discovered asset lacks a record of authorization. Direct correction of the register is safe.\n- **investigation_required** — Choose when any discrepancy is unexplained: an asset discovered but not registered with no authorizing record, a registered asset absent from discovery with no decommission record, or an attribute mismatch that no logged change explains. A single unexplained item — especially an asset discovered with no record of authorization — is enough to require investigation.\n\n**Record in AssureSwarm**\n- Query the prior cycle's carry-forward Issue items linked to the anchor Control via coach-query-data; the inventory, discovery, and change-log sources are external and enter as uploaded extracts (query only — no new records are created at this checkpoint).\n- Attach the baseline extract — in-scope population count, per-source counts, and the prior carry-forward items folded in — as a step document with coach-document-upload.\n- Attach the discrepancy dashboard (coach-dashboard-create) and the reconciliation recommendation (coach-document-upload).\n- Submit the `reconciliation_disposition` SELECT. Record the decision rationale with evidence references in the step result and the approver in the step's approver record.\n\n**Exit criteria** — Every required discovery source reported this cycle (counts recorded, no silent gap); the baseline extract lists the complete in-scope population with per-source counts and the prior carry-forward items represented; the discrepancy dashboard and recommendation are attached; the `reconciliation_disposition` form is submitted with rationale and owner recorded; the unused branch is prunable.","kind":"decision","label":"Reconcile discovery against inventory","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload"]}},"id":"reconcile-discovery-against-inventory"},{"data":{"description":"Agent opens an owned investigation for every unexplained discrepancy and checks for an existing decommission or offboarding case; human confirms unauthorized or unresolved items are contained before the register is corrected","instructions":"**Objective** — Resolve every unexplained discrepancy — including any asset with no record of authorization — before the inventory register is corrected, so a correction never quietly launders an unresolved risk.\n\n**Inputs**\n- The discrepancy dashboard and reconciliation recommendation from the reconciliation decision (the unexplained items only — this node runs on the `investigation_required` branch).\n- Open workflows that might already own a flagged asset: decommission, offboarding, or security-investigation cases.\n- The flagged asset identifiers from the discrepancy dashboard. There is no Asset item type — each investigation is an Issue linked to the anchor Control that carries the asset identifier in its description.\n\n**Procedure**\n1. Scan open workflows with coach-workflow-scan to check whether an existing decommission, offboarding, or security-investigation case already covers a flagged asset — avoid opening a duplicate investigation.\n2. For every discrepancy without an existing case, create an investigation Issue with coach-item-create — issue_type: exception, source: management_identified, severity, issue_owner, target_remediation_date, with the asset identifier, discrepancy type, and business unit in the description — and link it to the anchor Control with coach-items-link (there is no Asset item type to link to).\n3. For each unrecognized (discovered-not-registered) asset, use the existing ownership and authorization records first; the responsible owner or business-unit participant records any unresolved ownership fact and required authorization in native results and approvals.\n4. Triage the returns: a confirmed-authorized asset routes to a register add/correct; a denied or unclaimed asset routes to containment (isolate/quarantine per policy) and, where warranted, a security-investigation case — before any register change is made.\n5. Compile the investigation log with current status, owner, and due date for every item, and attach it with coach-document-upload.\n\n**Record in AssureSwarm**\n- Create one Issue per unexplained discrepancy (coach-item-create) — issue_type: exception, source: management_identified, severity, issue_owner, target_remediation_date — and link each to the anchor Control (coach-items-link); the asset identifier lives in the Issue description because there is no Asset item type.\n- Record ownership findings and native authorization references in the investigation log; no separate attestation questionnaire is required.\n- Attach the investigation log as a step document (coach-document-upload).\n\n**Exit criteria** — Every unexplained or unauthorized asset is contained or explained; every investigation has a named owner and a due date; the investigation log is attached; the IT asset manager confirms nothing unresolved will pass into the register correction.","label":"Investigate and remediate discrepancies","performedBy":{"primitives":["coach-workflow-scan","coach-item-create","coach-items-link","coach-form-create","coach-document-upload"]}},"id":"investigate-and-remediate-discrepancies"},{"data":{"description":"Agent compiles the corrected, complete attribute set for every in-scope component; human confirms owner, location, and security attributes are accurate so the register stands as the authoritative record","instructions":"**Objective** — Close the reconciliation loop by confirming the inventory register carries accurate owner, location, and security attributes for every in-scope component, so it stands as this cycle's authoritative record for audit, compliance, and security scoping.\n\n**Inputs**\n- The routine corrections identified on the `corrections_applied` path and/or the resolutions closed out of investigation on the `investigation_required` path. This node joins both branches — it waits for whichever ran.\n- The confirmed baseline population count compiled at `reconcile-discovery-against-inventory` (to verify completeness).\n- The documented required attribute set: owner, location, criticality, environment, network zone.\n\n**Procedure**\n1. Apply the routine corrections and the closed investigation resolutions with coach-query-data, compiling the resulting attribute set for every in-scope hardware, software, system, and service record.\n2. Verify completeness: re-run the in-scope population count against the confirmed baseline and confirm no in-scope component was dropped or left uncorrected. A count mismatch voids the close — return to reconciliation.\n3. Confirm every record carries an accountable owner, a current location, and the security attributes needed for accountability and security management (criticality, environment, network zone). Flag any record missing a required attribute for same-cycle fix.\n4. Compile the reconciled inventory extract together with the completeness-check evidence.\n\n**Record in AssureSwarm**\n- Compile the corrected attribute set via coach-query-data; the authoritative register of record is updated in the external ITAM/CMDB (Studio has no Asset item type).\n- Attach the reconciled inventory extract — confirmed owner, location, and security attributes, with the population count tied to baseline — as a step document (coach-document-upload).\n\n**Exit criteria** — Owner, location, and security attributes are accurate and complete for every in-scope component; the population count ties to baseline; the IT asset manager confirms the register is ready to serve as this cycle's authoritative record.","label":"Confirm inventory attributes and scope","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"confirm-inventory-attributes-and-scope"},{"data":{"decisionField":"relabeling_disposition","description":"Agent finds new and changed classification candidates, proposes a level and priority for each under the documented scheme, and computes which classifications changed from the prior register; human corrects the proposals and decides whether relabeling is required this cycle or labels remain current","formData":{"fields":[{"key":"relabeling_disposition","label":"Relabeling Disposition","options":[{"label":"Relabeling required for changed classifications","value":"relabel_required"},{"label":"No changes, labels remain current","value":"labels_current"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Find every item this cycle's classification review must touch, apply the documented classification scheme to each, and decide whether the resulting changes require refreshed labels and handling markings — so nothing is classified late, protections scale with sensitivity, criticality, and business impact, and relabeling effort is spent only where the classification actually moved; owned by the information-classification owner.\n\n**Inputs**\n- The reconciled inventory extract from `confirm-inventory-attributes-and-scope`, so every newly confirmed in-scope asset is represented in the classification population.\n- The information/asset intake log and new-system and new-data-flow records since the last cycle.\n- The business and regulatory change log for the same period (ownership changes, new regulatory scope, changed business processes).\n- The current classification register — Studio has no Information Asset / classification-record item type, so the register lives as the prior cycle's exported register document and holds the existing classification for each re-review candidate.\n- The documented classification scheme (an org policy/standard document referenced at this step) with its sensitivity, criticality, and business-impact criteria and the handling/distribution rules per level.\n\n**Procedure**\n_Items 1–13 are agent-run (items 1–4 folded from the former \"Identify classification intake and changes\" step, items 5–9 from the former \"Classify and prioritize assets\" step); the human moment is item 14._\n1. Query the intake log, new-system/new-data-flow records, and change log since the last cycle with coach-query-data to find confidential information created or received with no recorded classification.\n2. Review the prior cycle's exported classification register together with the reconciled inventory extract for assets whose sensitivity, criticality, or business impact may have shifted — driven by an ownership change, new regulatory scope, or a business-process change recorded in the same period.\n3. Cross-check the intake population against the reconciled inventory extract so every newly confirmed in-scope asset is represented in the classification population; add any asset that is missing.\n4. Compile the candidate list, recording per item its source and the reason for inclusion (new intake vs. changed sensitivity).\n5. Pull the documented classification scheme and its sensitivity, criticality, and business-impact criteria with coach-query-data.\n6. For each candidate, record a classification worksheet in the evidence package proposing the classification level, the distribution/handling limitations, and the resulting priority or protection tier — each justified against the documented criteria (cite which criterion drives the level).\n7. For a re-review item, compare the proposed level to the existing record and flag any change explicitly, so the relabeling delta is computed from an accurate baseline.\n8. Where a re-classification surfaces a control or remediation gap that must survive the cycle, raise it as an Issue linked to the anchor Control (coach-item-create, coach-items-link). There is no Information Asset / classification-record item type, so classifications are not stored as items.\n9. Compile the proposed classification set into the proposed classification register document.\n10. Compare the proposed classification set against the prior cycle's exported register with coach-query-data to compute the delta of items whose classification level, distribution, or handling limitation changed.\n11. Separate the delta by medium — including physical media, which needs a distinct physical-marking refresh from digital metadata.\n12. Build a relabeling-scope dashboard with coach-dashboard-create showing the changed population by classification level and medium.\n13. Draft the relabeling-scope recommendation and attach it with coach-document-upload.\n14. The information-classification owner confirms the candidate population is complete, reviews every proposed classification — correcting any wrong level and confirming the scheme was applied consistently — and submits the disposition below. Any correction re-runs items 10–13 first so the disposition is decided on the corrected delta.\n\n**Decision criteria**\n- **relabel_required** — Choose when any item's classification level, distribution, or handling limitation changed this cycle — even one changed item, on any medium including physical.\n- **labels_current** — Choose only when this cycle's confirmed classifications match the prior register exactly, with zero changed items across all media.\n\n**Record in AssureSwarm**\n- Query the reconciled inventory extract and the prior carry-forward Issues via coach-query-data; the intake log, classification register, and business/regulatory change log are external or document sources brought in as extracts (there is no classification-record item type to query).\n- Attach the candidate population list — each item with its source and inclusion reason — as a step document (coach-document-upload).\n- Record each proposed classification in the worksheet evidence document — level, handling limitation, priority and cited criterion — with the owner’s actual rationale in the step result.\n- Per-item classifications are not created as items — the confirmed set is compiled into the proposed classification register document, attached as a step document (the extract is materialized for downstream at the compile step via coach-item-export). Where a re-classification surfaces a control/remediation gap, raise it as an Issue linked to the anchor Control (coach-item-create, coach-items-link).\n- Attach the relabeling-scope dashboard (coach-dashboard-create) and recommendation.\n- Submit the `relabeling_disposition` SELECT. Record the rationale with evidence references in the step result and the approver in the step's approver record.\n\n**Exit criteria** — The candidate population captures every item created, received, or changed since the last cycle plus every newly confirmed in-scope asset, each with a source and inclusion reason; every candidate has a proposed level, handling limitation, and priority justified by the scheme, with changes from prior records flagged; the information-classification owner has corrected any wrong classification and confirmed consistent application; the scope dashboard is attached; the `relabeling_disposition` form is submitted with rationale and owner recorded; the unused branch is prunable.","kind":"decision","label":"Determine relabeling scope","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload","coach-form-fill","coach-item-create","coach-items-link"]}},"id":"determine-relabeling-scope"},{"data":{"description":"Agent opens a labeling task for every changed item, including physical media, and links the handling-marking standard; human confirms every changed item is relabeled before the record is compiled","instructions":"**Objective** — Apply refreshed labels and handling markings to every item whose classification changed this cycle, including physical media, so the label a user or system sees always matches the current classification.\n\n**Inputs**\n- The changed population (delta) from the relabeling-scope decision, split by medium (this node runs on the `relabel_required` branch).\n- The current handling-marking standard document (the correct marking format per classification level).\n- The confirmed classification set from the classification register document and, for physical media, the media identifier. There is no Asset or classification-record item type — per-item labeling tasks are tracked in the completion log, not as items.\n\n**Procedure**\n1. Track a relabeling task for each item in the changed population in the relabeling completion log, capturing the new classification level, the required label or marking, and the owner responsible for applying it — there is no item type for per-item labeling tasks, so they are subsumed into the log document (materializing each as an Issue would be noise).\n2. For physical media, capture the media identifier and responsible owner in the same log (no Asset item type to link to).\n3. Link the current handling-marking standard document to the step with coach-document-link so the person applying the label uses the correct marking format for that classification level.\n4. Track completion per medium: for a digital item confirm the metadata/label updated; for physical media require evidence (photo or attestation) that the physical marking was applied. Any item that cannot be relabeled this cycle becomes an Issue linked to the anchor Control (coach-item-create, coach-items-link) so it carries forward.\n5. Compile the relabeling completion log, including the physical-media marking evidence, and attach it with coach-document-upload.\n\n**Record in AssureSwarm**\n- Track relabeling per item in the completion log — there is no item type for labeling tasks; escalate any item that cannot be relabeled this cycle as an Issue linked to the anchor Control (coach-item-create, coach-items-link).\n- Link the handling-marking standard document to the step (coach-document-link).\n- Attach the relabeling completion log, including the physical-media marking evidence, as a step document (coach-document-upload).\n\n**Exit criteria** — Every item in the changed population, including physical media, is relabeled with the correct marking and evidenced; the completion log is attached; the information-classification owner confirms the changed population is fully relabeled before the cycle record is compiled.","label":"Refresh labels and handling markings","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"refresh-labels-and-handling-markings"},{"data":{"description":"Agent compiles the reconciliation record and the updated classification register, exports the extract downstream security processes scope from, archives the signed operating record, and seeds the next cycle's carry-forward items; human dual-signs both records, and that sign-off closes the cycle","instructions":"**Objective** — Compile this cycle's two authoritative outputs — the reconciled inventory and the updated classification register — into the dual-signed record that downstream security-scoping processes consume, then archive it under retention and seed the next cycle so no open item is ever dropped; the IT asset manager's and information-classification owner's sign-off here is the cycle's closure.\n\n**Inputs**\n- The final reconciled inventory extract (from `confirm-inventory-attributes-and-scope`, carried through the classification chain).\n- The final confirmed classification set and the relabeling completion log — reached via either the `relabel_required` path (through `refresh-labels-and-handling-markings`) or the `labels_current` path (directly from `determine-relabeling-scope`). This node joins both paths.\n- The export format the downstream security-scoping processes require.\n- Open investigations and deferred corrections still tracked this cycle, and the next scheduled discovery-scan and classification-review dates.\n- The control execution log and the designated evidence repository (retention controls).\n\n**Procedure**\n_Items 6–9 close the workflow (folded from the former \"Close and archive\" step); the dual sign-off recorded in item 5 is the closure._\n1. Pull the final reconciled inventory extract and the final confirmed classification set with coach-query-data.\n2. Compile the reconciliation record: discrepancies found, corrections applied, and investigations closed (with outcomes).\n3. Compile the classification register view: every classified item, its level, its handling limitation, and its labeling status.\n4. Export the updated classification register extract with coach-item-export, compiled from this cycle's classification register document (there is no classification-record item type), in the format the downstream security-scoping processes consume.\n5. Package both records with the dual sign-off block and attach them with coach-document-upload. The IT asset manager and the information-classification owner review both records for completeness and accuracy and sign; this packaged, dual-signed record is the de-facto handoff package for downstream security-scoping (there is no named downstream workflow), and the two signatures close the cycle.\n6. Export the full operating record with coach-workflow-export and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n7. Create carry-forward Issue items with coach-item-create — source: management_identified, issue_owner and target_remediation_date set (issue_type: exception for an open investigation, observation for a deferred correction) — for any open investigation, any deferred correction, and the next scheduled scan/review dates; link each to the anchor Control and to its source Issue with coach-items-link so they arrive as explicit inputs to the next cycle.\n8. Update the control execution log with the cycle result, the discrepancy count, and the classification-change count.\n9. Attach the closure record with coach-document-upload.\n\n**Record in AssureSwarm**\n- Compile the reconciled inventory extract and the confirmed classification set via coach-query-data; export the classification register extract with coach-item-export in the consumable format.\n- Attach the packaged, dual-signed reconciliation record and classification register — the de-facto handoff package downstream security-scoping consumes — as a step document (coach-document-upload).\n- Export and archive the full operating record with coach-workflow-export; the archived workflow instance attached to the anchor Control is the control-execution-log entry.\n- Create carry-forward Issue items (coach-item-create) — source: management_identified, issue_owner and target_remediation_date set — and link each to the anchor Control and its source Issue (coach-items-link).\n- Attach the closure record — cycle result, discrepancy count, classification-change count — as a step document.\n\n**Exit criteria** — Both the reconciliation record and the classification register are complete and accurate; the register extract is exported in the consumable format; the IT asset manager and the information-classification owner have signed off; the archived record is immutable and retrievable under retention; every open item has a tracked owner and due date carried into the next cycle; the control execution log is updated — the dual sign-off is the cycle's formal closure.","label":"Compile reconciliation and classification record","performedBy":{"primitives":["coach-query-data","coach-export-package","coach-document-upload","coach-workflow-export","coach-item-create","coach-items-link"]}},"id":"compile-reconciliation-and-classification-record"}],"sourceTemplateId":"workflow-library:controls-it-asset-inventory-classification-upkeep"}