We have been told we need a pen test. Do we?

Possibly not, and this is the first thing worth checking. Ask whoever asked for it to send their exact wording. Auditors, insurers and enterprise procurement teams often use the phrase loosely, and many of those requests are satisfied by a vulnerability assessment. An assessment records that a weakness exists; a test proves what is actually reachable, and is priced by the days that proving takes. If your systems have no multi-factor authentication and nobody has ever restored a backup, a penetration test will spend your money telling you that. Basic hardening first is the cheaper route to the same report.

What paperwork has to exist before testing starts?

A signed authorisation letter from someone empowered to give it, naming the assets in scope and the testing window, plus a rules of engagement document covering what is excluded, what happens if something breaks, and named emergency contacts on both sides with out-of-hours numbers. Where an asset sits on infrastructure owned by a third party — a hosting provider, a SaaS platform — that party's permission may be needed too. Without all of it, testing is a criminal offence under the Computer Misuse Act and the CFAA regardless of intent.

Will the testing take our systems down?

Denial-of-service testing is excluded by default and we would advise keeping it that way. Other testing can still cause load or unexpected behaviour, which is why the scope defines a testing window, blackout periods around your busiest hours, and a contact who can be reached immediately. If something destabilises, testing stops and you are called — not emailed.

What happens if you find something critical halfway through?

You are told immediately. Anything actively dangerous does not wait for the report to be written and formatted. That is written into the rules of engagement, along with who receives that call and what is expected to happen next.

Is a retest included?

It is quoted separately, and it should be. Testing again after you have fixed things is its own piece of work with its own time cost, and lumping it into the original fee tends to mean it is done quickly and badly. The same applies to the attestation letter — the short signed document you hand to the customer or auditor who asked for this in the first place.

Can you test a competitor, or a supplier we are unhappy with?

No, and we would end the conversation there. Testing a system you do not own or control is a crime and asking for it is a request to commit one. If you have a dispute with a former developer or a partner holding your accounts, that is a matter for your lawyer and the platform concerned.

Cybersecurity

Penetration testing

A scoped, authorised attack simulation against systems you own — evidence of what is genuinely reachable, a report your auditor or customer will accept, and a retest afterwards.

From: $2,000–$25,000
Typical time: 2–6 weeks
Usually bought by: Regulated, funded firms

What this actually solves

Most penetration tests are not bought because somebody woke up wanting one. They are bought because a door has closed. A SOC 2 or ISO 27001 auditor has listed it as evidence they require. An enterprise customer's vendor onboarding process asks for a recent test before the contract can be signed. An insurer wants one before it will write the policy. Or a payment obligation such as PCI DSS makes it non-optional. The real sentence behind the enquiry is usually "I need the report my customer is asking for", and that is a legitimate reason to buy one.

The second reason is narrower and more honest — a company has built something that holds customer data or money, has hardened it as far as its own knowledge goes, and wants to know what somebody who does this professionally can reach. Not a list of theoretical weaknesses, but demonstrated ones, with the evidence attached.

What separates this profession from a crime is one thing, and it is not skill or intention. It is written authorisation with a defined scope. The same tools, the same actions and the same good intentions are an offence under the Computer Misuse Act in the UK and the CFAA in the US when that paperwork does not exist, and courts look at whether permission existed, not at what you meant. That is why the paperwork stage of this engagement is not a formality and is not skipped, even when it feels tiresome.

How the engagement runs

Scoping. A structured questionnaire before anything is agreed — exactly which domains, IP ranges, applications, mobile apps and cloud accounts are in scope and which are explicitly excluded; who legally owns each one and whether a third-party host's permission is also required; the testing window and the blackout periods around your business-critical hours; whether the test is black box, grey box or white box and what credentials will be provided; whether social engineering is in or out of scope and what HR and legal approvals exist if it is; and what the final deliverable is for, because an auditor, an enterprise customer and an insurer each expect a different format. Three to five days, mostly waiting on your answers.
Rules of engagement and authorisation. The signed letter from your authorised signatory, the exclusions written down, denial-of-service testing ruled out, named emergency contacts on both sides with numbers that are answered out of hours, and the data-handling terms — how findings and anything accessed during testing are stored, for how long, and how they are destroyed afterwards. Two to three days.
Testing against a defined methodology. Web applications follow the OWASP Web Security Testing Guide; network and infrastructure work follows a PTES-shaped structure. Everything is recorded as it happens, with timestamps, because the record is what makes the findings defensible later. Anything found that is actively dangerous is reported the moment it is confirmed. Three to ten days, and this is where the price is set.
Reporting. Each finding with its evidence, its rating, the business consequence and remediation written for the platform it actually sits on rather than in general terms. An executive summary a non-technical director can act on, and a technical section your developers can work through. Three to five days.
Retest and attestation. After you have fixed things, the same findings are tested again and the result recorded, followed by the short attestation letter you can hand to whoever asked for this. Two to four days, once remediation is complete.

