How long should a penetration test take?

For a single application with a handful of roles, five to ten working days of testing is typical, plus reporting. Anything materially shorter than five days on a real application is either very narrowly scoped or is not manual testing. If a supplier quotes two days for a multi-tenant product with an admin interface, ask which parts they intend to leave out, because something is being left out.

Should we test production or staging?

Staging is the usual answer where it is a faithful copy: same code, same configuration, same authentication provider, representative data. Production gives a more accurate result and carries real risk, so it is normally reserved for non-destructive checks agreed in advance. What matters more than the choice is that the environment tested is close enough to production that the findings transfer, and that the report says which one was used.

Do we need to tell our security team the test is happening?

Somebody with authority must know, or an unannounced test becomes a real incident response with real cost. Whether the wider monitoring team is told depends on what you are testing. If you want to measure detection and response, keep the circle small and record who was informed. If you are testing the application itself, tell the team, because time spent investigating your own tester is wasted on both sides.

What happens if the tester finds something critical mid-test?

It should be escalated immediately under the rules of engagement rather than held for the report. Agree the escalation path and the criteria before the test starts, and give a phone number that works outside office hours. On our engagements findings publish to your workspace as they are confirmed, so a critical issue is in front of your team the hour it is written rather than at the end of the engagement.

Can we change the scope once testing has started?

Adding a target mid-engagement usually means either extending the window or taking time away from what was already agreed, and the second option quietly reduces coverage of the thing you originally cared about. If new attack surface is discovered during the test, the right response is to say so and decide together, rather than to absorb it silently. We tell you and agree the change rather than invoicing for it after the fact.

How often should we retest the same application?

Annually is the common baseline, and most standards that mention frequency say at least once every twelve months plus after significant change. The significant change clause is the one people forget: a new authorisation model, a new public API, a migration to a different identity provider or a substantial architectural change all reset the assumptions the previous test was based on.

Scoping

How to scope a penetration test

Scope decides what gets tested, what it costs and whether the report answers the question you bought it to answer. Here is the information a tester needs, the decisions only you can make, and the mistakes that quietly waste half an engagement.

Last updated 18 June 20269 min read

Key takeaways

Scope is a statement of coverage. It decides what the report can honestly say was examined, which is the part an auditor or a customer reads.
Price follows effort, and effort follows the number of distinct user roles, the number of separate applications and the amount of authenticated functionality, far more than it follows the number of pages.
Grey box is the default for a reason: it removes reconnaissance time that produces no findings and spends it on the authorisation model instead.
Test accounts are the single most common cause of lost days. Provide one working account per role, per tenant, before the start date.
Write down what is out of scope and why. An undocumented exclusion looks identical to a gap in coverage six months later.

What scoping actually decides

Most people think of scoping as a pricing exercise. It is, but that is the smaller half of it. Scope is the statement of what was examined, and it is the part of the report that outlives the findings. Findings get fixed. The sentence describing what was in scope is what a customer, an auditor or an insurer reads two years later when they want to know whether your payments service was ever tested, and if the answer is ambiguous then the test may as well not have happened for that purpose.

That has a practical consequence. A scope written to fit a budget, with the awkward parts quietly left out, produces a clean report and a false sense of assurance. A scope written to answer a question produces a report that says what was covered and, just as usefully, what was not. If you can only afford to test part of the estate this year, the right move is to test part of it and say so, not to spread the same number of days across all of it.

Before anything else, work out who is asking. A customer security review, a SOC 2 examination and a PCI DSS assessment each want different things from the same engagement, and the requirement wording usually settles arguments about scope faster than any internal discussion.

The information a tester needs before quoting

A supplier who quotes without asking most of the following is either guessing or intending to raise a change request later. Have these answers ready and you will get a firm number on the first call rather than after a week of email.

What the system is and what it is for, in two sentences. A tester needs to know what a bad outcome looks like before they can look for one.
The targets themselves: domains, hostnames, IP ranges, mobile bundle identifiers, API base URLs. Be exact. Two subdomains that resolve to the same application are one target; two that resolve to different codebases are two.
How many distinct applications are involved, and whether they share an authentication system, a database or nothing at all.
The list of user roles, and whether the product is multi-tenant. Roles and tenants are the two multipliers that matter most.
Rough size: number of API endpoints or routes, number of significant user journeys, whether there is an administrative back office and whether it is in scope.
The technology involved at a high level. A single-page application with a GraphQL backend is a different day of work from a server-rendered monolith.
Which environment will be tested, and how closely it matches production in data, configuration and integrations.
Whether there is a web application firewall, rate limiting or bot protection in front of the target, and whether it can be relaxed for the testing source addresses.
Any third-party components you do not own and therefore cannot authorise testing against.
The deadline behind the request, and what it is driven by. A board meeting and an audit fieldwork date have different amounts of give in them.

