Technical explainer
Penetration Test Scoping and Rules of Engagement: What a Good Test Plan Covers
Authorised penetration testing starts long before the first scan. What to agree on scope, authorisation, rules of engagement, reporting and retesting — and what frameworks like PCI DSS expect.
A penetration test is an authorised attempt to find and exploit weaknesses in systems, so that the organisation can fix them before someone else finds them. The word authorised carries most of the weight. Most problems in penetration testing, from outages and legal disputes to reports nobody can act on, trace back to a test plan agreed too quickly.
This guide covers what a good test plan covers. It is written for the people who commission tests (security, GRC and engineering leads) as well as for testers.
1. Objectives first
Agree why the test is happening before deciding what to test.
- Compliance-driven. For example, the PCI DSS requirement for regular internal and external penetration testing and segmentation testing.
- Risk-driven. A new product launch, a major architecture change, or a high-value application.
- Assurance for customers. Evidence for due-diligence questionnaires.
Objectives decide depth, timing and the shape of the report.
2. Scope
A precise scope lists:
- In-scope targets: IP ranges, hostnames, applications and environments (production or staging), cloud accounts, APIs, and mobile apps with versions;
- Out-of-scope targets, stated explicitly, including third-party systems you do not own or have no permission to test;
- Test types: external network, internal network, web application, API, cloud configuration, wireless, social engineering (only if specifically authorised);
- Perspective: unauthenticated or authenticated, and the user roles to be provided;
- Third-party permissions: many cloud and hosting providers publish testing policies. Confirm that testing their infrastructure is permitted and on what terms.
3. Written authorisation
Testing requires written authorisation from someone with authority over the systems. The authorisation should name the testers or firm, the scope, the time window and the permitted activities. Without it, testing may breach computer-misuse laws in many jurisdictions. Testers should carry a copy and stop if the scope appears wrong.
4. Rules of engagement
| Topic | What to agree |
|---|---|
| Timing | Testing windows, blackout periods (such as peak trading), time zones |
| Permitted techniques | Whether exploitation, privilege escalation, lateral movement, password attacks or denial-of-service checks are allowed |
| Data handling | How any sensitive data encountered is treated, stored, minimised and destroyed |
| Safety | Stop conditions, maximum request rates, avoiding destructive payloads |
| Communication | Named contacts on both sides, an out-of-hours escalation route, how to report a critical finding immediately |
| Detection | Whether the SOC is informed (a “white” test) or is being evaluated |
| Evidence | Screenshots, logs and proof-of-concept boundaries |
5. Methodology
Professional testers follow a documented methodology. Public references include NIST SP 800-115 for planning and conducting technical testing, and the OWASP Web Security Testing Guide for web applications. PCI DSS expects the entity to define a penetration testing methodology that covers the whole CDE perimeter and critical systems, from inside and outside the network, including segmentation controls.
6. Reporting that drives action
A useful report contains:
- an executive summary in business terms;
- each finding with affected assets, description, evidence, a reproducible path, a severity rating and the method used to rate it (for example CVSS with environmental context), plus remediation guidance;
- positive observations: controls that worked;
- limitations: what was not tested, and why.
7. Remediation and retesting
Agree retest arrangements up front. Many frameworks, including PCI DSS, expect exploitable vulnerabilities to be corrected and the corrections verified by repeat testing. Feed findings into the risk register and vulnerability management process, so they are tracked to closure rather than filed away.
Common pitfalls
- Testing third-party systems without their permission.
- Scope drawn around what is easy rather than what is valuable.
- Production outages caused by aggressive automated scanning.
- No retest, so findings are “closed” without verification.
- Treating an automated vulnerability scan as a penetration test.
Related Academy guides
Sources and official references
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment — NIST (official source)
- PCI SSC Document Library (PCI DSS v4.0.1 and penetration testing guidance) — PCI Security Standards Council (official source)
- OWASP Web Security Testing Guide — OWASP Foundation (official source)
Links go to the publisher's own site. Where a standard is sold or copyrighted, MajorCyber™ summarises it in original words and links to the official listing instead of reproducing its text.
Listen to this page
Read aloud in UK English by your own device. Nothing is sent anywhere, and the voice is whichever one your browser provides.
General educational information, not legal or professional advice. Check the official sources and take qualified advice before acting.
