Rules of Engagement for a Safe Security Assessment
Rules of engagement (ROE) convert authorisation into safe operating limits. NIST testing guidance supports planning, execution, analysis, and mitigation; ROE fixes the human decisions that must exist before technical work begins. A statement that “testing is authorised” is insufficient without named assets, methods, contacts, exclusions, timing, data rules, and authority to stop.
Write decisions that testers can use
Name legal or business authoriser, technical owner, assessment lead, operations contact, incident contact, and a stop authority reachable during test window. Define time zone, allowed hours, escalation channel, acknowledgement expectation, and evidence storage. Identify production, staging, and sandbox separately. A hostname or IP range alone may not identify cloud tenant, shared service, third party, or environment.
List permitted methods precisely: authenticated application testing, configuration review, safe port discovery, or controlled phishing simulation only when individually authorised. List exclusions equally precisely: denial-of-service, destructive payloads, persistence, ransomware simulation, physical access, social engineering, production data extraction, third-party infrastructure, and payment or safety systems unless written scope says otherwise. “No disruption” is not measurable; name prohibited action and stop condition.
Stop authority beats momentum
Any tester may pause work for unexpected impact, real compromise indicators, scope uncertainty, sensitive data exposure beyond agreed handling, rate-limit symptoms, or an unapproved asset. Named stop authority can order immediate stop. Pause means stop active testing, preserve minimal facts, notify contacts, and wait for written direction; it does not mean keep probing while a message is sent.
| Decision | Evidence | Result |
|---|---|---|
| Approved API test | target, method, window signed | Pass: safe requests permitted |
| Load testing | not listed in methods | Fail: excluded; no test run |
| Unrecognised cloud host | owner cannot confirm | Stop: isolate evidence and notify |
| Alert from operations | stop authority invoked | Pass: activity halted and logged |
Protect data and evidence
ROE specifies least collection necessary to prove a condition, encryption and access control for evidence, retention period, transfer method, and deletion or return path. Do not place tokens, passwords, personal data, or full production records into ordinary chat, tickets, or reports. Define whether proof-of-concept may alter a record, create a test account, or send a notification. If it is not written, treat it as excluded.
Completed authorisation examples should show pass/fail. “Credentialed test account approved for staging tenant, role reader, expires August 3” is usable. “Test credentials provided” is not. “Production payment gateway excluded; vendor endpoint not touched” is usable. Every exception to a restriction needs issuer, exact method, asset, date, controls, and expiry.
Close safely
End with a stop time, debrief contact, evidence inventory, findings channel, and remediation/retest agreement if one exists. Do not promise an SLA or outcome. Preserve a chronological activity log so operations can distinguish assessment traffic from an incident. Strong ROE protects systems, assessors, and owners because it tells everyone when to proceed, when to pause, and who decides.
Confirm before each window
Before each testing window, confirm contacts, targets, monitoring state, scope amendment status, and stop channel. Record confirmation time and responder. If no reachable contact exists for a production test, defer that test rather than assuming prior approval still applies. During execution, record only necessary activity facts: time, target, method, result, and any pause. Do not record secrets in the activity log. After a pause, written resumption authority should state what changed and what remains excluded. This preserves safety when personnel, infrastructure, or threat conditions change during a multi-day assessment.
Review ROE changes
Treat a changed target, test method, test window, or data-handling rule as an ROE change. Record requester, assessment lead review, owner approval, and effective time. Do not rely on verbal expansion of scope during an incident. If operations requests investigation of a new host, pause until authority and safe method are written. At debrief, compare activity log with authorised methods and exclusions, then document any pause or exception. This review confirms operating boundaries worked and supplies specific improvements for future assessments without claiming a security outcome.
Keep authorization reproducible
Store signed scope version, amendment identifier, target inventory revision, approved methods, contact confirmation, and stop or resume decision with timestamps. Link activity entries to applicable authorization version. If a target is moved, renamed, or fronted by a third party, stop until owner confirms same authority applies. Reproducible authorization protects test team and operations when later evidence must be reviewed.
Sources
Worked closure check
For production API testing, close activity log against signed ROE revision, target inventory, approved window, stop contact, permitted method, assessment lead, and pause or resume decisions. Record shows authorized activity and observed outcome only; it does not prove security, compliance, certification, or legal authority beyond ROE. New host, technique, or handling rule needs written amendment before work resumes. Independent reviewer samples one request and confirms authorization version, log time, evidence custody, and exclusion status; any unauthorized activity or missing approval remains open.