A test is not a discovery exercise

If nobody can produce an accurate list of what is exposed, that is worth knowing on its own, and it is cheaper to answer with an attack surface review or scanning than with manual testing days. Scoping a manual test around an inventory nobody trusts means paying senior rates for asset discovery.

How scope drives price

Effort is what is being priced, and effort concentrates in a small number of places. The table below is the honest version of what moves the number, in rough order of influence. Ours are fixed price, quoted on scope, agreed after a scoping call, and typically run five to ten working days.

What increases the effort in a penetration test, and why
Factor	Effect on effort	Why
Number of distinct user roles	Large	Authorisation is tested as a matrix. Each new role has to be tested against every resource the other roles can reach, so the work grows faster than the count of roles.
Multi-tenancy	Large	Tenant isolation requires at least two accounts in two tenants and a deliberate pass over every identifier that crosses a boundary. It is also where the worst findings live.
Separate applications or codebases	Large	Each one needs its own reconnaissance, its own mapping and its own coverage against the methodology. Two applications is close to twice the work, not slightly more.
Authenticated functionality	Large	The public surface of most products is small. Almost all interesting behaviour, and almost all of the risk, sits behind a login.
API endpoint count	Moderate	Endpoints are cheap individually and expensive in aggregate. A hundred routes with consistent authorisation is a smaller job than thirty written by four teams.
Business logic depth	Moderate	Payments, workflows with approval steps, quotas and anything with money or state transitions need a tester to understand the intended rules before they can break them.
Environment quality	Moderate	A staging environment with no representative data, missing integrations or an aggressive rate limiter costs days that produce nothing.
Page or screen count	Small	The factor buyers volunteer first and the one that matters least. Forty screens sharing one authorisation model is less work than eight that do not.

Black box, grey box and white box

These describe how much you tell the tester before they start. They are not grades of thoroughness, and the most expensive option is not the best one.

Information provided in each testing approach
Approach	What the tester is given	Best used when
Black box	A target name and nothing else. No accounts, no documentation, no architecture detail.	You want to measure what an outsider can reach with no help, or you are testing detection and response rather than the application itself.
Grey box	Accounts for each role, a description of the architecture, and access to any API documentation that exists.	Almost always. It is the default for application testing because it puts the days into the authorisation model rather than into reconnaissance.
White box	Everything grey box gives, plus source code, infrastructure configuration and design documents.	High-assurance work, bespoke cryptography, complex authorisation logic, or where you want the tester to reason about the code as well as the running system.

The argument for black box is that it is realistic. The argument against it is that you are paying a senior tester to spend two days discovering things you already know, and a determined attacker has months where your engagement has days. That asymmetry is the whole case for grey box: the attacker will eventually find the admin panel, so buying the discovery of it is poor value compared with buying an examination of what is behind it.

White box is worth the extra where the risk is in logic rather than in exposure. If the question is whether your authorisation checks are correct in every branch, reading the branches is faster and more complete than guessing at them, which is why a secure code review is often bought alongside a test rather than instead of one.

Deciding what is in scope and what is not

Exclusions are legitimate. Undocumented exclusions are not, because a reader cannot tell the difference between something deliberately left out and something nobody thought of. Write each exclusion down with a reason next to it.

Things commonly and reasonably excluded

Denial of service and volumetric testing. It proves little about design and risks the availability you are trying to protect.
Third-party services you do not control. Your payment processor, your identity provider and your cloud provider each have their own testing rules, and most forbid testing without prior authorisation.
Social engineering and phishing, unless specifically bought. It answers a question about people rather than about the system, and it needs its own consent and its own rules.
Physical access to offices or data centres.
Anything owned by a customer of yours rather than by you, in a multi-tenant product.

Things that should almost never be excluded

The administrative interface. It is where the highest privileges live and it is regularly left out because it is internal, which is not the same as unreachable.
Password reset, invitation and account recovery flows. They are where authentication is most often undone.
The API behind the interface. Testing only the browser front end leaves the actual authorisation boundary untested.
One role, for convenience. A role matrix with a gap in it is not a role matrix.

Say what you own

A tester can only be authorised to test systems you are entitled to authorise. If part of the target sits with a hosting provider, a managed service partner or a parent company, get the written authorisation before the start date rather than during the engagement.

Credentials and test accounts

