{"description":"Standing monthly operator workflow anchored to the existing **Facility Access Administration** Process item (process_type: security_process), with the operated Control items UC-PHYS-01, UC-PHYS-02, and UC-ACCESS-19 (control_category: physical, frequency: monthly) linked to it; each cycle runs as a fresh workflow instance and its reconciliation packages, decision forms, and Issue items attach to that instance. It covers credential authorization, entry control and visitor logging, key/badge custody and revocation — plus the monthly surveillance, access-log, and environmental-safeguards review with facilities, including the data-center and protected-asset access confirmation. In scope: authorization, issuance, and periodic re-justification of physical credentials; entry-control and visitor-escort enforcement; key/combination/badge custody, rotation, and revocation; and the monthly surveillance, access-log, visitor-record, and environmental-safeguards review across all facilities, perimeters, and secure areas including the data center and other protected-asset locations. Out of scope: logical/system access provisioning and full incident-response investigation — a confirmed intrusion or data-center compromise is handed off to the incident-response process. No upstream workflow feeds this capability; it runs on its own monthly cadence and on personnel-change and reported-anomaly triggers, and terminates at close-and-archive (the run itself is the retained audit trail — no other downstream workflow consumes the cycle package). Control references: NIST 800-53 PE-2/PE-3/PE-6/PE-8, ISO 27001 A.7.1–A.7.4/A.7.6.","edges":[{"id":"e-authorize-and-issue-access-credentials-investigate-anomalies-and-violations","source":"authorize-and-issue-access-credentials","target":"investigate-anomalies-and-violations"},{"id":"e-investigate-anomalies-and-violations-escalate-and-remediate-anomaly","label":"Anomaly","source":"investigate-anomalies-and-violations","target":"escalate-and-remediate-anomaly","whenValue":"anomaly_or_violation_confirmed"},{"id":"e-investigate-anomalies-and-violations-classify-capability-readiness","label":"Clean","source":"investigate-anomalies-and-violations","target":"classify-capability-readiness","whenValue":"no_anomalies_detected"},{"id":"e-escalate-and-remediate-anomaly-classify-capability-readiness","source":"escalate-and-remediate-anomaly","target":"classify-capability-readiness"},{"id":"e-classify-capability-readiness-log-corrective-actions","label":"Gaps","source":"classify-capability-readiness","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-capability-readiness-close-and-archive","label":"Healthy","source":"classify-capability-readiness","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-PHYS-01","UC-PHYS-02","UC-ACCESS-19"],"department":"facilities","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-facility-access-administration-monitoring","contentDigest":"sha256:6a3c818bee6b517fa47e0ccd1ea9f1bd11cd4954c08acda6202b41e564c7ff5e","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:6a3c818bee6b517fa47e0ccd1ea9f1bd11cd4954c08acda6202b41e564c7ff5e","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-facility-access-administration-monitoring"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-facility-access-administration-monitoring","source":"coworkcanvas-gallery","standards":["iso-27001","nist-800-53","soc2","hipaa"],"teams":["facilities","it"]},"name":"Facility Access Administration & Monitoring","nodes":[{"data":{"description":"Agent compiles pending access requests against defined perimeters and drafts authorization decisions; human approves credential issuance and confirms the periodic review","instructions":"**Objective** — Authorize, issue, and periodically re-justify physical access credentials so only role-appropriate, business-justified personnel hold entry to facilities, offices, and sensitive locations (data center, backup-media storage, server rooms).\n\n**Inputs**\n- The anchor **Facility Access Administration** Process item and its linked **Control** items (UC-PHYS-01/UC-PHYS-02/UC-ACCESS-19) — the governing authorization rules, least-privilege standard, and re-justification intervals live in `Control.description` (no structured threshold fields); the mitigated exposure is the linked **Risk** item (Control ↔ Risk). Control refs: NIST 800-53 PE-2 (access authorizations), ISO 27001 A.7.2 (physical entry).\n- Facility/perimeter register and current secure-area definitions — uploaded to this step each cycle (PBC/badging-system extract); no Facility/Asset item type exists, so the register is a step document, not items. Each sensitive location's defined perimeter and assigned access tier.\n- Pending physical access requests, with requester role and stated business justification — uploaded to this step from the badging/request-queue system (no Credential item type).\n- The roster of credentials due for periodic review (re-justification interval, e.g., quarterly for standard areas, monthly for the data center) — uploaded to this step.\n- The personnel roster / HR feed for role validation — HRIS period extract, uploaded to this step.\n- This is a parallel entry checkpoint: it runs on the workflow's own inputs and does not wait on any other node.\n\n**Procedure**\n1. Confirm scope integrity: query the facility/perimeter register and verify every sensitive location (data center, backup-media storage, server rooms) has a defined perimeter and an assigned access tier. Flag any location with no tier — it cannot be authorized against.\n2. Pull pending access requests and match each requester's role and business justification to the tier requested. Reject any request where the tier exceeds the role's need (least privilege) — e.g., a desk analyst requesting standing data-center access with no operational reason.\n3. Pull the periodic-review roster and re-justify each existing credential: confirm the holder's role still requires the tier and that the access was actually used in the period. Dormant high-tier credentials are step-down or revocation candidates, not automatic renewals.\n4. Draft an authorization recommendation (grant / reject / step-down / revoke-dormant) per pending request and per periodic-review credential, citing the role-and-justification basis for each.\n\n**Record in AssureSwarm**\n- **Step document (XLSX)** — attach the *credential authorization log*: every request/renewal with its grant / reject / step-down / revoke-dormant decision and role-and-justification basis (coach-document-upload). There is no Credential/Badge item type, so approved credentials live as rows in this log, not as items (honest fallback for the credential gap).\n- **Item create — Issue** — where a credential is granted or retained above the role's default least-privilege tier by documented business approval, raise a `policy_exception` Issue (`issue_type: policy_exception`, `exception_approver`, `exception_expiry_date`, `source: management_identified`) so the exception carries a filterable expiry index (coach-item-create).\n- **Item relationship** — link each exception Issue to the anchor **Process** item and the governing **Control** (Issue ↔ Process, Issue ↔ Control) (coach-items-link).\n- Perform register/roster/request pulls via coach-query-data.\n\n**Exit criteria** — Every pending request and every periodic-review credential has a recorded decision with a role-and-justification basis captured as a row in the authorization log; every above-tier retention is raised as a linked `policy_exception` Issue; the physical security manager has approved the authorization log.","label":"Authorize and issue access credentials","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"authorize-and-issue-access-credentials"},{"data":{"decisionField":"monitoring_disposition","description":"Judge entry configuration, escorted visitor records, surveillance retention, personnel-change revocations and unexplained access flags to select the anomaly path.","formData":{"fields":[{"key":"monitoring_disposition","label":"Monitoring Disposition","options":[{"label":"No anomalies detected","value":"no_anomalies_detected"},{"label":"Anomaly or violation confirmed","value":"anomaly_or_violation_confirmed"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge entry configuration, escorted visitor records, surveillance retention, personnel-change revocations and unexplained access flags to select the anomaly path.\n\n**Inputs**\n- Entry-control configuration for every access point (badge readers, mantraps/turnstiles, PIN pads, guard posts) and the enforcement mode set for each secure-area tier — uploaded to this step (badge-reader-system extract).\n- The visitor log for the period (identity, purpose, time-in, time-out, and assigned escort per entry) — uploaded to this step from the visitor-management system; there is no Visitor item type, so the log stays a period-extract document.\n- The posted secure-area work rules (no unescorted visitors, no unauthorized recording devices, clean-desk) — governed by the anchor **Process** / **Control** items.\n- This is a parallel entry checkpoint: it runs on these inputs and does not depend on the credential-authorization node.\n- Surveillance and intrusion-detection (IDS) system output for the review period: alerts, after-hours activity, and any detection-system downtime.\n- Physical access logs for every controlled access point.\n- Visitor access records (identity, date, time, purpose) for the same period.\n- The reviewed credential records from **Authorize and issue access credentials** and the visitor-escort exception list from **Enforce entry controls and visitor logging** — this checkpoint reconciles the logs against both.\n- The retention requirement (e.g., 90 days surveillance footage, 1 year access/visitor records, or the org's stated period).\n- The monthly review package from **Monitor surveillance and review access logs**: surveillance and intrusion-detection output, physical access logs, and visitor records for the period, with retention confirmed.\n- The physical access audit log of entries/exits at controlled access points for the period — uploaded to this step (access-control-system extract).\n- The personnel-change feed: terminations, role changes, and transfers with effective dates — HRIS period extract, uploaded to this step.\n- The credential and physical-device inventory (keys, combinations, badges) and any lost/stolen/compromised-device reports — uploaded to this step; there is no Credential/Device item type, so the inventory is a step document.\n- The revocation timeliness standard (e.g., same business day for terminations, 24–72h for role changes) — held in the governing **Control** items' `Control.description` (no structured SLA field).\n\n**Procedure**\n_This checkpoint absorbs “Enforce entry controls and visitor logging”, “Monitor surveillance and review access logs”. 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. Enforce entry controls and visitor logging: Query the entry-control configuration for each access point and confirm it is active and set to the correct enforcement mode for its tier — e.g., the data-center door in two-factor/anti-passback mode, not propped or in free-egress.\n2. Cross-check every visitor-log entry against an assigned escort and a complete record (purpose, time-in, time-out). Flag any visitor with no escort, no time-out, or no stated purpose.\n3. Confirm the secure-area work rules are posted and acknowledged at each secure area; note any area where acknowledgement is missing.\n4. Compile the exception list: disabled or misconfigured readers, propped doors, unescorted or partially-logged visitors, and missing rule acknowledgements — each with the access point, timestamp, and severity.\n5. Monitor surveillance and review access logs: Query the surveillance/IDS output and compile alerts, after-hours or off-schedule activity, and any period the detection system was down — a blind window is itself a finding.\n6. Pull the physical access logs and visitor records and reconcile them: every logged entry maps to a live, authorized credential; every visitor entry maps to a logged escort. List any entry that does not.\n7. Verify retention: confirm surveillance footage, access logs, and visitor records from prior periods remain retrievable for the full retention period and none were purged early.\n8. Assemble the monthly review package: surveillance summary, access-log summary, visitor-record summary, and retention confirmation.\n9. Investigate anomalies and violations: Pull the physical access audit log and confirm it is complete for the period with no gaps — every controlled access point reporting, no missing days. A gap must be raised: it undermines every downstream reconciliation.\n10. Cross-reference the personnel-change feed against the credential/device inventory: for every termination, role change, or transfer, identify each key, combination, or badge to rotate or revoke and each access grant to adjust, with its SLA deadline.\n11. Add every reported lost/stolen/compromised device — and every shared combination exposed by a departure — to the rotation list. A departed key-holder means the combination is compromised, not just their badge.\n12. Draft the rotation/revocation action list: device, triggering event, required action, deadline, and current status.\n13. Scan the monthly review package for irregular patterns: after-hours or off-schedule entries, use of a credential that should have been revoked, tailgating or unescorted-visitor indicators, repeated failed entry attempts, and unresolved intrusion-detection alerts.\n14. Correlate each flag against the credentialing records and the rotation/revocation list from items 9–12. A flag is *explained* when it maps to a legitimate late shift, an approved exception, or an already-actioned revocation; *unexplained* otherwise.\n15. The physical security manager reviews the per-flag dispositions and the rotation/revocation list against the criteria below and submits the branch.\n\n**Decision criteria**\n- `no_anomalies_detected` — every flag is explained or there were none: the audit log is complete for the period, and no compromise or SLA-missed revocation is left un-actioned.\n- `anomaly_or_violation_confirmed` — at least one flag remains unexplained: an entry by a credential that should have been revoked, a confirmed tailgating event, a data-center entry with no authorization, an unresolved intrusion alert, or an audit-log gap that cannot be reconciled.\n\n**Record in AssureSwarm**\n- **Step document (XLSX)** — attach the *entry-control and visitor-logging exception list* (access point, timestamp, and severity per exception) (coach-document-upload). Visitor records have no native item type, so both the log and its exceptions live as step documents (honest fallback for the visitor gap).\n- Perform configuration and visitor-log pulls via coach-query-data.\n- Attach the monthly review package (coach-document-upload).\n- Perform surveillance, log, and reconciliation pulls via coach-query-data.\n- **Step document (XLSX)** — attach the *rotation/revocation action list* (device, triggering event, required action, SLA deadline, status) plus the reconciled device inventory and the complete audit log (coach-document-upload). There is no Credential/Device item type, so each rotation/revocation lives as a row in this list, not as an item (honest fallback for the device gap).\n- **Item create — Issue** — for every revocation that missed its SLA (or a compromise left un-rotated), raise an Issue (`issue_type: exception`, `source: management_identified`, `issue_owner`, `identified_date`, `target_remediation_date`) so the breach is tracked to closure (coach-item-create).\n- **Item relationship** — link each such Issue to the governing **Control** breached (UC-ACCESS-19) and the anchor **Process** (Issue ↔ Control, Issue ↔ Process) (coach-items-link).\n- Attach the per-flag investigation notes and evidence; perform the audit-log, inventory, and pattern-scan pulls via coach-query-data.\n- Submit the `monitoring_disposition` SELECT; write the evidence-referenced basis in the step result and the decision owner in the step's approver record.\n\n**Exit criteria**\n- Every access point's enforcement mode is verified; every visitor is tied to an escort and a complete log entry or is on the exception list; the physical security manager has confirmed the exception list is complete.\n- Surveillance, access-log, and visitor-record summaries are assembled and reconciled against the credential and escort data; retention is confirmed; the physical security manager has confirmed the review is complete for the period.\n- The audit log is confirmed complete (or gaps raised); every terminated or role-changed person and every compromised device has a rotation/revocation action with a deadline and nothing is left un-actioned; the `monitoring_disposition` routing selector is submitted and the step result contains a rationale citing the specific flags and their disposition; the unused branch is prunable (a clean period opens no escalation case).","kind":"decision","label":"Investigate anomalies and violations","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"investigate-anomalies-and-violations"},{"data":{"description":"Agent opens a tracked case for the confirmed anomaly/violation and drafts containment and remediation actions; human confirms escalation reached the right owner and remediation is underway","instructions":"**Objective** — Escalate every confirmed anomaly or apparent violation to a tracked case and drive containment so the irregularity does not recur unaddressed.\n\n**Inputs**\n- The confirmed anomaly/violation flags and evidence from **Investigate anomalies and violations**.\n- The severity rubric and the incident-response handoff threshold (suspected intrusion, data-center or protected-asset compromise, credential misuse at a protected asset).\n- Containment options: additional credential revocation, access-point lockdown, guard reassignment.\n\n**Procedure**\n1. Open a case per confirmed anomaly/violation capturing the affected access point or asset, the evidence, and a preliminary severity.\n2. Draft the immediate containment recommendation appropriate to severity — e.g., revoke the implicated credential now, lock down the access point, or reassign a guard to the perimeter.\n3. Route: decide whether the anomaly meets the incident-response threshold (suspected intrusion or data-center/protected-asset compromise → hand off to the incident-response process) or remains a physical-security case, and record the routing decision.\n4. Assign an owner and a remediation deadline per case.\n\n**Record in AssureSwarm**\n- **Item create — Issue** — open one Issue per confirmed anomaly/violation (`issue_type: finding` for a confirmed violation, `exception` for a control lapse; `severity` per the rubric; `source: management_identified`; `issue_owner`; `identified_date`; `target_remediation_date`; `remediation_plan` holds the containment action and the routing decision) (coach-item-create).\n- **Item relationship** — link each Issue to the governing **Control** breached and the anchor **Process** (Issue ↔ Control, Issue ↔ Process) (coach-items-link).\n- **Step document** — attach the case record and containment recommendation (coach-document-upload). An incident-response handoff for a suspected intrusion or data-center compromise runs in the incident-response process (outside AssureSwarm); the routing decision recorded on the Issue is the AssureSwarm evidence of it.\n\n**Exit criteria** — Every confirmed anomaly has a case with an owner, a containment action taken or scheduled, and a recorded routing decision; the physical security manager has confirmed escalation reached the right owner and any incident-response handoff was made.","label":"Escalate and remediate anomaly","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"escalate-and-remediate-anomaly"},{"data":{"decisionField":"capability_readiness","description":"Judge high-risk roster and separation closure, environmental safeguards and correlated events against capability thresholds.","formData":{"fields":[{"key":"capability_readiness","label":"Capability Readiness","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 high-risk roster and separation closure, environmental safeguards and correlated events against capability thresholds.\n\n**Inputs**\n- The current data-center and protected-asset access roster.\n- The credential authorization records and badge assignments from **Authorize and issue access credentials**, and the access-log activity from **Monitor surveillance and review access logs**.\n- The rotation/revocation action list produced in **Investigate anomalies and violations**, and any containment revocation from a confirmed-anomaly case.\n- The personnel-change feed, to confirm separations are closed for these highest-risk locations.\n- The asset risk ranking (which assets carry the highest impact if physically compromised).\n- The facilities management system: power conditioning/backup (UPS, generator), fire detection/suppression, and temperature/humidity control for the data center and protected locations.\n- The environmental event log for the period: power events, fire-system alarms/tests, and temperature/humidity excursions.\n- The physical access log from **Monitor surveillance and review access logs**, to correlate access with environmental events.\n- The data-center/protected-asset access confirmation and any confirmed-anomaly case from the monitoring branch, plus the credentialing and rotation/revocation records for the cycle.\n- The facilities liaison, for maintenance and testing confirmation.\n\n**Procedure**\n_This checkpoint absorbs “Confirm data center and protected asset access”. 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. Confirm data center and protected asset access: Pull the data-center/protected-asset roster and cross-check each holder against a live authorization record, a badge assignment, and actual access-log activity. Flag any holder with no authorization or no activity (dormant high-risk access).\n2. Verify closure: confirm every separated or role-changed person from the personnel-change feed no longer appears on the roster, and that any anomaly-driven containment revocation is reflected here.\n3. Rank each protected asset by risk and confirm the assigned access tier and monitoring intensity is commensurate — a top-risk asset should carry the tightest tier and densest monitoring. Flag mismatches.\n4. Draft the data-center/protected-asset access confirmation with each flag and its remediation.\n5. Classify capability readiness: Query the facilities system for the current status of each safeguard — UPS/generator, fire detection/suppression, HVAC/temperature/humidity — covering the data center and other protected locations. Flag any safeguard offline, in fault, or overdue for test.\n6. Pull the environmental event log and cross-reference it against the physical access log: determine whether any power event, fire alarm, or temperature/humidity excursion coincided with irregular or unexpected access — a coincidence warrants a joint look.\n7. With the facilities liaison, confirm maintenance and testing of each safeguard is current, and compile any deferred maintenance or open facilities finding.\n8. Draft the environmental safeguards and events review.\n9. Compute the cycle metrics: credential authorization turnaround, entry-control/visitor-logging exceptions, device rotation/revocation timeliness against SLA, unresolved anomalies or violations, data-center/protected-asset access mismatches, and environmental-safeguard or maintenance gaps — each against its threshold and the trend versus prior cycles.\n10. The physical security manager reads the metrics and the environmental review against the criteria below and submits the branch.\n\n**Decision criteria**\n- `healthy` — every metric is within tolerance: revocations met SLA, no unresolved anomaly or violation, no data-center/protected-asset access mismatch, and every environmental safeguard functioning and current on testing with no deferred maintenance open.\n- `gaps_identified` — any of these holds: a revocation missed SLA, an anomaly or violation is unresolved, a data-center/protected-asset access mismatch exists, or an environmental-safeguard or maintenance gap is open.\n\n**Record in AssureSwarm**\n- Attach the access confirmation (coach-document-upload); perform roster cross-checks via coach-query-data.\n- Attach the environmental safeguards and events review and the readiness summary (coach-document-upload); perform the safeguard-status, event-log, and metric pulls via coach-query-data.\n- Build the capability-health dashboard (coach-dashboard-create) showing each metric against its threshold and the trend versus prior cycles.\n- Submit the `capability_readiness` SELECT; write the evidence-referenced basis in the step result and the owner in the step's approver record.\n\n**Exit criteria**\n- Every data-center/protected-asset holder maps to a live authorization, badge, and activity; every separation is closed on these rosters; risk-commensurate tiers are confirmed or flagged; the physical security manager has signed off.\n- Each environmental safeguard's status and test currency is confirmed or flagged, environmental events are correlated against access, and deferred maintenance is listed with the facilities liaison's confirmation; the dashboard is built; the `capability_readiness` routing selector is submitted and the step result contains a rationale citing the breaching metrics; the unused branch is prunable (a healthy cycle opens no corrective-action pass).","kind":"decision","label":"Classify capability readiness","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-dashboard-create"]}},"id":"classify-capability-readiness"},{"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 readiness review into an owned, dated, tracked corrective action so nothing degrades the standing facility-access capability unaddressed.\n\n**Inputs**\n- The readiness summary and capability-health dashboard from **Classify capability readiness**, listing each breaching metric and its evidence.\n- Open anomaly/violation cases, data-center access mismatches, and environmental findings from the cycle.\n- The corrective-action / issue register.\n\n**Procedure**\n1. Parse the readiness summary and list each gap with its root cause and the metric, case, or asset that surfaced it.\n2. Create a corrective-action item per gap with root cause, owner, due date, and interim mitigation.\n3. Raise capability-level improvement items for systemic gaps — chronic revocation delays, an understaffed guard post, deferred environmental maintenance — rather than treating each recurrence as a one-off.\n4. Escalate any unresolved anomaly, violation, or data-center access mismatch to the accountable owner with a hard due date.\n\n**Record in AssureSwarm**\n- **Item create — Issue** — one Issue per gap (`issue_type: finding` for a control gap, `observation` for a systemic capability-level item; `source: self_assessment`; `issue_owner`; `target_remediation_date`; `root_cause`; `remediation_plan`) (coach-item-create).\n- **Item relationship** — link each Issue to the driving **Control** or the anchor **Process** it degrades (Issue ↔ Control / Issue ↔ Process) (coach-items-link).\n- **Step document (XLSX)** — attach the *corrective-action register* rolling up every gap Issue (coach-document-upload).\n\n**Exit criteria** — Every gap has a named owner and due date; systemic gaps have capability-level items; escalations are routed; the physical security manager has confirmed nothing is left untracked before closure.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record for the cycle: all attached packages, decisions, cases, and the corrective-action register.\n- Open corrective actions, pending credential reviews, and upcoming device-rotation dates.\n- The control execution log and the monthly review schedule.\n- Note: this is the single terminal sink. A confirmed intrusion or data-center compromise routed to incident response during the cycle is tracked there, not here; no other downstream workflow consumes this cycle's package.\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 for open corrective actions, pending credential reviews, and upcoming device-rotation dates, so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log with the cycle result and key metrics, and confirm the next monthly surveillance/access-log review is scheduled.\n4. Attach the closure record.\n\n**Record in AssureSwarm**\n- **Workflow instance** — export the full operating record via coach-workflow-export; the run itself is the immutable, retained audit trail for the cycle.\n- **Item create — Issue** — create a carry-forward Issue for each open corrective action, pending credential review, and upcoming device-rotation date (`issue_type: observation`, `target_remediation_date` set to the next-cycle due date) so they arrive as explicit inputs to the next cycle (coach-item-create).\n- **Item relationship** — link each carry-forward Issue to the anchor **Process** so the next cycle's entry steps query them (coach-items-link).\n- **Step document** — attach the closure record (coach-document-upload).\n\n**Exit criteria** — The archived record is immutable and retrievable for the retention period; carry-forward items exist and are linked; the next 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-facility-access-administration-monitoring"}