# Give every security test written rules of engagement > A useful penetration test can also interrupt services, expose data, or resemble a real attack. Written rules of engagement turn scope, permission, safety boundaries, communications, evidence handling, and stop authority into testable controls. - Canonical URL: https://update.dsesecurity.com/updates/give-every-security-test-written-rules-of-engagement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:38:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity - Reading time: 3 minutes ## What you need to know A useful penetration test can also interrupt services, expose data, or resemble a real attack. Written rules of engagement turn scope, permission, safety boundaries, communications, evidence handling, and stop authority into testable controls. ## Potentially affected Penetration tests, vulnerability validation, red-team exercises, external assessors, system owners, security operations, legal and privacy stakeholders, production services, and sensitive test evidence. ## DSE recommendation Approve rules of engagement before testing begins, validate every target and exclusion, establish communications and stop conditions, protect test data, and require retest evidence after remediation. ## Article ## Source facts: technical tests have different purposes and consequences NIST Special Publication 800-115 provides guidance for planning and conducting technical security tests and examinations, analyzing findings, and developing mitigation strategies. It describes techniques including review, target identification and analysis, vulnerability validation, and penetration testing. Each technique has different strengths, limitations, resource needs, and potential impact. A scan can identify a possible weakness without proving exploitability; a penetration test may demonstrate impact but can create operational risk. NIST organizes an assessment into planning, execution, and post-execution phases. Planning includes developing a policy, prioritizing and scheduling work, selecting and customizing techniques, managing logistics, identifying constraints, and establishing rules of engagement. Execution collects and validates data. Post-execution analyzes root causes, recommends mitigation, reports results, and supports remediation. Rules of engagement establish authority and boundaries for the assessment. Relevant subjects include purpose, scope, assumptions and limitations, risks, personnel, schedule, locations, equipment, communication, incident handling, target data, allowable and prohibited activities, data handling, and reporting. Because testing can look malicious, coordination with monitoring and incident-response functions must be intentional without unnecessarily defeating the exercise. ## DSE recommendation: make scope machine-verifiable and human-readable Name the sponsoring executive, system owner, test lead, provider, and person authorized to stop the work. State the objective in terms of the question the test must answer. List approved domains, addresses, applications, accounts, facilities, cloud tenants, interfaces, dates, and time zones. List exclusions just as precisely. Resolve shared hosting, supplier systems, subsidiaries, and dynamic cloud resources before execution. Confirm that the authorizing party has authority over every target and technique. Obtain separate written permission where a carrier, cloud provider, software supplier, landlord, or customer environment is involved. An internal contract cannot grant rights over someone else’s system. ## DSE recommendation: specify safety boundaries before the first packet - Control techniques. State whether social engineering, physical activity, credential attacks, persistence, malware simulation, exploitation, data access, privilege escalation, denial of service, or destructive commands are allowed, limited, or prohibited. - Define test identities and infrastructure. Register source addresses, tools, accounts, domains, callback systems, and expected artifacts so defenders can distinguish authorized work when necessary. - Protect production. Document backups, health checks, rate limits, fragile systems, prohibited hours, rollback steps, and the threshold for pausing activity. - Establish communications. Maintain primary and out-of-band contacts, check-in times, incident escalation, suspected-real-attack procedures, and a shared understanding of what defenders will and will not know. - Protect evidence. Define collection minimization, encryption, access, transfer, retention, deletion, and breach reporting for credentials, personal information, configuration, screenshots, packet captures, and exploit artifacts. ## DSE recommendation: preserve learning without preserving unnecessary risk Require testers to report critical safety or active-compromise findings immediately through the agreed channel. At completion, remove accounts, payloads, persistence, files, firewall changes, test data, and temporary infrastructure; then have the system owner verify cleanup. Record any artifact that cannot be removed. Reports should separate confirmed exploitation from inferred exposure, state the tested path and conditions, preserve evidence provenance, describe business consequence without overstating it, and identify limitations. Assign remediation owners and acceptance authority. Retest the corrected path and verify that the fix did not merely block one tool signature. Close with a joint review of unexpected effects, detection and response performance, communication failures, scope gaps, and assumptions. Retain authorization, final rules, activity logs, evidence index, findings, cleanup confirmation, and retest results under controlled access. Track the disposition of every copied credential or sensitive record and obtain written confirmation when the testing provider completes required deletion. Good rules do not make a test timid; they make its risk deliberate and its conclusions defensible. ## Official references - National Institute of Standards and Technology, [SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final), September 30, 2008; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/115/final - Source publication date: 2008-09-30 ## Citation and use Preferred citation: “Give every security test written rules of engagement,” DSE Security, https://update.dsesecurity.com/updates/give-every-security-test-written-rules-of-engagement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.