How fast can a CREST penetration test actually be?

Four clocks, and only three of them compress

"How long does a penetration test take" is four questions wearing one coat, and conflating them is why quoted timelines vary so wildly for what looks like the same job.

The four clocks in a penetration testing engagement

Clock	What happens	Compresses?
Enquiry to agreed scope	Working out what is being tested, from how many angles, with what access	Yes, to a single call
Agreed scope to first packet	Authorisation, rules of engagement, credentials, scheduling a tester	Partly, and this is where short-notice jobs actually stall
Testing	The tester-days you bought	No
Testing to report in hand	Writing up, peer review, quality assurance, delivery	Yes, but not to zero

A provider promising a two-day turnaround has made one of those four go away. It is almost never the first, because scoping a job badly is free and fast. It is usually the third and the fourth: fewer tester-days than the scope needs, and a report that nobody senior has read before it reaches you.

What CREST accreditation actually obliges a provider to do

Most writing about CREST stops at "it means the company has been assessed". That is true and not very useful, because it does not tell you what is being assessed, and it is the substance that puts a floor under how fast the work can honestly go.

Accreditation is granted against the organisation's processes, not its marketing. The assessment looks at documented testing methodology and whether real engagements follow it; at how findings are evidenced and retained; at data handling, from how client data is transmitted to when it is destroyed; at how testers are vetted and how their competence is maintained; at how a report is reviewed before it leaves the building; and at what happens when a client complains. It is audited and it is renewed, and a lapse is a real thing that shows on the register.

Two of those bear directly on speed.

The methodology has to be followed, not merely owned

A methodology that says authenticated testing covers each user role means each user role gets tested. If your application has four roles and the quote prices two days, the arithmetic does not work, and an accredited provider cannot quietly resolve that by testing one role and describing the others. This is the single biggest driver of honest day counts, and it is why a CREST quote is often higher than the one next to it for what appears to be identical work.

The report is reviewed before you see it

Peer review is not a formality. A second tester reads the findings, checks the evidence supports the severity, and sends it back if it does not. That costs somewhere between half a day and two days depending on the size of the report, and it is the step that gets deleted first when somebody is competing on turnaround. You will not see its absence in the quote. You will see it in a report that rates everything medium, cites a scanner plugin ID as its evidence, and cannot be handed to your buyer without embarrassment.

So how fast is fast?

Measured properly, from the day you say go to the day the finished report is in your hands, with authorisation already settled.

Enquiry to report in hand, with authorisation already in place

Scope	Tester-days	Report in hand, at short notice
Verifying one disclosed vulnerability and its surrounding area	1 to 2	Often within a week
External infrastructure, up to 10 IPs	2 to 3	7 to 10 days
CMS website, unauthenticated	2 to 3	7 to 10 days
Web application, three user roles, authenticated	5 to 8	2 to 3 weeks
Internal network, single site	5 to 10	2 to 3 weeks, subject to site access
Multi-application estate or a cloud tenant review	10+	Rarely below 3 weeks, and we will say so

The two rows at the top of that table are the two tests you can buy on this page without a scoping call, which is why they exist. They are not the right answer for every requirement, and where they are not we will tell you rather than sell you one anyway.

Critical findings do not wait for the report. Anything we confirm as critical reaches you the day we confirm it, with enough detail to act on, because a finding held back for four days so it can appear in a tidy document is a finding that was not treated as critical.

Where the days really go on a short-notice job

Everyone assumes the constraint is tester availability. Sometimes it is. Far more often the engagement sits still for a week for one of these reasons, all of which are fixable in advance and none of which involve us.

Nobody can sign. The authorisation and the rules of engagement need a signature from somebody who can commit the organisation. If that person is on leave, or it turns out to need two signatures, or the target belongs to a parent company, that is days.

The hosting provider has not been asked. If the target sits in someone else's cloud or on a managed host, their testing policy governs what may be done to it. Most of the large providers permit customer-initiated testing of your own assets within a stated policy, some require notification, and testing the provider's own infrastructure is out of bounds everywhere. Finding out which applies to you takes an afternoon; finding out after the tester has started takes a great deal longer.

The credentials do not work. Test accounts are issued, the tester logs in on day one, and two of the four roles are broken or have the wrong permissions. A day lost, sometimes two, and it is the most common single cause of a test overrunning.

