Penetration test scope: the one page that decides whether the test was worth it
Elementrica
Black box or grey box, the Rules of Engagement, the methodology, and what you deliberately leave out of scope. We break down the document most people sign without a second look, the one that decides everything else.
“And did you test the partner portal too?”
That question usually lands about three weeks after the test, in the wrap-up meeting, once the report has gone out and everyone has relaxed a little. And the answer is usually no, because the partner portal was never in scope. Nobody wrote it down. Not because anyone dropped the ball, but because when the scope was set, everyone was thinking about the main application, while the partner portal sat quietly on its own subdomain that nobody happened to mention.
Here is the part service pages rarely say out loud: the result of a penetration test is not mostly about how good the tester is. It is about what you put in scope before the tester ever sits down at the keyboard.
Scope sounds like a formality. It is a contract about what actually gets tested
Scope is the least exciting word in this business. It sounds like an attachment you sign on your way to the fun part, the part where someone “hacks” something. In practice it draws the line: what is in play and what is not. What actually gets tested and what we deliberately leave alone.
The problem is that the attacker never got a copy of your scope. The asset list you agreed on in meetings does not bind them. They go in where you are weakest, not where the test happened to fit the budget. So a scope that does not reflect how an attacker thinks can hand you a report with a green summary and yet zero real coverage where it actually hurts.
Too narrow or too broad? Both extremes cost you
A narrow scope has an upside: the tester goes deep, takes one application apart piece by piece, and finds things no scanner will ever touch. It also has a downside. If the line was drawn in the wrong place, all that depth sits next door to the real door.
A broad scope has the opposite balance. “Test everything” sounds safe until you set that “everything” against the number of days on the schedule. Five days for the whole infrastructure is not a penetration test, it is a quick walk with a flashlight. You touch a lot of things, none of them hard enough to mean anything.
The line does not run where the budget runs out. It runs where someone who means you harm could actually get in.
What we found out of scope (and why it hurts twice)
A real example. A client ordered a test of a production application. Deliberately, sensibly, with a clear list. Out of scope was a subdomain with a reporting panel, treated as an “internal tool that hardly anyone knows about.”
Along the way, entirely legally, during reconnaissance, we ran into that tool from the public internet. One of its endpoints returned data by ID number without checking whose data it was. Change the number in the request and out came another tenant’s reports.
On the technical side, that is textbook broken access control. On the business side, it is a data leak between customers, a breach of the confidentiality agreement, and grounds for a report to the data protection authority. Formally it was out of scope, so in the report it went into a separate “out of scope, but you need to see this” section. Had the line been drawn a few feet further out, it would have been finding number one, not a footnote.
The lesson is not “test everything at any cost.” It is this: when you draw the line, ask first where your data actually lives, not where the convenient line falls in the contract.
What belongs in a good scope
If you have a test proposal in hand, this part is for the people who will read it most closely. A good scope answers seven questions:
- What exactly gets tested. Specific domains, IP addresses, web apps, APIs, mobile apps. Named one by one. “The whole company” is not a scope, it is an intention.
- From what perspective. Black box (the tester starts like someone off the street, with no knowledge), grey box (they get an account and some context), white box (they get documentation and code). This decides how much they can actually check in the same amount of time. With no starting knowledge, half the engagement goes to reconnaissance that grey box cuts down to minutes.
- Where we attack from. From the internet or from inside the network. With a user account or without. A different scenario means a different result, and “external and internal” is two separate tests, not one longer one.
- The Rules of Engagement. When we test, whether social engineering is allowed, whether we touch production at all or a copy, how far the effects can reach, and who picks up the phone if something starts happening. This point saves everyone’s nerves more often than any other.
- The methodology. PTES, OWASP (WSTG for web, MASTG for mobile), NIST. The point is a result that is repeatable and verifiable, not one that depends on what a given tester felt like doing that day.
- Time, meaning how many person-days. This is not an administrative detail, it is the real ceiling on how deep anyone can go. An honest vendor tells you straight when the budget does not close the scope, instead of watering the test down to a scan with a nicer cover.
- What you get at the end. A report with proof, risk priorities, and a concrete fix path, plus a retest after the fixes go in. Without a retest you do not know whether the hole is really gone or just no longer visible from that one angle.
The “what is out” list matters just as much as the “what is in” list. Deliberately cutting something from scope is a business decision. Leaving it out by accident is a gap you will hear about from someone else.
Scope, DORA, and NIS2: the auditor cares about more than the fact that a test happened
If you are running the test for regulatory reasons, there is one more reason not to treat the scope as an afterthought. DORA and NIS2 require regular testing, but the auditor also looks at what was actually tested. A scope trimmed down to a single application does not close the obligation for the whole critical infrastructure. A report that looks great but covers a fraction of what the regulator considers relevant holds up poorly in a conversation with an auditor. Scope is where compliance either starts or falls apart, long before the first line of a finding.
One last thing
Scope sounds like homework. A document about boundaries that is easy to sign unread so you can finally get the test going. And that one page is exactly what decides whether you get a map of real holes or a polite PDF with a green summary, with the real door standing untouched right next to it.
If you read a paragraph about paperwork all the way to here, you are probably one of the people who read the contract attachments too. A rare and useful trait in this line of work. So, one question: when did someone last open the scope of your most recent test and calmly count what actually stayed outside it?
Want to see what this looks like in practice? See a sample test scope - a real, anonymized document that shows how we draw the line and what we put in the “out of scope” section.
Would you rather talk through your own case right away? Book a free consultation. 30 minutes, no obligation, a call with a consultant. You will walk away with a first draft of a sensible scope, whether or not you decide to run the test with us.
Book a free consultation. A call with a consultant - you will leave with a scope proposal matched to your case.