Cheap CREST penetration testing › Scope reduction done properly
Most budget conversations start the same way. A quote arrives at £7,000, there is £3,000 available, and the buyer asks whether the price can come down. It usually can. Whether that turns out to be a saving or a waste depends entirely on which of the two available levers gets pulled.
The first lever reduces the tester-days and leaves the scope alone. Everything on the list is still nominally examined, just less carefully. The second reduces the list and leaves the effort per item where it was. Buyers ask for the first because it does not require them to give anything up on paper. It is also the one that produces a report which reads as complete and is not.
This article is about pulling the second lever properly, because done well it is not a compromise at all. A thorough test of the system that matters is worth considerably more than a thin test of everything you own.
Width and depth are different purchases
A test has a width and a depth. Width is how many things are in scope: how many addresses, applications, roles, environments. Depth is how thoroughly each one is examined once the tester is in front of it.
Width is yours to set. You know which systems exist, which are load bearing and which are a marketing landing page nobody has touched since 2021. Depth is not really yours to set, because below a certain level of effort per target a tester stops finding the things that require thought and starts reporting the things a tool prints out. There is no version of that which is good value, however cheap the day looks.
So the rule is short. Take things out of the list. Do not take hours off what stays.
Working out which system actually matters
This is the part organisations find genuinely hard, because the answer is a decision rather than a lookup, and because three departments will give you three different answers. Four questions settle it faster than a workshop does.
What would an attacker do with it in the first hour?
Not what it holds, but what it enables. A system that stores nothing interesting but issues session tokens for everything else is a better target than the database everyone worries about. Ask what the next move would be after compromising each candidate, and the ranking tends to reorder itself.
What can it reach that it does not need to?
Flat networks and over-permissive service accounts are what turn a modest foothold into an incident. If one of your candidates sits on a segment with unrestricted access to the rest of the estate, its blast radius is the whole estate and that is the one to test.
Who can already talk to it?
Anything reachable from the public internet outranks anything reachable only from inside, all else being equal, because the population of people who can attempt it is the whole world rather than your staff and whoever gets a laptop. Internal testing matters, and it is rarely the right first purchase on a constrained budget.
What would you have to tell people about?
If a compromise would trigger a notification to the Information Commissioner's Office, a disclosure to a major customer, or a conversation with a regulator, that system carries a cost the others do not. This is the question that most reliably breaks a tie between two technically similar candidates.
Answer those four and you will usually have one clear winner and one close second. Test the winner properly. Put the second in next year's budget rather than halving the days across both.
The order to cut in
Work down this list and stop as soon as the number fits. It is ordered so that the cheapest information is given up first.
- Dormant and decorative systems. The old campaign microsite, the staging copy nobody uses, the supplier portal with four users. These are often in scope because they appeared on an asset list, not because anyone decided they should be tested. Take them out, and in several cases take them offline, which is better than testing them.
- Duplicated environments. If staging is a genuine mirror of production, test one of them rather than both. Say in the scope which one, and say why, because the two are never quite identical and the report should be honest about which one the findings describe.
- Secondary applications sharing a platform. Six sites on one content management system with one theme and one plugin set are not six tests. Test the one with the most functionality and accept that findings in the shared components almost certainly apply across all six.
- Breadth of infrastructure. Forty addresses of which eight are live and the rest are broadcast, gateway and unused. Confirm what is actually listening before you pay anyone to scope against a range.
- Whole classes of testing you have not thought about yet. Wireless, physical intrusion, phishing and social engineering sit outside a standard penetration test, and each needs consenting and scoping on its own terms. They are frequently bundled into a request for a penetration test by people who have not decided they want them. Decide, and if the answer is not yet, remove them.
- Number of user roles. This one hurts and it comes last for a reason, which is the next section.
The two cuts that quietly buy you nothing
Dropping from four user roles to one is a real saving and a real loss, and people underestimate the loss because the report still says the application was tested. Nearly all serious access control findings live between roles rather than inside one: what a standard user can reach that belongs to another standard user, and what a standard user can reach that belongs to an administrator. With one account, neither of those can be examined at all. If your application has roles and the budget only allows one, be clear with yourself that you have bought a test of functionality rather than a test of authorisation.
The other false economy is removing the retest. It looks like a clean saving because the testing has already happened by the time you think about it. But the document most requirements actually want is the one showing findings closed, not the one showing findings open, and buying a retest separately later at full rate costs more than including it did.
The report has to state what was left out
This is the clause that makes a reduced scope legitimate rather than misleading, and it is the thing to insist on when you agree the reduction.
A report on a narrowed test must carry an explicit statement of exclusions covering four things: what was in scope, what was deliberately excluded and why, what depth was applied to what was included, and what conclusions may therefore not be drawn from the document. Not a footnote on page thirty. A section near the front, in the same language as the executive summary.
The reason is that reports outlive the conversation that produced them. Eighteen months later the person reading it will be an auditor, an insurer, a prospective acquirer or a new head of IT, none of whom were in the scoping call. To all of them, a document that lists findings without stating its boundaries reads as reassurance covering the whole organisation. That is how a sensible budget decision turns into an inaccurate assurance claim, and it is entirely preventable by half a page of text.
Ask to see the exclusions wording before testing starts rather than after. It is a fair request, it takes a provider ten minutes, and how they respond to it tells you a good deal about the report you are going to get.
Phasing, which is what most constrained buyers should actually do
If you have four systems worth testing and the budget for one, the choice is not between testing one and testing four badly. It is between testing one properly every year for four years, or testing everything shallowly every year forever and never learning much about any of it.
Write the phasing down and share it with whoever asked for the test. A documented three-year plan that names which system is covered when is a far better answer to an auditor or an insurer than a single thin report, and it is the same money. It also stops the rotation being forgotten, which is the usual fate of good intentions formed during a budget round.
Is it better to test one system thoroughly or three systems briefly?
One system thoroughly, in almost every case. A brief test of three systems finds the issues that any scan would have found and misses the access control and business logic flaws that require someone to sit with the application. Rotate the others through future years and record the rotation somewhere, so that the plan survives the person who made it.
How do we choose between two systems that both look important?
Ask which one a compromise would force you to tell somebody about: a regulator, a major customer, the Information Commissioner’s Office. That question breaks ties more reliably than arguing about data volumes, because it captures the consequence rather than the size of the system.
Will a provider agree to a reduced scope, or will they push for the full one?
A reasonable provider will help you reduce it, because a well scoped small job is easier to deliver well than a badly scoped large one. What they should not do is keep your original scope and quietly cut the days. If a revised quote covers the same list for half the money, ask which activities have been removed and expect a straight answer.
Does a narrowed test still satisfy a tender or insurance requirement?
Sometimes, and it depends on how the requirement is worded rather than on the size of the test. Some clauses name systems, some name a frequency, and some simply say that testing must be carried out. Read the wording, and if it is ambiguous, ask the party who wrote it in writing before you buy rather than after.
Tell us the budget as well as the scope
Send both and we will tell you what a reduced scope would honestly cover and what it would leave untested, before you commit anything.