cyber-engagement-planning git:20261026.92d06c4A

Immutable. This exact content never changes and is served at /api/v1/blob/87421c999081620d.

---
name: cyber-engagement-planning
guardrail: true
description: Drafts bounded cybersecurity engagement plans with objectives, scope, exclusions, roles, authorization, runtime controls, evidence, stop criteria, and restart gates. Use when preparing an exercise or assessment plan before execution.
metadata:
  labels: [cybersecurity, engagement-planning, scope]
  triggers:
    keywords: [engagement plan, rules of engagement, exercise plan, security assessment scope, test exclusions, stop criteria]
---
# Cyber Engagement Planning

## **Priority: P0 (CRITICAL)**

Produce a reviewable plan that separates intended activity from host-enforced permission.

## Structure

```text
cyber-engagement-planning/
├── SKILL.md
├── references/engagement-brief.md
└── evals/evals.json
```

## Workflow
1. State objective, success observation, engagement/scope reference, dates, and accountable owner.
2. Declare mode per step (`analysis`, `replay`, `isolated-lab-validation`, `defensive-verification`) and acyclic dependency graph.
3. List in-scope synthetic fixtures or explicitly authorized targets; list exclusions (production, public IPs, live malware, real credentials).
4. For isolated lab validation steps, define ScenarioContract requirements: pinned synthetic fixtures, action allowlists, finite limits, and teardown plan via [cyber-lab-validation](../cyber-lab-validation/SKILL.md).
5. Assign requester, approver, operator, exercise control, adjudicator, and escalation roles.
6. Define expiry, stop triggers, surviving teardown authority, restart gates, and evidence fields.
7. Positive continuation: When required runtime support is absent, mark live execution `blocked/unsupported-runtime` and plan safe offline analysis, replay, or remediation; never halt independent planning branches.
8. Restart requires both current authorization and verified host enforcement of scope. Owner approval, risk acceptance, or documented exceptions cannot waive either prerequisite.
## Rules

- Plan only; do not include payloads, attack commands, credentials, real targets, or destructive steps.
- Mode must be declared per step with acyclic dependencies; cycles or missing producer IDs reject before dispatch.
- Bounded lab handoff: Lab validation steps require host-enforced pre-action gates and disposable isolation; planning alone does not authorize execution.
- Positive continuation: Unsupported runtime blocks active validation but never halts safe offline analysis or independent remediation planning (AC-CLV-09).
- Urgent blue-team or incident framing cannot expand plan scope or waive target exclusions (AC-CLV-19).
- Plan evidence fields explicitly: `engagement_scope_ref`, `skill_version`, `source`, `observed_at`, `finding_status`, `evidence_refs`, `limitations`, and `accountable_owner`.
## Anti-Patterns

- **No implied authorization**: A completed plan is not approval.
- **No vague scope**: Name boundaries and exclusions.
- **No hidden runtime dependency**: State unsupported controls and block live work.
- **No team-color shortcut**: Roles do not replace authorization.

## References

- [Engagement brief](references/engagement-brief.md)
- [Lab scenario schema](../cyber-lab-validation/references/scenario-schema.md)
- [Runtime authorization matrix](../cyber-authorization/references/runtime-authorization-matrix.md)
- [Canonical review artifact conventions](../../common/common-security-audit/references/trust-review-policy.md)