{"description":"Platform Isolation & Separation Enforcement as a decision-aware operator workflow. Each semiannual run attaches to the existing platform-isolation Control item — UC-NET-04 (framework nist-800-53, family SC, frequency semi_annual, control_owner = security architect), with sibling Controls UC-NET-05 and UC-NET-06 linked — enriching that standing control with a fresh cycle of evidence rather than creating any new anchor; consecutive instances stack on the same Control as its cycle history. Three verification streams run in parallel — user/system-management/security function and sensitivity-domain separation, shared-resource sanitization and covert-channel bandwidth reduction, and hardware- and software-enforced separation-mechanism integrity — and converge into a single posture review and closure. It consumes the prior cycle's still-open findings (Issue items carried forward on the anchor Control) plus live platform telemetry, and produces named deliverables: the function-and-domain separation matrix, the shared-resource sanitization report, the covert-channel analysis report, the hardware/software-mechanism verification report, a consolidated isolation-posture dashboard and evidence summary, and a signed cycle closure record. In scope: the semiannual verification and corrective-action closure of platform isolation across all in-scope platform components. Out of scope: the platform-engineering re-architecture behind a fix (tracked here as corrective-action Issues, executed by platform engineering) and boundary/network-protection controls owned by their own cycle. No upstream workflow feeds this cycle; its only handoff is downstream to its own next run — open corrective actions are left as OPEN Issue items on the anchor Control and arrive as explicit inputs to the next semiannual instance.","edges":[{"id":"e-adjudicate-separation-findings-classify-isolation-posture","label":"Confirmed","source":"adjudicate-separation-findings","target":"classify-isolation-posture","whenValue":"separation_confirmed"},{"id":"e-adjudicate-separation-findings-remediate-separation-gaps","label":"Remediate","source":"adjudicate-separation-findings","target":"remediate-separation-gaps","whenValue":"remediation_required"},{"id":"e-remediate-separation-gaps-classify-isolation-posture","source":"remediate-separation-gaps","target":"classify-isolation-posture"},{"id":"e-classify-isolation-posture-close-and-archive","label":"Healthy","source":"classify-isolation-posture","target":"close-and-archive","whenValue":"healthy"},{"id":"e-classify-isolation-posture-log-corrective-actions","label":"Gaps","source":"classify-isolation-posture","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-NET-04","UC-NET-05","UC-NET-06"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-platform-isolation-separation-enforcement","contentDigest":"sha256:87d7ec847bc369edee212ee417702566be5995820fc364469fa7dab1fbcc5c9a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:87d7ec847bc369edee212ee417702566be5995820fc364469fa7dab1fbcc5c9a","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-platform-isolation-separation-enforcement"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-platform-isolation-separation-enforcement","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it"]},"name":"Platform Isolation & Separation Enforcement","nodes":[{"data":{"decisionField":"separation_disposition","description":"Agent maps every in-scope component to its function class and sensitivity domain, checks partitioning/virtualization enforcement in the live environment, and ranks each violation by blast radius; human decides whether separation is confirmed or remediation is required","formData":{"fields":[{"key":"separation_disposition","label":"Separation Disposition","options":[{"label":"Separation confirmed","value":"separation_confirmed"},{"label":"Remediation required","value":"remediation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Prove component by component that user/UI functionality, system-management functionality, and security functions stay in separate execution and sensitivity domains, then resolve whether the separation result is clean or carries at least one open violation, so the cycle either proceeds straight to evidence consolidation or routes through remediation first. The security architect owns this call.\n\n**Inputs**\n- The anchor: the existing platform-isolation Control item UC-NET-04 (framework nist-800-53, family SC, frequency semi_annual, control_owner = security architect) with sibling Controls UC-NET-05 and UC-NET-06 linked — the semiannual instance runs against and enriches these Controls, it does not create a new anchor. These carry the governing NIST 800-53 SC controls: SC-2 (separate user and system-management functionality, including UI services), SC-3 (isolate security functions from non-security functions), SC-32 (partition the system into components of differing sensitivity in separate domains).\n- Cycle scope: the in-scope systems and components, the security-architecture and platform-engineering owners accountable for each domain (standing ownership lives in Control.control_owner on UC-NET-04/05/06), and the target completion date — carried as the run's kickoff context on the anchor Control. The cycle is triggered by the semiannual cadence (Control.frequency = semi_annual), by a newly deployed or re-architected component awaiting classification, or by a prior finding needing re-verification.\n- The in-scope platform component inventory and service catalog, each component tagged with its function classification (user/UI, system-management, security) — there is no native Component/Asset item type, so this is queried from the external CMDB/service catalog and the queried snapshot is embedded in the separation matrix attached to this step, not stored as items.\n- The sensitivity-domain map (for example management plane vs. user plane, security tooling vs. general workloads) — an architecture reference document (PDF/XLSX) attached to this step; its source of truth is the external architecture repository.\n- Prior-cycle findings and any open corrective actions carried forward — the still-open Issue items (issue_type finding/deficiency, source self_assessment) the prior cycle left linked to the anchor Control; this cycle has no upstream workflow, so these are its own carry-forward inputs.\n\n**Procedure**\n_Items 1–8 are agent-run (items 1–5 folded from the former \"Verify function and domain separation\" step); the human moment is the disposition call in item 9._\n1. Classify every in-scope component as user/UI-facing functionality, system-management functionality, or a security function, querying the component inventory and service catalog. Record the classification basis (what the component does, who calls it) so a reviewer can retrace it; flag any component that mixes classes (for example an admin console that also serves end-user traffic).\n2. For each pairing that must stay separated (user vs. management, security vs. non-security), identify the mechanism currently enforcing the boundary — network partitioning, a hypervisor or container virtualization boundary, or a separate physical or logical component — and confirm it is active in the live environment, not merely documented in an architecture diagram.\n3. Map every component to its sensitivity domain and flag any component that shares a domain with a component of differing sensitivity. For each violation, size the blast radius: what an attacker who compromised the shared domain could then reach.\n4. Separate a documented boundary from an active one: where the enforcing mechanism cannot be observed as running (no firewall rule, no hypervisor isolation flag, no separate host), treat the boundary as unproven and record it as a violation, not a pass.\n5. Assemble the separation matrix — one row per component listing function class, sensitivity domain, enforcing mechanism, live-verification evidence, and any violation with its blast radius.\n6. Aggregate every violation flagged in the matrix and rank them by blast-radius exposure and by whether a security function is involved.\n7. Cross-reference each violation against prior-cycle findings to distinguish new violations from carried-forward ones still open.\n8. Build the decision summary showing violation count, affected components, and exposure per violation, and present it alongside the full separation matrix.\n9. Security architect: spot-check the enforcing mechanisms against the live environment, then pick the disposition against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- `separation_confirmed` — Choose only when every function pairing (user vs. system-management per SC-2, security vs. non-security per SC-3) and every sensitivity domain (SC-32) is genuinely separated with an active enforcing mechanism, and no violation remains open — neither newly found this cycle nor carried forward from a prior cycle.\n- `remediation_required` — Choose when any violation exists: a mixed-function component, a documented-but-unenforced boundary, a component sharing a domain with differing-sensitivity peers, or a prior-cycle separation violation still open. A single unresolved security-function violation (SC-3) is sufficient on its own.\n\n**Record in AssureSwarm**\n- Submit the `separation_disposition` SELECT field with the chosen branch value; record the decision rationale and evidence references in the step result, and the deciding security architect in the native approval record.\n- Query the external component inventory, function classifications, sensitivity-domain map, and the violation aggregations with the data-query primitive (coach-query-data) — there is no native Component/Asset item type, so the results are captured as evidence inside the matrix rather than written to items.\n- Attach the completed function-and-domain separation matrix (XLSX) and the decision summary to this step (coach-document-upload).\n\n**Exit criteria** — Every in-scope component appears in the matrix with a function class, a sensitivity domain, and an active (not merely documented) enforcing mechanism, and every violation carries a blast-radius note; the `separation_disposition` routing selector is submitted and the step result contains a rationale that names the specific violations (or their absence); the unused branch is prunable.","kind":"decision","label":"Adjudicate separation findings","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"adjudicate-separation-findings"},{"data":{"description":"Agent tickets each violation with a corrective configuration change and tracks it to verified closure; human approves closure before the result feeds evidence consolidation","instructions":"**Objective** — Convert every open separation violation into a completed, re-verified fix so no function or sensitivity-domain boundary remains crossed before the cycle's evidence is consolidated.\n\n**Inputs**\n- The `remediation_required` disposition from the separation-findings decision and its rationale.\n- The function-and-domain separation matrix, with each flagged violation and its blast-radius note.\n- The accountable platform-engineering owner for each affected component.\n\n**Procedure**\n1. Create one corrective-action Issue per violation (coach-item-create) — issue_type: deficiency, source: self_assessment, severity by blast radius, a named issue_owner, and a target_remediation_date — capturing the required fix: repartition the network, reassign the component to the correct virtualization boundary, move it to a separate physical or logical component, or reassign its sensitivity domain. Link each Issue to the anchor Control (UC-NET-04/05/06) and to its separation-matrix row (coach-items-link) so evidence stays traceable.\n2. Route each item to the accountable platform-engineering owner and track execution against the due date (coach-workflow-scan), escalating any item slipping past its date.\n3. After each fix is applied, re-query the affected component (coach-query-data) to confirm the enforcing mechanism is now active in the live environment and the component sits in the correct sensitivity domain. Mark each item resolved only on that re-verification; leave it open otherwise.\n4. For any violation that cannot be fully closed this cycle, record an interim compensating control (for example a tightened firewall rule or a temporary access restriction) and keep the item open with the residual risk noted.\n5. Assemble the remediation log with before-and-after evidence for every violation — the pre-fix state, the change made, and the post-fix live-verification result.\n\n**Record in AssureSwarm**\n- Create one corrective-action Issue per violation (coach-item-create) — issue_type: deficiency, source: self_assessment, severity by blast radius, issue_owner, identified_date, target_remediation_date — and link each to the anchor Control (UC-NET-04/05/06) and to its separation-matrix row via item relationships (coach-items-link).\n- On re-verified closure set the Issue's actual_remediation_date and verified_date; track open items with coach-workflow-scan and re-query the live environment with coach-query-data.\n- Attach the remediation log with before-and-after evidence to this step as an XLSX document (coach-document-upload).\n\n**Exit criteria** — Every violation has a corrective-action item linked to its matrix row; each closed item shows post-fix evidence that the enforcing mechanism is active and the domain is correct; any still-open item carries an interim compensating control; the security architect has approved closure and confirmed no unmitigated violation remains.","label":"Remediate separation gaps","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"remediate-separation-gaps"},{"data":{"decisionField":"isolation_posture","description":"Judge sampled sanitization, channel bandwidth and boot/memory isolation evidence, reconcile all streams and classify the complete isolation posture.","formData":{"fields":[{"key":"isolation_posture","label":"Isolation Posture","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge sampled sanitization, channel bandwidth and boot/memory isolation evidence, reconcile all streams and classify the complete isolation posture.\n\n**Inputs**\n- Cycle scope: the in-scope systems and components and the accountable owners (this stream runs in parallel with the function-separation and hardware/software-mechanism streams; it depends on neither).\n- The shared-resource register (memory pages, disk blocks, object caches, temporary storage, multi-tenant compute hosts) and, for each, which users or processes sequentially reuse it — there is no native Asset/Resource item type, so this comes from the external platform telemetry/config store and its snapshot lives inside the sanitization report attached to this step.\n- Configured sanitization mechanisms per resource type and the reuse-event logs for this cycle.\n- The acceptable-bandwidth threshold for the system's protection profile — the covert-channel tolerance documented in a Policy item (policy_type: standard, framework nist-800-53, domains network_communications_security); it may also be restated in Control.description of UC-NET-05, the covert-channel control.\n- Governing controls: NIST 800-53 SC-4 (prevent unauthorized/unintended information transfer via shared system resources) and SC-31 (covert-channel analysis — identify channels, estimate bandwidth, reduce/eliminate those exceeding the acceptable level).\n- Cycle scope: the in-scope systems and the critical execution domains they run (this stream runs in parallel with the function-separation and shared-resource streams; it depends on none of them).\n- The hardware-enforced-mechanism register (memory-protection configuration, non-modifiable boot media, attestation/measured-boot sources) per critical execution domain — there is no native Component/Asset item type, so this is read from the external platform/firmware config and attestation service and its evidence copy lands in this step's verification report.\n- The software-enforced separation configuration (execution-domain policy, privilege-level separation, inter-domain mediation), likewise read from the external config and captured as report evidence.\n- Governing controls: NIST 800-53 SC-49 (hardware-enforced separation and policy enforcement), SC-50 (software-enforced separation and policy enforcement), SC-51 (hardware-based protection of non-modifiable executable code), SC-34 (non-modifiable executable code from hardware-enforced, read-only media).\n- From the function-separation stream: the separation matrix and, where remediation ran, the remediation log with before-and-after evidence (this node waits on the separation-findings decision's confirmed branch or the remediation step, whichever the cycle took).\n- From the shared-resource stream: the shared-resource sanitization report and the covert-channel analysis report.\n- From the mechanism stream: the hardware- and software-mechanism verification report.\n- Prior-cycle posture metrics for trend comparison.\n\n**Procedure**\n_This checkpoint absorbs “Run covert-channel analysis and reduction”, “Verify hardware and software separation mechanisms”, “Compile isolation evidence and dashboard”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Run covert-channel analysis and reduction: Prove every shared system resource is cleared, sanitized, or isolated between the users and processes that reuse it, then analyze those same resources for covert storage and timing channels and drive every channel above the acceptable threshold down to an acceptable level or eliminate it — producing the shared-resource sanitization report and the covert-channel analysis report with before/after bandwidth per channel.\n2. Inventory the shared system resources in scope and, for each, identify the users or processes that sequentially reuse it — the reuse boundary is where leakage would occur.\n3. Pull the configured sanitization mechanism for each resource type: memory zeroing on deallocation, storage scrubbing on volume release, cache eviction on session end, host reclamation on workload teardown. Record the mechanism and its trigger condition.\n4. Sample reuse events from this cycle and collect evidence that sanitization actually executed on each sampled event — a scrub log entry, a zeroed-page attestation, a reclamation record — not just that a mechanism is configured.\n5. Flag as a leakage exposure any shared resource with no configured sanitization mechanism, or any sampled reuse event where sanitization did not run or cannot be evidenced.\n6. Assemble the sanitization report: the resource inventory, the mechanism per resource, the sampled evidence, and every exposure found with the users/processes it would leak between.\n7. Run the covert storage-channel and timing-channel analysis across those same in-scope shared resources and the inter-domain interfaces between them (coach-query-data). Identify candidate channels created by resource contention, timing variance, or observable state changes that a lower-sensitivity domain could modulate and a higher-sensitivity domain observe (or vice versa).\n8. Estimate the bandwidth of each identified channel with the standard measurement approach (bits per second under realistic contention), and compare each estimate against the acceptable-bandwidth threshold for the protection profile.\n9. For each channel exceeding the threshold, draft the reduction approach — rate limiting, resource partitioning, timing-noise injection, or channel elimination — and open a tracked Issue for it, linked to the covert-channel control UC-NET-05 and to its channel record.\n10. Re-measure bandwidth after each reduction is applied and confirm it now sits below the threshold or the channel is eliminated; leave the item open if it does not.\n11. Assemble the covert-channel analysis report listing every channel, its estimated bandwidth before and after reduction, the technique applied, and its final disposition.\n12. Security architect: judge whether the sampled sanitization evidence is sufficient for each reuse boundary, and whether any channel left above threshold is a tolerable residual with a tracked item or blocks the stream from being called covered.\n13. Verify hardware and software separation mechanisms: Produce a hardware- and software-mechanism verification report proving that the mechanisms isolating critical security functions and enforcing policy between execution domains are in place and effective, so critical code cannot be altered at runtime.\n14. Query the platform's memory-protection configuration for every critical execution domain (coach-query-data): confirm write-protected or read-only memory is enforced where the architecture requires it, and list any domain running with writable memory it should not have.\n15. Verify the boot and load chain for key programs — firmware, hypervisor, boot loader, security kernel — loads and executes from hardware-enforced, non-modifiable media (SC-34/SC-51). Pull attestation or measured-boot evidence confirming each loaded image matches its approved non-modifiable source.\n16. Confirm the software-enforced separation mechanisms (SC-50) are configured — execution-domain policy enforcement, privilege-level separation, inter-domain mediation — and test that a lower-privilege domain cannot alter a higher-privilege domain's code or policy.\n17. Treat any gap as a finding: a critical domain with writable code memory, a boot image whose attestation does not match the approved source, or a privilege boundary a lower domain can cross. Record each with the domain and the mechanism that failed.\n18. Assemble the verification report: one row per critical execution domain with its memory-protection state, its boot-integrity/attestation evidence, its software-enforced separation result, and any gap found.\n19. Compile isolation evidence and dashboard: Consolidate the three verification streams into one evidence package and posture dashboard so the cycle is classified on a complete picture rather than three disconnected reports.\n20. Collect all five artifacts — separation matrix, remediation log (if any), sanitization report, covert-channel report, and hardware/software-mechanism report — and link each to its originating step (coach-document-link) so provenance is preserved.\n21. Compute the cycle's isolation-posture metrics (coach-query-data): open separation violations, shared resources without sanitization evidence, covert channels still above threshold, and execution domains with unresolved memory-protection or boot-integrity gaps.\n22. Build the isolation-posture dashboard (coach-dashboard-create) showing each metric against its threshold and its trend against the prior semiannual cycle, so a widening gap is visible at a glance.\n23. Reconcile the streams: confirm every corrective-action item opened in remediation or covert-channel reduction is reflected in the metrics, and that no report contradicts the dashboard counts.\n24. Draft the consolidated evidence summary tying the three streams to one overall posture statement.\n25. Classify isolation posture: Judge whether platform isolation held within tolerance this cycle or carries gaps needing tracked corrective action, so only the relevant closure path continues. The security architect owns this call.\n\n**Decision criteria**\n- `healthy` — Choose when every posture metric is within tolerance: zero open separation violations, zero shared resources without sanitization evidence, zero covert channels above the acceptable-bandwidth threshold, and zero execution domains with unresolved memory-protection or boot-integrity gaps.\n- `gaps_identified` — Choose when any metric is out of tolerance: an open separation violation, a shared resource with no sanitization evidence, a covert channel still above threshold, or a mechanism gap in a critical execution domain. Any single out-of-tolerance metric forces this branch.\n\n**Agent preparation**\n1. Re-check the isolation-posture dashboard against its thresholds (coach-query-data) and list every metric currently out of tolerance.\n2. Cross-reference outstanding items against their owners and due dates to confirm nothing was silently dropped between the three verification streams.\n3. Draft the readiness summary stating the overall posture and every open item, and present it with the dashboard.\n\n**Record in AssureSwarm**\n- Query the shared-resource register, configured sanitization mechanisms, reuse-event logs, and the channel analysis and re-measurement from the external platform telemetry/config store (coach-query-data); read the acceptable-bandwidth threshold from its Policy item (policy_type: standard). There is no native Asset/Resource item type, so the register snapshot is captured inside the reports rather than as items.\n- Open one reduction Issue per over-threshold channel (coach-item-create; issue_type: deficiency, source: self_assessment, issue_owner, target_remediation_date) and link each to the covert-channel control UC-NET-05 and to its channel record (coach-items-link).\n- Attach the shared-resource sanitization report and the covert-channel analysis report, with before/after bandwidth per channel, to this step as XLSX or PDF documents (coach-document-upload).\n- Query the memory-protection configuration, boot-chain attestation, and software-separation configuration from the external platform/firmware config and attestation service (coach-query-data) — there is no native Component/Asset item type, so this evidence is captured in the report, not as items.\n- Attach the hardware- and software-mechanism verification report to this step as an XLSX or PDF document (coach-document-upload).\n- Link each of the five source artifacts to its originating step (coach-document-link) and compute the posture metrics (coach-query-data).\n- Create the isolation-posture dashboard showing each metric against its threshold and prior-cycle trend (coach-dashboard-create), and attach the consolidated evidence summary to this step as a DOCX or PDF document (coach-document-upload).\n- Submit the `isolation_posture` SELECT field with the chosen branch value.\n- Record the decision rationale and evidence references in the step result, and the deciding security architect in the native approval record.\n- Attach the readiness summary (coach-document-upload); recompute metrics via coach-query-data.\n\n**Exit criteria**\n- Every in-scope shared resource is in the sanitization report with its mechanism and sampled execution evidence, and every exposure is documented with its reuse boundary; the analysis covers every in-scope shared resource and inter-domain interface with a before-and-after bandwidth estimate per channel; every channel that exceeded the threshold is now below it, eliminated, or carries an open tracked item; the security architect has ruled on residual exposure and confirmed coverage.\n- Every critical execution domain appears in the report with a memory-protection state and boot-integrity evidence; software-enforced privilege separation is tested, not just configured; every gap is recorded with its domain and mechanism; the security architect has reviewed the attestation evidence and confirmed critical code is protected from runtime alteration.\n- All five stream artifacts are linked and reconciled; the dashboard shows every metric against its threshold and prior-cycle trend; the consolidated summary states one overall posture; the security architect has reviewed the package for completeness and accuracy.\n- The `isolation_posture` routing selector is submitted and the step result contains a rationale that names each out-of-tolerance metric (or confirms all are within tolerance); the unused branch is prunable.","kind":"decision","label":"Classify isolation posture","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"classify-isolation-posture"},{"data":{"description":"Agent converts each remaining gap into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap remaining at the posture review into an owned, tracked corrective action so nothing degrades platform isolation unaddressed between cycles.\n\n**Inputs**\n- The `gaps_identified` disposition and the readiness summary from the posture decision, listing each open gap.\n- The evidence artifacts that surfaced each gap (separation matrix, sanitization report, covert-channel report, mechanism report) for root-cause linkage.\n- The accountable owners across security architecture and platform engineering.\n\n**Procedure**\n1. Parse the readiness summary to list each open gap with its root cause and the verification stream that surfaced it.\n2. Create one corrective-action Issue per gap (coach-item-create) — issue_type: deficiency, source: self_assessment, root_cause, issue_owner, target_remediation_date, and the interim compensating control noted in remediation_plan — and link it to the anchor Control and to the driving evidence artifact/step (coach-items-link).\n3. Raise a capability-level improvement Issue (issue_type: opportunity) for any systemic gap — a component class with no sanitization mechanism defined, or a recurring covert-channel source — so the pattern, not just the instance, gets fixed.\n4. Escalate any gap touching a security function (SC-3) to the accountable security-architecture owner, and confirm the escalation is acknowledged rather than merely sent.\n5. Assemble the corrective-action register listing every gap, its owner, due date, compensating control, and escalation status.\n\n**Record in AssureSwarm**\n- Create one corrective-action Issue per open gap (coach-item-create; issue_type: deficiency, source: self_assessment, root_cause, issue_owner, target_remediation_date, interim compensating control in remediation_plan) and raise systemic gaps as issue_type: opportunity; link each to the anchor Control and to the driving evidence artifact/step (coach-items-link).\n- Attach the corrective-action register to this step as an XLSX document (coach-document-upload).\n\n**Exit criteria** — Every open gap has a corrective-action item with a named owner and due date, linked to its driving evidence; systemic gaps have a capability-level item; security-function gaps are escalated and acknowledged; the security architect has confirmed nothing is left untracked.","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 consolidated evidence package and isolation-posture dashboard.\n- The posture decision and, on the gaps branch, the corrective-action register (this node is the single sink for both the healthy and gaps paths).\n- The designated evidence repository and its retention configuration; the control execution log; the semiannual review schedule.\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 any open corrective action or interim compensating control, and link them to their source (coach-items-link) so they arrive as explicit inputs to the next cycle — this workflow's only handoff is to its own next run.\n3. Update the control execution log with the cycle result and key metrics (open violations, sanitization gaps, covert channels above threshold, mechanism gaps), and confirm the next semiannual review is scheduled.\n4. Verify the archived record is immutable and retrievable — re-open it from the repository to confirm it reads back intact under the retention policy.\n5. Assemble the closure record summarizing the cycle result, the archive reference, and every carry-forward item.\n\n**Record in AssureSwarm**\n- Export the full operating record (coach-workflow-export) and archive it in the external evidence repository under retention controls; the workflow instance itself remains the durable in-AssureSwarm audit trail on the anchor Control.\n- Leave every open corrective action and interim compensating control as an OPEN carry-forward Issue (coach-item-create) linked to the anchor Control (coach-items-link) — this workflow's only handoff, consumed as an existing input by its own next run.\n- Attach the signed cycle closure record to this step as a document (coach-document-upload).\n\n**Exit criteria** — The full record is archived immutably and confirmed retrievable; every open item has a linked carry-forward with an owner; the control execution log is updated and the next semiannual review is scheduled; the authorized cycle record is complete.","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-platform-isolation-separation-enforcement"}