Security Assessment

Required Tools

This is an orchestrator skill that delegates to sub-skills. Tool requirements depend on which sub-skills are invoked during the assessment.

Tool Execution Protocol

Before starting any assessment, verify tool availability and establish fallback chains:

1. Pre-Assessment Tool Check

CRITICAL: If SUPERHACKERS_ROOT is not set, auto-detect it first

# Auto-detect SUPERHACKERS_ROOT if not set
if [ -z "${SUPERHACKERS_ROOT:-}" ]; then
  # Try common plugin cache paths
  for path in \
    "$HOME/.claude/plugins/cache/superhackers/superhackers/1.2.* \
    "$HOME/.claude/plugins/cache/superhackers/superhackers/"* \
    "$HOME/superhackers" \
    "$(pwd)/superhackers" \
    "$(dirname "$(dirname "${BASH_SOURCE[0]:-$0}")")"; do
    if [ -d "$path" ] && [ -f "$path/scripts/detect-tools.sh" ]; then
      export SUPERHACKERS_ROOT="$path"
      echo "Auto-detected SUPERHACKERS_ROOT=$SUPERHACKERS_ROOT"
      break
    fi
  done
fi

# Verify detection worked
if [ -z "${SUPERHACKERS_ROOT:-}" ] || [ ! -f "$SUPERHACKERS_ROOT/scripts/detect-tools.sh" ]; then
  echo "ERROR: SUPERHACKERS_ROOT not set and auto-detection failed"
  echo "Please set: export SUPERHACKERS_ROOT=/path/to/superhackers"
  return 1
fi

# Run automated tool detection
bash $SUPERHACKERS_ROOT/scripts/detect-tools.sh > tool_check.log 2>&1

# Analyze results
if rg -q "TOOLS_BROKEN" tool_check.log; then
  echo "WARNING: Some tools are broken and need reinstallation"
  rg "TOOLS_BROKEN" tool_check.log
fi

if rg -q "REQUIRED_MISSING" tool_check.log; then
  echo "CRITICAL: Required tools are missing"
  rg "REQUIRED_MISSING" tool_check.log
  echo ""
  echo "Options:"
  echo "1. Install missing tools (see SETUP.md)"
  echo "2. Proceed with available tools (reduced coverage)"
  echo "3. Cancel assessment"
fi

# Cache tool availability for sub-skills
export TOOL_AVAILABILITY=$(cat tool_check.log)

2. Sub-Skill Tool Validation

Before delegating to any sub-skill, verify its required tools are available:

# Check if recon tools are available before loading recon skill
RECON_TOOLS="rustscan nmap ffuf nuclei httpx dig"
MISSING_TOOLS=()

for tool in $RECON_TOOLS; do
  if ! command -v $tool >/dev/null 2>&1; then
    MISSING_TOOLS+=($tool)
  fi
done