What moves the price

$2,000–$25,000 over 2–6 weeks is a wide range, and it is wide for one structural reason rather than several.

Testing days. This is the whole of it, structurally. A single web application with a handful of user roles is a small number of days. A full network, or a large multi-tenant SaaS product with an API, an admin plane and several integrations, is a large number. Every other factor is really a way of changing that count.

How much is in scope, and how much is genuinely out. Each additional domain, brand, environment or mobile app is more testing, not the same testing spread wider. A scope that lists three environments and expects one environment's price is the most common source of friction, which is why the exclusions list is written to be longer than the inclusions.

Whether retest and attestation are needed. Many buyers only discover at the end that the customer who demanded the test also expects proof the findings were fixed. Priced from the start, that is straightforward. Discovered afterwards, it is a second negotiation at the worst possible moment.

What usually goes wrong

A test is sold to a company that needed hardening. This is the expensive one. A business with no multi-factor authentication on its email admin, backups nobody has ever restored, and a CMS two years behind will get a report saying exactly that — for the price of a test, when the basics would have produced the same list for far less. The right answer sometimes is "not yet", and it is worth more to you than the sale.

Scope is agreed verbally and expands during testing. Someone mentions another subdomain, a staging environment, an API "while you're in there". Every one of those is outside the signed authorisation, which means it is outside the law as well as outside the budget. Scope changes go back through the same signature, every time, with no exceptions for convenience.

The report is treated as the finish line. A pen test report that sits in a folder has changed nothing except the balance sheet. The value arrives when the findings are fixed and retested, and when the attestation letter goes to the customer whose question started all of this. Booking the remediation window at the same time as the test is the difference between a purchase and an outcome.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We have been told we need a pen test. Do we?: Possibly not, and this is the first thing worth checking. Ask whoever asked for it to send their exact wording. Auditors, insurers and enterprise procurement teams often use the phrase loosely, and many of those requests are satisfied by a vulnerability assessment. An assessment records that a weakness exists; a test proves what is actually reachable, and is priced by the days that proving takes. If your systems have no multi-factor authentication and nobody has ever restored a backup, a penetration test will spend your money telling you that. Basic hardening first is the cheaper route to the same report.
What paperwork has to exist before testing starts?: A signed authorisation letter from someone empowered to give it, naming the assets in scope and the testing window, plus a rules of engagement document covering what is excluded, what happens if something breaks, and named emergency contacts on both sides with out-of-hours numbers. Where an asset sits on infrastructure owned by a third party — a hosting provider, a SaaS platform — that party's permission may be needed too. Without all of it, testing is a criminal offence under the Computer Misuse Act and the CFAA regardless of intent.
Will the testing take our systems down?: Denial-of-service testing is excluded by default and we would advise keeping it that way. Other testing can still cause load or unexpected behaviour, which is why the scope defines a testing window, blackout periods around your busiest hours, and a contact who can be reached immediately. If something destabilises, testing stops and you are called — not emailed.
What happens if you find something critical halfway through?: You are told immediately. Anything actively dangerous does not wait for the report to be written and formatted. That is written into the rules of engagement, along with who receives that call and what is expected to happen next.
Is a retest included?: It is quoted separately, and it should be. Testing again after you have fixed things is its own piece of work with its own time cost, and lumping it into the original fee tends to mean it is done quickly and badly. The same applies to the attestation letter — the short signed document you hand to the customer or auditor who asked for this in the first place.
Can you test a competitor, or a supplier we are unhappy with?: No, and we would end the conversation there. Testing a system you do not own or control is a crime and asking for it is a request to commit one. If you have a dispute with a former developer or a partner holding your accounts, that is a matter for your lawyer and the platform concerned.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Penetration testing All Cybersecurity services