{"description":"Standing quarterly operator workflow that runs against the EXISTING deception/OPSEC concealment Control in the control library (control_type: detective, framework: nist-800-53, frequency: quarterly, mapped to UC-NET-10/UC-VULN-11/UC-NET-11) — each quarter's instance enriches that Control's operating history and is archived as its audit trail, never creating a duplicate control. In scope: deploy and reposition honeypot/honeynet decoys and honeyclient sandbox detonation ahead of user delivery, seed/monitor/functionally-test honeytoken/beacon/watermark taint mechanisms across systems and datasets, and run the OPSEC process that identifies critical operational information (Risk items), analyzes adversary collection paths, and deploys concealment and misdirection countermeasures (Control items) on the cycle's designated systems, segments, and datasets. Originates on its own: the four operating streams (OPSEC, decoys, sandbox, taint) are parallel entry points fed by the organization's own asset, threat-intel, and inventory data — no upstream workflow feeds it. Named deliverables: the isolation-verified deception estate (deployment/repositioning plan + isolation-verification record), sandbox pipeline test results, the seeded taint-mechanism placement inventory, the OPSEC critical-information register with countermeasure register, the cycle detections timeline, and the program-health readiness dashboard. Out of scope: incident containment and eradication — confirmed activations are handed to the incident-response workflow with a preserved chain-of-custody evidence package (that handoff fires only on the activations-detected branch), rather than contained here.","edges":[{"id":"e-seed-and-verify-taint-mechanisms-review-cycle-detections-and-decide-disposition","source":"seed-and-verify-taint-mechanisms","target":"review-cycle-detections-and-decide-disposition"},{"id":"e-review-cycle-detections-and-decide-disposition-handoff-confirmed-activations-to-incident-response","label":"Activations detected","source":"review-cycle-detections-and-decide-disposition","target":"handoff-confirmed-activations-to-incident-response","whenValue":"activations_detected"},{"id":"e-review-cycle-detections-and-decide-disposition-classify-deception-program-readiness","label":"Clean cycle","source":"review-cycle-detections-and-decide-disposition","target":"classify-deception-program-readiness","whenValue":"no_activations"},{"id":"e-handoff-confirmed-activations-to-incident-response-classify-deception-program-readiness","source":"handoff-confirmed-activations-to-incident-response","target":"classify-deception-program-readiness"},{"id":"e-classify-deception-program-readiness-remediate-coverage-gaps","label":"Gaps","source":"classify-deception-program-readiness","target":"remediate-coverage-gaps","whenValue":"gaps_identified"},{"id":"e-classify-deception-program-readiness-close-and-archive","label":"Healthy","source":"classify-deception-program-readiness","target":"close-and-archive","whenValue":"healthy"},{"id":"e-remediate-coverage-gaps-close-and-archive","source":"remediate-coverage-gaps","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-NET-10","UC-VULN-11","UC-NET-11"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-deception-honeytoken-opsec-concealment-operations","contentDigest":"sha256:6f0b367a6b42ff061615e403c2c5ce39ef09a5ec054aa932d43c8b74d4d220e6","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:6f0b367a6b42ff061615e403c2c5ce39ef09a5ec054aa932d43c8b74d4d220e6","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-deception-honeytoken-opsec-concealment-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-deception-honeytoken-opsec-concealment-operations","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it"]},"name":"Deception, Honeytoken & OPSEC Concealment Operations","nodes":[{"data":{"description":"Approve isolated decoy placement and justified sensor repositioning together with armed, inconspicuous taint-mechanism coverage before live monitoring.","instructions":"**Objective** — Approve isolated decoy placement and justified sensor repositioning together with armed, inconspicuous taint-mechanism coverage before live monitoring.\n\n**Inputs**\n- The current decoy and sensor inventory (honeypot and honeynet instances, honeyclient endpoints, network placement, last-verified isolation status) — the prior-cycle inventory document carried forward from the last close-and-archive step; the source of truth is the external deception platform (no Asset item type holds decoys).\n- The in-scope network segments and environments for decoys this cycle — a scope-list document uploaded (PBC/external) at this step.\n- Current threat intelligence and internal telemetry for repositioning decisions. This is a parallel entry point: it draws on the organization's own inventory and threat data, not on another step's output.\n- The current taint-mechanism inventory (existing honeytokens, beacon files, watermarked records; location; last-verified status) — the prior-cycle placement inventory document carried forward from the last close-and-archive step. This is a parallel entry point.\n- The in-scope systems and datasets due for new or refreshed seeding this cycle (new data stores, reorganized file shares, newly onboarded systems) — a scope-list document uploaded (PBC/external) at this step; there is no Asset item type to hold the systems and datasets.\n\n**Procedure**\n_This checkpoint absorbs “Deploy and reposition decoy network”. 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. Deploy and reposition decoy network: Query the current decoy and sensor inventory: honeypot and honeynet instances, honeyclient endpoints, placement, and last isolation-verification date.\n2. Draft the refresh plan — which decoys need redeployment or patching to stay convincing (stale services, fingerprintable defaults) and which honeyclient capability needs renewal. Create a deployment task per action.\n3. Pull threat intel and telemetry; decide whether sensors should be relocated or repositioned this cycle. Draft the repositioning plan with reasoning tied to specific observed threat conditions — never reposition without a recorded reason.\n4. Verify each decoy's isolation from production: no route back to production, no shared credentials, no shared segments. Any decoy failing isolation is held offline until fixed.\n5. Compile the isolation-verification record (pass/fail per decoy); the pass rate feeds the readiness metric.\n6. Seed and verify taint mechanisms: Query the current taint-mechanism inventory: type, location, unique identifier, and last-verified status of every honeytoken, beacon file, and watermarked record.\n7. Identify systems and datasets due for new or refreshed seeding this cycle and decide the mechanism type per location: a honeytoken credential or record for data stores, a beacon file for shares, a watermark for distributable datasets.\n8. Seed each mechanism and create a placement record capturing type, location, unique identifier, and expected callback or alert channel; link each record to its host system or dataset.\n9. Verify each seeded mechanism is correctly armed (callback/alert path reachable) and inconspicuous (blends with real data rather than reading as obvious bait).\n10. Reconcile placement against the in-scope list so every in-scope system and dataset carries at least the intended mechanism.\n\n**Record in AssureSwarm**\n- Attach the deployment plan, repositioning rationale, and isolation-verification record as documents on this step (coach-document-upload) — this signed deliverable is the record for the decoy stream.\n- Capture each deployment and repositioning action inside the deployment-plan document with its owner and target date: there is no Task or Asset item type, so decoys and their actions live in the document with the external deception platform as source of truth, not as items.\n- Attach the full placement inventory as a document on this step (coach-document-upload) — capturing each mechanism's type, location, unique identifier, host system/dataset, and expected callback/alert channel. There is no native item type for a per-mechanism placement record or for its host system/dataset, so this inventory document IS the record for the taint stream.\n\n**Exit criteria**\n- Every decoy is verified isolated from production (or held offline until fixed); any sensor repositioning is justified by recorded threat conditions; the detection-engineering lead has approved the network going live for the cycle.\n- Coverage matches the in-scope systems and datasets; each mechanism is armed and inconspicuous; the placement inventory is accurate; the detection-engineering lead has confirmed it before monitoring begins.","label":"Seed and verify taint mechanisms","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload","coach-items-link"]}},"id":"seed-and-verify-taint-mechanisms"},{"data":{"decisionField":"detection_disposition","description":"Agent operates the sandbox detonation pipeline and the taint monitoring and functional testing for the cycle and compiles every decoy, sandbox, and taint signal into one detections timeline; human decides whether any activation must be escalated to incident response","formData":{"fields":[{"key":"detection_disposition","label":"Detection Disposition","options":[{"label":"No activations, cycle clean","value":"no_activations"},{"label":"Activation(s) detected, escalate","value":"activations_detected"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Operate the sandbox detonation pipeline and the taint-mechanism monitoring and functional testing for the cycle, correlate every resulting signal with the decoy network's hits into one picture, and decide whether any activation reflects genuine unauthorized activity that must be escalated to incident response. Owned by the detection-engineering lead.\n\n**Inputs**\n- The reviewed placement inventory document from \"Seed and verify taint mechanisms\" (required to start — you monitor and test exactly what it lists).\n- The taint-mechanism alert feed since the last cycle — an alert-feed extract from the external SIEM/alerting platform, uploaded at this step.\n- The authorized-activity calendar (approved testing, red-team exercises, known internal scans) used to separate real triggers from noise — uploaded as a document at this step.\n- The detonation pipeline configuration and routing rules — a config extract from the external sandbox/email-gateway platform, uploaded as a document at this step.\n- Known-benign and known-malicious test sample sets — sample manifests uploaded at this step.\n- The cycle's production detonation log and the delivery-hold SLA — uploaded as documents at this step.\n- The decoy-network hits and repositioning record from \"Deploy and reposition decoy network\".\n\n**Procedure**\n_Items 1–10 are agent-run (items 1–5 folded from the former \"Operate sandbox detonation pipeline\" step, items 6–10 from the former \"Monitor and test taint activations\" step); the human moment is the disposition decision in item 12._\n1. Query the pipeline configuration and routing rules; confirm email attachments, web downloads, and code artifacts are routed through the sandbox before reaching end users.\n2. Run a batch of test detonations against known-benign and known-malicious samples; record verdict accuracy (false-positive and false-negative counts) and time-to-verdict against the delivery-hold SLA.\n3. Pull the cycle's production detonation log; flag any file, URL, or code sample that bypassed the sandbox or was delivered before a verdict returned.\n4. For each bypass or late-verdict exception, record root cause (routing gap, timeout, unsupported file type) and whether it is a one-off or systemic.\n5. Summarize SLA adherence (share of samples with a verdict returned before delivery); this feeds the readiness metric.\n6. Query the taint alert feed for any activation since the last cycle; correlate each against known authorized activity to separate genuine triggers from approved testing and red-team noise.\n7. For each unresolved (non-authorized) activation, create an alert record capturing mechanism, trigger time, source, and destination; link it to its placement record. Confirm the security team was alerted on every genuine activation.\n8. Functionally test every deployed mechanism not already activated this cycle: deliberately fire a controlled test event and record which mechanisms fired correctly and which are dead or unreachable.\n9. List dead or unreachable mechanisms needing replacement, with the reason (expired credential, moved file, broken callback path).\n10. Compute the functional-test pass rate and dead-mechanism count; both feed the readiness metric.\n11. Compile decoy-network hits, sandbox true-positive verdicts, and taint activations into one detections timeline, cross-reference each against authorized activity to rule out self-inflicted triggers, and scan open workflows to check whether any detection already has an open incident-response case, avoiding duplicate escalation.\n12. The detection-engineering lead reads the timeline against the criteria below and submits the disposition.\n\n**Decision criteria**\n- `no_activations` (clean cycle): after cross-referencing every signal against authorized activity — scheduled testing, red-team or pentest exercises, and known internal scans — no decoy hit, sandbox true-positive verdict, or taint activation reflects genuine unauthorized activity. Everything that fired is explained by sanctioned work.\n- `activations_detected` (escalate): at least one decoy hit, sandbox true-positive verdict, or taint activation reflects real unauthorized activity after ruling out self-inflicted and authorized triggers. When a signal cannot be confidently explained as sanctioned, select this branch — under-escalating a real intrusion is the costlier error.\n\n**Record in AssureSwarm**\n- Gather pipeline configuration, test results, production logs, and the alert feed (coach-query-data); scan open workflows for an existing incident-response case (coach-workflow-scan).\n- Attach the pipeline test results, accuracy and latency figures, and any bypass exceptions with root cause; the taint activation log, functional-test results, and dead-mechanism list; and the correlated detections timeline with the disposition recommendation (coach-document-upload). The activation log records each genuine (non-authorized) activation with its mechanism, trigger time, source, and destination.\n- There is no native Incident item type, so genuine activations are captured in the activation-log document here; only detections confirmed for escalation at this decision become Issue items at the incident-response hand-off.\n- The human submits the `detection_disposition` SELECT (no_activations or activations_detected), records the rationale and evidence references in the step result, and the decision owner in the step's approver record.\n\n**Exit criteria** — Detonation completed with a verdict before delivery in every case (or each exception is explained) with verdict accuracy and latency within tolerance; the security team was alerted on every genuine taint activation; functional testing covered every deployed mechanism and dead or unreachable mechanisms are flagged for replacement; the routing selector is submitted and the step result contains a rationale citing the correlated evidence, and the unused branch is prunable.","kind":"decision","label":"Review cycle detections and decide disposition","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"review-cycle-detections-and-decide-disposition"},{"data":{"description":"Agent packages evidence and opens the hand-off to the incident-response workflow without performing containment itself; human confirms chain of custody and receipt","instructions":"**Objective** — Hand every confirmed activation to the incident-response workflow with a complete, chain-of-custody-preserved evidence package, without performing any containment here.\n\n**Inputs**\n- The `activations_detected` disposition and its evidence references from \"Review cycle detections and decide disposition\" (required to start — this step runs only on that branch).\n- Decoy telemetry, sandbox detonation reports, and taint-activation forensics for each escalated detection.\n- The receiving incident-response workflow instance — the named downstream workflow that owns containment and eradication; this workflow does not perform them.\n\n**Procedure**\n1. Package the evidence for each escalated detection — decoy telemetry, sandbox detonation report, or taint-activation forensics — preserving source, timestamps, and chain of custody (record who handled each artifact and when).\n2. Create a hand-off case per escalated detection and link its evidence package.\n3. Scan for the receiving incident-response workflow instance; confirm the hand-off case is visible to the response team, or create the linkage if no case exists yet.\n4. Take no containment action; explicitly record that containment and eradication remain owned by the incident-response workflow.\n\n**Record in AssureSwarm**\n- Create one Issue item per escalated detection as the hand-off case (coach-item-create) — `issue_type: exception`, `source: management_identified`, `severity`, `identified_date`, and `issue_owner`; relate it to the anchor deception/OPSEC Control (coach-items-link: Issue ↔ Control).\n- Attach the evidence package and hand-off log as documents on this step (coach-document-upload) — this is the handoff package the incident-response workflow's first step consumes; containment fields (source/destination telemetry, chain-of-custody ownership) have no native item home, so they live in the evidence-package document.\n- Confirm or create the linkage to the receiving incident-response workflow instance (coach-workflow-scan) so the hand-off case is visible to the response team without duplicate escalation.\n\n**Exit criteria** — Every escalated detection has a preserved chain of custody; the incident-response team has acknowledged receipt; no containment action was taken outside the response workflow's ownership; the detection-engineering lead has confirmed the hand-off.","label":"Hand off confirmed activations to incident response","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload"]}},"id":"handoff-confirmed-activations-to-incident-response"},{"data":{"decisionField":"readiness_disposition","description":"Judge critical-information collection paths, accepted OPSEC countermeasures and concealment effects with decoy, sandbox and taint readiness metrics.","formData":{"fields":[{"key":"readiness_disposition","label":"Readiness Disposition","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge critical-information collection paths, accepted OPSEC countermeasures and concealment effects with decoy, sandbox and taint readiness metrics.\n\n**Inputs**\n- The anchor deception/OPSEC Control in the control library (framework: nist-800-53, domains include network_communications_security / logging_monitoring_detection) — the existing item this quarter's instance runs against and enriches.\n- The prior cycle's OPSEC critical-information register — the Risk items carried forward (category: cyber_security, treatment: mitigate) plus the prior cycle's archived workflow-instance documents (attached at its close-and-archive step), where last cycle's list and dispositions live.\n- Asset inventories and data-classification registers — pulled from the external CMDB/data catalog and uploaded as documents at this step (no Asset item type exists to hold them).\n- Current threat-intelligence reporting on adversary reconnaissance and collection techniques — attached as a document at this step from the external threat-intel feed.\n- This cycle's in-scope designated systems and environments — a scope-list document uploaded (PBC/external) at this step, with each system's current banner, response-timing, and metadata posture from the external configuration/deception platform. This is a parallel entry point: no other workflow step or upstream workflow feeds it; it opens from the organization's own asset and threat data.\n- Operational and monitoring constraints — systems where suppression would break legitimate telemetry or operations.\n\n**Procedure**\n_This checkpoint absorbs “Apply OPSEC countermeasures and concealment”. 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. Apply OPSEC countermeasures and concealment: Query asset inventories, data-classification registers, and the prior OPSEC assessment to compile candidate critical operational information: mission-sensitive plans, system-architecture details, personnel and schedule patterns, and technical indicators an adversary could aggregate. Carry forward prior-cycle items and their status.\n2. Pull current threat-intel on adversary collection techniques — OSINT harvesting, network scanning, social engineering, supply-chain and physical observation — and map which apply to the organization's actual exposure.\n3. For each candidate, decide whether it is genuinely critical: would its disclosure materially aid an adversary's targeting or operation? Drop non-critical noise; keep the defensible set.\n4. For each retained item, draft the specific collection-and-exploitation path it enables (what an adversary observes, how they aggregate it, what operation it feeds). Create a register entry and link each entry to its supporting threat-intel source.\n5. Flag items whose exposure changed since last cycle (a new system, a reorganized team, a new public footprint) so countermeasure design prioritizes them.\n6. For each register entry, draft the matching countermeasure — information minimization, need-to-know handling, scheduling variance, or public-footprint reduction — tied to the specific collection path it denies. Create a countermeasure item and link it to the register entry.\n7. Identify the designated systems in scope for concealment this cycle and draft per-system concealment and misdirection configuration: suppress version and service banners, randomize observable response timing and headers, and mask system naming and metadata.\n8. Verify each system's current posture against the drafted configuration and record the deltas.\n9. Check each proposed change against legitimate monitoring and operational needs; record any system where a countermeasure would break required telemetry or operations, and note the accepted alternative.\n10. Compute preliminary concealment coverage (designated systems with applied config divided by total designated systems) — it feeds the readiness metric later — then have the detection-engineering lead review the register, the countermeasure set, and the applied configuration: is the retained critical-information list complete, is every collection path denied, and did anything break?\n\n**Decision criteria**\n- `healthy`: every metric is within tolerance — decoy isolation-verification pass rate at target, sensor repositioning current, sandbox verdict-SLA adherence within threshold, taint functional-test pass rate at target with zero unresolved dead mechanisms, and OPSEC countermeasure and concealment coverage complete across designated systems.\n- `gaps_identified`: any breach exists — an isolation failure, stale repositioning, a sandbox SLA breach, a dead taint mechanism, or a designated system missing concealment coverage. A single unresolved breach selects this branch.\n\n**Record in AssureSwarm**\n- Create one Risk item per retained critical-information item (coach-item-create) — `category: cyber_security`, `description` = the collection/exploitation path it enables, `treatment: mitigate`, `taxonomies` including cyber_security, and `risk_owner`.\n- Relate each Risk item to the anchor deception/OPSEC Control (coach-items-link: Risk ↔ Control) so the capability's exposure register is queryable from the control.\n- Create one Control item per standing OPSEC countermeasure (coach-item-create) — `control_type: preventive`, `control_category: administrative` or `technical`, `domains` including network_communications_security, `framework: nist-800-53`, and `control_owner` — mirroring the catalog's Control-mitigates-Risk pattern.\n- Relate each countermeasure Control to the Risk register entry it denies (coach-items-link: Control ↔ Risk).\n- Attach the critical-information register with its collection-path analysis, the countermeasure register, and the per-system concealment configuration record as documents on this step (coach-document-upload); the supporting threat-intel extract stays a document here, and the concealment config record is a document because designated systems have no Asset item type.\n- Before deciding, the agent computes the cycle metrics (coach-query-data) — decoy isolation pass rate, sensor-repositioning currency, sandbox verdict-SLA adherence, taint functional-test pass rate and dead-mechanism count, and OPSEC countermeasure and concealment coverage against designated systems — builds a program-health dashboard against each threshold and the prior-cycle trend (coach-dashboard-create), lists every breach with its owner and evidence, and attaches the readiness summary (coach-document-upload).\n- The human submits the `readiness_disposition` SELECT (healthy or gaps_identified), records the rationale and evidence references in the step result, and the decision owner in the step's approver record.\n\n**Exit criteria**\n- Every retained Risk item has a named collection/exploitation path and is linked to the anchor Control; changed-exposure items are flagged; every collection path has a linked countermeasure Control; concealment config is applied only to the correct designated systems; conflicts with legitimate operations are recorded with an accepted resolution; the detection-engineering lead has verified the register is complete and no legitimate monitoring or operations were broken.\n- The routing selector is submitted and the step result contains a rationale referencing the dashboard and metrics, and the unused branch is prunable.","kind":"decision","label":"Classify deception program readiness","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"classify-deception-program-readiness"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned, dated, and tracked","instructions":"**Objective** — Convert every gap identified at the readiness review into an owned, dated, tracked corrective action so decoy, sandbox, taint, and OPSEC coverage does not silently decay.\n\n**Inputs**\n- The readiness summary and breach list from \"Classify deception program readiness\" (`gaps_identified` branch — its reviewed output is required to start).\n- The driving metric or affected system behind each gap.\n\n**Procedure**\n1. Parse the readiness summary and list each gap with its root cause and the metric or system that surfaced it.\n2. Create a corrective-action item per gap capturing root cause, owner, due date, and interim mitigation; link it to the driving metric or affected system.\n3. Raise capability-level improvement items for systemic gaps — a chronically dead taint-mechanism type, an under-resourced sandbox pipeline, or a designated system persistently missing concealment coverage.\n4. Confirm nothing on the breach list is left without an owner and a due date.\n\n**Record in AssureSwarm**\n- Create one Issue item per gap (coach-item-create) — `issue_type: deficiency`, `source: self_assessment`, `root_cause`, `issue_owner`, `target_remediation_date`, and `remediation_plan` (capture any interim mitigation there); relate each to the anchor deception/OPSEC Control (coach-items-link: Issue ↔ Control). The driving metric or affected system has no native item type, so name it in the Issue's `root_cause` and the corrective-action register.\n- Attach the corrective-action register as a document on this step (coach-document-upload).\n\n**Exit criteria** — Every gap has a named owner and due date; systemic gaps have capability-level items; nothing is left untracked; the detection-engineering lead has confirmed before closure.","label":"Remediate coverage gaps","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"remediate-coverage-gaps"},{"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: every attached deliverable, decision, and register produced upstream.\n- Open corrective actions (when the gaps branch ran), decoys and taint mechanisms due for refresh, and the next OPSEC critical-information review date.\n- This is the single closure sink: on the healthy path it runs directly after the readiness decision; on the gaps path it runs after remediation.\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 items for open corrective actions, decoys and taint mechanisms due for refresh, and the next OPSEC critical-information review; link each to its source so it arrives as an explicit input to the next cycle.\n3. Update the control execution log with the cycle result and key metrics; confirm the next quarterly review is scheduled.\n4. Verify the archived record is immutable and retrievable before completing automatic archival.\n\n**Record in AssureSwarm**\n- Export the completed workflow instance (coach-workflow-export) and archive it as the durable audit trail on the anchor deception/OPSEC Control — the run itself is the operating record for the cycle.\n- Attach the closure record and the carry-forward list — decoys and taint mechanisms due for refresh and the next OPSEC critical-information review date — as documents on this step (coach-document-upload); these carry-forward items have no Task item type, so they live in the carry-forward document.\n- Open corrective actions carry forward as the still-open Issue items created at \"Remediate coverage gaps\" — link them to the anchor Control (coach-items-link: Issue ↔ Control) so they arrive as explicit inputs to the next cycle.\n\n**Exit criteria** — The archived record is immutable and retrievable; the next cycle is scheduled with carry-forward inputs; 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-deception-honeytoken-opsec-concealment-operations"}