{"description":"Standing operator workflow for the Security & Privacy Architecture Review Board. Each cycle runs as a recurring workflow instance attached to the existing UC-GOV-19 Control item (security & privacy architecture governance; framework nist-800-53 + cobit-2019) in the control library — it enriches that Control and its evidence trail, never creates a duplicate, and the chain of archived instances is that control's execution log (Control has no native execution-log field). The cycle maintains the enterprise, security, and privacy architecture views (across the business, data, application, technology, security, and privacy domains), runs a scheduled annual full-refresh branch, reviews solution designs and acquisition decisions for architectural alignment with a remediation loop, and pushes approved architecture updates into system security plans and acquisition requirements. It consumes: the prior cycle's archived baseline and architecture-view documents plus its open carryover Issue items; the live system/application inventory and mission/strategy statements (uploaded from external systems, no native item type); and the Risk items that form the security (category cyber_security) and privacy (category privacy) risk registers. Named deliverables: the refreshed enterprise architecture baseline package and drift log, the updated security and privacy architecture views with risk-crosswalk gap lists, the alignment assessment register, the pushed-updates package of SSP and acquisition-requirement changes, and the program-health dashboard. In scope: enterprise/security/privacy architecture maintenance, solution-design and acquisition alignment review, and SSP and acquisition-requirement updates. Out of scope: implementing the individual system security controls and running procurement themselves — those execute in the owning system-authorization (ATO) and acquisition/procurement workflows, which are the real downstream consumers of this cycle's SSP and acquisition-requirement updates. No upstream workflow feeds this cadence; it is triggered by the standing quarterly ARB cadence, the annual refresh date, or an ad hoc urgent design or acquisition submission.","edges":[{"id":"e-update-security-architecture-view-update-privacy-architecture-view","source":"update-security-architecture-view","target":"update-privacy-architecture-view"},{"id":"e-update-privacy-architecture-view-determine-refresh-depth","source":"update-privacy-architecture-view","target":"determine-refresh-depth"},{"id":"e-determine-refresh-depth-conduct-annual-deep-dive-refresh","label":"Annual refresh","source":"determine-refresh-depth","target":"conduct-annual-deep-dive-refresh","whenValue":"annual_full_refresh"},{"id":"e-determine-refresh-depth-review-designs-and-acquisitions-for-alignment","label":"Quarterly maintenance","source":"determine-refresh-depth","target":"review-designs-and-acquisitions-for-alignment","whenValue":"standing_quarterly_maintenance"},{"id":"e-conduct-annual-deep-dive-refresh-review-designs-and-acquisitions-for-alignment","source":"conduct-annual-deep-dive-refresh","target":"review-designs-and-acquisitions-for-alignment"},{"id":"e-review-designs-and-acquisitions-for-alignment-classify-architecture-program-health","label":"Aligned","source":"review-designs-and-acquisitions-for-alignment","target":"classify-architecture-program-health","whenValue":"alignment_confirmed"},{"id":"e-review-designs-and-acquisitions-for-alignment-remediate-design-and-acquisition-conditions","label":"Conditions required","source":"review-designs-and-acquisitions-for-alignment","target":"remediate-design-and-acquisition-conditions","whenValue":"conditions_required"},{"id":"e-remediate-design-and-acquisition-conditions-classify-architecture-program-health","source":"remediate-design-and-acquisition-conditions","target":"classify-architecture-program-health"},{"id":"e-classify-architecture-program-health-log-corrective-actions","label":"Gaps","source":"classify-architecture-program-health","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-architecture-program-health-close-and-archive","label":"Healthy","source":"classify-architecture-program-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-GOV-19"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-security-privacy-architecture-review-board","contentDigest":"sha256:f4fe8ecd7ca5d670f071656992621a3ae28d900aec23d4843962eac9e65866ac","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:f4fe8ecd7ca5d670f071656992621a3ae28d900aec23d4843962eac9e65866ac","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-security-privacy-architecture-review-board"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-security-privacy-architecture-review-board","source":"coworkcanvas-gallery","standards":["nist-800-53","cobit-2019"],"teams":["it","privacy"]},"name":"Security & Privacy Architecture Review Board","nodes":[{"data":{"description":"Reconcile the enterprise baseline to live mission-aligned systems and judge security-risk control placement in the refreshed view.","instructions":"**Objective** — Reconcile the enterprise baseline to live mission-aligned systems and judge security-risk control placement in the refreshed view.\n\n**Inputs**\n- The current enterprise architecture baseline artifacts (business, data, application, and technology views) — documents carried forward from the prior cycle's archived workflow instance (the architecture repository is an external system; AssureSwarm holds the evidence copy). Upload the working copy to this step.\n- The live system and application inventory — the source of truth for what is actually deployed — extracted from the external CMDB/asset inventory and uploaded to this step (no native System/Asset item type).\n- The mission and strategy statements the architecture must align to — uploaded to this step from their external source (no native document item type).\n- The review calendar (standing quarterly ARB dates and the annual refresh date) and this cycle's trigger — standing quarterly cadence, the annual refresh, or an ad hoc urgent design/acquisition submission — plus the prior cycle's ARB minutes (documents on the prior archived instance) and open carryover action items (the open Issue items the prior cycle's log-corrective-actions and close-and-archive steps created and linked to the UC-GOV-19 Control).\n- Governing control references: the UC-GOV-19 Control item this instance is attached to, plus the related Control items in the library for NIST 800-53 PL-8 (security and privacy architectures) and PM-7 (enterprise architecture) and COBIT 2019 APO03 (managed enterprise architecture) — read via query.\n- The refreshed enterprise architecture baseline and its drift log (the reviewed output of the baseline step).\n- The current security architecture artifacts — trust-boundary and zone diagrams and the control-placement catalog.\n- The security risk register: every material security risk and its current rating.\n\n**Procedure**\n_This checkpoint absorbs “Refresh enterprise architecture baseline”. 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 enterprise architecture baseline: Refresh the enterprise architecture baseline (the business, data, application, and technology views) so it accurately describes the currently deployed system landscape and demonstrably aligns to the organization's mission and strategy, providing the reviewed foundation every other step in this cycle builds on.\n2. Pull the current baseline artifacts and the live inventory and diff them to detect drift between the documented architecture and what is actually deployed — new or decommissioned systems, changed integrations, and unmanaged (shadow) IT.\n3. Update the business, data, application, and technology views to close each identified drift, recording for every change the source system and the evidence that confirms it.\n4. Draft the mission-and-strategy alignment narrative: describe how the current system landscape and information flows support each stated strategic objective, and flag any system or flow that no longer maps to a current objective as a rationalization candidate.\n5. Assemble a drift log (item, old state, new state, source) and the refreshed baseline package.\n6. Update security architecture view: Maintain the security architecture view so trust boundaries, security zones, control placements, and key/secrets management are correctly positioned across the refreshed system landscape and every material security risk maps to a documented architectural control.\n7. Query the current security architecture artifacts and the security risk register and list every material security risk together with its current architectural mitigation, if any.\n8. Update the security architecture view against the refreshed baseline: trust boundaries, security zones, control placements, and key and secrets management architecture, so it reflects the systems as actually deployed.\n9. Crosswalk each material security risk to the specific architectural control that addresses it; any risk with no corresponding architectural mitigation is recorded as a gap with a proposed control.\n10. Compile the updated security architecture view and the risk-crosswalk gap list.\n\n**Record in AssureSwarm**\n- Attach the refreshed baseline package and the drift log to this step (document upload).\n- Record this cycle's trigger and the applicable control references on the step.\nAttach the updated security architecture view and the risk-crosswalk gap list to this step (document upload).\n\n**Exit criteria**\n- The four architecture views reconcile to the live inventory with every drift item resolved or logged; the mission-and-strategy alignment narrative is attached; the chief security architect has verified the baseline reflects the actual deployed environment.\n- The security view reflects the refreshed baseline; every material security risk either maps to a documented control or is captured as a tracked gap; the chief security architect has confirmed it complete and current.","label":"Update security architecture view","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"update-security-architecture-view"},{"data":{"description":"Agent updates the privacy architecture view and crosswalks it to the privacy risk register; human confirms every material privacy risk maps to a documented control","instructions":"**Objective** — Maintain the privacy architecture view so personal and sensitive information flows, processing purposes, transfer paths, and data-minimization/retention touch points are documented across the refreshed landscape and every material privacy risk maps to a documented architectural control.\n\n**Inputs**\n- The refreshed enterprise architecture baseline and its drift log (the reviewed output of the baseline step).\n- The current privacy architecture artifacts and the data inventory.\n- The privacy risk register: every material privacy risk and its current rating.\n\n**Procedure**\n1. Query the privacy architecture artifacts, the data inventory, and the privacy risk register and list every personal or sensitive data flow, its processing purpose, and any cross-border transfer path.\n2. Update the privacy architecture view against the refreshed baseline: information-flow diagrams, processing purposes, cross-border transfer paths, and data-minimization and retention touch points.\n3. Crosswalk each material privacy risk to the architectural control that addresses it (for example minimization, pseudonymization, or transfer safeguards such as standard contractual clauses); any risk with no corresponding architectural mitigation is recorded as a gap.\n4. Compile the updated privacy architecture view and the risk-crosswalk gap list.\n\n**Record in AssureSwarm** — Attach the updated privacy architecture view and the risk-crosswalk gap list to this step (document upload).\n\n**Exit criteria** — The privacy view reflects the refreshed baseline; every material privacy risk either maps to a documented control or is captured as a tracked gap; the privacy architect has confirmed it complete and current.","label":"Update privacy architecture view","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"update-privacy-architecture-view"},{"data":{"decisionField":"refresh_depth","description":"Agent compiles baseline-health signals; human decides whether this cycle is standing quarterly maintenance or the annual full refresh","formData":{"fields":[{"key":"refresh_depth","label":"Refresh Depth","options":[{"label":"Standing quarterly maintenance","value":"standing_quarterly_maintenance"},{"label":"Annual full refresh","value":"annual_full_refresh"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve how deep this cycle goes — lightweight standing quarterly maintenance versus the full annual re-validation — owned by the chief security architect, so the scheduled annual refresh gets its deep dive while routine cycles stay proportionate.\n\n**Decision criteria**\n- `standing_quarterly_maintenance` — the annual refresh date does NOT fall within this cycle window, the drift closed in the baseline step was limited, and the count of unaddressed security and privacy risk gaps is within the program's tolerance threshold. Proceed directly to design and acquisition review.\n- `annual_full_refresh` — the scheduled annual refresh date falls within this cycle window, OR drift volume or the count of unaddressed security/privacy gaps exceeds the tolerance threshold even off-schedule. Run the deep-dive re-validation first.\n- Before picking, compile the deciding signals: drift volume from the baseline step, unaddressed gap counts from the security and privacy risk crosswalks, and time elapsed since the last full architecture refresh; draft a scope recommendation and attach it.\n\n**Record in AssureSwarm** — Submit the `refresh_depth` SELECT field with the chosen branch; capture the deciding signals and the reason in the step result and the approver in the step's approver record; attach the scope recommendation (document upload).\n\n**Exit criteria** — The routing selector is submitted and the step result contains a rationale citing the refresh-due check and the gap counts; the unchosen branch is prunable.","kind":"decision","label":"Determine refresh depth","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"determine-refresh-depth"},{"data":{"description":"Agent runs the full annual re-validation with domain owners; human confirms architecture principles and the target-state roadmap are still sound","instructions":"**Objective** — Execute the full annual architecture refresh — a re-validation of architecture principles, standards, and the target-state roadmap that goes beyond standing quarterly maintenance — so the reference architecture is rebuilt and internally consistent before design and acquisition review resumes.\n\n**Inputs**\n- The refresh-depth decision resolved to `annual_full_refresh` (this step runs only on that branch).\n- The refreshed baseline and the updated security and privacy architecture views.\n- The current architecture principles and standards catalog and the target-state roadmap with its milestones.\n- Domain-owner input across data, application, technology, security, and privacy.\n\n**Procedure**\n1. Convene input from each domain owner: pull their domain artifacts and create one Issue per domain (issue_type: observation, source: self_assessment) to capture their assessment of whether current principles and standards remain fit for purpose.\n2. Rebuild the reference architecture diagrams end to end from the refreshed baseline and the updated security and privacy views so the full picture is internally consistent.\n3. Benchmark the current-state architecture against the target-state roadmap; record each variance and re-affirm or revise the affected roadmap milestones with rationale.\n4. Compile the annual refresh package: revalidated principles, the rebuilt reference architecture, and the roadmap variance analysis.\n\n**Record in AssureSwarm**\n- Item create — one Issue per domain (issue_type: observation, source: self_assessment) holding that domain owner's fitness assessment.\n- Item relationship — link each per-domain assessment Issue to the UC-GOV-19 Control.\n- Step document — attach the annual refresh package (revalidated principles, the rebuilt reference architecture diagrams, and the roadmap variance analysis) as PDF/XLSX on this step.\n\n**Exit criteria** — Principles, standards, and the target-state roadmap are re-affirmed or revised; the reference architecture is internally consistent end to end; the chief security architect has confirmed before design and acquisition review resumes.","label":"Conduct annual deep-dive refresh","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"conduct-annual-deep-dive-refresh"},{"data":{"decisionField":"alignment_disposition","description":"Agent compiles the queue of solution designs and acquisition requests and drafts an alignment assessment for each; human decides the board disposition","formData":{"fields":[{"key":"alignment_disposition","label":"Alignment Disposition","options":[{"label":"Alignment confirmed","value":"alignment_confirmed"},{"label":"Conditions required","value":"conditions_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the solution designs and acquisition requests in the review queue are architecturally aligned as submitted, or need conditions before proceeding — owned by the board — so only aligned designs and purchases advance into system security plans and acquisition requirements.\n\n**Decision criteria**\n- `alignment_confirmed` — every design and acquisition in the queue fits the refreshed baseline and the updated security and privacy views: trust-boundary placement, data-flow fit, control coverage, and standards compliance all pass with no open condition.\n- `conditions_required` — one or more items need changes or conditions (a misplaced trust boundary, an uncovered data flow, a missing required control, or a standards deviation) before they can proceed.\n- Before picking, compile the queue of solution designs and acquisition requests submitted since the last cycle — each submission's target system, data handled, and requesting owner — evaluate each against the refreshed baseline and the security and privacy views, and draft a per-item alignment assessment with a recommended disposition and any approval condition.\n\n**Record in AssureSwarm** — Submit the `alignment_disposition` SELECT field; capture the per-item basis in the step result and the board decision owner in the step's approver record; attach the alignment assessment register (document upload).\n\n**Exit criteria** — The form is submitted with the assessment register attached and per-item rationale recorded; the unchosen branch is prunable.","kind":"decision","label":"Review designs and acquisitions for alignment","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"review-designs-and-acquisitions-for-alignment"},{"data":{"description":"Agent converts each condition into an owned action and tracks resolution back to the requesting owner; human confirms every condition is cleared or formally waived","instructions":"**Objective** — Clear every condition the board attached to a solution design or acquisition request so nothing proceeds into system security plans or acquisition requirements while still architecturally non-compliant.\n\n**Inputs**\n- The alignment assessment register (the reviewed output of the design and acquisition review), with each condition, the design or acquisition it belongs to, and its requesting owner.\n- The refreshed baseline and the updated security and privacy views to re-verify remediated items against.\n\n**Procedure**\n1. Parse the alignment assessment register into a condition list: each condition, the design or acquisition it belongs to, and its requesting owner.\n2. Create one Issue per condition (issue_type: exception, source: self_assessment) capturing the required change in the description, the requesting owner in issue_owner, and the due date in target_remediation_date; name the source design or acquisition in the description (no native Design-Review/Acquisition item type exists to link to) and relate the Issue to the UC-GOV-19 Control.\n3. Follow up on each action: confirm the requesting owner updated the design or acquisition and re-verify the change against the architecture — set actual_remediation_date on the Issue when cleared — OR route the item to the board for a formal waiver when the condition cannot be met.\n4. Assemble the updated remediation register and any waiver records.\n\n**Record in AssureSwarm**\n- Item create — one Issue per condition (issue_type: exception, source: self_assessment, issue_owner, target_remediation_date; actual_remediation_date set when the change is re-verified).\n- Item relationship — link each condition Issue to the UC-GOV-19 Control (the source design/acquisition is named in the Issue description; it has no native item type to link to).\n- Step document — attach the updated remediation register and any waiver records to this step.\n\n**Exit criteria** — Every condition is resolved and re-verified against the architecture or formally waived by the board with nothing left ambiguous; the chief security architect has confirmed before updates flow downstream.","label":"Remediate design and acquisition conditions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"remediate-design-and-acquisition-conditions"},{"data":{"decisionField":"program_health","description":"Verify approved architecture reaches each affected SSP/acquisition requirement and classify program health from all unresolved gaps.","formData":{"fields":[{"key":"program_health","label":"Program Health","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Verify approved architecture reaches each affected SSP/acquisition requirement and classify program health from all unresolved gaps.\n\n**Inputs**\n- The confirmed alignment dispositions — either `alignment_confirmed` directly from the review decision, or the cleared and waived conditions from the remediation step.\n- This cycle's baseline, security, and privacy architecture updates.\n- The register of system security plans and the acquisitions currently in flight.\n\n**Procedure**\n_This checkpoint absorbs “Reflect updates into SSPs and acquisitions”. 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. Reflect updates into SSPs and acquisitions: Push the approved architecture and the confirmed design/acquisition dispositions into every affected system security plan and acquisition requirement so downstream authorization and procurement work from the current architecture.\n2. Identify every system security plan affected by this cycle's baseline, security, or privacy updates, and every acquisition whose requirements must reflect the confirmed alignment disposition.\n3. Draft the specific system-security-plan updates for each affected system — architecture references, control placements, and data-flow diagrams — cross-referencing each update to the source architecture artifact (the baseline/security/privacy view documents on the earlier steps).\n4. Draft the acquisition requirement updates for each approved or conditionally approved acquisition — architectural constraints, required controls, and standards references — and route them to the acquisition owner.\n5. Compile the full set of pushed updates into one package.\n6. Classify architecture program health: Resolve whether the architecture program operated within tolerance this cycle or carries gaps needing tracked action — owned by the chief security architect — so only the relevant closure path continues.\n\n**Decision criteria**\n- `healthy` — every cycle metric is within tolerance: no unresolved drift, no unaddressed security or privacy risk gap, no design or acquisition condition past its due date, and no system security plan or acquisition requirement left un-updated.\n- `gaps_identified` — any metric breaches: unresolved drift, an unaddressed risk gap, an overdue condition, or a stale SSP or acquisition update exists.\n- Before picking, compute the cycle metrics, build a program-health dashboard showing each metric against its threshold and the trend versus prior cycles, and list every breach with its owner and the evidence behind it.\n\n**Record in AssureSwarm**\n- Step document — attach the pushed-updates package to this step; the live SSPs and acquisition requirements are updated in their external authorization/procurement systems (no native System/SSP item type), so the AssureSwarm copy is the evidence record and it cross-references the source architecture-artifact documents on the earlier steps.\n- Item relationship — relate the cleared/confirmed condition Issues from the remediation step to the UC-GOV-19 Control so the disposition that drove each SSP/acquisition update traces to the governing control.\nSubmit the `program_health` SELECT field; capture the metric readings and breaches in the step result and the decision owner in the step's approver record; attach the dashboard and the readiness summary (dashboard create, document upload).\n\n**Exit criteria**\n- Every affected system security plan and acquisition requirement is actually updated to reflect the approved architecture with none left stale; the chief security architect has confirmed.\n- The form is submitted with the dashboard attached and every breach evidenced; the unchosen branch is prunable.","kind":"decision","label":"Classify architecture program health","performedBy":{"primitives":["coach-query-data","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"classify-architecture-program-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 program-health review into an owned, dated, tracked corrective action so nothing degrades the enterprise, security, or privacy architecture unaddressed.\n\n**Inputs**\n- The readiness summary and program-health dashboard (the reviewed output of the program-health classification), with each breach and its evidence.\n- The driving metrics and the design or acquisition items behind each gap.\n\n**Procedure**\n1. Parse the readiness summary into a gap list: each gap, its root cause, and the metric or item that surfaced it.\n2. Create one Issue per gap (issue_type: deficiency, or finding for a confirmed control failure; source: self_assessment) capturing root_cause, issue_owner, target_remediation_date, and interim mitigation, and relate each to the Risk item that surfaced it (the crosswalked security/privacy Risk) and to the UC-GOV-19 Control.\n3. Raise program-level improvement Issues (issue_type: observation) for systemic gaps — a chronically drifting domain, an under-resourced privacy architecture review, or repeatedly missed SSP updates — and escalate any unresolved high-risk gap to the accountable executive.\n4. Assemble the corrective-action register.\n\n**Record in AssureSwarm**\n- Item create — one Issue per gap (issue_type: deficiency or finding, source: self_assessment, root_cause, issue_owner, target_remediation_date) plus program-improvement Issues (issue_type: observation) for systemic gaps.\n- Item relationship — link each corrective-action Issue to its driving Risk item and to the UC-GOV-19 Control.\n- Step document — attach the corrective-action register to this step.\n\n**Exit criteria** — Every gap has a named owner and due date, escalations are routed, and nothing is left untracked; the chief security architect has confirmed 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: the refreshed baseline, the security and privacy architecture views, the alignment assessments, the SSP and acquisition updates, and the program-health metrics.\n- Any corrective-action register from the gaps branch (absent when the cycle closed healthy).\n- The review calendar for the next quarterly session and the next annual refresh date.\n\n**Procedure**\n1. Export the full operating record and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Create carry-forward Issue items for open corrective actions, unresolved conditions, and the next scheduled review (the quarterly session or the annual refresh date), and link each to its source Issue and to the UC-GOV-19 Control so it arrives as an explicit input to the next cycle.\n3. Record the cycle result and key metrics: since Control has no native execution-log field, this archived workflow instance — attached to the UC-GOV-19 Control — is itself that control's execution-log entry; confirm the next cadence review is scheduled.\n4. Assemble the closure record.\n\n**Record in AssureSwarm**\n- Workflow instance — export the full operating record (coach-workflow-export) so this archived instance stands as the UC-GOV-19 Control's execution-log entry.\n- Item create — carry-forward Issue items for open corrective actions, unresolved conditions, and the next scheduled review.\n- Item relationship — link each carry-forward Issue to its source Issue and to the UC-GOV-19 Control.\n- Step document — attach the closure record to this step; archive the exported operating record in the designated evidence repository under retention controls.\n\n**Exit criteria** — The archived record is immutable and retrievable, the next review is scheduled, no item remains open without a tracked owner, and 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-security-privacy-architecture-review-board"}