if [ ${#MISSING_TOOLS[@]} -gt 0 ]; then
  echo "WARNING: Recon phase missing tools: ${MISSING_TOOLS[*]}"
  echo "Fallback tools will be used by recon skill"
  echo "See TOOLCHAIN.md for fallback chains"
fi

3. Tool Failure During Assessment

If a tool fails during assessment execution:

1. Don't skip the phase - Use fallback tools
2. Document the failure - Note which tools failed and what was used instead
3. Don't downgrade severity - Finding severity based on what was tested, not what failed

# Example: Port scanning phase
echo "=== Phase 2: Port Scanning ==="

if command -v rustscan >/dev/null 2>&1; then
  echo "Using rustscan for port discovery..."
  bash $SUPERHACKERS_ROOT/scripts/run-tool.sh rustscan 60 scan_results.txt -- rustscan -a $TARGET --ulimit 5000
else
  echo "PRIMARY_TOOL_FAILURE: rustscan not available"
  echo "FALLBACK: Using nmap for port scanning"
  bash $SUPERHACKERS_ROOT/scripts/run-tool.sh nmap 300 scan_results.txt -- nmap -sS -T4 $TARGET
fi

# Validate output before proceeding
bash $SUPERHACKERS_ROOT/scripts/validate-output.sh rustscan scan_results.txt $?

4. Assessment-Level Decision Tree

When multiple tools fail, decide whether to:

• Continue with reduced coverage - Document limitations, test what you can
• Re-plan the assessment - Adjust methodology to available tools
• Report to stakeholder - If critical tools are missing

# Decision framework
PRIMARY_TOOLS_AVAILABLE=$(rg -c "local" tool_check.log)
TOTAL_REQUIRED_TOOLS=$(rg -c "Yes" TOOLCHAIN.md | head -1)

AVAILABILITY_RATIO=$((PRIMARY_TOOLS_AVAILABLE * 100 / TOTAL_REQUIRED_TOOLS))

if [ $AVAILABILITY_RATIO -lt 50 ]; then
  echo "WARNING: Less than 50% of required tools available"
  echo "Recommendation: Re-plan assessment or install tools"
  echo "Current tool availability: $PRIMARY_TOOLS_AVAILABLE/$TOTAL_REQUIRED_TOOLS"
fi

Run bash $SUPERHACKERS_ROOT/scripts/detect-tools.sh for tool availability, or read $SUPERHACKERS_ROOT/TOOLCHAIN.md for the full resolution protocol before starting any assessment to identify available tools and plan accordingly.

Overview

Role: Engagement Planner — Your job is to define scope, select methodology, and sequence the engagement phases. Stay in your lane: you plan and coordinate, you do NOT perform testing, verification, or reporting.

Master orchestrator skill for comprehensive security assessments. This skill coordinates the full assessment lifecycle — from scoping and planning through testing, analysis, and reporting. It ties together all specialized security skills (recon, pentesting, code review, exploit development, reporting) into a cohesive engagement.

Pipeline Position

Position: Phase 1 (Planning) — the FIRST skill loaded in a full engagement Expected Input: User's scope definition, target URLs/IPs, rules of engagement, engagement depth preference Your Output: Engagement plan — scope boundaries, skill sequence, depth selection, rules of engagement Consumed By: All subsequent skills (defines their operating boundaries and sequence) Critical: Your plan determines which skills are loaded, in what order, and at what depth. An incomplete plan = an incomplete engagement.

This is NOT a replacement for specialized skills. It is the conductor that determines WHICH skills to invoke, in WHAT order, and HOW to synthesize their outputs into actionable security intelligence.

Sub-Skill Registry

When to Use

• Starting a new security assessment, pentest, or red team engagement
• Defining scope, rules of engagement, or methodology for a security project
• Coordinating multiple testing activities across different attack surfaces
• Performing threat modeling (STRIDE, attack trees, DFDs)
• Rating vulnerabilities with CVSS and mapping to compliance frameworks
• Managing assessment timeline, milestones, and deliverables
• Communicating findings to stakeholders (emergency, interim, final)
• Deciding which specialized skill to invoke for a given task
• Synthesizing findings from multiple testing phases into a unified report

Core Pattern

PLAN  → Define scope, methodology, threat model, timeline
  ↓
RECON → Discover and enumerate the attack surface
  ↓
TEST  → Execute testing activities using specialized skills
  ↓
ANALYZE → Rate findings, assess risk, map to frameworks
  ↓
REPORT → Compile deliverables, present to stakeholders

Execution Discipline

• Persist: Continue working through ALL steps of the Core Pattern until completion criteria are met. Do NOT stop after a single tool run or partial result.
• Scope: Work ONLY within this skill's methodology. Do NOT jump to another phase (e.g., don't start writing the report while still testing).
• Negative Results: If thorough testing reveals no vulnerabilities, that IS a valid result. Document what was tested and report "no findings" — do NOT invent issues.
• Retry Limit: Max 3 attempts per test. If blocked, classify the failure and proceed.

Quick Reference

Assessment Type Decision Matrix

Skill Orchestration Flowchart

External Assessment (no source):
  recon-and-enumeration → webapp-pentesting / api-pentesting / infra-pentesting
    → vulnerability-verification → exploit-development (if needed)
    → writing-security-reports

Internal Assessment (with source):
  secure-code-review → vulnerability-verification
    → webapp-pentesting / api-pentesting (validate in running app)
    → writing-security-reports

Full Engagement:
  recon-and-enumeration → secure-code-review (if source available)
    → webapp-pentesting + api-pentesting + infra-pentesting + android-pentesting
    → vulnerability-verification → exploit-development
    → writing-security-reports

CVSS v4.0 Quick Scoring

CVSS 4.0 uses a lookup-based algorithm rather than a simple formula with individual metric weights. Use the FIRST calculator or Python cvss library for accurate scores.

Note: Use Python cvss library (pip install cvss) for accurate score calculation: from cvss import CVSS4

Implementation

Phase 1: Assessment Planning

1.1 Scope Definition

Establish clear boundaries before any testing begins.

## Assessment Scope Document

### In-Scope Assets
- [ ] Web applications (list URLs/domains)
- [ ] APIs (list endpoints, documentation links)
- [ ] Infrastructure (list IP ranges, cloud accounts)
- [ ] Mobile applications (list app IDs, platforms)
- [ ] Source code repositories (list repos, branches)
- [ ] Internal networks (list VLANs, subnets)

### Out-of-Scope
- [ ] Third-party services not owned by client
- [ ] Production databases (unless explicitly authorized)
- [ ] Denial-of-service testing (unless explicitly authorized)
- [ ] Social engineering (unless explicitly authorized)
- [ ] Physical security testing (unless explicitly authorized)

### Rules of Engagement
- Testing window: [dates and times]
- Emergency contact: [name, phone, email]
- Escalation procedure: [steps for critical findings]
- Data handling: [classification, storage, destruction]
- Credential usage: [provided creds, credential stuffing policy]
- Automated scanning limits: [rate limiting, excluded scanners]

1.2 Engagement Depth Selection

Before selecting methodology, determine the engagement depth. This setting propagates to ALL downstream skills and controls how much time and effort is invested in each phase.

Quick Depth:

• Recon: Map auth + critical flows only, identify high-value endpoints, skip deep discovery
• Testing: Focus on critical/high-impact vulns only (auth bypass, RCE, SQLi, SSRF, exposed secrets)
• Subagents: Only for parallel high-priority targets
• Validation: Minimal PoC, demonstrate real impact
• Chaining: When a strong primitive is found, attempt ONE high-impact pivot immediately
• Scanner config: nuclei -severity critical,high only

Standard Depth:

• Recon: Full crawl, endpoint enumeration, role mapping, tech fingerprinting
• Testing: Systematic by category with focused subagents (input validation, auth, access control, business logic)
• Subagents: One per testing category, run in parallel
• Validation: Working PoC with impact demonstration, try one chain per finding
• Chaining: Always ask "what does this finding enable next?" — prefer complete end-to-end paths
• Scanner config: nuclei -severity critical,high,medium

Deep Depth:

• Recon: Whitebox analysis — every code path, data model, integration point. If source available, map every file/module
• Business Logic: Map every user flow, state machine, trust boundary, invariant. Identify implicit assumptions
• Testing: Hierarchical decomposition — component → feature → vulnerability level. Each area gets dedicated analysis
• Subagents: Spawn specialized agents per component, scale horizontally
• Chaining: Every finding is a pivot point — continue to maximum privilege. Validate full sequence
• Persistence: Research tech-specific bypasses, alternative techniques, edge cases. Revisit with new info from other findings
• Scanner config: nuclei with all templates, custom templates if needed

How to determine depth:

• User says "quick check", "sanity test", "before deployment" → Quick
• User says "pentest", "security assessment", "vulnerability assessment" → Standard
• User says "comprehensive", "thorough", "annual assessment", "red team" → Deep
• If unclear → Ask: "Should I do a quick high-impact check, a standard systematic assessment, or a deep comprehensive review?"

Propagating depth to downstream skills: When invoking sub-skills, pass the depth context:

Engagement depth: [Quick|Standard|Deep]
→ recon-and-enumeration: adjust scope per depth level above
→ webapp/api/infra-pentesting: adjust testing breadth and tool configuration
→ vulnerability-verification: adjust PoC depth (minimal for Quick, full for Deep)
→ exploit-development: skip for Quick, selective for Standard, comprehensive for Deep

Time Distribution Within Each Phase

Regardless of engagement depth, distribute effort within each phase as:

Anti-patterns:

• Spending 80% on automated scanning — miss manual-only findings
• Spending 80% on one attack vector — miss breadth
• Skipping evaluation — report unverified findings

Plan Adaptation: When findings change priorities, adjust the remaining plan using minimal modifications — don't restart from scratch. Add new targets, remove dead ends, reorder by updated priority.

1.3 Methodology Selection

Choose methodology based on assessment type and client requirements:

1.3 Threat Modeling

Perform threat modeling BEFORE testing to focus effort on highest-risk areas.

STRIDE Model — Apply to each component in the data flow:

Building an Attack Tree:

Goal: Access admin panel without authorization
├── Bypass authentication
│   ├── Brute-force credentials
│   ├── Exploit password reset flow
│   ├── Steal session token (XSS, session fixation)
│   └── Exploit SSO/OAuth misconfiguration
├── Bypass authorization
│   ├── IDOR on admin API endpoints
│   ├── Modify role claim in JWT
│   ├── Exploit mass assignment to set admin flag
│   └── Access admin routes without auth middleware
└── Exploit infrastructure
    ├── Access admin interface on internal port
    ├── Exploit SSRF to reach admin panel
    └── Pivot from compromised internal host

Data Flow Diagram Approach:

1. Identify all data entry points (user inputs, API calls, file uploads, third-party webhooks)
2. Map data flows between components (frontend → API → database → cache)
3. Mark trust boundaries (internet → DMZ → internal network → database tier)
4. Identify where data crosses trust boundaries — these are your priority testing points
5. Document data sensitivity levels at each point

Phase 2: Reconnaissance

REQUIRED SUB-SKILL: Use superhackers:recon-and-enumeration for detailed reconnaissance methodology.

Orchestration approach for recon:

# 1. Passive reconnaissance first — no direct target interaction
# Domain enumeration, OSINT, technology fingerprinting
# → Output: list of subdomains, IPs, technologies, exposed services

# 2. Active reconnaissance — direct target interaction
# Port scanning, service enumeration, directory discovery
# → Output: detailed service map, application inventory

# 3. Synthesis — combine passive and active findings
# Build target inventory with:
#   - Each application/service identified
#   - Technology stack per target
#   - Authentication mechanisms observed
#   - Potential attack vectors per target

Phase 3: Testing Execution

3.1 Testing Orchestration

Execute testing in priority order based on threat model:

Priority 1: Authentication & Authorization
  REQUIRED SUB-SKILL: Use superhackers:webapp-pentesting for web auth testing
  REQUIRED SUB-SKILL: Use superhackers:api-pentesting for API auth testing
  Focus: Login bypass, privilege escalation, session management, OAuth/OIDC flows

Priority 2: Injection & Input Handling
  REQUIRED SUB-SKILL: Use superhackers:webapp-pentesting for web injection testing
  REQUIRED SUB-SKILL: Use superhackers:api-pentesting for API injection testing
  REQUIRED SUB-SKILL: Use superhackers:secure-code-review for source-level analysis
  Focus: SQLi, XSS, SSTI, command injection, deserialization

Priority 3: Business Logic
  No specific sub-skill — requires manual analysis based on application context
  Focus: Payment manipulation, workflow bypass, race conditions, IDOR

Priority 4: Infrastructure
  REQUIRED SUB-SKILL: Use superhackers:infra-pentesting for infrastructure testing
  Focus: Service misconfigurations, default credentials, network segmentation

Priority 5: Client-Side & Mobile
  REQUIRED SUB-SKILL: Use superhackers:android-pentesting for Android testing
  Focus: Local storage, certificate pinning, reverse engineering, IPC

Priority 6: Configuration & Hardening
  REQUIRED SUB-SKILL: Use superhackers:secure-code-review for configuration review
  Focus: Headers, TLS, CORS, cookie flags, error handling

3.2 Testing Tracker

Maintain a testing checklist during execution:

## Testing Progress

### Authentication (P1)
- [ ] Registration flow — input validation, email verification
- [ ] Login — brute force protection, credential stuffing, timing attacks
- [ ] Password reset — token entropy, expiration, reuse
- [ ] Session management — token generation, expiration, invalidation
- [ ] Multi-factor auth — bypass techniques, fallback mechanisms
- [ ] OAuth/OIDC — redirect_uri validation, state parameter, token leakage

### Authorization (P1)
- [ ] Horizontal access control — IDOR on all resource endpoints
- [ ] Vertical access control — privilege escalation paths
- [ ] Function-level access — admin functionality accessible to users
- [ ] API authorization — missing auth on endpoints

### Injection (P2)
- [ ] SQL injection — all input points, blind, time-based
- [ ] Cross-site scripting — reflected, stored, DOM-based
- [ ] Command injection — OS command contexts
- [ ] Template injection — server-side template engines
- [ ] LDAP/XPath injection — directory service queries
- [ ] Header injection — HTTP response splitting, host header

### Data Exposure (P2)
- [ ] Sensitive data in responses — PII, credentials, tokens
- [ ] Error handling — stack traces, debug info, verbose errors
- [ ] API response filtering — excessive data exposure
- [ ] Caching — sensitive data in cache headers

### Business Logic (P3)
- [ ] Payment/transaction manipulation
- [ ] Workflow bypass — skipping required steps
- [ ] Race conditions — TOCTOU, parallel request abuse
- [ ] Rate limiting — absence or bypass

### Infrastructure (P4)
- [ ] TLS configuration — protocol version, cipher suites
- [ ] Security headers — CSP, HSTS, X-Frame-Options, etc.
- [ ] CORS configuration — origin validation
- [ ] Cookie attributes — Secure, HttpOnly, SameSite

3.3 Emergency Finding Protocol

When a critical vulnerability is discovered during testing:

1. Stop and document — capture full evidence immediately (request/response, screenshot, reproduction steps)
2. Assess blast radius — determine if actively exploited or if others could discover it
3. Notify immediately — contact emergency contact from scope document
4. Provide quick remediation — give the client actionable steps to mitigate RIGHT NOW
5. Continue testing — don't let one critical finding halt the entire assessment
6. Follow up in report — include full write-up in final deliverable

## EMERGENCY FINDING NOTIFICATION

**Date/Time:** [timestamp]
**Severity:** CRITICAL
**Title:** [concise title]

**Description:** [1-2 sentences]

**Evidence:** [screenshot/request/response]

**Immediate Risk:** [what's exposed RIGHT NOW]

**Recommended Immediate Action:**
1. [specific step to mitigate]
2. [specific step to mitigate]

**Full details will be provided in the final report.**

Phase 4: Risk Analysis

4.1 CVSS Scoring Process

For each finding, calculate CVSS 4.0 base score:

1. Determine Attack Vector — how does attacker reach the vulnerable component?
   Network = remotely exploitable over internet
   Adjacent = requires same network segment
   Local = requires local access or user interaction to deliver payload
   Physical = requires physical access

2. Determine Attack Complexity — are there conditions beyond attacker's control?
   Low = no special conditions, works reliably
   High = requires specific configuration, race condition, or MITM position

3. Determine Attack Requirements — are there prerequisites for exploitation?
   None = no preconditions needed
   Present = specific deployment/config requirements

4. Determine Privileges Required — what access level is needed?
   None = unauthenticated
   Low = regular user account
   High = admin/privileged account

5. Determine User Interaction — does a victim need to do something?
   None = fully attacker-driven
   Passive = victim must access the vulnerable system (e.g., visit a page)
   Active = victim must actively interact (e.g., submit a form, accept a prompt)

6. Determine Vulnerable System Impact — what's the effect on the vulnerable component?
   Confidentiality (VC): None / Low (limited data) / High (all data)
   Integrity (VI): None / Low (limited modification) / High (full modification)
   Availability (VA): None / Low (degraded) / High (full DoS)

7. Determine Subsequent System Impact — does exploitation impact resources beyond the vulnerable component?
   Confidentiality (SC): None / Low / High
   Integrity (SI): None / Low / High
   Availability (SA): None / Low / High

4.2 Business Impact Assessment

CVSS alone is insufficient. Overlay business context:

Adjust severity based on business context:

• SQLi on a public-facing app with 10M user records → stays Critical
• SQLi on an internal tool with test data only → downgrade to Medium
• XSS on marketing site with no auth → Low
• XSS on banking portal → High/Critical

4.3 Compliance Mapping

Map each finding to relevant compliance frameworks:

OWASP Top 10 (2021) Mapping:

SANS/CWE Top 25 — Map findings to specific CWE IDs:

PCI DSS Mapping (for payment-related targets):

SOC 2 Trust Service Criteria Mapping:

ISO 27001 Annex A Controls:

Phase 5: Reporting & Deliverables

REQUIRED SUB-SKILL: Use superhackers:writing-security-reports for detailed report writing methodology.

5.1 Report Structure

1. Executive Summary (1-2 pages)
   - Assessment overview and scope
   - Key findings summary (Critical/High counts)
   - Overall risk posture assessment
   - Top 3 recommendations

2. Methodology
   - Testing approach and tools used
   - Assessment timeline
   - Limitations and caveats

3. Findings (bulk of report)
   - Ordered by severity (Critical → Info)
   - Each finding: description, evidence, impact, remediation, references
   - CVSS score and compliance mapping per finding

4. Risk Summary
   - Finding distribution by severity
   - Finding distribution by category
   - Trend analysis (if repeat assessment)

5. Remediation Roadmap
   - Prioritized action items
   - Quick wins (< 1 day effort)
   - Medium-term fixes (1-2 weeks)
   - Strategic improvements (1-3 months)

6. Appendices
   - Full vulnerability details
   - Tool output
   - Scope document
   - Testing evidence

5.2 Stakeholder Communication Timeline

5.3 Assessment Closeout Checklist

## Closeout Checklist

### Evidence & Data
- [ ] All testing evidence organized and stored securely
- [ ] Client data purged from testing systems
- [ ] Credentials rotated or returned
- [ ] VPN/access tokens revoked
- [ ] Testing tools removed from client environment

### Deliverables
- [ ] Executive summary delivered
- [ ] Technical report delivered
- [ ] Raw findings exported (CSV/JSON if requested)
- [ ] Remediation roadmap included
- [ ] Presentation slides prepared (if requested)

### Follow-Up
- [ ] Retest date scheduled
- [ ] Remediation guidance provided for each finding
- [ ] Client questions addressed
- [ ] Lessons learned documented internally

Common Mistakes

1. Starting Testing Without a Plan

Wrong: Jump straight into scanning and exploitation. Right: Define scope, rules of engagement, threat model, and methodology FIRST. Testing without a plan leads to missed areas, scope creep, and client conflicts.

2. Using Only One Testing Approach

Wrong: Run automated scanners and report the output. Right: Combine automated scanning, manual testing, and code review. Scanners miss business logic flaws, auth issues, and complex injection chains. Each approach catches what others miss.

3. Skipping Threat Modeling

Wrong: Test everything with equal depth. Right: Build a threat model first to identify highest-risk areas. A threat model focusing testing on auth and payment flows is more valuable than broad shallow coverage.

4. Reporting Vulnerabilities Without Verification

Wrong: Report scanner output as confirmed findings. Right: Verify every finding before including in the report. False positives destroy credibility. REQUIRED SUB-SKILL: Use superhackers:vulnerability-verification for confirmation methodology.

5. Poor Severity Rating

Wrong: Using tool-assigned severity without context. Right: Calculate CVSS manually and overlay business impact. A "Critical" finding on an internal dev server with no sensitive data is not the same as one on the production payment system.

6. Missing the Forest for the Trees

Wrong: Listing 150 individual findings without synthesis. Right: Identify systemic issues. "50 XSS findings across the application indicate a systemic lack of output encoding, not 50 separate problems." Root cause analysis is more valuable than finding enumeration.

7. Incomplete Scope Coverage

Wrong: Spending all time on the main web app and ignoring APIs, mobile, or infra. Right: Track coverage against the scope document. Use the testing tracker from Phase 3 to ensure every in-scope asset gets tested. Flag under-tested areas in the report.

8. Not Communicating Critical Findings Immediately

Wrong: Waiting until the final report to disclose a critical RCE. Right: Follow the emergency finding protocol. If you find a critical vulnerability that is actively exploitable, notify the client IMMEDIATELY. Waiting until the report is irresponsible.

9. Ignoring Compliance Context

Wrong: Delivering findings without compliance mapping. Right: Ask the client about their compliance requirements upfront. Map findings to OWASP Top 10, PCI DSS, SOC 2, or ISO 27001 as relevant. This makes findings actionable for compliance teams.

10. No Remediation Guidance

Wrong: "Fix the SQL injection." Right: Provide specific, actionable remediation with code examples. Show the vulnerable code AND the fixed version. Include framework-specific guidance (e.g., "Use Django ORM's parameterized queries instead of raw SQL"). REQUIRED SUB-SKILL: Use superhackers:writing-security-reports for structured remediation guidance.

Completion Criteria

This skill's work is DONE when ALL of the following are true:

• Scope boundaries are clearly defined (in-scope targets, out-of-scope exclusions)
• Engagement depth has been selected (Quick / Standard / Deep)
• Skill sequence has been determined (which testing skills apply to this target)
• Rules of engagement are documented (testing windows, restricted actions, escalation contacts)
• All todo items created during this phase are marked complete

When all conditions are met, state "Phase complete: security-assessment" and stop. Transition to recon-and-enumeration as the next phase.