---
{
  "title": "Rules of engagement",
  "summary": "Define exactly what testing is authorized and how to handle unexpected events.",
  "topic": "offensive",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Rules of engagement specify boundaries for a security assessment. They include authorized targets, permitted techniques, exclusions, dates, operational limits, communication, stop conditions, and evidence handling. The owner’s authority over each target must be clear. Written agreements reduce ambiguity, but testers still need to recognize when a discovered dependency or third-party service falls outside scope. Pause and coordinate when boundaries are uncertain.

## In practice

An assessment permits a lab subnet during a defined window but excludes production payment services and denial-of-service activity.

## A common misunderstanding

Permission for one application does not automatically include its provider, customers, or connected third-party systems.

## Check your understanding

What should happen when a test reveals an out-of-scope service?

**Think it through:** Document the observation without extending active testing and ask the authorized engagement contact to resolve scope.

## Translate permission into operational decisions

An engagement agreement should let a tester answer concrete questions while working. Is this hostname included? May the test use an employee account? What request volume is acceptable? Who can approve a changed scope? A vague statement such as 'test our network' leaves these decisions unresolved, especially when cloud providers, managed services, and shared infrastructure are involved.

Define targets with identifiers appropriate to the environment: applications, domains, account identifiers, address ranges, or specific tenant resources. Include exclusions explicitly. An internet address may host several organizations, and a domain may redirect to a third-party identity service. Technical connectivity does not extend the owner's authority over every connected component.

## Plan for unexpected conditions

A fictional hospital assessment might allow testing against a training portal while excluding clinical devices and production patient records. The agreement could require the tester to stop when unexpected patient information appears, when error rates cross an agreed threshold, or when the designated incident contact declares a pause. These conditions should be observable enough to apply under pressure.

Communication arrangements need more than an email address. Identify primary and backup contacts, how urgent notifications are delivered, and who can restart paused work. Define whether defenders know about the exercise, who maintains deconfliction information, and how genuine suspicious activity is distinguished from testing. The details should match the exercise rather than follow a generic template unquestioningly.

## Evidence and cleanup are part of scope

Agree where evidence will be stored, who can access it, what must be redacted, and when it will be deleted. If temporary accounts, files, or configuration changes are permitted, identify their owner and cleanup verification. A forgotten test account can become a real exposure after the assessment ends.

Practice by reviewing a fictional scope containing one application, its hosted login provider, and a shared storage service. List the unresolved authority and data-handling questions before proposing any technical tests. Then write one permitted action, one excluded action, and one stop condition. Good rules make those distinctions understandable to testers and system owners alike.

## Keep exploring

- [[ethical-hacking]]
- [[virtual-labs]]
- [[penetration-test-reporting]]