This is the most common cause of a delayed start, and it is entirely avoidable. Have accounts ready before the first day rather than promising them on it.

One working account per role. If you have five roles, that is five accounts, and ideally two of each so that horizontal access between peers can be tested.
Accounts in at least two separate tenants or organisations if the product is multi-tenant, each populated with distinguishable data.
Credentials that will still work on day five. Accounts that expire, require a fresh invitation link or lock after a few failed attempts cost hours.
Multi-factor authentication either provisioned with a shared secret the tester can enrol, or disabled for the test accounts by agreement, with that decision recorded.
Representative data. An empty account tests almost nothing. Orders, documents, users and whatever else the product manages should be present.
A named contact who can reinstate a locked account quickly, because at least one will lock.

How credentials are handed over matters as much as whether they exist. Email and chat messages are the wrong place for a working administrator account. On our engagements test accounts go into the encrypted credential store in the platform and are shared with everyone on the project, so nobody has to forward a password to get their work done.

Timing, environment and rules of engagement

The rules of engagement are the short document that says what the tester may do, when, from where and who to call when something breaks. It should exist even for a small engagement, and it should be signed by somebody with the authority to authorise it.

What the rules of engagement should state

The exact targets, written as hostnames, URLs and IP ranges rather than as descriptions.
The testing window, including whether out-of-hours or weekend testing is permitted or required.
The source addresses the testing will come from, so your monitoring team can distinguish the test from an incident.
What is explicitly forbidden: denial of service, destructive actions, data exfiltration beyond proof, changes to production data.
The escalation path and the criteria for using it. A critical finding and an outage need different phone numbers.
Named contacts on both sides, with a route that works outside office hours.
How evidence and any data encountered will be handled, stored and disposed of.
Whether your security monitoring team is being told. If not, say who does know, so an unannounced test does not become a genuine incident response.

Production or staging

Production gives an accurate answer and carries real consequences. Staging is safer and only as useful as its fidelity. The practical middle ground most teams land on is testing a staging environment that is deployed from the same code and configuration as production, with representative data and the same authentication provider, and then agreeing a short list of non-destructive checks that may be run against production to confirm parity.

Whichever you pick, decide in advance what happens if something is genuinely broken during the test. Findings arriving live, rather than in a document six weeks later, changes that conversation: a critical issue reaches your queue the hour it is confirmed, which is when you can still act on it cheaply.

Common scoping mistakes

Scoping by page count. It is the number people reach for and it correlates poorly with effort. Roles, tenants and authenticated functionality are the real drivers.
Excluding the admin interface because it is internal. Internal means fewer people can reach it, not none, and the blast radius of a flaw there is the whole system.
Testing the front end and not the API. The browser is a client. The authorisation boundary is the API, and that is where the finding will be.
Providing one account and one role. Almost every high-impact application finding is somebody reaching something they should not, and that cannot be tested with a single identity.
Leaving the web application firewall at full strength. You then pay for a test of the firewall rather than of the application, and the firewall is not the thing you were worried about.
Booking the test for the week before the deadline. Leave time to fix things and to have the fixes verified, or the report tells your auditor about open issues rather than closed ones.
Treating a scan as a scope. Automated output is a starting inventory, not a statement of what a person examined, and the two are not interchangeable when somebody external is relying on the answer.
Forgetting the retest. Verification is what turns a finding into a closed finding. Ours are included in the engagement rather than quoted separately.

The seventh point deserves its own link, because it is the one most often got wrong under budget pressure: a penetration test and a vulnerability scan answer different questions, and several standards ask for both separately.

A scoping brief you can send in one message

Fill this in and send it to whoever is quoting. It is enough for a firm price from most suppliers and it will expose disagreements inside your own organisation before they cost you anything.

What the system does, in two sentences, and what the worst realistic outcome would be.
Who is asking for the test, and the exact wording of what they asked for.
The targets, written exactly: hostnames, URLs, IP ranges, app bundle identifiers.
The user roles, and whether the product is multi-tenant.
Rough scale: applications, endpoints, significant user journeys, whether there is an admin back office.
Environment to be tested, and how it differs from production.
Approach: black, grey or white box, and what you can provide to support it.
What is out of scope, each with a one-line reason.
The window, the deadline, and what the deadline is driven by.
Named technical contact, named escalation contact, and who can authorise the test.

If you would rather work through it with somebody, that is what a scoping call is for. Ours takes about thirty minutes and ends with a fixed price, and the services list is a reasonable place to start if you are not yet sure whether you need web, API, mobile or network testing.

Keep reading

All resources