Penetration test scope

ElementricaJun 23, 20266 min

A sample, anonymized document. An excerpt from a Statement of Work and Rules of Engagement.

About this document. It is an excerpt from a real one, stripped of client data and anything sensitive. Every name, domain, and IP address here is fictional (domains sit in the .example zone, the addressing is anonymized). We are showing it so you can see how we draw the line for a test and what we deliberately put in the “out of scope” section. The commercial layer (exact effort, pricing, day-by-day schedule) is set per engagement.

Version	Document type	Confidentiality	Author
1.0	Scope and rules of engagement	Demonstration material	Elementrica

1. Engagement context

The client profile and the goal of the test shape where we draw the line. So we start with context, not with a tool list.

Field	Value
Client (profile)	A mid-sized SaaS provider in fintech, around 130 employees, multi-tenant model.
Reason for the test	Preparation for a DORA audit, plus a security requirement from an enterprise customer.
Type of data	Personal and financial data of platform users. The key question: is one tenant's data separated from another's.

2. Test goals

We write the goals in the language of the client's risk, not in technical terms. They decide what matters and what is secondary.

Determine whether someone on the internet can gain unauthorized access to platform users' data.
Verify data isolation between tenants (broken access control, IDOR, horizontal and vertical authorization flaws).
Test how well login, password reset, and session management hold up.
Deliver proof and risk priorities for a remediation plan, plus material for the conversation with a DORA auditor.

3. Test scope (in scope)

Every asset is named. There is no line item like “everything else” or “the rest of the infrastructure.” If it is not on this list, it does not get tested.

Asset	Type	Perspective and notes
app.klient.example	Web application (production)	Grey box. Two test accounts: a standard role and a role with elevated privileges.
api.klient.example	REST API	Grey box, authenticated. Authorization testing at the object and function level.
iOS + Android (test builds)	Mobile app	Analysis per OWASP MASTG. Local storage, API communication, secret protection.
partners.klient.example	Partner portal	Grey box. A separate subdomain, deliberately included at the security team's request.
xxx.xxx.xxx.0/28	External infrastructure	16 addresses. External network test: exposed services, configuration, known vulnerabilities.

4. Test type and perspective

Field	Value
Knowledge model	Grey box. A test account shortens reconnaissance and lets us go deeper into the application's business logic in the same amount of time.
Starting points	From the internet without an account (an anonymous perspective) and with a user account in two roles.
Environment	Production for web, API, and infrastructure (with written consent and the limits from section 6). Test builds for the mobile app.

5. Methodology and standards

The methodology exists so the result is repeatable and verifiable, not dependent on what a given tester felt like doing that day.

PTES as the process for running the test.
OWASP WSTG 4.x for the web application and the partner portal.
OWASP API Security Top 10 for the API.
OWASP MASTG for the mobile app.
NIST SP 800-115 for the external infrastructure.
Risk classification and priorities per CVSS 4.0.

6. Rules of Engagement

Area	Agreement
Time windows	Business days, 08:00 to 18:00 CET. Anything with a higher risk to stability only after prior agreement and outside peak traffic hours.
Production	Allowed, with nothing that risks service downtime. No DoS or DDoS testing.
Social engineering	Out of scope for this engagement. Available as a separate project if the client wants it.
Sensitive data	If a tester reaches real personal data, they stop exploring, document the minimum proof, and report it. No downloading or storing of client data.
Critical findings	Reported immediately through the emergency channel, before the final report.
Emergency contact	A named person on the client side and an on-call contact at Elementrica. Two numbers, reachable during the test windows.
Whitelisting	The tester's source addresses are shared with the client's team so they can tell the test apart from a real attack and avoid an unnecessary SOC response.

7. Out of scope

This is the most important part of the document. It is not a list of things we cannot do. It is a list of deliberate decisions, each with a reason.

Item	Reason for exclusion
DoS and DDoS attacks, load testing	Risk of production downtime. The goal here is unauthorized access, not load.
Social engineering and phishing against employees	Deliberately excluded from this engagement. Available as a separate project.
Physical access to offices and hardware	Outside the threat model agreed with the client for this engagement.
Third-party provider services (payments, email, hosting)	No consent from the infrastructure owner. Testing someone else's systems without authorization is not allowed.
Source code review (white box, SAST)	A different type of service. This engagement runs as grey box.
Domains and subdomains not on the list in section 3	Outside the agreed asset list. See the note below.

What we do when we find something past the line. If reconnaissance turns up a meaningful asset outside the scope (say, a forgotten subdomain with an admin panel), we do not test it without extending the engagement. We report it separately as an observation, with a description of the risk. The line protects both sides, but we will not pretend a problem does not exist just because it sits a few feet past the boundary.

8. Effort and deliverables

The number of person-days is the real ceiling on how deep a test can go. We state it plainly, because a scope with no time attached is an intention, not a plan. The figures below are examples.

Area	Person-days
Web application	6
REST API	3
Mobile app (iOS + Android)	4
Partner portal	2
External infrastructure	2
Reporting and results debrief	2
Retest after fixes are deployed	1
Total (example)	20

What the client gets at the end:

A technical report with proof: reproduction steps, a working proof of concept, priorities per CVSS 4.0, and a concrete fix path for each vulnerability.
An executive summary in the language of business risk, ready for a conversation with the board and the auditor.
A session to walk through the results with the client's team.
A retest of the fixes and written confirmation that the vulnerabilities are gone.

9. Assumptions and conditions

The client provides test accounts, access to environments, and mobile builds before work starts.
The client confirms it has the right to commission a test of the listed assets.
Any change to the scope during the work needs written agreement (a change request).
Everything is covered by an NDA. When the work is done, test data is deleted per the agreed retention policy.

Want a scope like this for your own infrastructure?

Book a free 30-minute consultation, no obligation. After the call with a consultant you will have a first draft of a scope that makes sense.

Penetration test scope: the one page that decides whether the test was worth it