/social-engineering-engagement-plan

name: social-engineering-engagement-plan
description: "Plans authorized defensive phishing simulations, vishing exercises, and other social-engineering engagements with explicit channel and cohort scope, pretext approval, participant safety, data minimization, readiness gates, metrics, and debrief. Use before measuring human-security exposure or reviewing a proposed campaign."
allowed-tools: Read Grep Glob

Social-engineering engagement plan

Defensive human-security testing measures organizational exposure and validates controls, but it can cause harm even when every technical action is reversible. Sponsor authority permits a bounded exercise; it does not prove the target list, pretext, infrastructure, control cell, support route, or data handling are ready.

This skill creates a checked plan. It does not write deceptive content, call scripts, payloads, collection pages, target profiles, or execution instructions.

When to Use

• Plan authorized human-security exercises safely.
• Use only within explicit authorization and the stated rules of engagement.

When NOT to Use

• Do not treat this skill as permission to access, test, or change a target.
• Do not convert missing evidence into a clean result or a stronger claim.

Workflow

1. Record the sponsor, window, timezone, owners, digest-bound written-authority evidence, its approving role and validity window, allowed and prohibited channels, asks, persona classes, themes, and actions. The v0.1 contract supports email and voice only; keep every other channel prohibited. 2. Define each target cohort by opaque ID, channel, supplied population, opaque inclusion and exclusion references, list state, and evidence. Never store addresses, numbers, names, or descriptive dossiers. 3. Describe pretexts by ID, persona class, channel, approved ask, state, evidence, and limitations. Store no message copy or scripts. 4. Inventory the target list, sending domain, training page, callback number, control cell, and support route as applicable. Planned infrastructure is not verified. 5. Define interaction stops for distress, participant request, reporting, active incidents, and out-of-scope people or data. Define campaign pauses for cumulative distress, client incidents, scope-risking defects, and loss of the control cell. Record whether a pause fired and bind a threshold-triggered pause to evidence. 6. Minimize data before execution. Allow only named event types; use opaque identities, aggregate reporting, no individual ranking, no public identification, and an owner for retention or disposition. Before readiness, choose no retention or a bounded retention period and name the disposition method. An unapproved event is not a useful extra metric. 7. Link each planned action to one authorization, cohort, approved pretext, safety policy, data policy, and every required infrastructure item. Keep it `planned` until all readiness evidence exists. 8. For executed actions, cite chronologically valid event-export or operator-log evidence and record bounded aggregate counts. Keep unexecuted and unapproved event fields null: zero is an observed measurement, not absence of collection. Never infer opens, delivery, reports, distress, or control adherence. 9. Cover authorization, cohort, pretext, infrastructure, safety, data handling, deconfliction, debrief, measurement, and reporting for every allowed channel. 10. Record immediate and organization-wide debrief ownership, participant support, feedback timing, and no-shaming rules.

Boundary with adjacent skills

• Use `osint-scanner` or `social-engineering-recon` to collect public intelligence.
• Use `opsec-planning` to compare detection risk and operational artifacts.
• Use this skill to govern authorized interaction with people and participant care.
• Use `findings-report` after evidenced results exist.
• Credential collection, payload delivery, physical-entry methods, and target-system

access require separate capabilities and explicit authority.

Rationalizations to reject

• **"The sponsor approved phishing, so the campaign is ready."** Approval does not

verify the target list, pretext, infrastructure, control cell, or support route.

• **"Open rate is standard."** If open tracking was not approved, it is prohibited

data collection rather than a free metric.

• **"A click means the participant was compromised."** It proves only the approved

event that was observed; credentials, execution, and access remain separate.

• **"We can exclude people manually during launch."** Exclusions belong in the

checked target manifest before contact.

• **"Stopping one call handles distress."** Individual stops and campaign-wide pause

thresholds solve different safety problems; both are required.

• **"Zero means we did not collect it."** Zero is a measured result. Prohibited or

uncollected events stay null so the record cannot disguise unauthorized telemetry.

• **"Recording helps evidence."** Recording requires explicit authorization and legal

review. A useful artifact does not create permission.

• **"Individual rankings make training actionable."** They increase harm and suppress

reporting. Report cohort and process controls unless individual handling is approved.

• **"A successful test should stay secret until the report."** Timely debrief and a

private support route are part of the engagement, not optional cleanup.