{"description":"Standing monthly operator workflow for the secure-baseline and integrity-drift cycle: maintain and approve hardening baselines and least-functionality settings against accepted industry standards, run configuration-compliance scanning and remediate drift as findings, triage file-integrity, hash/signature, and secure-boot alerts while verifying security functions self-test correctly, and keep the configuration management plan current annually or after significant environment change. In scope: system components and network security controls governed by CM-2/CM-6/CM-7/CM-9 and SI-6/SI-7 (ISO 27001 A.8.9, PCI DSS Req.1/Req.2, NIST CSF PR.PS-01/DE.CM-09). Out of scope: incident containment and response — unexplained changes are escalated as potentially adverse events to the detect-to-respond incident-analysis practice rather than contained here. Anchor: each monthly run is a recurring workflow instance attached to the EXISTING secure-configuration Control item (the CM-2/CM-6/CM-7 hardening-baseline control — domains=secure_configuration_change_management, frequency=monthly, framework nist-800-53/pci-dss/iso-27001); the cycle enriches that standing Control and never creates a new one. No upstream workflow feeds this cycle — it is self-seeding: its inputs are the prior instance's archived operating record, the approved hardening-baseline standards (Policy items linked to the Control), the open drift/integrity backlog and baseline-reassessment carry-forward (Issue items linked to the anchor Control), and the CM-plan review calendar. Named deliverables: the approved hardening-baseline standards and least-functionality list, the configuration-compliance scan-result register, the integrity-alert and self-test register, drift and corrective-action findings (Issue items linked to the Control), the reviewed configuration management plan (Policy item), the cycle-health dashboard and readiness summary, and the signed, archived cycle operating record. The only cross-workflow handoff is the adverse-event escalation package handed to the detect-to-respond incident-analysis practice.","edges":[{"id":"e-update-and-approve-hardening-baselines-classify-drift-and-integrity-findings","source":"update-and-approve-hardening-baselines","target":"classify-drift-and-integrity-findings"},{"id":"e-classify-drift-and-integrity-findings-classify-cycle-health","label":"Authorized","source":"classify-drift-and-integrity-findings","target":"classify-cycle-health","whenValue":"authorized_change"},{"id":"e-classify-drift-and-integrity-findings-remediate-baseline-drift-and-least-functionality","label":"Remediate","source":"classify-drift-and-integrity-findings","target":"remediate-baseline-drift-and-least-functionality","whenValue":"remediate_as_finding"},{"id":"e-classify-drift-and-integrity-findings-escalate-adverse-event-for-analysis","label":"Escalate","source":"classify-drift-and-integrity-findings","target":"escalate-adverse-event-for-analysis","whenValue":"escalate_adverse_event"},{"id":"e-remediate-baseline-drift-and-least-functionality-classify-cycle-health","source":"remediate-baseline-drift-and-least-functionality","target":"classify-cycle-health"},{"id":"e-escalate-adverse-event-for-analysis-classify-cycle-health","source":"escalate-adverse-event-for-analysis","target":"classify-cycle-health"},{"id":"e-classify-cycle-health-log-corrective-actions","label":"Gaps","source":"classify-cycle-health","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-cycle-health-close-and-archive","label":"Healthy","source":"classify-cycle-health","target":"close-and-archive","whenValue":"healthy"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CONFIG-01","UC-CONFIG-09","UC-VULN-06"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-secure-baseline-integrity-drift-management","contentDigest":"sha256:0af32625b7fb0bd5d59150bc4d02bc9e6a537d1997191911212275676a044f27","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:0af32625b7fb0bd5d59150bc4d02bc9e6a537d1997191911212275676a044f27","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-secure-baseline-integrity-drift-management"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-secure-baseline-integrity-drift-management","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","pci-dss","iso-27001"],"teams":["it"]},"name":"Secure Baseline & Integrity Drift Management","nodes":[{"data":{"description":"Agent drafts baseline and least-functionality updates aligned to industry hardening standards; human approves the baseline set before scanning","instructions":"**Objective** — Establish and maintain current, standards-aligned baseline configurations and least-functionality settings for every in-scope system component, and get them approved as the standard the compliance scan measures against.\n\n**Inputs**\n- The anchor secure-configuration Control item (existing) this instance attaches to — its `control_owner`, `framework`, and `domains: secure_configuration_change_management` scope the cycle. This standing Control is enriched, never re-created.\n- The baseline configuration register — the approved hardening baselines held as Policy items (`policy_type: standard`) linked to the anchor Control, plus the baseline changeset document attached at this step on the prior archived instance.\n- The prior-cycle operating log — the previous archived workflow instance on the anchor Control (its close-and-archive closure record and exported operating record).\n- The open drift/integrity backlog — open Issue items (`issue_type: finding`, `source: vulnerability_scan`) linked to the anchor Control from prior cycles, plus the baseline-reassessment carry-forward (`issue_type: observation`) seeded at the prior instance's close-and-archive.\n- The cycle trigger — routine monthly cadence, that open backlog, or a significant environment change that also forces an out-of-cycle baseline reassessment — and the confirmed in-scope system components and network security control rulesets (external CMDB / firewall management; the AssureSwarm copy is the inventory/coverage document on this step, since there is no native Asset/System item type).\n- The accepted industry hardening standards in force per platform type (CIS benchmarks, vendor STIGs, or equivalent) — published externally; the per-component mapping is recorded on the baseline Policy items and changeset document.\n\n**Procedure**\n1. Query the current baseline Policy items and standards mappings (coach-query-data) and identify any newly onboarded system component, network security control, or platform type that lacks documented baseline coverage (CM-2).\n2. Draft or update the baseline configuration and mandatory secure-settings for each affected component as a Policy item (`policy_type: standard`, `domains: secure_configuration_change_management`, `framework`, `review_frequency`, `next_review_date`), mapped to the accepted industry hardening standard it follows (CIS benchmark, vendor STIG, or equivalent), and record the update in the existing change-management record with native approval.\n3. Draft the least-functionality settings list — the ports, protocols, services, and functions to disable or restrict on each component (CM-7) — with a written business justification for anything retained.\n4. Package the baseline changeset and least-functionality list and attach it to the baseline Policy item and this step (coach-document-upload).\n\n**Record in AssureSwarm**\n- Create or update a Policy item per baseline standard (`policy_type: standard`, `policy_owner`, `version`, `framework`, `domains: secure_configuration_change_management`, `review_frequency`, `next_review_date`) and link it to the anchor Control (coach-item-create, coach-items-link).\n- Link the existing change-management record and native approval for each baseline update.\n- Attach the baseline changeset and least-functionality list document to the step and its Policy item (coach-document-upload). The in-scope system inventory is kept as a step document — there is no native Asset/System item type.\n\n**Exit criteria** — The control owner has approved the updated baselines and least-functionality settings, including the justification for every retained port, protocol, service, or function, before any scanning begins.","label":"Update and approve hardening baselines","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-form-create","coach-document-upload"]}},"id":"update-and-approve-hardening-baselines"},{"data":{"decisionField":"finding_disposition","description":"Agent runs the baseline-compliance scan and the integrity, boot, and self-test sweep and correlates the deviations and alerts into a single finding batch with a classification recommendation; human decides how each finding is dispositioned","formData":{"fields":[{"key":"finding_disposition","label":"Finding Disposition","options":[{"label":"Authorized change, no remediation","value":"authorized_change"},{"label":"Remediate as finding","value":"remediate_as_finding"},{"label":"Escalate as adverse event","value":"escalate_adverse_event"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Run the configuration-compliance scan and the file-integrity, hash/signature, secure-boot, and security-function self-test sweep, then resolve how the combined batch of deviations and integrity alerts is dispositioned so authorized changes are logged and closed, genuine drift is remediated as a finding, and unexplained changes are escalated as potentially adverse events. Owned by the control owner.\n\n**Inputs**\n- The approved baseline set — the baseline Policy items (`policy_type: standard`) and least-functionality list document from the hardening-baseline step (its reviewed output).\n- The confirmed in-scope system inventory and the network security control rulesets — external CMDB / firewall management; the AssureSwarm copy is the inventory/coverage document on the prior step (no native Asset/System item type).\n- The configuration-compliance scanning tool and its coverage map (external scanner).\n- The file-integrity-monitoring, cryptographic hash/signature validation, and secure/measured-boot alert feeds since the last sweep (external monitoring stack, pulled via coach-query-data; the AssureSwarm copy is the integrity-alert/self-test register document on this step).\n- The scheduled and on-demand security- and privacy-function self-test results.\n- The authorized-change record used to attribute each detected change — external ITSM change tickets; attribution evidence is embedded in the register on this step (no native Change Request item type).\n\n**Procedure**\n_Items 1–11 are agent-run (folded from the former \"Run configuration-compliance scan\" and \"Verify integrity and boot controls\" steps); the human moment is item 12._\n1. Query or trigger the configuration-compliance scan against the approved baseline set across every in-scope system, including a dedicated pass over network security control rulesets.\n2. Compute the deviation count and severity per system, and separately flag configurations that newly expose the environment to a known vulnerability (UC-VULN-06) rather than a simple setting drift.\n3. Cross-check scan coverage against the confirmed system inventory to identify any component the scan did not reach — a silent coverage gap invalidates the batch, so it must be closed or explicitly flagged before triage.\n4. Compile the configuration-compliance scan-result register with per-system deviation and coverage detail and attach it.\n5. Sweep file-integrity-monitoring alerts, cryptographic hash and signature validation failures, and secure/measured-boot alerts since the last sweep (coach-query-data), correlating each against the authorized-change record to separate authorized changes from unexplained ones (SI-7).\n6. Pull the results of scheduled and on-demand self-tests verifying correct operation of security and privacy functions at startup and on the defined schedule (SI-6), and flag any failure or anomaly.\n7. Continuously monitor computing hardware, software, and runtime environments for unexpected changes outside the alert feeds already swept, so nothing surfaces only in hindsight.\n8. Compile the integrity-alert and self-test register with authorization status against each entry, attach it (coach-document-upload), and confirm the sweep covers the full alerting window with no unacknowledged backlog.\n9. Correlate the scan-deviation register and the integrity-alert register into one finding batch, matching each entry against change-ticket history.\n10. For each finding, draft a classification rationale: matched to an approved change ticket; a genuine baseline or least-functionality violation with no matching authorization; or an unexplained change with no plausible benign cause.\n11. Scan open workflows (coach-workflow-scan) to detect any already-running incident case a finding belongs to, avoiding a duplicate escalation, then draft the classification recommendation and attach it.\n12. The control owner reviews the batch, its coverage, and the recommendation against the criteria below and submits the disposition.\n\n**Decision criteria**\n- `authorized_change` — every finding matches an approved change ticket with nothing left to remediate.\n- `remediate_as_finding` — genuine baseline or least-functionality violations exist with no matching authorization and require remediation.\n- `escalate_adverse_event` — one or more unexplained changes with no plausible benign cause must be handled as potentially adverse events.\n\n**Record in AssureSwarm**\n- Attach the configuration-compliance scan-result register as a step document (XLSX/CSV, coach-document-upload), carrying the per-system deviation count and severity and the list of any coverage gaps — these live in the register document, as there is no native Asset/System item type to hold per-system results.\n- Attach the integrity-alert and self-test register as a step document, recording the authorization status (authorized change vs. unexplained) against each entry and every self-test failure — change-ticket attribution stays in the external ITSM.\n- Attach the classification recommendation as a step document.\n- Submit the step form: the `finding_disposition` SELECT with the dominant disposition for the batch, plus the step result (with evidence references) and the step's approver record.\n\n**Exit criteria** — Scan coverage reached every in-scope system with no silent gaps; the integrity sweep covers the full alerting window with no unacknowledged backlog and every security- and privacy-function self-test failure is logged; the `finding_disposition` form is submitted with the batch disposition, rationale, and decision owner recorded, and the unused branches are prunable.","kind":"decision","label":"Classify drift and integrity findings","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload"]}},"id":"classify-drift-and-integrity-findings"},{"data":{"description":"Agent opens and drives remediation for each drift and least-functionality finding and re-scans to confirm closure; human verifies every finding is fully remediated","instructions":"**Objective** — Remediate confirmed configuration drift and least-functionality violations as tracked findings and re-verify that the fix actually restores the approved state.\n\n**Inputs**\n- The confirmed `remediate_as_finding` batch from the finding-disposition decision (its reviewed output), with the deviating setting and target baseline value per finding.\n- The approved baseline values from the baseline Policy items and the least-functionality settings list from the hardening-baseline step.\n\n**Procedure**\n1. Create a remediation finding for each confirmed deviation as an Issue item (coach-item-create) — `issue_type: finding`, `source: vulnerability_scan`, `severity`, `issue_owner`, `identified_date`, `target_remediation_date` — capturing the deviating setting and target baseline value in `description`, and link it to the anchor Control and its source finding (coach-items-link).\n2. Drive the configuration change back to the approved baseline value, or disable or restrict the offending port, protocol, service, or function per the least-functionality settings list (CM-7).\n3. Re-run the configuration-compliance scan on the remediated systems (coach-query-data) to verify the deviation is closed and no new deviation was introduced by the fix, then write closure back to each finding Issue (`actual_remediation_date`, `verified_date`) (coach-item-update).\n4. Attach the remediation and re-verification log (coach-document-upload).\n\n**Record in AssureSwarm**\n- Create a remediation Issue per confirmed finding (`issue_type: finding`, `source: vulnerability_scan`, `severity`, `issue_owner`, `identified_date`, `target_remediation_date`) and link it to the anchor Control and its source finding (coach-item-create, coach-items-link).\n- On re-verification, write closure back to each finding Issue (`actual_remediation_date`, `verified_date`) (coach-item-update).\n- Attach the remediation and re-verification log as a step document (coach-document-upload).\n\n**Exit criteria** — The control owner confirms every finding in this branch is fully remediated and re-verified closed, and separately judges whether this cycle's drift volume or pattern warrants an out-of-cycle baseline reassessment to feed the next cycle's baseline-update step.","label":"Remediate baseline drift and least-functionality violations","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-item-update","coach-document-upload"]}},"id":"remediate-baseline-drift-and-least-functionality"},{"data":{"description":"Agent packages unexplained changes as potentially adverse events and hands them to incident analysis; human confirms the handoff without duplicating containment","instructions":"**Objective** — Surface unexplained changes that integrity monitoring could not attribute to an authorized change as potentially adverse events and hand them to incident analysis rather than treating them as routine configuration drift.\n\n**Inputs**\n- The `escalate_adverse_event` findings from the finding-disposition decision (its reviewed output): affected component, the change detected, the integrity mechanism that flagged it, and why no authorization was found.\n- The designated security-operations or incident-response contact and the defined alerting channel.\n\n**Procedure**\n1. Package each unexplained finding as an Issue item (coach-item-create) — `issue_type: exception`, `severity: high`/`critical`, `source: management_identified`, `issue_owner` = receiving incident owner — capturing the affected component, the change detected, the integrity mechanism that flagged it, and why no authorization was found, and link it to the anchor Control (coach-items-link).\n2. Alert the designated security-operations or incident-response contact through the defined channel (coach-notify).\n3. Scan for an already-open incident case (coach-workflow-scan) the finding should attach to instead of opening a duplicate — consistent with handing genuine incidents to the detect-to-respond incident-analysis practice rather than re-running containment here.\n4. Attach the escalation package and handoff record (coach-document-upload).\n\n**Record in AssureSwarm**\n- Create an escalation Issue per unexplained change (`issue_type: exception`, `severity: high`/`critical`, `source: management_identified`, `issue_owner`) and link it to the anchor Control (coach-item-create, coach-items-link).\n- Attach the escalation package and handoff record as a step document (coach-document-upload) — this document is the handoff package the detect-to-respond incident-analysis practice consumes; change-ticket attribution stays in the external ITSM (no native Change Request item type).\n\n**Exit criteria** — The control owner confirms every unexplained change was escalated with a named receiving owner, that no escalation was silently dropped, and that this workflow did not duplicate containment work owned by incident response.","label":"Escalate adverse event for analysis","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-notify","coach-workflow-scan","coach-document-upload"]}},"id":"escalate-adverse-event-for-analysis"},{"data":{"decisionField":"cycle_disposition","description":"Approve due CM-plan updates and classify cycle health from complete scan, remediation, alert and policy-currency metrics.","formData":{"fields":[{"key":"cycle_disposition","label":"Cycle Disposition","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve due CM-plan updates and classify cycle health from complete scan, remediation, alert and policy-currency metrics.\n\n**Inputs**\n- The configuration management plan, policies, and procedures held as Policy items (`policy_type: policy`/`procedure`, `domains: secure_configuration_change_management`, `review_frequency: annual`) linked to the anchor Control; the review calendar is the `next_review_date` on those Policy items.\n- The cycle trigger — specifically whether it was a significant environment change that independently requires reassessment.\n\n**Procedure**\n_This checkpoint absorbs “Assess CM plan and policy currency”. 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. Assess CM plan and policy currency: Keep the configuration management plan, policies, roles, responsibilities, and procedures current through the annual review cycle and after any significant environment change, so the practice this workflow executes stays governed by an accurate document.\n2. Check the CM plan Policy items' `next_review_date` (coach-query-data) for the annual due date, and separately determine whether this cycle's trigger was a significant environment change that independently requires reassessment (CM-9).\n3. When a review is due or triggered, pull the current CM plan, policies, and procedures and draft updates to the roles, responsibilities, and processes for identifying, managing, and protecting configuration items across the system development life cycle, then update the CM plan Policy item(s) (`version`, `approved_by`, `effective_date`, `next_review_date`) (coach-item-update).\n4. When no review is due or triggered, compile a currency confirmation showing the plan remains accurate against this cycle's operating experience and the standing next review date.\n5. Route any drafted update for approval and attach the current or updated plan to its Policy item (coach-document-upload).\n6. Classify cycle health: Judge whether the secure-baseline and integrity practice operated within tolerance this cycle or carries gaps that need tracked action, so only the relevant closure path continues. Owned by the control owner. Before the decision, the agent prepares the evidence:\n7. Compute the cycle metrics (coach-query-data): scan coverage completeness, mean time to remediate drift, least-functionality exceptions outstanding, integrity-alert and self-test backlog, adverse-event escalations, and CM plan currency status.\n8. Build a baseline-integrity health dashboard (coach-dashboard-create) showing each metric against its threshold and the trend against prior cycles.\n9. List every breach with its owner and the evidence behind it.\n10. Draft the readiness summary and attach it (coach-document-upload).\n\n**Decision criteria**\n- `healthy` — every metric is within tolerance.\n- `gaps_identified` — any coverage gap, overdue remediation, unresolved integrity or self-test backlog, or stale CM plan exists.\n\n**Record in AssureSwarm**\n- Update the CM plan Policy item(s) (`policy_type: policy`/`procedure`, `policy_owner`, `approved_by`, `version`, `effective_date`, `review_frequency: annual`, `next_review_date`, `domains: secure_configuration_change_management`) linked to the anchor Control, or record the currency confirmation and standing `next_review_date` on them when no review is due (coach-item-create, coach-items-link, coach-item-update).\n- Attach the updated CM plan or the currency confirmation as a document on the Policy item and this step (coach-document-upload).\n- Submit the step form: the `cycle_disposition` SELECT with the chosen branch, plus the step result (with evidence references) and the step's approver record.\n- Build the baseline-integrity health dashboard (coach-dashboard-create) and attach the readiness summary as a step document (coach-document-upload).\n\n**Exit criteria**\n- The control owner approves the updated CM plan, policy, and procedures and their effective date when a review occurred, or confirms the existing plan remains current and the next review date stands.\n- The `cycle_disposition` form is submitted with the branch, rationale, and decision owner recorded, and the unused branch is prunable.","kind":"decision","label":"Classify cycle health","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-item-update","coach-document-upload","coach-dashboard-create"]}},"id":"classify-cycle-health"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap identified at the cycle-health review into an owned, tracked corrective action so nothing degrades the secure-baseline and integrity practice unaddressed.\n\n**Inputs**\n- The readiness summary and health dashboard from the cycle-health decision (its reviewed output), listing each gap and the metric or finding that surfaced it.\n\n**Procedure**\n1. Parse the readiness summary to list each gap with its root cause and the metric or finding that surfaced it.\n2. Create a corrective-action Issue for each gap (coach-item-create) — `issue_type: observation` or `deficiency`, `issue_owner`, `identified_date`, `target_remediation_date`, `root_cause`, `remediation_plan` (interim mitigation) — and link it to the anchor Control and the driving metric or finding (coach-items-link).\n3. Raise capability-level improvement items for systemic gaps such as a chronically under-scanned system class, a stale least-functionality exception list, or a recurring integrity-alert source, and escalate any unremediated finding past its tolerance window to the accountable owner.\n4. Attach the corrective-action register (coach-document-upload).\n\n**Record in AssureSwarm**\n- Create a corrective-action Issue per gap (`issue_type: observation` or `deficiency`, `issue_owner`, `identified_date`, `target_remediation_date`, `root_cause`, `remediation_plan`) and link it to the anchor Control and the driving metric or finding (coach-item-create, coach-items-link).\n- Attach the corrective-action register as a step document (coach-document-upload).\n\n**Exit criteria** — The control owner confirms every gap has a named owner and due date, that escalations were routed, and that nothing is left untracked before closure.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record for the cycle: approved baselines, scan-result register, integrity and self-test register, finding dispositions, remediation and escalation logs, the CM plan assessment, the readiness summary, and any corrective-action register.\n- The designated evidence repository retention configuration and the monthly cadence calendar.\n\n**Procedure**\n1. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n2. Create carry-forward items (coach-item-create) for open corrective actions, the next CM plan review date, and any baseline reassessment triggered by this cycle's drift volume, and link them to their source (coach-items-link) so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log with the cycle result and key metrics, and confirm the next monthly cadence review is scheduled.\n4. Attach the closure record (coach-document-upload).\n\n**Record in AssureSwarm**\n- Archive the exported operating record as the workflow instance's audit trail and record the archive location/reference (coach-workflow-export).\n- Create carry-forward Issue items (`issue_type: observation` for the baseline-reassessment carry-forward and open corrective actions; the next CM-plan review is carried on the CM-plan Policy item's `next_review_date`) and link them to the anchor Control (coach-item-create, coach-items-link) so the next instance queries them.\n- Attach the closure record as a step document and update the control execution log (coach-document-upload).\n\n**Exit criteria** — Verify automatically that the archived record is immutable and retrievable, the next review is scheduled and every open item has its previously assigned owner.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-secure-baseline-integrity-drift-management"}