Penetration testing rules of engagement turn written authorization into an operational plan: exact targets, approved methods, test accounts, timing, contacts, evidence handling and stop conditions. Use the worked scope decisions and copyable planning worksheet below to make those boundaries reviewable before any assessment begins.
This guide is for planning legitimate assessments of systems the organization owns or is authorized to test. It is not legal advice or permission to assess third-party services. Obtain the approvals and professional guidance appropriate to the systems, contracts, and jurisdictions involved.
Write penetration testing rules of engagement before testing
Identify the authorizing party and confirm that it has authority over the proposed targets. A request from an employee does not automatically authorize every connected platform or supplier system. Record the approval and the responsible assessment leads.
Define the purpose: inventory, configuration review, vulnerability assessment, penetration testing, or another bounded activity. These terms can imply different techniques and impact. Use concrete descriptions rather than assuming everyone interprets the label identically.
Make the approved rules available to the people performing and coordinating the work. An inaccessible document cannot guide decisions during an unexpected event.
List targets and exclusions precisely
Specify the addresses, applications, accounts, environments, and time window covered by approval. Include explicit exclusions for systems that must not be assessed. Clarify whether related domains, shared infrastructure, and third-party integrations are inside or outside scope.
Review target ownership before testing. Cloud resources and network ranges can change, and an old list may no longer describe the organization’s systems. Do not expand the scope because a linked host looks interesting.
Define how a newly discovered target is handled. The safe default is to record it and seek the required approval, not silently add it to active testing.
Agree on permitted techniques and impact limits
Separate passive review, ordinary interaction, scanning, and more intrusive validation. Specify which methods are permitted and any required safeguards. A broad statement that testing is authorized should not be treated as permission for every available tool feature.
Identify sensitive operations such as account lockout, service disruption, data modification, or external messaging. Define whether they are prohibited, restricted to a test environment, or allowed under a separate coordinated procedure.
Set resource and timing limits appropriate to the environment. Legacy or specialized devices may need additional precautions. The plan should reflect the actual systems rather than a generic tool default.
Define accounts and data boundaries
Use approved test identities with documented roles. Clarify what data testers may access, retain, or modify. A successful authorization check should not be demonstrated by collecting unnecessary personal records from real users.
Prefer synthetic data and representative nonproduction environments where the assessment goal allows it. If production testing is necessary, document the rationale and stricter handling requirements.
Set rules for credentials and secrets discovered during the assessment. Do not place live values in ordinary reports or public issue trackers. Use the approved secure route and involve the responsible owner when rotation or revocation is needed.
Establish communication and stop conditions
Name contacts who can respond during the test window. Define how testers report unexpected service behavior, a possible incident, or a scope question. A contact list should include an escalation route if the primary person is unavailable.
Agree on conditions that pause or stop activity. These can include unexpected disruption, sensitive data exposure, evidence of an unrelated incident, or uncertainty about target ownership. The exact conditions should match the environment and assessment risk.
Make the pause process operationally simple. A tester should not feel pressured to continue questionable activity because the plan lacks a clear route for obtaining a decision.
Coordinate monitoring and recovery
Decide how defenders and service owners will distinguish planned testing from unrelated activity. The arrangement depends on whether the assessment is intended to be visible or partly blind, but the responsible parties still need an approved safety and escalation model.
Confirm recovery options for activities that can affect data or availability. A backup that has never been restored is not a strong basis for accepting avoidable risk. Our WordPress restore-drill guide illustrates the value of proving recovery before relying on it.
Record the expected testing window and how changes are approved. Operational conditions can shift, so a postponed assessment may need renewed confirmation of targets and limits.
Set evidence and reporting requirements
Define what the report should contain: scope, methods, observed evidence, validation status, impact, limitations, and recommended remediation. Separate tool alerts from confirmed findings. Avoid making claims stronger than the evidence supports.
Protect screenshots, request logs, captured traffic, and exported records. Assessment evidence can reveal internal architecture and sensitive information. Choose approved storage, sharing, access, and retention rather than sending raw materials through convenient public services.
Include a clear handoff to the remediation owner. A report is more useful when the organization can identify the affected component, reproduce the safe evidence, and verify a correction.
Review changes and close the assessment
Treat changes to scope or technique as controlled updates that need the appropriate authorization. A verbal request during testing can be ambiguous; record the decision through the agreed process before changing activity.
At completion, reconcile created accounts, temporary access, test data, and diagnostic settings. Remove or hand over artifacts according to the plan, and confirm that unintended changes are addressed.
The NIST security testing and assessment guide provides broader planning context. Use its framework alongside the organization’s current policies and professional judgment, not as blanket permission for every technique.
Worked example: a staging review does not authorize its suppliers
This is a fictional planning exercise, not an assessment we performed or a grant of permission. A small team wants a manual, passive-observation review of its own staging application. The example host staging.example.com is a reserved illustrative name; it is not a target to test. The team must separately confirm ownership, contractual permissions and approvals for its real environment.
The proposed plan allows ordinary navigation through agreed test workflows using synthetic records. It excludes active scanning, exploitation, credential attacks, load testing and production data. The service owner has not yet approved the plan, so the initial decision is no testing. A filled-in worksheet alone is not authorization.
- A checkout link opens a payment provider: do not follow the real payment workflow as an assessment target. Confirm an approved sandbox and its separate provider rules first; otherwise exclude the workflow and record the coverage limit.
- A redirect reaches an unlisted hostname: stop that path, record only the non-sensitive destination and ask the assessment lead to resolve scope. An application link does not extend authorization.
- A test account exposes a real customer record: stop the relevant activity and notify the designated contact through the approved channel. Do not copy additional records to strengthen the finding.
- A scanner proposes active verification: decline it under this passive-only plan. Any change needs documented approval, a suitable environment and revised impact limits before execution.
- The agreed window ends or the response contact becomes unavailable: pause. Do not assume unfinished work extends the window or that a silent contact has approved continued activity.
- The test produces no alerts: report which workflows and roles were observed. Do not turn limited coverage into a claim that the application is secure.
Copyable rules of engagement planning worksheet
Replace every bracketed entry through the organization’s review process. An unresolved target, permission, contact or stop procedure means the relevant activity is not ready. Keep live credentials, customer records and raw session tokens out of this planning document.
ASSESSMENT PLAN — DRAFT, NOT AUTHORIZATION
Purpose and requested evidence: [bounded question]
Authorizing owner and basis of authority: [name/role/record]
Approved plan version and approval record: [reference]
Environment and exact target list: [reviewed assets]
Excluded targets, suppliers and integrations: [explicit list]
Permitted methods and prohibited actions: [specific limits]
Approved accounts and synthetic data: [references, no secrets]
Start/end and time zone: [approved window]
Traffic/impact limits and monitoring owner: [agreed controls]
Primary contact and escalation route: [reachable contacts]
Pause/stop triggers and restart authority: [decision process]
Evidence storage, access and retention: [approved procedure]
Change-control and emergency handling: [recorded workflow]
Recovery prerequisites and responsible owner: [checked evidence]
Report, remediation handoff and closeout: [owners/records]Before the start, walk through one scope question and one stop event with the responsible people. Confirm who can authorize restart rather than assuming the tester can decide alone. At closeout, reconcile temporary accounts and artifacts, hand findings to an owner, and record what remained untested. This worksheet organizes decisions; it is not a legal agreement, a safe-harbor statement or a complete assessment methodology.
For a related bounded workflow, read OWASP ZAP passive scanning and its limits. The NIST SP 800-115 publication provides broader assessment-planning context; use current organizational and provider requirements for the actual engagement.
Frequently asked questions
Does authorization for one website cover linked services?
Not automatically. Ownership and approval must cover the specific targets and activities. Treat third-party systems and newly discovered hosts as scope questions.
Should rules be copied unchanged from a template?
No. A template can help organize the plan, but targets, impact limits, contacts, and data handling must reflect the actual environment.
What should happen when the tester is uncertain?
Pause the relevant activity, preserve safe evidence, and use the agreed escalation route. A clear decision is preferable to an unsupported assumption about authority or impact.
