Key takeaways
- A scope is a list of identifiers a tester can act on: hostnames, CIDR ranges, base URLs, bundle identifiers. A department's name for a system is not one of those.
- Two accounts in every role, working before day one. One account per role can only show that the application let that account do what it was meant to do.
- Exclusions are part of the scope. Denial of service, physical intrusion and anything running on a supplier's infrastructure need a written decision, and the supplier's permission takes longer to get than the test takes to run.
- Effort is the second half of the scope. Ask a vendor what they would cut if you halved the days, and book the retest at the same time as the test.
Scope is a list of things, not a budget line
Scope is the set of systems, accounts and behaviours a tester is allowed to attack, written down before the work starts. Everything the report can tell you comes out of that list. A weakness sitting one hop outside it does not appear, and not because anyone missed it: the tester was not permitted to look.
Most disappointing reports are scoping failures rather than testing failures. The scope named one application and the real path ran through an identity provider nobody listed. Or it named forty hosts against five days, so each host got an hour and the result reads like a scan with commentary. Deciding what goes on the list is the part of the purchase you control most and think about least.
This assumes the engagement type is already settled, and that a scoped test against systems you name is what you want rather than an objective-based Red Team. If that is still open, the case for starting lower on the ladder is at /blog/why-your-first-engagement-should-not-be-a-red-team.
Name assets, not departments
Write the scope as identifiers a tester can act on. Fully qualified domain names. IP ranges in CIDR. Base URLs and a specification file for an API. Bundle identifiers and a distributable build for a mobile client. "The customer portal" is a department's name for a thing, and a department's name resolves to different systems depending on which person you ask.
Then count honestly. One web application with three tenant subdomains, an admin panel on its own host, and a mobile client talking to the same backend is at least four assets, and the mobile client opens a fifth conversation about the API behind it. Whether those belong in one engagement or three is a pricing question. Calling them one asset does not make them one.
Boundaries matter as much as contents. If the application authenticates through a third-party identity provider, say whether that provider is in or out. If it calls a payment gateway, say what the tester may do with it. An unstated boundary turns into a question at the worst possible moment, which is the afternoon somebody finds a path across it.
Accounts decide how deep the test goes
An unauthenticated test of an authenticated application is mostly a test of the login page. Nearly everything worth finding in a business application sits behind a session: whether a user of one tenant can read another tenant's records, whether a read-only role reaches a write endpoint, whether an object identifier in a URL is checked against the session that asked for it.
Provide two accounts in every role that exists, not one. Two accounts in the same role are how horizontal access control gets proved, by having user A reach for user B's data. Include the administrator role even though it feels uncomfortable, because privilege escalation is measured against what the top of the tree can actually do, and a tester guessing at that is a tester writing softer findings than the truth.
Have the accounts working before the first day rather than on it. Credentials that arrive on day three of a five-day test cost two days of the depth you paid for, and the usual causes are dull and predictable: MFA enrolment, an IP allowlist, an invitation that expired over the weekend.
Production, staging, and the copy that is neither
Testing against production finds the configuration you actually run. It also carries the risk you actually run: a locked account, a queue filled with test records, an alert at two in the morning. Staging removes that risk and adds a different one, which is that staging is rarely the same system.
The question worth asking is what differs. Different data volumes are fine. A different authentication provider, a debug flag left on, no WAF, no rate limiting, a stubbed payment path: those change the findings, and a report from an environment that differs in those ways describes a system you do not operate. Where the differences are known, list them in the scope, so the report can mark which findings still need confirming in production.
Where production is the only faithful target, buy the controls instead of the argument. A testing window, a named contact reachable while the work runs, an agreed signal to stop, and a written undertaking that no denial of service or destructive payloads will be used. That is ordinary practice, and a vendor who treats it as a concession is telling you something.
What you exclude, and who has to agree to it
A scope needs its exclusions written as clearly as its contents. Denial of service, physical intrusion, social engineering against staff, and automated exploitation of anything shared with other tenants are the four that come up every time. Excluding them is not timidity. A test that takes the site down proves something everybody already knew and burns the day it proved it on.
Anything you do not own needs somebody else's permission. Cloud providers publish what they allow against tenant resources, most SaaS vendors do not permit testing of their platform at all, and managed hosting sits between the two. If your application runs on infrastructure a supplier operates, that supplier is a party to the scope. The paperwork takes longer to arrange than the test takes to run, so start it when you start collecting quotes.
Write the rules of engagement down alongside it: testing hours, the source addresses the tester will work from, whether the security team is told in advance, and who gets called if something breaks. If you decide not to tell the security team, decide it deliberately, because a test cannot casually be both an assessment of the application and an assessment of your detection. That second thing is purple teaming and it is scoped and bought differently.
How many days, and what the days buy
Effort is the second half of the scope and the half where the honest conversations happen. A manual test of a mid-sized authenticated web application usually runs five to ten days for one tester, and where it lands inside that range depends on the number of roles, the number of distinct workflows and how much of the functionality is hand-written rather than generated. A quote far under the range is not a discount on the same work. It is a scan with a cover page.
Ask a vendor what they would cut if you halved the days. A good answer names what disappears: business logic tested across roles, the second pass over an area the first pass opened up, the manual review of a workflow no scanner can reason about. A vague answer means nobody mapped the effort to the assets, which means the number was a guess and the coverage will be one too.
Book the retest when you book the test. Findings get fixed, fixes get made wrong, and a fix nobody verified is an assumption recorded in a spreadsheet. A retest costs a fraction of the original engagement and it is the only part of the exercise that proves the money changed anything.
What a scope has to survive in Dubai and Abu Dhabi
In the UAE the scope is often the document a regulator reads, not the finding. A bank under the Central Bank of the UAE, a Dubai government entity or one of its suppliers under DESC, an Abu Dhabi healthcare provider under ADHICS, and any federal entity under the Information Assurance Standards published by NESA: four regimes that name security testing, and each of them is satisfied by evidence that the testing covered the systems that matter rather than by a report existing at all. A scope that quietly left out the payment path is a gap an auditor can see on one page.
The practical difference between the two emirates is procurement rather than technique. Dubai entities and the suppliers who serve them are generally asked to tie testing to the DESC control set and to name the assets covered; Abu Dhabi health sector buyers work to ADHICS control families and often want the scope mapped against them before a purchase order is raised. Free zone companies, including those in Dubai Silicon Oasis, sit outside a sector regulator until a customer contract pulls them in, and at that point the customer's regime becomes theirs. Write the scope so it can be handed to whichever of those readers asks for it, with the asset list, the exclusions and the reason for each.
Frequently asked questions
What should be included in a penetration test scope?
A list of assets written as identifiers a tester can act on: hostnames, IP ranges in CIDR notation, API base URLs and specification files, mobile bundle identifiers. Alongside it, the accounts and roles that will be provided, the environment to be tested, the exclusions, the testing window and a named contact. Anything not on the list will not be tested, so the list is the engagement.
Should a penetration test run against production or staging?
Production gives findings about the system you actually operate, which is what a report is for. Staging is a reasonable substitute only where it matches production on the things that change findings: authentication, WAF and rate limiting, debug settings, and payment or integration paths. If those differ, record the differences in the scope so the report can flag which findings need confirming in production.
How many days does a penetration test take?
A mid-sized authenticated web application is commonly five to ten days of testing for one tester, moving with the number of roles and distinct workflows. Networks are priced by host and range count rather than by application. The useful question to put to a vendor is what coverage disappears if the days are reduced, because that answer shows whether the effort was mapped to the assets or estimated.
Do I need permission from my cloud or SaaS provider before testing?
For infrastructure you operate on a cloud provider, testing is usually allowed within published rules that prohibit denial of service and testing of the provider's own services. For SaaS applications you subscribe to, testing generally requires the vendor's written permission and is often refused outright. Start those requests when you start collecting quotes, because approval takes longer than the engagement.
