{"description":"Standing operator workflow that runs each quarter against the existing NIST 800-53 resilient-architecture / non-persistence Control item in the control library (framework=nist-800-53, SI/SC family covering SI-14, SI-21, SI-22, SI-23, SC-25, SC-29, SC-36, frequency=quarterly, control_owner = Infrastructure Architecture Lead); the recurring instance attaches to and enriches that Control — it never creates a new control. In scope: non-persistent provisioning and information refresh, diverse sourcing and fragmentation of high-value data, and the resilient-architecture review of thin nodes, technology heterogeneity, and distributed processing and storage against current threats. It consumes no upstream workflow handoff; its inputs are the standing non-persistence and resilient-architecture inventories — the critical-information suppliers adopt the native Vendor type, while the infrastructure components, information stores, and fragmentation entries have no native item type and are held as register documents on the anchor Control — plus any open carryover Issue items from the prior cycle. Named deliverables: the refresh-and-attestation log, the sourcing-diversity and fragmentation-verification report, the thin-node / heterogeneity / distribution assessments, the combined resilience-posture dashboard and posture-review summary, and the adjustment-action register; exceptions, drift, and gaps normalize into Issue items linked to the Control. Out of scope: incident response itself — a suspected refresh-source compromise is contained and escalated to the incident-response team (an escalation, not a workflow handoff) — and application-layer change management. This is a terminal recurring cycle: close-and-archive exports the run as the durable operating record and seeds the next quarter's inputs.","edges":[{"id":"e-execute-non-persistent-refresh-and-verify-source-contain-and-escalate-suspected-source-compromise","label":"Suspected compromise","source":"execute-non-persistent-refresh-and-verify-source","target":"contain-and-escalate-suspected-source-compromise","whenValue":"source_compromise_suspected"},{"id":"e-execute-non-persistent-refresh-and-verify-source-review-architecture-against-current-threats","label":"Verified","source":"execute-non-persistent-refresh-and-verify-source","target":"review-architecture-against-current-threats","whenValue":"source_integrity_confirmed"},{"id":"e-contain-and-escalate-suspected-source-compromise-review-architecture-against-current-threats","source":"contain-and-escalate-suspected-source-compromise","target":"review-architecture-against-current-threats"},{"id":"e-review-architecture-against-current-threats-plan-and-log-architecture-adjustments","label":"Adjustments","source":"review-architecture-against-current-threats","target":"plan-and-log-architecture-adjustments","whenValue":"adjustments_required"},{"id":"e-review-architecture-against-current-threats-close-and-archive","label":"Adequate","source":"review-architecture-against-current-threats","target":"close-and-archive","whenValue":"posture_adequate"},{"id":"e-plan-and-log-architecture-adjustments-close-and-archive","source":"plan-and-log-architecture-adjustments","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-VULN-09","UC-NET-09"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-resilient-architecture-non-persistence-operations","contentDigest":"sha256:31d5fcdf98f9720cc534b5692dc1003e851c430b4ab0c1e777006600f1e535e1","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:31d5fcdf98f9720cc534b5692dc1003e851c430b4ab0c1e777006600f1e535e1","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-resilient-architecture-non-persistence-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-resilient-architecture-non-persistence-operations","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it"]},"name":"Resilient Architecture & Non-Persistence Operations","nodes":[{"data":{"decisionField":"refresh_source_integrity","description":"Agent triggers the refresh of designated non-persistent components and services from the known-good source and captures integrity attestation; human decides whether the source is confirmed trustworthy or a compromise is suspected","formData":{"fields":[{"key":"refresh_source_integrity","label":"Refresh Source Integrity","options":[{"label":"Source integrity confirmed","value":"source_integrity_confirmed"},{"label":"Suspected source compromise","value":"source_compromise_suspected"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Refresh every component and service designated for non-persistent provisioning from its known-good trusted source, capture integrity attestation, and decide whether the source itself is trustworthy before the refreshed state is trusted for the cycle. Owned by the Infrastructure Architecture Lead.\n\n**Inputs**\n- The non-persistent component and service inventory — a standing register document attached to the anchor Control (the schema has no native Component item type), each entry carrying its refresh interval and its designated known-good source reference (golden-image id, signed artifact-repository path, or trusted configuration baseline).\n- This cycle's trigger — the recurring quarterly instance launch itself, an on-demand refresh request, or a threat-driven ad hoc review — and any open carryover refresh Issue items from the prior cycle, linked to the anchor Control.\n- The source-of-truth checksums/signatures and provenance for each designated source (from the external golden-image registry / signed artifact repo). This step reads the standing register documents on the anchor Control; no upstream workflow feeds it.\n\n**Evidence assembled before the call** (agent, autonomous)\n1. Query the non-persistent component and service inventory (coach-query-data) to list every designated component/service and confirm which are due this cycle by interval and which are being refreshed on demand.\n2. Trigger the rebuild/refresh of each from its designated known-good source, recording for each the source reference, the checksum or signature obtained, and the provenance chain.\n3. Compare each post-refresh state against the expected known-good baseline; flag any refresh whose source checksum, signature, or provenance does not verify, or whose resulting build diverges from baseline in a way consistent with a tampered source.\n4. Compile the refresh-and-attestation log — one row per component: source reference, checksum/signature result, provenance, and clean/flagged verdict.\n\n**Decision criteria**\n- Choose **source_integrity_confirmed** when every designated source and its resulting build verifies clean: checksum/signature matches, provenance is intact, and the post-refresh state matches the known-good baseline. The refreshed state is trusted for the cycle and this refresh finding flows to the posture review.\n- Choose **source_compromise_suspected** when any source checksum, signature, or provenance fails to verify, or a post-refresh state diverges from baseline in a way consistent with a tampered source — i.e., a supply-chain compromise of the non-persistence mechanism itself is plausible. This routes to containment and escalation.\n\n**Record in AssureSwarm**\n- **Step document** — the refresh-and-attestation log (coach-document-upload), one row per component: source reference, checksum/signature result, provenance, and clean/flagged verdict. The per-component rows live in this log rather than as items because the schema has no native Component/Attestation item type.\n- **Step form** — submit the `refresh_source_integrity` SELECT with a step result in the step result naming the specific components and evidence, and the decision owner in the step's approver record.\n\n**Exit criteria** — Every due component/service has been refreshed and attested; the SELECT is submitted with rationale and owner; the unused branch is prunable.","kind":"decision","label":"Execute non-persistent refresh and verify source","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload"]}},"id":"execute-non-persistent-refresh-and-verify-source"},{"data":{"description":"Agent isolates the affected component or service, halts further refresh from the suspect source, and opens an escalation; human verifies containment before the cycle continues","instructions":"**Objective** — Contain a component or service whose refresh source failed integrity verification so a possible supply-chain compromise cannot propagate through the non-persistence mechanism, and hand the matter to incident response.\n\n**Inputs**\n- The flagged component(s)/service(s) and the failed checksum/signature/provenance evidence from the refresh-and-attestation log (the `source_compromise_suspected` branch of the refresh decision).\n- The refresh-and-attestation log item/document, for linkage.\n- The incident-response intake convention: which item type and owner receive security escalations.\n\n**Procedure**\n1. Isolate each affected component/service and halt any further scheduled or on-demand refresh from the suspect source; capture the isolation action and timestamp.\n2. Scan open workflows (coach-workflow-scan) to detect any already-running incident case that the suspect source belongs to, so this escalation is linked rather than duplicated.\n3. Determine whether any other designated component shares the same compromised source and pull each into the isolation and escalation scope.\n4. Open one Issue (coach-item-create) recording the suspected source compromise for the incident-response team — the source reference, the failed checksum/signature/provenance evidence, and every component/service drawing from that source — and link it to the anchor Control and the refresh-and-attestation log (coach-items-link).\n5. Compile the containment-and-escalation record (coach-document-upload).\n\n**Record in AssureSwarm**\n- **Item create** — one Issue (coach-item-create) capturing the suspected source compromise: `issue_type: exception`, `severity: critical`, `source: management_identified`, `root_cause` = the failed checksum/signature/provenance evidence, `recommendation` = isolate and hand to incident response, `identified_date` = today; the isolation actions/timestamps and every component/service drawing from the suspect source are named in its `description`.\n- **Item relationship** — link that Issue to the anchor Control and to the refresh-and-attestation log (coach-items-link).\n- **Step document** — the containment-and-escalation record (coach-document-upload) with the full isolation and escalation trail. The escalation to the incident-response team is an operational handoff, out of this workflow's scope, evidenced by the Issue and record above.\n\n**Exit criteria** — Every affected component is demonstrably isolated; refresh from the suspect source is halted; the escalation has reached incident response; every component sharing the suspect source is identified; the record is attached.","label":"Contain and escalate suspected source compromise","performedBy":{"primitives":["coach-item-create","coach-workflow-scan","coach-items-link","coach-document-upload"]}},"id":"contain-and-escalate-suspected-source-compromise"},{"data":{"decisionField":"resilience_posture_disposition","description":"Judge purge/retention reconciliation, supplier diversity, physical fragmentation, thin-node drift and technology/location concentration against current threats.","formData":{"fields":[{"key":"resilience_posture_disposition","label":"Resilience Posture Disposition","options":[{"label":"Posture adequate","value":"posture_adequate"},{"label":"Adjustments required","value":"adjustments_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge purge/retention reconciliation, supplier diversity, physical fragmentation, thin-node drift and technology/location concentration against current threats.\n\n**Inputs**\n- The designated information register: information stores marked for periodic refresh, each with its refresh frequency and the freshness/corruption criteria that trigger a purge.\n- The active legal-hold and retention rules governing those stores. This workstream is independent of the component-refresh workstream; it reads the designated-information register document on the anchor Control (the schema has no native Information-Store item type).\n- The critical-information supplier and path register — the Vendor items in the vendor register that supply or route each critical information domain, each carrying its `category`, `tier`, `data_classification`, `reassessment_cadence`, and `monitoring_status` — with the required minimum count of independent suppliers/paths per domain.\n- The fragmentation map for designated high-value information — split key material, sharded sensitive datasets, segregated backup sets — and the separation requirement for each item. This step queries the supplier/path Vendor items and reads the fragmentation-map document on the anchor Control (the schema has a native Vendor type for the suppliers, but no native Data-Asset type for the fragmentation entries, which stay a document); it does not depend on the information-refresh workstream.\n- The inventory of nodes designated for minimal-functionality (thin-node) deployment, each with its approved service/software baseline.\n- The current running-services and installed-software state per node. This step reads the thin-node baseline inventory document on the anchor Control (no native Component/Asset item type); the live running-services/installed-software state is pulled from the CMDB/EDR at run time, and the step runs independently of the other assessments.\n- The refresh-and-attestation resolution from the non-persistent refresh decision (and, if it fired, the containment-and-escalation record).\n- The refresh-and-purge log (information refresh), the sourcing-diversity and fragmentation-verification report, and the thin-node posture report. This checkpoint consolidates the assessment streams after the refresh-source branch resolves.\n- The technology inventory across key layers — operating systems, hypervisors, network devices, cloud providers/regions, identity providers — with the defined heterogeneity target per layer, from the technology-inventory-and-targets document on the anchor Control (no native Asset item type); the prior-cycle concentration baseline is the prior cycle's heterogeneity assessment on the archived previous instance.\n- The processing/storage placement map across physical sites, availability zones, and infrastructure components, from the placement-map document on the anchor Control, with the distribution targets: the minimum number of independent locations, and the rule that no single location may hold the sole copy of critical processing or storage.\n- Current threat intelligence on persistent-adversary techniques, supply-chain/refresh-source compromise, and common-mode-compromise incidents.\n\n**Procedure**\n_This checkpoint absorbs “Refresh designated information”, “Verify diverse sourcing and fragmentation”, “Review thin-node minimal functionality”. 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. Refresh designated information: Refresh designated information at its defined frequency so stale or potentially corrupted data is purged before it can mislead a decision or persist an earlier compromise.\n2. List every information store designated for periodic refresh (coach-query-data) with its refresh frequency and the freshness/corruption thresholds that trigger a purge.\n3. Compare current contents against the freshness/integrity criteria and flag records due for purge — past the freshness window, failing an integrity check, or superseded by a newer authoritative copy.\n4. Execute the purge against each designated store, recording before/after counts in the refresh-and-purge log.\n5. Reconcile the purge results against retention rules to confirm no record under an active legal hold or a retention requirement was purged; raise one Issue (coach-item-create) for any conflict.\n6. Compile the refresh-and-purge log and the exception list (coach-document-upload).\n7. Verify diverse sourcing and fragmentation: Confirm that critical information is sourced from diverse suppliers or paths and that designated high-value information remains fragmented across genuinely separate systems, so no single compromise can expose or destroy it.\n8. Query the supplier/path Vendor items (coach-query-data) and confirm each critical information domain still has at least the required number of independent suppliers or delivery paths — distinct Vendors by `category`/`tier`, `monitoring_status: enrolled`; flag any domain that has consolidated onto a single source since the last cycle.\n9. Pull the fragmentation map and confirm each fragment remains hosted on a genuinely separate system with no shared dependency — shared host, shared key store, shared control plane — that would let one compromise reassemble or destroy the whole.\n10. Test-sample a subset of fragmented items to confirm the fragmentation is physical, not merely logical labels on a shared store.\n11. Compile the sourcing-diversity and fragmentation-verification report (coach-document-upload), listing each domain/item, its status, and any shortfall.\n12. Review thin-node minimal functionality: Confirm that nodes designated for minimal-functionality (thin-node) deployment remain thin, so each carries only the services it needs and offers a minimal attack surface.\n13. Pull the thin-node inventory and approved baselines (coach-query-data).\n14. Compare each node's current running services and installed software against its approved baseline to detect accreted functionality, unnecessary services, or configuration drift since the last cycle.\n15. For every node with drift, raise a remediation-candidate Issue (coach-item-create) with the specific drift observed as `root_cause` and the proposed action (service removal, re-baseline, or re-image) as `recommendation`, linked to the anchor Control (coach-items-link).\n16. Compile the thin-node posture report (coach-document-upload).\n17. Review architecture against current threats: Assess technology heterogeneity and the distribution of processing and storage, then review this cycle's non-persistence, information-refresh, sourcing, fragmentation, thin-node, heterogeneity, and distribution findings against current threats and decide whether the resilience posture is adequate or requires adjustment. Owned by the Infrastructure Architecture Lead.\n18. Pull the technology inventory (coach-query-data) and compute each layer's concentration on a single vendor, version, or provider.\n19. Compare current concentration against the prior-cycle baseline and the defined heterogeneity target for each layer; flag any layer drifting toward a monoculture (for example, a single OS family exceeding its concentration ceiling). For every flagged layer, draft a diversification recommendation naming a viable second technology or provider and the workloads it would cover, and compile the heterogeneity assessment (coach-document-upload) with per-layer concentration, target, and recommendation.\n20. Pull the placement map (coach-query-data) across physical sites, availability zones, and infrastructure components, and identify any designated workload or dataset that resolves to a single location or component.\n21. Compare the placement map against the distribution targets and flag every shortfall — below the minimum independent locations, or a sole-copy concentration of critical processing/storage — then compile the distribution assessment (coach-document-upload) naming each shortfall and the location/component that must be added.\n22. Gather current threat intelligence (coach-query-data) and map each item against the cycle's findings across all six dimensions.\n23. Compute the cycle's resilience-posture metrics: refresh source-integrity exceptions, information-purge exceptions, sourcing/fragmentation shortfalls, thin-node drift, heterogeneity concentration, and distribution shortfalls.\n24. Build the combined resilience-posture dashboard (coach-dashboard-create) showing every metric against its threshold and the trend versus prior cycles, including current placement against target for each in-scope workload and dataset.\n25. Draft the posture-review summary against current threats (coach-document-upload).\n26. Judge the posture against the criteria below and submit the branch with a rationale citing the specific metrics and threat mapping.\n\n**Decision criteria**\n- Choose **posture_adequate** when every metric is within tolerance and the architecture holds against current threats: no source-integrity exception outstanding, no purge/retention exception, sourcing and fragmentation intact, thin-node drift remediated or immaterial, heterogeneity within target, and distribution meeting its minima.\n- Choose **adjustments_required** when any exception, drift, or concentration must be corrected — an outstanding refresh-source compromise, a collapsed supplier path, a broken fragment, a drifted thin node, a monoculture layer, or a single-location/sole-copy shortfall — or when current threat intelligence makes an otherwise-tolerable metric unacceptable.\n\n**Record in AssureSwarm**\n- **Step document** — the refresh-and-purge log (coach-document-upload), one row per designated store with before/after counts; per-store rows live in the log because there is no native Information-Store item type.\n- **Item create** — for any record purged in conflict with a legal hold or retention requirement, one Issue (coach-item-create): `issue_type: exception`, `source: self_assessment`, `root_cause` = the retention/hold conflict, `issue_owner`, `identified_date`; link it to the anchor Control (coach-items-link).\n**Step document**: the sourcing-diversity and fragmentation-verification report (coach-document-upload), enumerating each critical domain against its supplier/path minimum and each high-value item against its separation requirement, with every shortfall named.\n- **Item create** — one Issue per drifted node (coach-item-create): `issue_type: observation`, `source: self_assessment`, `root_cause` = the specific drift observed, `recommendation` = the proposed action, `issue_owner`, `identified_date`; link each to the anchor Control (coach-items-link).\n- **Step document** — the thin-node posture report (coach-document-upload).\n- **Dashboard** — the combined resilience-posture dashboard (coach-dashboard-create), every metric against its threshold and the trend versus prior cycles, with current placement against target per in-scope workload/dataset.\n- **Step document** — the technology heterogeneity assessment (per-layer concentration versus target and the diversification recommendation for each flagged layer), the distribution assessment (each shortfall and its remedy), and the posture-review summary against current threats (coach-document-upload).\n- **Step form** — submit the `resilience_posture_disposition` SELECT with a step result in the step result citing the specific metrics and threat mapping, and the owner in the step's approver record.\n\n**Exit criteria**\n- Every designated store refreshed on or ahead of schedule; stale/corrupted data actually removed; no legitimately retained record lost; exceptions documented.\n- Every critical domain confirmed to meet its supplier/path minimum; every high-value item confirmed physically fragmented against a single-system compromise; shortfalls flagged; report attached.\n- Every thin node compared to its baseline; all drift enumerated, each with a remediation candidate; posture report attached.\n- Every key layer's concentration computed and compared to target with monoculture drift flagged and a concrete diversification recommendation; every in-scope workload/dataset placement compared to target with single-location and sole-copy shortfalls flagged and remedied; dashboard built and threat mapping documented; the SELECT is submitted with rationale and owner; the unused branch is prunable.","kind":"decision","label":"Review architecture against current threats","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"review-architecture-against-current-threats"},{"data":{"description":"Agent converts each identified gap into an owned adjustment action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap identified in the posture review into an owned, tracked adjustment so the non-persistence and resilient-architecture posture actually improves before the next cycle.\n\n**Inputs**\n- The posture-review summary and combined resilience-posture dashboard from the architecture-review decision (the `adjustments_required` branch), listing each exception, drift, and concentration with the metric that surfaced it.\n- The accountable owner per architecture dimension and the security owner for systemic escalations.\n\n**Procedure**\n1. Parse the posture-review summary to list each exception/drift/concentration with its root cause and the assessment that surfaced it.\n2. Create one Issue per gap (coach-item-create) — `issue_type: finding`, `source: self_assessment`, `severity` per gap, `issue_owner`, `target_remediation_date`, `remediation_plan` with the interim mitigation, `root_cause` = the metric/finding that surfaced it — and link each to the anchor Control (coach-items-link).\n3. Raise capability-level improvement Issues for systemic gaps — a chronically failing refresh source, a collapsed supplier path, a persistent technology monoculture — linking each to the containment escalation Issue where relevant, and escalate any supply-chain or common-mode-compromise risk to the accountable security owner.\n4. Attach the adjustment-action register (coach-document-upload).\n\n**Record in AssureSwarm**\n- **Item create** — one Issue per gap (coach-item-create): `issue_type: finding`, `source: self_assessment`, `severity` per gap, `issue_owner`, `target_remediation_date`, `remediation_plan` including the interim mitigation, `root_cause` = the metric/finding that surfaced it.\n- **Item relationship** — link each Issue to the anchor Control, and to the containment escalation Issue where the gap is systemic (coach-items-link).\n- **Step document** — the adjustment-action register (coach-document-upload) listing every gap, owner, and due date.\n\n**Exit criteria** — Every gap has a named owner and due date; systemic escalations are routed to the security owner; nothing is left untracked before closure.","label":"Plan and log architecture adjustments","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"plan-and-log-architecture-adjustments"},{"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: refresh attestation, information-refresh log, sourcing/fragmentation report, thin-node/heterogeneity/distribution assessments, posture-review summary, and — if raised — the adjustment-action register.\n- The designated evidence repository and its retention controls; the next quarterly review date and the next scheduled refresh dates.\n\n**Procedure**\n1. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Create carry-forward items (coach-item-create) for open adjustment actions, the next scheduled refresh dates, and the next quarterly review date; link them to their source (coach-items-link) so they arrive as explicit inputs to the next cycle.\n3. Record the cycle result and key metrics for SI-14, SI-21, SI-22, SI-23, SC-25, SC-29, and SC-36 in the closure record and attach it against the anchor Control (Control has no execution-log field, so the closure record is the execution evidence).\n4. Attach the closure record (coach-document-upload).\n\n**Record in AssureSwarm**\n- **Workflow instance** — the full run exported (coach-workflow-export) and archived in the designated evidence repository as the durable operating record; the archive location/reference is captured in the closure record.\n- **Item create** — carry-forward Issues (coach-item-create) for open adjustment actions and the next scheduled refresh/review dates, linked to the anchor Control (coach-items-link) so they arrive as explicit inputs to the next cycle.\n- **Step document** — the closure record (coach-document-upload), which also carries the cycle result and key metrics for SI-14/21/22/23, SC-25/29/36 attached against the anchor Control (Control has no execution-log field).\n\n**Exit criteria** — The archived record is immutable and retrievable; the next quarterly review is scheduled; nothing remains open without a tracked owner; 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-resilient-architecture-non-persistence-operations"}