Cheap CREST penetration testing › Does your requirement need a test?
Very few organisations wake up wanting a penetration test. It nearly always arrives attached to something else: a contract clause, an insurance proposal form, a security questionnaire from a customer, a tender, an auditor's observation. Somebody forwards it with a note asking how much this is going to cost.
The first useful thing to do is not to get quotes. It is to read what the document actually says, because the gap between what people assume these clauses require and what they literally require is wide, and it runs in both directions. Some organisations buy a £6,000 test to satisfy a requirement that a £320 certification would have met. Others buy a cheap scan to satisfy a clause that unambiguously demands manual testing, and find out at evaluation.
Read the words, not the heading
Print the clause. Underline every noun that describes a thing to be done and every one that describes a thing to be produced. Then answer four questions from the text alone, resisting the urge to fill gaps with what you assume is meant.
- What activity is named? "Penetration testing", "vulnerability scanning", "security testing", "an independent assessment", "an annual review". These are not synonyms and they are not priced alike.
- Who has to perform it? An accredited company, a certified individual, an independent third party, or simply someone. Independence is the crucial word here, because "independent" rules out your own IT team while "qualified" may not.
- What has to be produced? A report, a certificate, a summary, a statement of remediation, or nothing specific. This is the part that actually determines what you have to buy, and it is the part most often left vague.
- How often, and against what? Annually, on material change, before go-live, or once. Against all systems, internet-facing systems, or the systems used to deliver this particular contract.
That fourth question saves more money than the other three combined. A clause requiring testing of the systems used to deliver a specific contract is a much smaller scope than one requiring testing of your organisation, and the two are easy to confuse when you are reading quickly.
What different wordings usually mean in practice
| What the document says | What usually satisfies it |
|---|---|
| "Appropriate technical and organisational measures" | Nothing specific. This is data protection language and it is satisfied by a documented, proportionate set of controls. It does not name testing and a certification scheme frequently evidences it adequately. |
| "Regular vulnerability scanning" | Scanning, at the stated frequency, with evidence that findings were acted on. A penetration test is more than this asks for, and buying one does not remove the need for the recurring scanning. |
| "Industry standard security certification" | Usually a recognised certification scheme. Ask which ones the other party accepts before assuming, because the answer is often broader than you expect. |
| "Annual penetration testing by a qualified third party" | A penetration test, genuinely. Check whether "qualified" is defined; if it is not, ask what evidence of qualification will be accepted. |
| "Testing by a CREST-accredited provider" | Company-level accreditation, which only some providers hold. Note that accrediting bodies certify individuals separately from organisations, and a clause like this almost always means the company. |
| "Evidence that identified vulnerabilities have been remediated" | A retest report or an attestation of remediation, not the original findings document. Buying a test without a retest does not satisfy this. |
The insurance proposal form
Cyber insurance questionnaires are where the most unnecessary spending happens, because the questions are answered by someone under time pressure who reads them as instructions rather than as questions.
A proposal form asking whether you carry out penetration testing is asking a question. Answering no is permitted. It may affect your premium or your terms, and it may not, and the difference is very often less than the cost of the test. The mistake is to treat every box as a requirement and buy your way to a row of yeses without ever finding out which ones were priced.
The sequence that saves money is to complete the form honestly first, then ask your broker which answers materially affect the quote and by how much. Frequently the answers that move the number most are multi-factor authentication, backup arrangements, patching cadence and staff training, all of which cost far less than testing. Buy those first, and buy the test if the arithmetic still favours it.
One caution in the other direction. Answering yes to a testing question when what you have is a vulnerability scan is a misstatement on a proposal form, and that is a materially worse problem than a higher premium. If you are unsure which of the two you bought, there is a separate article on this site about telling them apart from the report.
The customer security questionnaire
These arrive from a prospective or existing client and are usually a spreadsheet with between forty and four hundred rows. The testing question inside one is almost never a pass or fail gate on its own.
Two things worth knowing. The first is that a questionnaire is a negotiation, not an examination: "not currently, and scheduled for the first quarter" is an acceptable answer to most reviewers and is much better than a hurried purchase. The second is that the organisation sending it will usually accept an attestation letter rather than a full report, which matters because handing a customer a detailed description of your weaknesses is a decision that deserves more thought than it normally gets.
What would genuinely be cheaper, and when
Three alternatives cover most of the cases where a test is not the right purchase.
A certification scheme
Where the requirement is about baseline controls being in place rather than about your systems being tested, a certification evidencing a defined set of controls is faster, cheaper and better understood by the people reading it. A great many clauses that people answer with a penetration test are satisfied this way.
Vulnerability scanning, sold as itself
Where the requirement names scanning, or asks for regular rather than annual activity, recurring scanning with a record of remediation is both what was asked for and a fraction of the cost. It is a legitimate product and the only problem with it is when it is sold as something else.
Doing nothing yet, deliberately
Where the requirement is aspirational language in a framework agreement with no evidence obligation attached, the correct purchase may be none. Record the decision and the reasoning, because a documented decision is defensible and an oversight is not.
Ask the person who wrote it
The step almost nobody takes, and the one that resolves the question outright. Whoever sent you the clause can tell you what they will accept, and asking makes you look diligent rather than evasive. Put it in writing, keep the reply, and ask three things: what evidence will be accepted, whether a certification satisfies it instead, and what scope they consider in and out.
For a tender there is usually a formal clarification window and you should use it. The answers are commonly published to all bidders, which means the question is a small gift to your competitors and a large one to you, because a wrongly scoped bid is worse than a slightly copied one.
When the answer is yes, buy the right size
If the requirement genuinely needs a test, the remaining lever is scope rather than product. Test the systems the clause actually covers, which is often narrower than your whole estate, and get the exclusions stated in the report so that the document says plainly what it does and does not assure. For a contained scope, two to three weeks from agreed scope to testing is the usual lead time, and a tight scope can often be fitted inside a week when a deadline demands it. That is worth knowing before you pay a premium for urgency you may not need.
Our insurer asked whether we do penetration testing. Do we have to say yes?
No. It is a question, and answering it accurately is what matters. Ask your broker which answers actually move the premium before buying anything, because multi-factor authentication, backups and patching frequently move it further and cost far less. What you must not do is answer yes when what you have is a vulnerability scan.
The clause says "CREST accredited". Does a tester with a personal certification satisfy it?
Usually not, because accreditation at company level and certification of an individual are separate things and a clause worded that way generally means the company. If your bid depends on it, ask the buyer in writing during the clarification period rather than deciding for them.
Can a certification replace a penetration test?
For some requirements, yes, and for others not at all. A certification evidences that a defined set of controls is in place. A penetration test evidences that somebody tried to defeat your specific systems. Where the wording is about controls being present, certification often satisfies it; where it is about testing, it does not.
What if we genuinely cannot afford what the requirement asks for?
Say so, early and in writing, with what you can do and by when. Most counterparties will accept a dated plan, and some will narrow the requirement once they understand the cost against the size of the contract. What causes real damage is agreeing to a clause you cannot meet and being found not to have met it.
Send us the clause, not the scope
We will tell you what it actually requires, whether something cheaper satisfies it, and if it does we will say so rather than quote you for a test.