Recommended resources
The freely available resources this lesson will direct you to.
Hello. Last lesson turned a business concern into testable criteria: for example, whether an ordinary test account can reach a seeded marker in a restricted finance workflow, and whether defenders detect and contain the attempt. Those criteria describe what the organization wants to learn. They do not, by themselves, authorize every action that might reach the marker.
This lesson defines the operating boundaries around that test. You will learn how to specify where and when operators may act, which actions are forbidden, what events require a pause or an immediate stop, and who can resolve uncertainty. The result is a rules-of-engagement framework that protects both the validity of the exercise and the systems and people involved.
An objective is not an authorization
Suppose the objective is to determine whether a supplied test account can retrieve the finance marker. An operator discovers that the application links to another service. Following that link might help reach the objective—but is the other service authorized for testing? The objective cannot answer. The service might belong to a different owner, host real records, or be shared with a third party.
Rules of engagement (RoE) supply the missing constraint. They record the agreed permissions, exclusions, responsibilities, and incident procedures for the engagement. NIST’s Technical Guide to Information Security Testing and Assessment describes an assessment plan as a way to establish rules and boundaries before testing, including the systems authorized for examination and activities expressly prohibited.
Technical guide to information security testing and assessment
Read NIST's guidance to see how an assessment plan makes permission and incident handling explicit. The red-team examples below adapt that planning approach; they are not a substitute for approval by the relevant owners.
In Section 6.5, “Assessment Plan Development” (pp. 6-9–6-10), begin where the guide says every assessment needs a plan. Read scope and permissions, ending after its instruction to state prohibited activities explicitly. Focus on the treatment of excluded systems and third-party ownership. Continue in the incident-handling discussion on p. 6-11. Read incident guidance, from the instruction to define an incident through the questions about stopping and resuming testing. Finally, in Appendix B, “Rules of Engagement Template,” read Section 3.2, “Incident Handling and Response” (p. B-2): halt and restart. In Sections 5, “Testing Execution,” 5.2, “Technical Test Components,” and 5.3, “Data Handling” (pp. B-2–B-3), read allowable activities and technical and data rules. Notice that permission to test a system and permission to create files or retain data on it are separate decisions.
The practical test of an RoE is whether an operator can decide before acting whether a proposed action is permitted. “Test the finance environment” is too vague. A useful boundary identifies the authorized assets and accounts, the permitted activity, the test window, and the data that may be observed or retained. It also identifies exclusions. Ownership matters: access to one organization’s application does not automatically authorize testing its hosting provider, connected services, employees, or other tenants on shared infrastructure.
Define the authorized space—and the space between
For the hypothetical marker exercise, the parties might agree to a two-hour window in a designated test environment. Operators receive one ordinary test account and may make controlled access attempts through a named finance workflow. They may record the seeded marker if reached, but may not collect real finance records. These are example permissions that would require approval, not permissions implied by the objective.
An operator-facing boundary could look like this:
| Boundary | Agreed rule in the example |
|---|---|
| Targets and identity | Only the named test application and the supplied test account are authorized. The approved inventory maps the application’s identifier to its actual endpoints. |
| Time and starting point | Active testing occurs only during the agreed two-hour window, from the approved starting account and access path. A separately agreed observation period allows defenders’ response to be measured afterward. |
| Permitted action and data | Controlled access attempts within the named workflow are permitted. Operators may record the seeded marker and the minimum evidence needed to verify the attempt. |
| Excluded assets and people | Production datasets, other applications or accounts, employees, and third-party services are not targets. A link or shared network address does not remove an exclusion. |
| Unlisted assets | An asset not expressly authorized is not a target. Operators do not probe it to find out whether it is safe; they request a scope decision first. |
The final row is important. Real environments rarely match an inventory perfectly. An unlisted system is not automatically “out of scope forever,” but neither is it temporarily in scope because it appears relevant. Record its identifier without further targeted interaction, then ask the designated contact to resolve ownership and authorization. If the boundary cannot be resolved in time, leave that path untested and report the limitation.
Scope also applies to methods, not just targets. A permitted account and application do not imply permission to send disruptive traffic, modify files, install software, contact staff, or copy sensitive data. Conversely, a prohibited method remains prohibited even if it appears to be the fastest way to meet a success criterion.
Write prohibitions as decisions an operator can apply
“Use caution” asks operators to make different judgments under pressure. A useful prohibition names the action and its boundary. For this example, the RoE might forbid password spraying; phishing or other contact with personnel; denial-of-service testing; persistence or software installation; changes to accounts, records, or security controls; access attempts against any service outside the named workflow; and collection of real finance data. These are engagement-specific choices, not a universal list of methods forbidden in every red-team exercise.
Some rules also need a narrow permitted counterpart. “Do not exfiltrate sensitive information” leaves open whether the marker can be recorded. “Operators may record the seeded marker value but must not open, copy, or retain real finance records” makes the distinction usable. If real data appears unexpectedly, the plan should specify how to stop interacting with it and report the exposure without collecting more to strengthen the finding.
HackerSploit’s Planning Red Team Operations | Scope, ROE & Reporting walks through the role of an RoE and a sample document. Watch the indicated portions for how objectives, authorized target space, responsibilities, and cease-operation provisions fit together.
Planning Red Team Operations | Scope, ROE & Reporting
Watch HackerSploit's “Planning Red Team Operations | Scope, ROE & Reporting” for a practitioner-oriented account of what belongs in an RoE. Compare its sample provisions with the finance-workflow boundaries above.
Watch ROE fundamentals for the document’s purpose and the kinds of activities and responsibilities it should address. Then watch the template walkthrough, focusing on authorized target space, sensitive-information reporting, cease-operation procedures, and who is responsible for each decision. Treat a template as a prompt for agreement, not as authorization on its own.
An RoE should be reviewed and approved by people with authority over the relevant assets and risks, with legal review where required. Even a signed document is useful only if its restrictions are specific enough to follow and its approvers actually have authority over what it covers.
Distinguish a local pause from an emergency stop
Not every unexpected event calls for the same response. If an operator encounters an unlisted service, the safe response is normally to pause that path while other clearly authorized work may continue. If a test appears to disrupt a service or encounters signs of a genuine intrusion, continuing the campaign could worsen an incident or confuse responders. The RoE should define when to stop all active testing.
The following are illustrative triggers for the finance exercise; the engagement owners would agree on the final wording and response:
| Trigger | Immediate operator action |
|---|---|
| An intended next step would touch an unlisted application or account | Do not take that step. Record the ambiguity and request a scope ruling. |
| Real finance records become accessible or appear in evidence | Stop interacting with that data. Preserve only what the agreed reporting procedure permits and notify the designated contact promptly. |
| Unexpected service degradation, loss of availability, or other potentially harmful effect occurs during testing | Stop the affected activity—and, if the cause or impact is unclear, stop all active testing. Notify the emergency contacts. |
| Signs of a genuine, unrelated compromise appear | Stop activity that could interfere with investigation, promptly notify the designated security contact, and follow the organization’s incident process. |
| The test window expires or authorization is withdrawn | Stop active testing, even if the marker has not been reached. |
“Stop” needs an operational meaning. It should say whether operators must cease all new actions, who communicates the instruction to the team, and what limited steps—if any—are authorized to leave the test environment safe. Do not assume that cleanup is always the first action. Removing an artifact during a genuine incident could interfere with an investigation; the agreed incident lead should direct the next steps.
Stop conditions are not failure criteria. A halted test may leave the marker outcome not established, while still producing an important safety or detection observation. No operator should continue solely to obtain a cleaner success score.
Give every uncertainty an escalation path
A stop rule is incomplete without a way to reach someone who can act on it. An RoE should identify a primary and alternate contact on both the operator and organization sides, approved communication methods, and a fallback if the primary channel fails. The contact details themselves belong in the controlled engagement document, not in a general-purpose lesson or widely shared runbook.
It helps to assign decision authority by question:
- The operator lead directs the team to pause or stop and confirms that every operator received the instruction.
- A designated organization contact or trusted agent helps deconflict authorized activity with defender observations and brings in the appropriate asset owner or incident lead.
- The asset owner and other authorized approvers decide whether a proposed target or method can be added to scope. The trusted agent cannot grant permissions they do not hold.
- The incident lead directs the response to suspected harm or a genuine compromise, including whether and when testing may resume.
For a time-sensitive event, the plan should state which channel to try first, which alternate to use if it fails, and what happens while no one responds. No answer is not permission to proceed. Operators remain paused or stopped as the trigger requires. The plan should also distinguish routine status reporting from urgent notification; an unexpected exposure should not wait for the next scheduled update.
Deconfliction should prevent mistaken attribution without suppressing a real security response. A trusted agent may verify whether an observed action matches the approved test, but that role is not a blanket instruction for defenders to disregard alerts. If an observation does not match the engagement—or remains uncertain—the organization’s incident process still applies.
Finally, resumption needs an explicit decision. Record what happened, which activity is proposed next, who authorized the restart, and any revised conditions. If the change would add a target, method, person, or time window, update and approve the RoE before testing it. An informal “that should be fine” cannot silently expand written authorization.
Conclusion
A defensible red-team boundary states what may be tested, by whom, when, how, and with what data. It treats exclusions and unlisted assets deliberately, turns prohibited actions into usable operator rules, and pairs each pause or stop condition with notification and restart authority. The business objective tells the team what question to answer; the RoE determines which ways of answering it are authorized.
Next, you will build a threat profile by mapping selected adversary behaviors to MITRE ATT&CK techniques. That profile can guide realistic scenario choices, but it will not override the boundaries established here.