The fortnight before the test is the cheapest part of it

Cheap CREST penetration testing › Fix before the tester arrives

A CREST-accredited tester costs somewhere between £800 and £1,200 a day. That rate is the same whether they spend the morning on an expired certificate that any free tool would have reported, or on an authorisation flaw that took four hours of reading requests to find. You pay identically for both, and only one of them was worth the money.

So the highest return available to a constrained buyer is not negotiating the rate. It is clearing out, in the two weeks beforehand, everything a tool would have found anyway. Organisations that do this get noticeably better reports from the same spend, and the work is unpaid, uncomplicated and entirely within your control.

Here is a specific fortnight.

Week one: find out what is actually exposed

Build the real asset list

Almost every organisation has more on the internet than it thinks. Start with your external DNS zone and list every A, AAAA and CNAME record. For each one, answer three questions: is it ours, is it live, and does it need to be reachable. Records pointing at decommissioned hosts and at cloud resources that have been torn down are a standing risk in their own right, because the addresses get reallocated to someone else. Delete them.

Then check your public address ranges for what is listening. You do not need a commercial tool for this. What you need is the list, because a scope built on a guess is a scope that either misses something or has you paying to test broadcast addresses.

Take the management interfaces off the public internet

This single action removes more findings than anything else on this page. Administrative consoles, content management logins, database front ends, remote desktop, file transfer services, printer web interfaces, network device management, backup appliance consoles, monitoring dashboards. If it exists to administer something, it should be behind a VPN or restricted to known addresses, and if it cannot be, that is itself worth knowing before the test rather than during it.

Deal with accounts

Pull a list of every account in every externally reachable system and check it against your current staff list. Leavers, contractors whose engagement ended, the shared account three people use, the service account created for a migration in 2022, the vendor support login. Disable what should not exist and record what must.

Then turn on multi-factor authentication everywhere it is available, starting with anything reachable from outside and anything with administrative privilege. Where an application does not support it, note that as a known limitation rather than discovering it in a findings table.

Hunt for the things that should never be published

A short list, each of which takes minutes to check and is embarrassing to receive as a finding.

• Version control directories served by the web server, which hand over your source and often your credentials.
• Backup files, database dumps and archives sitting in the web root, usually with a name ending in .bak, .old, .zip or a date.
• Directory listing enabled on any path.
• Configuration and environment files reachable by URL.
• Cloud storage buckets with public read, particularly ones created for a one-off file transfer and never closed.
• Internal documentation, staging notices and test pages indexed by search engines.

Week two: patch, configure, and prepare the access

Run your own scan and act on it

Free and low-cost vulnerability scanners will tell you about missing patches, end-of-life software, weak transport security and default configurations. Run one, then fix what it reports rather than filing it. The point is not the scan; it is that every item you close is an item a tester does not have to write up.

Prioritise anything with a public exploit, anything on the perimeter, and anything where the fix is a version bump. Where you cannot patch, write down why, because a tester who knows you have accepted a risk deliberately will spend their time differently to one who assumes you missed it.

The content management system specifics

If the target is a WordPress, Drupal, Joomla or similar site, most of what a test finds is in the plugins and the theme rather than the core. Update core, update every plugin, and remove every plugin that is deactivated rather than leaving it in place. Deactivated plugin code is frequently still reachable. Remove unused themes for the same reason. Check that the administrative path is not the default one, that user enumeration is not trivially possible, and that file editing through the administration panel is disabled.

Transport and headers

Certificates in date and covering every hostname in scope, including the ones that only redirect. Old protocol versions and weak cipher suites switched off. Plain HTTP redirecting to HTTPS everywhere. Security headers set. None of this is exciting and all of it is cheap, and it removes a predictable block of low and medium findings that would otherwise take up report pages you paid for.

Get the access ready now, not on the morning

Accounts that turn out to be unusable when the window opens are the single most common cause of a test losing a day, and on a small engagement that is a quarter of what you bought. Before the window opens: create an account for every role in scope, plus a duplicate account holding identical privileges to one of them, so that access between peers is testable at all. Log into each one yourself and complete any first-run setup. Decide what happens with multi-factor authentication on test accounts. Populate the accounts with representative data, because empty accounts hide most of the business logic. Name somebody who can unlock accounts the same hour, because testing authentication locks accounts. Agree a secure route for sending the credentials that is not a plain email.

Tell the right people

Your hosting provider or managed service provider, if their agreement is needed. Whoever runs your monitoring, so that a flood of alerts does not become an incident response exercise. Your out-of-hours contact, who needs to know they are on call during the window. Anyone running a release, a migration or a month-end close in the same fortnight, so the dates can move before they collide.

Four things not to do

Do not rebuild anything in the week before. Changes made in a hurry immediately before a test are the changes most likely to introduce the flaw the test then finds. Freeze the estate a few days out.

Do not hide things from the tester. Removing a system from scope because you suspect it is weak is the most expensive decision available to you. You will pay for a test that avoids the problem and you will still have the problem.

Do not turn on protection you do not intend to keep. A web application firewall enabled for the fortnight of the test and relaxed afterwards buys you a clean report and no security. If there is protection in front of the application, decide deliberately whether testing runs through it or behind it, and record the decision.

Do not stop at the fortnight. The work above is the baseline the test is supposed to start from, not preparation for an event. If it degrades over the following year, next year's test spends its first day in the same place.

What this actually buys

On a three-day engagement, this preparation typically converts most of a day of write-up on predictable findings into time spent on the parts of your system that are genuinely yours: the workflow that can be skipped, the identifier that can be changed, the export that returns more than it should, the permission check that exists on the page and not on the request behind it. Those are the findings nobody else could have given you, and they are what a tester is for.