The environment is not the environment. A staging instance three releases behind production tells you about a system that no longer exists. Worth checking what is actually deployed before the window opens.

Questions that separate efficient from skipped

If two quotes differ by a week and several thousand pounds, these five answers will usually explain it. Ask both providers, in writing.

1. How many tester-days am I buying, and how are they split across the scope? A quote without a day count is not a quote, it is a price.
2. Is testing authenticated, and how many user roles are covered? Unauthenticated testing of an application with logins covers the front door and nothing behind it.
3. Who writes the report, and who reviews it before I see it? If the answer is the same person, there is no peer review and the turnaround is quicker for a reason.
4. What proportion of findings will come from automated tooling? Everyone uses tooling. An honest provider will tell you where it ends and manual testing begins.
5. Is a retest included, or priced separately? Whoever has to accept your report will usually want evidence the findings are closed, not a list of what was open.

Fast, and the thing fast is often standing in for

A decent proportion of urgent enquiries are not really about speed. Somebody has been told to produce a penetration test report by a date, and the underlying question is what will satisfy the person asking. That is worth ten minutes before it becomes a scoping conversation, because the answer sometimes makes the job smaller, cheaper and quicker.

If the requirement names CREST, check it means the company and not an individual, because that decides whether the report satisfies the clause at all. If it names CHECK, that is the NCSC scheme for UK government systems and CREST is not automatically a substitute. If it names nothing, you have more freedom than you think and the report's readability matters more than the badge on it.

And if you have had an actual incident, a penetration test is the wrong purchase this week. It tells you what could happen. It does not tell you what did. Incident response first, testing once the environment is stable.

What this costs

CREST-accredited day rates in the UK run roughly £800 to £1,200. Short notice does not change the rate: an urgent engagement is priced the same as a planned one, because the day count is driven by scope rather than by your deadline. What urgency costs you is choice of dates.

Work quoted at £250 to £500 a day is usually an automated vulnerability scan with a cover page. That is a legitimate product and it has its uses, but it is not a penetration test and it will not satisfy a clause that asks for one.

Automated tooling, and the honest version of it

Every competent tester uses automated tooling. Discovery, enumeration, known-vulnerability checks and regression sweeps are work a machine does faster and more consistently than a person, and a provider claiming to do all of it by hand is either exaggerating or wasting your money.

The distinction that matters is whether the tooling is the test or the start of it. A scanner finds things already known to be wrong: missing patches, weak ciphers, default credentials, published CVEs. It does not find a business logic flaw that lets one customer read another's invoices, an access control check applied in the interface and not in the API behind it, or a password reset flow that can be walked backwards. Those need somebody who understands what the application is for, and they are consistently where the findings that actually matter turn up.

Solusec holds CREST's AI-Enabled Penetration Testing accreditation, one of the first ten granted worldwide. That is worth stating precisely rather than waving at, because the term is being used loosely elsewhere. It means the way AI-assisted tooling is used within testing has itself been assessed against a standard: what it is used for, what it is not trusted with, how its output is verified before it reaches a report, and how client data is handled when it passes through such tooling. It does not mean a model writes your report.

What you should get, whoever you buy from

The deliverable is where the difference between two similar-looking quotes becomes visible, usually after you have paid. A report worth the money contains all of this.

• The scope as tested, including anything agreed and then dropped, and why.
• Each finding with the evidence behind it: what was done, what came back, and enough detail for your developer to reproduce it without a phone call.
• Severity with reasoning, in the context of your system rather than a generic score lifted from a tool.
• Remediation advice that fits your stack, not a paragraph of vendor-neutral boilerplate.
• An executive summary a non-technical director can act on, because that is usually who decides whether the fixes get funded.
• A clear statement of what was not covered, so nobody later mistakes a narrow test for a broad assurance.

If a sample report is not available before you commit, ask why. Every provider has one with the client details removed, and a reluctance to share it is informative.

Retests, and why they get forgotten

The report is the middle of the process rather than the end of it. Whoever asked you for the test almost always wants evidence the findings were closed, and a list of what was open on a date in the past does not provide that.

A retest re-examines the specific findings after you have fixed them and states, for each one, whether it is closed, partially addressed, or still present. That document is what satisfies an auditor, an insurer or a buyer. Check whether it is included in what you have been quoted and what window it has to be used within, because a retest priced separately six weeks later at full day rate is a common and avoidable surprise.