# PLAYBOOK — ROE Templates and Authorization Flow ## Default ROE template ```yaml engagement_id: ---PENTEST- authorizer: name: "" email: "" role: "" # CISO, CTO, VP Eng, Director of Security, etc. organization: "" in_scope_targets: - host: "" notes: "" out_of_scope_targets: - host: "" reason: "" time_window: start: "2026-MM-DDT00:00:00Z" end: "2026-MM-DDT23:59:59Z" emergency_contact: name: "" phone: "" email: "" rules: - No exploitation of confirmed findings without written prompt approval. - No password cracking against production accounts. - Testing pauses during declared business-hours blackout windows. - All findings are confidential until report delivery. signature_block: signer: "" signed_at: "2026-MM-DDTHH:MM:SSZ" signature: | ``` ## Per-engagement-type variants ### External web-app pentest `in_scope_targets` is hosts/URLs. `rules` typically include "no DoS, no brute-force against rate-limited endpoints, no testing during peak hours (specify the window)." ### Internal network pentest `in_scope_targets` is CIDRs. `out_of_scope_targets` typically excludes the company VOIP range, the surveillance camera VLAN, and any PCI scope without separate authz. `rules` typically include "no exploit of the domain controller, no lateral movement past the documented hop limit." ### Red-team engagement `in_scope_targets` may be the entire ASN, with explicit `out_of_scope` exclusions. `rules` typically include "exfiltration attempts are in scope; persistence mechanisms must be reversible; physical intrusion is/isn't included." Time window is often months. ### Purple-team engagement ROE has an explicit clause acknowledging the SOC is informed. Adds a `coordination_contact` field for the SOC liaison. ### Cloud account pentest (AWS/Azure/GCP) `in_scope_targets` includes account IDs / subscription IDs. `rules` typically include "no creation of new principal identities beyond the documented test identity; no modification of production IAM roles." ### SaaS integration pentest `in_scope_targets` is the customer's tenant in the SaaS app. `rules` typically include the SaaS vendor's own policy (many SaaS vendors require explicit prior notification before testing). ## Authorization escalation flow When the prospective authorizer says "yes, you can test," the escalation flow inside the customer's organization typically: 1. **Operational owner agreement** — the team that owns the system signs off that testing is welcome. 2. **Security leadership approval** — CISO or equivalent approves the engagement scope. 3. **Legal review** — the customer's counsel reviews the ROE for indemnification, liability cap, and scope clarity. 4. **Executive sign-off** — for high-value or high-risk engagements, CFO/COO/CEO sign as the binding party. The skill's `.allowed-authorizers` list captures step 2 + 4 identities — security leadership + executive sign-off — as the authoritative signers. Operational owners are not in the allowlist by default because they typically don't bind the organization legally. ## Time-window extension procedure When an in-progress engagement needs more time: 1. Tester requests extension via the engagement's documented communication channel. 2. Authorizer (or delegate from the allowlist) signs a new ROE with the extended `time_window.end`. 3. Tester archives BOTH the original ROE and the extension; the skill is re-run against the extension and produces a fresh authorization record. Never run the skill on a ROE whose time window has been verbally or informally extended. The whole point of the schema is to make extensions auditable. ## Emergency-stop protocol A pentest can need to stop immediately when: - The customer's SOC detects testing activity and treats it as a real attack (the test pre-notification didn't reach the SOC team on shift). - An out-of-scope system is accidentally probed. - The tester's tools cause an unexpected outage. - The customer requests a halt for any reason. The ROE's `emergency_contact` field is the call-immediately number. Halting is a hard stop: 1. Cease all active tools. 2. Notify the emergency_contact verbally. 3. Document the stop time + reason. 4. Re-run the authorization skill before resuming. If anything in the ROE changed (e.g. scope amendment), the skill produces the new authorization record. ## Allowed-authorizers file format ``` # .allowed-authorizers — one signer identity per line # Comments OK. Email addresses or PGP key fingerprints. jane.doe@acme.example john.smith@acme.example 0xDEADBEEFCAFE1234 ``` Maintained by the tester's business-development team. Updates should require a co-sign from a second person to prevent single-actor manipulation. ## Storage and retention The ROE itself is part of the engagement evidence chain. Store it in the engagement's evidence directory, NOT in the customer's codebase under test: ``` engagements/ └── acme-2026-q2/ ├── roe.yaml ├── allowed-authorizers ├── evidence/ │ ├── authz-check-20260601.json │ ├── authz-check-20260615.json # after time-window extension │ └── ... └── findings/ └── ... ``` Retention: keep ROEs for at least the statute-of-limitations period for unauthorized-access offences in the relevant jurisdiction (typically 5-7 years). Some customers require longer retention for SOC2 / ISO 27001 evidence. ## When the customer signs a "blanket" pentest authorization Some customers issue a blanket annual or multi-year authorization covering all engagements with a given pentester. This is legally valid but operationally risky: - Scope drift across engagements becomes invisible. - Personnel changes on either side can void the blanket implicitly. - Time-window enforcement disappears. Recommended: write a per-engagement ROE that references the blanket authorization but adds specific scope + time window. The blanket establishes the relationship; the per-engagement ROE establishes what's authorized today.