What to include in security testing rules of engagement

Write rules that can answer an operational question

Rules of engagement should help a practitioner decide whether the next action is permitted, prohibited, or awaiting clarification. A document that describes the business objective but leaves systems and methods undefined does not provide that operational clarity.

Use concrete boundaries and named decision roles. “Test the environment” is ambiguous; an approved inventory with explicit exclusions, permitted activities, a time window, and a stop contact is reviewable. Keep sensitive target details in the controlled engagement record, not in a public template or email subject.

Separate permission, scope, and constraints

Permission identifies who can authorize the work. Scope identifies the systems and activities being authorized. Constraints define the conditions under which those activities may proceed. Record all three rather than treating a stakeholder’s interest as permission to test.

Third-party systems and shared infrastructure require special attention because the customer may not control every relevant boundary. If authorization is unclear, exclude the activity until the appropriate owner resolves it. This worksheet is a planning structure, not legal advice or an authorization document by itself.

Make stop and resume decisions explicit

Agree what happens if the environment becomes unstable, a sensitive system is encountered, scope is ambiguous, or an operational contact cannot be reached. State who can stop work and who can authorize resumption. Those are not necessarily the same decision.

A request to expand scope should describe the change, its reason, affected systems, and revised constraints. Record approval before acting. Retain the previous version so a reviewer can understand which boundaries applied when a particular activity occurred.

Agree evidence handling before collecting it

Specify the minimum evidence needed, who may receive it, the transfer method, and retention or deletion expectations. Sensitive artifacts need handling rules even when the assessment itself is authorized. Avoid collecting unrelated customer data simply because it is accessible.

Use the worksheet as an agenda for review with the customer and testing lead. Resolve the authorization and safety rows before activity. Later changes should update the agreement and the people relying on it, not just a private copy on one person’s laptop.

Your working record

Adapt these criteria to the engagement. The CSV includes blank evidence, status, owner, and review-date fields. Nothing is pre-marked as passed. Scroll the table horizontally on small screens.

Worked example: an unexpected dependency

Illustrative scenario: an approved application points to a service that is absent from the target inventory. The operator records the dependency without actively extending testing to it. The engagement owner checks ownership and whether additional permission is required.

If the dependency is added, the parties update scope, constraints, and the applicable version before activity proceeds. If it remains excluded, the final report states the resulting coverage limitation. The agreement has done its job when uncertainty produces a controlled decision, not an improvised expansion.

Source context & further reading

Background on planning technical assessments, understanding technique limitations, analyzing findings, and mitigation. The worksheet here is an original planning aid, not a NIST checklist.

NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment