What the conversation should produce.
- A signed scope register listing every in-scope and excluded environment with the reason for each exclusion
- An escalation matrix naming contacts, availability windows, and response time expectations for each communication channel
- A change log recording scope modifications, their impact, and the updated authorisations distributed to all contacts
State objectives and exactly which environments are included
Begin by recording the purpose of the assessment in plain terms, then list every environment that falls within scope. Include production, staging, development, third-party integrations, and any cloud or on-premises systems that the team may touch. Vague references such as core services or relevant infrastructure create ambiguity and risk testing the wrong systems. Define what is excluded, including legacy systems, partner networks, and customer data stores, and state the reason for each exclusion so that reviewers can verify the boundaries later.
Objectives should describe the decisions the assessment will inform, not the desired outcome. A statement such as validating whether a new deployment introduces unauthorised access paths differs from claiming to confirm the system is secure. Record the assumptions that underpin the scope, such as which networks are reachable and which identities are tested. If an environment is partially understood, mark it as untested rather than assumed safe, and note what additional information would be required before it can be included in future work.
Record the people who can authorise, pause and resume work
Identify the individuals or roles with authority to approve the engagement, suspend it, and confirm completion. Distinguish between the sponsor who funds the work, the technical owner who controls the environment, and the escalation contact who can be reached during incidents. Record their contact details, availability windows, and any delegation rules that apply when they are unavailable. Ambiguity about who holds authority leads to delays and conflicting instructions when decisions are needed under pressure.
Document how instructions flow between the assessment team and the authorised contacts. Specify whether changes require written confirmation, whether verbal approvals are acceptable during emergencies, and how disputes are resolved. State the consequence of contacting an unauthorised person, such as pausing work until the correct authority is confirmed. This prevents accidental exposure of findings to individuals who lack the mandate to act on them and ensures that every instruction can be traced to a responsible decision-maker.
Specify permitted activities and exclusions in understandable language
List each activity the team may perform, using language that a non-specialist can verify against the environment. Examples include authenticated configuration review, network connectivity testing between defined segments, and application behaviour observation under controlled conditions. For each activity, state the method and the limit, such as testing only endpoints that have been explicitly whitelisted. Avoid technical jargon that obscures what is actually allowed, and define any terms that could be interpreted in multiple ways before the work begins.
Exclusions deserve the same precision as permissions. State which techniques are not permitted, such as denial-of-service testing or social engineering, and explain the operational reason. If a technique is conditionally allowed, record the conditions, the additional authorisation required, and the evidence that must be collected before proceeding. When an activity is excluded because it could affect availability or data integrity, consider whether a lower-impact alternative can answer part of the question, and state any resulting limit, so that the assessment remains useful rather than simply restricted.
Agree operating windows, communications and incident deconfliction
Define the times during which work may occur, the duration of each session, and the buffer periods for recovery between activities. Record the communication channels that will be used for routine updates and for urgent notifications, and specify the expected response times for each. Distinguish between scheduled check-ins and ad hoc alerts, and state how findings that suggest immediate risk are communicated outside the normal window. Clear timing reduces the chance that testing coincides with maintenance or peak usage, which could cause confusion or unintended disruption.
Incident deconfliction requires a separate procedure from routine communication. State how the team will verify whether an alert originates from the assessment or from normal operations, and what steps are taken if the two cannot be distinguished immediately. Record the escalation path, the information that must be shared to confirm the source, and the point at which work pauses until the situation is resolved. This prevents defensive teams from wasting resources investigating their own activity and ensures that genuine incidents receive attention without delay.
Set evidence minimisation, access and retention expectations
State what evidence will be collected, why each item is needed, and how it will be stored. Collect only what is necessary to support the findings, and avoid capturing data that does not contribute to the assessment conclusions. Record the access controls applied to the evidence, the individuals permitted to view it, and the process for requesting access. Define the retention period for each category of evidence and the method of secure destruction once the period expires, so that unnecessary data does not accumulate beyond the engagement.
Distinguish between raw observations and interpreted findings in the retention policy. Raw logs and screenshots may be retained for verification, while personal or sensitive information that appears incidentally should be excluded or redacted before storage. State how the team handles evidence that contains data belonging to third parties or customers, and whether additional authorisation is required before it is retained. Clear expectations support careful handling and help ensure that evidence remains available for review without compromising unrelated information.
Control scope changes and record how the engagement is closed
Scope changes should follow a documented process that records the reason, the impact, and the authorisation required. Any addition or removal of environments, activities, or timelines must be confirmed in writing before the change takes effect, and the updated rules of engagement must be distributed to all contacts. State how changes that affect risk or availability are evaluated, and whether a pause is required while the impact is assessed. Uncontrolled scope creep introduces untested assumptions and can invalidate the conclusions of the work that was already completed.
Closure requires a record of what was tested, what was not, and why the engagement ended. Document any activities that were interrupted, the status of pending observations, and the decisions that remain open. Confirm that all evidence has been accounted for, that temporary access has been revoked, and that the final report has been delivered to the authorised recipients. A structured close prevents loose ends from becoming unresolved findings and ensures that the engagement can be reviewed or repeated with full knowledge of its boundaries.
Illustrative scenario: Adding a staging environment mid-engagement
An assessment of a production application is underway when the sponsor requests that a staging environment be included because recent changes were deployed there first. The staging system shares components with production but uses different credentials and a separate database. The request arrives during an active testing window, and the team must decide whether to proceed, pause, or decline, while ensuring that the original objectives remain intact and that no unauthorised systems are touched.
- Confirm whether the staging environment falls within the originally defined scope, and if not, record the additional authorisation required before any testing begins and the impact on the current timeline.
- Evaluate whether testing staging could reveal findings that apply to production, and decide whether to treat the results as provisional until the production environment is examined under the same conditions.
- Determine whether the staging credentials and access methods differ from those approved, and pause work until the new access is verified against the rules of engagement.
This scenario establishes that scope changes require explicit authorisation and documented impact assessment, not ad hoc decisions. It does not prove that staging findings apply to production, nor does it excuse testing environments that were never approved. The process protects both the integrity of the assessment and the operational stability of the systems involved.
Useful decision table for rules of engagement
| Question | What to establish | Useful output |
|---|---|---|
| Which systems may be tested | A complete list of in-scope and excluded environments with the reason for each exclusion | A signed scope register that can be verified against network diagrams |
| Who can pause work | The named contacts, their availability, and the delegation rules when they are absent | An escalation matrix with response time expectations for each channel |
| What happens when scope changes | The written process for requesting, approving, and recording changes before they take effect | A change log with impact notes and updated authorisations distributed to all contacts |
Scroll the table horizontally on smaller screens.
Useful questions.
Can we test systems that were not listed in the original scope?
An additional environment needs the relevant authority and an agreed scope change before activity begins against it. Record its ownership, operating conditions, evidence arrangements and effect on the original plan. Discovering an asset or receiving a request from one participant does not automatically resolve those questions. Keep the updated boundary available to the people who need to act on it.
What should we do if an alert appears during testing?
Follow the agreed deconfliction and pause criteria. Share enough context with the designated contact to determine whether the alert corresponds to exercise activity or needs a separate response. A scenario may intentionally generate alerts, so not every alert requires ending the exercise. Uncertain attribution or unexpected operational impact should trigger the controls established during planning.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.