The penetration test process is opaque to most of the people who commission it. A UK business signs off a quote, agrees some dates, and then waits. Somewhere in that gap a tester is doing something to the organisation’s systems, and a fortnight later a PDF arrives containing between twelve and ninety findings, colour-coded, with a covering summary that manages to be both alarming and non-specific. Nobody in the building has been told what to expect, what to prepare, or what to do with the document when it lands.
This guide walks the engagement from end to end from the client’s side of the table. It covers what happens during scoping and why the questions are asked the way they are, what the rules of engagement document is for and the legal reason it exists in UK law, what reconnaissance and testing actually involve day to day, what your staff will and will not notice while it is happening, and how to read a findings report and turn it into a prioritised remediation plan rather than a filing-cabinet artefact. It also covers realistic durations, the difference between a test and a scan, and the retest step that most organisations do not budget for and should.
What a penetration test is, and what it is not
A penetration test is an authorised, time-boxed attempt by a skilled tester to compromise defined systems, using the techniques a real attacker would, in order to establish what is genuinely exploitable and what the business impact would be. Three words in that sentence carry most of the weight: authorised, time-boxed, and defined.
Authorised is the one with legal consequences. Under the Computer Misuse Act 1990, accessing a computer system without authorisation is a criminal offence, and the Act draws no exemption for good intentions or professional competence. The written authorisation from someone with the standing to grant it is what makes the engagement lawful, which is why no reputable UK firm will begin testing on a verbal go-ahead or an email from somebody who does not own the systems. If a supplier is relaxed about this, that is informative about how they handle everything else.
Time-boxed is the one that shapes expectations. A tester has an agreed number of days. A real attacker has as long as they want, no scope boundaries, and no obligation to avoid breaking things. A test therefore establishes what a competent adversary could achieve within a comparable effort window, not an exhaustive proof that nothing else exists. A clean report means nothing was found in the time allowed, within the agreed scope, which is genuinely valuable and is not the same as a guarantee.
Defined is where most disappointment originates. A test finds problems in the things it was pointed at. An organisation that scopes an external infrastructure test and then asks why the report says nothing about its web application has not received a poor test; it has received the test it bought. Scoping is the single highest-leverage conversation in the whole engagement, and it is the one clients most often treat as administrative.
Before the scoping call, write down what you are actually worried about in plain language — “could someone get at our client files from the internet”, “if a laptop were stolen, what could they reach”, “could a customer of our portal see another customer’s data”. A good tester will translate those concerns into a technical scope far more accurately than you will translate them yourself, but only if they hear them. Clients who arrive with a list of IP addresses and no stated concerns get a technically correct test of the wrong thing more often than anyone would like.
Penetration testing in UK businesses — the numbers
The figures below reflect what we typically see across first-time and early-cycle engagements for UK organisations in the 20 to 400 seat range. They describe organisations with functioning IT and no prior testing history, which is the usual profile for a first test.
The second figure is the one that should reframe expectations most usefully. A first penetration test rarely uncovers an exotic, previously unknown weakness. It finds an unpatched edge device, a service exposed that nobody meant to expose, a default credential, an over-permissioned account, a certificate that expired, a legacy protocol still enabled. These are unglamorous findings and they are precisely the ones real intrusions use, because attackers are opportunists rather than artisans.
The last figure is the one that most undermines the value of the whole exercise. A test identifies problems; a retest confirms they are actually gone. Organisations that skip the retest are relying on their own assertion that a fix worked, and in our experience a meaningful minority of remediations either do not fully address the finding or introduce a new one. The retest is usually a fraction of the original cost and it is the step that converts a report into an improved security position.
Where the findings come from
The chart below shows the distribution of findings by category across first-time UK SME engagements. It is drawn from the composition of typical reports rather than from severity — a patching finding can be critical and an information-disclosure finding can be trivial. The purpose is to show what a report is actually likely to contain.
The top two categories appearing on more than four fifths of first tests tells you something about where remediation effort should be expected to land. Most of what a first report asks for is patching discipline and hardening — unglamorous operational work rather than a project. Organisations that budget for a test and not for the remediation that follows it tend to be surprised by this, because the instinctive assumption is that findings will require new products.
The web application row is lower than many expect, and the reason is scope rather than security. Fewer than half of first engagements include a web application in scope at all, so the category is underrepresented. Where an application is included, and particularly where it handles customer data or payments, it usually accounts for a disproportionate share of the higher-severity findings, because application logic flaws cannot be patched away by a vendor update.
Test types, durations and indicative UK cost
Scoping resolves to choosing one or more test types, each with its own effort profile. The table below gives indicative figures for UK engagements in 2026, excluding VAT. Actual pricing depends on the size of the estate, the complexity of the application, whether accreditation is required and how much retesting is included, so these are for planning rather than quotation. The fuller breakdown sits in our guide to penetration testing costs in the UK.
| Test type | What is examined | Typical duration | Indicative cost |
|---|---|---|---|
| External infrastructure | Internet-facing IP ranges, edge devices, exposed services, VPN and mail gateways | 2–4 days | £2,000–4,500 |
| Internal infrastructure | What an attacker could reach from inside the network, including privilege escalation and lateral movement | 3–6 days | £3,000–6,500 |
| Web application or API | Authentication, authorisation, input handling, business logic, session management | 4–10 days | £4,000–11,000 |
| Cloud and Microsoft 365 review | Tenant configuration, identity, conditional access, sharing and privilege model | 3–5 days | £3,000–6,000 |
| Social engineering assessment | Simulated phishing and pretext contact against agreed staff groups | 2–5 days | £2,000–5,500 |
Add three to five working days for reporting on top of the testing days in every case. This is not padding — writing up findings with reproduction steps, evidence, severity rationale and specific remediation guidance is a substantial part of the work, and a report produced in an afternoon is generally a scanner export with a cover page. When comparing quotes, check whether the stated duration includes reporting or only testing, because the two conventions are both in common use and produce quotes that are not comparable.
Two scoping decisions move cost more than most clients expect. The first is credentialed against uncredentialed testing: giving the tester valid low-privilege accounts costs nothing and typically finds considerably more, because it examines what a compromised user account or a malicious insider could reach rather than only what is visible from outside. The second is the knowledge model — whether the tester works blind, with partial information, or with full documentation and architecture diagrams. Blind testing feels more realistic and usually delivers less value per day, because a meaningful share of the budget is spent rediscovering things you already know and could simply have told them.
Rules of engagement and the legal basis
Before any testing begins there is a document, usually called the rules of engagement, which is the most important paperwork in the engagement and the part clients read least carefully. It exists for two reasons: to establish lawful authority, and to make sure that when something unexpected happens at two in the afternoon, everybody already knows what to do.
What it contains
A complete rules of engagement document sets out the precise scope — specific IP addresses, URLs, tenant identifiers, physical locations — and states explicitly what is out of scope. It names the testing window, including whether out-of-hours testing is permitted or required. It names individuals on both sides with contact details, including an out-of-hours escalation path. It states which techniques are excluded, which for most commercial engagements means denial-of-service testing, anything destructive, and any action that would degrade a production service. It records how any data the tester encounters will be handled, stored and destroyed. And it states the immediate-notification threshold: the severity of finding that triggers a phone call the same day rather than waiting for the report.
Why the authorisation matters legally
As noted above, the Computer Misuse Act 1990 makes unauthorised access to computer systems a criminal offence, and authorisation is the entire basis on which a tester operates lawfully. The practical implication is that authorisation must come from someone with the actual authority to grant it for the systems in question. This is straightforward for systems you own and becomes important for anything you do not: a web application hosted on a third-party platform, a service running in a colocation facility, or a SaaS product. Where the target is not wholly yours, the provider’s permission or their published testing policy needs checking before the test, not during it.
Cloud platforms are the common case here. The major providers now permit customer-initiated testing of their own resources within published boundaries, without individual pre-approval in most circumstances, but the boundaries are real and they specifically exclude the provider’s shared infrastructure and any denial-of-service activity. Reading the relevant provider policy during scoping takes ten minutes and prevents an awkward conversation.
The stop clause
Every engagement needs an agreed mechanism for halting immediately, and an agreed expectation about what happens if testing appears to have caused a problem. Reputable testing is careful and production incidents are uncommon, but they are not impossible — some legacy systems respond badly to entirely ordinary probing, and the systems most likely to do so are the ones most likely to be fragile in the first place. Knowing in advance who can call a halt, how they reach the tester within minutes, and who on your side investigates, converts a potential crisis into a managed pause.
Tell your monitoring provider, managed service provider or security operations centre that a test is happening, and tell them the source addresses the testing will originate from — but consider deliberately not telling them the exact timing. A test is a rare opportunity to find out whether your detection and response actually works, and that question is only answered if the team responds genuinely. What you must avoid is the opposite failure: a SOC that detects the test, treats it as a live incident, and spends a weekend on incident response for a scheduled engagement. Agreeing a code word with one named person who can confirm authorised activity resolves both problems at once.
Penetration test against vulnerability scan
These are routinely conflated, including in procurement documents and occasionally in supplier proposals. They are different exercises with different outputs and different prices, and knowing which one you are buying matters. Both have a legitimate place; the mistake is paying for one and expecting the other.
Vulnerability scan
Automated detection against a signature set
Penetration test
Human-led, scanning as one input among many
The chained-weaknesses row is where the difference becomes concrete. A scanner reports three medium-severity issues on three different hosts and rates each on its own merits. A tester notices that the first yields a set of credentials, that those credentials work on the second, and that the second has a trust relationship with a system holding the client database — and reports one critical finding describing a path from the internet to the data, with evidence. No individual link in that chain is critical in isolation, which is exactly why automated scoring misses it and why the finding is the one the board needs to see.
This distinction also matters for Cyber Essentials, where the requirement is around patching and configuration rather than a full penetration test, and where vulnerability scanning plays the assurance role. Organisations pursuing certification sometimes buy a penetration test believing it is required, or buy a scan believing it satisfies a contractual pen test obligation. We cover the boundary in our guides to vulnerability scanning and Cyber Essentials Plus and the Cyber Essentials Plus technical audit.
How ready most organisations are to be tested
A test is more useful when the organisation is prepared for it, and preparation is not the same as remediation. The grid below groups the readiness gaps we most often encounter before a first engagement. The badges reflect how much each gap degrades the value of the test, rather than how severe a security weakness it represents.
The third card is the one that determines whether the money was well spent, and it is the one almost nobody thinks about before commissioning. A report with fourteen findings and no allocated remediation capacity becomes an aging document that makes the organisation demonstrably aware of problems it has not fixed — which is a worse position, in both risk and liability terms, than not having tested. Budgeting roughly the cost of the test again for remediation effort is a crude rule that is closer to right than zero.
The report circulation item deserves a specific note. A penetration test report is a document describing exactly how to compromise your organisation, with evidence and reproduction steps. It should be handled accordingly: distributed on a need-to-know basis, stored somewhere access-controlled rather than emailed around as an attachment, and never forwarded wholesale to prospective clients or insurers who ask for evidence of testing. Where third parties need assurance, an attestation letter or summary from the testing firm is the appropriate artefact, and most will provide one on request.
Methodology — what testers work from
Competent testing follows a published methodology rather than personal preference, which is what makes results comparable between engagements and between suppliers. Most UK firms work from a recognisable combination: the OWASP testing guidance for web applications and APIs, the Penetration Testing Execution Standard or NIST guidance for infrastructure engagements, and their own accumulated internal process on top.
Findings are almost always rated using the Common Vulnerability Scoring System, which produces a numeric score and a severity band from a set of defined metrics. This matters when reading a report because it explains why a finding you consider serious might be rated medium, or vice versa. CVSS scores technical characteristics of a weakness, not its importance to your business. A medium-rated finding on the system holding your entire client database may warrant more urgency than a high-rated finding on a development server with nothing on it. Good reports account for this by adding a business-context risk rating alongside the CVSS score; when a report does not, that contextual judgement becomes your job.
On accreditation, the practical distinction in the UK is between firms operating under a formal scheme — CREST member companies, and NCSC CHECK for engagements touching government systems — and firms whose testers hold individual technical certifications without the organisational accreditation. Both can deliver good work. The difference is in assured process, quality review and recourse, and accredited engagements cost more accordingly. Which one you need is usually determined by a contractual or regulatory requirement rather than by a technical argument, and we set out the comparison in our guide to CREST against standard penetration testing.
The engagement, phase by phase
This is what actually happens, in order, on a typical UK engagement. Durations assume a combined external infrastructure and web application test for an organisation of around 150 staff.
Two things about that sequence commonly surprise first-time clients. The first is how much of the elapsed time is not testing: on a ten-day engagement, four days are reporting and debrief. The second is that the exploitation phase, which is what everyone imagines a penetration test to consist of, is a minority of the effort. Most of the work is careful enumeration and validation, because that is what produces findings you can act on rather than a list of possibilities.
What actually happens on test days
The most common question from clients preparing for a first engagement is what they will notice while it is happening. For most test types, the honest answer is very little, and the second most common question follows from that: how do we know anything is being done? Both deserve a straight answer.
External infrastructure testing
Almost invisible from inside the organisation. Traffic arrives at your internet-facing systems from the tester’s source addresses, and unless somebody is watching firewall logs there is nothing to see. Services stay up. Staff notice nothing. If you have monitoring that is working properly, it should generate alerts, and those alerts are a useful output in their own right — a test that produced no detections at all tells you something important about your visibility.
Internal infrastructure testing
More visible, because the tester is operating from inside the network, either from a device shipped to your office, a virtual machine you host, or a remote connection. Endpoint protection may flag activity. Accounts may lock out if password policies interact with testing. Administrators may see unusual authentication patterns in logs. None of this should affect users, but it is the phase where a briefed internal contact matters, because somebody will ask a question.
Web application testing
Depends heavily on whether you test production or a staging environment. Testing against production is more representative and carries a small risk of odd behaviour — test data appearing in the application, notification emails firing, records created that need cleaning up afterwards. Testing against staging is safer and only meaningful if staging genuinely matches production, which it frequently does not. Where production must be used, agreeing in advance how test data will be identified and removed avoids a tidying exercise later.
Social engineering
The only phase your general staff population experiences directly, and the one requiring the most careful handling. Agreeing in advance how results will be communicated internally matters more than the technical findings: an assessment reported as a list of individuals who failed produces defensiveness and quiet resentment, while the same data reported as an aggregate with a conversation about process improvement produces engagement. Naming individuals to management is rarely useful and frequently counterproductive.
Across all types, expect a short daily update during the testing window — typically a few lines confirming progress and flagging anything significant. If a tester goes quiet for four days and then produces a report, that is worth raising. And expect the phone to ring, outside the update rhythm, if something critical is found; a firm that sits on a critical finding until the report is delivered is handling it wrongly.
Benchmarks — engagement practice against what we see
The figures below reflect how often each practice is in place across UK organisations commissioning tests in the SME and mid-market band. They describe client-side behaviour rather than tester quality, and they are the variables clients actually control.
Client-side engagement practice in UK organisations
The shape of that list is the whole argument of this guide. Ninety-four per cent get the paperwork right, because the testing firm insists on it. Twenty-nine per cent articulate what they are worried about, twenty-four per cent plan for the remediation, twenty-one per cent verify the fixes and nineteen per cent carry the findings into anything ongoing. The engagement is executed properly and then the value leaks away at every stage where the client, rather than the supplier, holds the pen.
The most cost-effective single change in that table is the third row. Articulating specific concerns costs one conversation and materially changes what the test examines. The second most cost-effective is the last row: findings that enter a risk register get revisited, and findings that stay in a PDF do not.
The number that tells you what remediation will involve
Clients approaching a first test often brace for findings that will require new products or architectural change. The figure below is the useful corrective, and it is worth knowing before the report arrives because it shapes what capacity to set aside.
Roughly seven findings in ten are closed by doing something you already have the ability to do: applying an update, disabling a service, correcting a permission, enforcing a setting, removing an account. That is encouraging in the sense that remediation is rarely blocked by budget, and sobering in the sense that it means most of what a test finds is a consequence of operational discipline rather than of insufficient investment.
It also explains a pattern worth anticipating. Organisations that test annually without addressing why findings arise tend to receive structurally similar reports each year, with different specifics. The individual findings get fixed and the conditions that produced them persist — no patching cadence, no hardening baseline for new systems, no periodic review of accounts and permissions. A test is a measurement of those processes as much as of the systems themselves, and reading the report for its pattern rather than only its list is what breaks the cycle.
The remaining three findings in ten are where genuine investment decisions live: a legacy application that cannot be secured in its current form, an architecture that grants too much implicit trust, an authentication model that needs replacing. These are the items to take to a board, and they benefit from being separated in your remediation plan from the operational majority, because they run on project timescales rather than maintenance ones.
How to read a findings report
A report typically arrives as a single document of thirty to a hundred pages, and the instinct is to start at page one and work forward. That is the wrong order. Read it in the sequence below and it takes an hour rather than an afternoon, and produces a plan rather than an impression.
Start with the executive summary, then stop
The summary should state, in business language, the overall security position, the most serious issues, and whether the tester achieved anything significant. Read it and form an initial view. If the summary is full of technical terminology and does not tell you whether anyone could reach your data, that is a legitimate criticism of the report worth raising at the debrief.
Read the findings table next, not the detail
Most reports include a single-page table of every finding with its severity. This is the working document. Copy it out, because you are going to add columns to it: system owner, remediation action, effort estimate, target date, and whether the finding is operational or structural. The report is the input to your plan; it is not the plan.
Re-rate by business context, deliberately
Severity ratings describe technical characteristics, so go through the table and ask a different question of each finding: what would it cost this organisation if this were exploited? A medium-rated finding on the system holding client contracts may outrank a high-rated finding on an isolated test server. Write your own priority order alongside the tester’s. Where the two disagree substantially, that is a good debrief question and often reveals context the tester did not have.
Then read the detail, for the findings that matter
Now open the technical sections for your top items. Each should contain evidence, reproduction steps and specific remediation guidance. Generic guidance — “apply vendor patches”, “follow best practice” — is a sign of a weaker report, and it is reasonable to go back and ask what specifically should be changed. The value of a good report is in this specificity.
Look for the pattern, not just the list
Finally, step back and ask what the findings have in common. Several missing patches across different systems point at patching cadence. Several over-permissioned accounts point at joiner-mover-leaver process. Several exposed services point at change control. Fixing eleven findings addresses eleven symptoms; fixing the three underlying processes prevents the next eleven. This is the reading that distinguishes organisations whose reports improve year on year from those whose reports merely change.
The 12-point preparation checklist
Items one to five are completed before scoping. Items six to nine relate to the testing window. Items ten to twelve are what happens after the report and determine whether the engagement produces an improvement or a document.
- Write down your actual concerns in plain language. What you fear could happen, in business terms. This single artefact improves scope accuracy more than anything else you can prepare.
- Produce an asset list. Internet-facing IP ranges, domains and subdomains, applications, cloud tenants, and the systems holding your most sensitive data. Incomplete is fine; absent is not.
- Identify what you do not own. Anything hosted by a third party, in a colocation facility, or delivered as SaaS needs the provider’s permission or their published testing policy checked before it goes in scope.
- Decide on credentialed testing. Providing low-privilege test accounts costs nothing and typically increases findings substantially, because it examines what a compromised user could reach.
- Allocate remediation capacity and budget before the test. Roughly the cost of the test again, as a working assumption. A report with no capacity behind it creates documented awareness of unfixed problems.
- Check the window against the business calendar. Avoid month-end, year-end, a major release, a product launch or the week your one systems administrator is on leave.
- Brief your monitoring provider on scope and source addresses, and agree a verification code word. Consider withholding exact timing so detection is genuinely tested, while ensuring one named person can confirm authorised activity within minutes.
- Name an escalation contact who is actually reachable. Including out of hours, for the whole window. Verify the phone number works rather than assuming.
- Flag known-fragile legacy systems explicitly. Testers will treat them carefully if told. Nobody can be careful about a system they were not warned about.
- Attend the debrief with a decision-maker present. It is normally included in the price, it is where severity ratings can be challenged, and it is the most under-used hour in the engagement.
- Commission the verification retest. It confirms the fixes actually worked, it is a fraction of the original cost, and it produces the evidence a client, insurer or auditor will accept.
- Feed findings into a risk register and address root causes. Separate operational fixes from structural ones, and treat recurring categories as process problems rather than as a longer list of tasks.
If only three items here are completed, make them items one, five and eleven. Stating your concerns shapes the test towards what matters to you; allocating remediation capacity means the findings can actually be acted on; and the retest is what turns “we were told about some problems” into “we found problems and closed them”. Those three, together, are most of the difference between an engagement that improves your position and one that documents it.
Engagement readiness — where most organisations start
Combining the readiness areas into a single figure gives an indication of how much value an organisation is positioned to extract from a test it commissions today. The gauge reflects a first-time UK client in the 20 to 400 seat band with functioning IT and no prior testing history.
A score in the mid-thirties is composed almost entirely of the things the testing firm handles. The paperwork is right, the window is agreed, the test will be executed competently. What is missing sits on the client side: articulated concerns, a reasonable asset picture, allocated remediation capacity, a decision-maker at the debrief, and any mechanism for carrying findings forward.
The useful feature of this particular benchmark is how cheaply it moves. Nothing in the list of gaps requires expenditure. Writing down your concerns is an hour. Producing a rough asset list is a morning. Naming an owner and booking the debrief into a diary are administrative acts. An organisation that does those things before commissioning moves from the mid-thirties to somewhere in the seventies without spending anything beyond the cost of the test itself, and gets a materially more useful engagement for the same fee.
The caveat that applies generally applies here too. A small organisation with a simple estate, a clear view of what it cares about and a named person who will act on the report is in a good position regardless of how formal its processes look, and will score lower than its actual readiness. The benchmark measures the presence of practices, and practices are a proxy for the underlying capability rather than the thing itself.
Remediation, retesting and what to do with the evidence
The engagement is not finished when the report arrives. What happens over the following eight weeks determines whether the exercise changed anything, and it follows a reasonably predictable shape.
Triage in the first week
Work the findings table into a plan with owners and dates while the report is still fresh and attention is available. Anything critical or high with a straightforward fix should be closed within days, not scheduled into a quarterly cycle — the window between a weakness being documented and being fixed is a period in which the organisation knowingly carries a risk that somebody has written down. Lower-severity items can join the normal work queue, provided they genuinely do rather than disappearing into it.
Separate the operational from the structural
Roughly seven findings in ten will be closed by patching, configuration or permission changes, which belong in operational work. The remainder may require a project: replacing an authentication model, retiring a legacy application, re-architecting something that grants too much implicit trust. Mixing the two on one list guarantees that the structural items stall, because they never compete successfully against tasks that can be completed this week.
The retest
Once fixes are in place, the tester re-examines the specific findings and confirms closure, producing an updated report or an addendum. Most firms include or offer this within a defined window after the original engagement, commonly thirty to ninety days, and it usually costs a fraction of the original fee. Beyond that window it is generally priced as fresh work, which is a practical reason not to let remediation drift. The retest is also the point at which partial fixes surface — a patch applied to three of four affected systems, a permission tightened in one environment but not another.
Using the result as evidence
Clients, insurers, auditors and prospective customers increasingly ask for evidence of testing. Do not send them the report. It is a document describing how to compromise your organisation, and it should stay access-controlled and internal. What you send is an attestation letter or summary from the testing firm confirming that an engagement took place, its scope and date, and that identified issues were remediated and verified. Most firms provide this on request, and a retested engagement produces a considerably stronger letter than an untested one, which is one more reason the retest earns its cost.
On cadence, the honest position is that an annual test is a convention rather than a derived answer, and the right frequency depends on rate of change. An organisation that deploys application changes weekly and one that has not altered its infrastructure in two years do not have the same testing need, and material change — a migration, a new customer-facing application, a merger — is a better trigger than a calendar date. We work through how to set this in our guide to how often UK businesses should test, and the broader picture sits in our complete guide to penetration testing.
Common mistakes clients make
These are the client-side errors that most reduce the value of an engagement. None of them are technical, and all of them are avoidable at no cost.
- Treating scoping as administrative. Supplying IP ranges without stating what you are worried about produces a technically correct test of possibly the wrong thing. Scoping is the highest-leverage conversation in the engagement.
- Buying a scan and expecting a test. Automated scanning produces a list of possibilities; a test produces validated findings with business impact and chained attack paths. Check which one the quote describes.
- Declining credentialed testing to make the test harder. Realism is not the objective — finding what a compromised account could reach is. Blind testing spends budget rediscovering what you could have supplied.
- Not budgeting for remediation. A report with no capacity behind it leaves the organisation demonstrably aware of problems it has not fixed, which is worse in both risk and liability terms than not having tested.
- Skipping the debrief. It is normally included, it is where ratings can be challenged with business context, and it is where the findings become comprehensible to the people who authorise the spending to fix them.
- Skipping the retest. Without it you are relying on your own assertion that fixes worked. Partial remediations are common, and the retest is what produces defensible evidence.
- Circulating the report freely. It is a compromise manual for your organisation. Share the attestation letter externally and keep the report access-controlled internally.
- Fixing findings without addressing causes. Recurring categories — missing patches, over-permissioned accounts, exposed services — are process failures. Fix the process or receive a structurally identical report next year.
Be cautious about commissioning a test primarily to satisfy a contractual box rather than to find problems. The incentive that creates is to scope narrowly, which produces a clean report that is technically accurate and materially misleading — and which the organisation then relies on. If a customer contract requires annual testing, the useful response is to scope the test around your genuine risk and let it satisfy the contract as a by-product. A narrow scope chosen to produce a comfortable result is the one circumstance in which testing can leave an organisation worse off than not testing, because it manufactures confidence that is not warranted.
What this looks like in practice
A Bristol-based financial services intermediary with 85 staff commissioned its first penetration test because a corporate client had made annual testing a contractual condition. The internal view, stated candidly at the scoping call, was that this was a compliance exercise: the organisation had a managed service provider, endpoint protection, multi-factor authentication on Microsoft 365, and no history of incidents.
Scoping went further than the contract required. Asked what they would least like to happen, the operations director said that a client’s portfolio documents being readable by another client would end the business. That sentence changed the scope: the client portal, which had not been in the original quote, was added as a web application test alongside the external infrastructure work.
The external infrastructure findings were routine and largely as expected — an unpatched firewall firmware version, a management interface reachable from the internet that was supposed to be restricted, an expired certificate, and a legacy protocol still enabled on the mail gateway. Four findings, one high, three medium, all closed within eleven days by the managed service provider at no additional cost.
The portal was different. The tester found that a document reference in a URL could be altered to retrieve documents belonging to other clients, with no additional authentication. The portal checked that a user was logged in and did not check that the document requested belonged to them. It was a single finding, rated critical, notified by telephone within two hours of discovery, and it was precisely the scenario the operations director had described at scoping. The portal was taken offline that afternoon, the fix deployed by the software supplier within four days, and a retest confirmed closure eight days later.
The remediation cost was modest. The significant number was different: the portal had been live for three years, the access logs were retained for ninety days, and the organisation could not establish from the evidence available whether anyone had ever exploited it. That uncertainty required a documented assessment, a conversation with the corporate client and a decision about notification, none of which would have been necessary had the weakness been found earlier.
We went into it as a form-filling exercise for a client contract. The thing that found the real problem was not the technology and not the tester’s tooling — it was being asked, at the start, what we were actually afraid of, and answering honestly instead of giving them a list of servers. We would have passed the contractual requirement without ever putting the portal in scope.
Two points generalise. The first is that the highest-severity finding came from the system added because of a stated business concern, not from the infrastructure the organisation thought it was buying a test of. The second is the logging point: the cost of a weakness is partly determined by whether you can establish afterwards what happened. Retention long enough to answer that question is a decision made long before any test, and it interacts directly with how you have set your backup and log retention policy.
At a glance — the penetration test process
| Question | Short answer |
|---|---|
| What makes a test lawful? | Written authorisation from someone with authority over the systems. The Computer Misuse Act 1990 has no exemption for good intentions. |
| Phases in order | Scoping, rules of engagement, reconnaissance, vulnerability identification, controlled exploitation, post-exploitation and clean-up, reporting, debrief, retest |
| Typical duration | 4–6 testing days for a UK SME external and web test, plus 3–5 days reporting |
| Indicative cost range | £2,000–4,500 external infrastructure; £4,000–11,000 web application |
| Scan or test? | A scan lists possibilities automatically; a test validates them, finds chained paths and states business impact |
| Will staff notice? | External testing, almost never. Internal testing, administrators may. Social engineering, by design. |
| Should we brief our SOC? | Brief them on scope and source addresses; consider withholding exact timing so detection is genuinely tested |
| Credentialed or blind? | Credentialed almost always delivers more value; blind testing spends budget rediscovering what you could have supplied |
| Findings on a first test | Typically 2–3 rated high or critical, with patching and configuration dominating the total |
| What remediation usually involves | About 71 per cent closed by patching, configuration or permission changes rather than new technology |
| How to read the report | Executive summary, then the findings table, re-rate by business context, then detail for the top items, then look for the pattern |
| Are CVSS ratings the priority order? | No. CVSS scores technical characteristics, not importance to your business. Re-rate deliberately. |
| Retest | Confirms fixes worked, usually a fraction of the original cost, commonly within a 30–90 day window |
| What to send third parties | An attestation letter from the testing firm — never the report itself |
| How often to test | Driven by rate of change and material events rather than by the calendar; annual is a convention, not a derivation |
How Cloudswitched runs penetration testing engagements
Cloudswitched delivers penetration testing for UK organisations across external and internal infrastructure, web applications and APIs, and Microsoft 365 and cloud configuration, as CREST-accredited or standard engagements depending on what the requirement calls for. In practice the part we spend most time on is the one at the front: establishing what the organisation is actually worried about, so the scope reflects business risk rather than a list of addresses. Engagements include the rules of engagement and authorisation process, daily updates during the window, immediate notification of anything critical, a report written to be read by both technical staff and decision-makers, a debrief, and verification retesting to confirm findings are closed.
Know what a test will involve before you commission one
We scope around what matters to your business, run the engagement to a recognised methodology, and verify the fixes afterwards so you have evidence rather than a document.
Talk to a Penetration Testing SpecialistFrequently Asked Questions
What actually happens during a penetration test?
The engagement runs in a defined sequence. Scoping establishes what is in and out of scope and what you are concerned about. A rules of engagement document and written authorisation are signed, without which no testing is lawful. The tester then performs reconnaissance, gathering public information and mapping what exists within scope, followed by vulnerability identification using both automated tooling and manual inspection. Controlled exploitation attempts to confirm what is genuinely exploitable and how findings chain together. Post-exploitation assesses business impact and removes any test artefacts. Reporting takes a further three to five days, followed by a debrief meeting and, ideally, a verification retest once fixes are in place.
How long does a penetration test take?
For a typical UK SME, four to six testing days for combined external infrastructure and a web application, plus three to five working days for reporting. Individual test types vary: external infrastructure is commonly two to four days, internal infrastructure three to six, a web application or API four to ten depending on complexity, and a cloud or Microsoft 365 configuration review three to five. When comparing quotes, check whether the stated duration includes reporting, because both conventions are in use and produce figures that are not directly comparable. Add elapsed time for the debrief and for the retest window after remediation.
What do we need to prepare before a penetration test?
Five things, none of which are technical. A plain-language statement of what you are actually worried about, which shapes scope better than anything else. An asset list covering internet-facing addresses, domains and subdomains, applications and cloud tenants. Identification of anything you do not own, so third-party permissions can be checked. A decision on whether to provide low-privilege test accounts. And allocated capacity and budget for the remediation that will follow. Practically, also name an escalation contact who is genuinely reachable throughout the window, and check the dates against month-end, year-end and any planned release.
Is a penetration test legal in the UK?
Only with authorisation. The Computer Misuse Act 1990 makes unauthorised access to computer systems a criminal offence and provides no exemption for professional or well-intentioned testing. Written authorisation from someone with genuine authority over the systems is the entire legal basis on which the engagement operates, which is why no reputable UK firm begins on a verbal agreement. This becomes important where systems are not wholly yours: applications on third-party platforms, colocated infrastructure and SaaS products need the provider’s permission or their published testing policy checked during scoping, not afterwards.
Will a penetration test break our systems or disrupt the business?
Disruption is uncommon and is not impossible. Standard commercial engagements exclude denial-of-service testing and anything destructive, and testers work to avoid degrading production services. The residual risk sits with legacy systems that respond badly to ordinary probing, which is why flagging known-fragile systems during scoping genuinely matters — a tester can be careful about a system they have been warned about. Make sure the rules of engagement include an agreed mechanism for halting immediately and a contact who can reach the tester within minutes, so that if something does behave unexpectedly it becomes a managed pause rather than an incident.
Should we tell our staff and our IT provider about the test?
Brief your monitoring provider or managed service provider on the scope and the source addresses the testing will come from, and agree a code word with one named person who can confirm authorised activity. Consider not telling them the exact timing, because a test is a rare chance to find out whether detection and response genuinely work. What you must avoid is a security team treating a scheduled engagement as a live incident and spending a weekend on response. General staff normally need no notice, with the exception of social engineering assessments, where how results will be communicated internally should be agreed before the work begins.
What is the difference between a penetration test and a vulnerability scan?
A vulnerability scan is automated, takes hours, and produces a list of potential issues matched against a signature set, including false positives that nobody has validated. A penetration test is human-led over several days, uses scanning as one input, validates findings manually, establishes actual business impact, and finds chains where several individually minor weaknesses combine into a serious one. That chaining is the main added value and it is what automated scoring cannot do. Both are legitimate: scanning suits frequent ongoing hygiene monitoring, testing suits periodic assurance and major change. The mistake is buying one while expecting the other.
How many findings should we expect?
For a first engagement, expect a report containing perhaps ten to twenty findings in total, of which typically two or three are rated high or critical. Do not read a long list as a disaster or a short one as a triumph — a large share of findings on a first test are low-severity hygiene items, and the count depends heavily on scope size. Around seventy per cent will be closed by patching, configuration changes or permission tightening rather than by buying anything, which is the useful thing to know when deciding how much remediation capacity to set aside.
How should we prioritise the findings in the report?
Not purely by the severity ratings, which are usually CVSS scores describing technical characteristics rather than importance to your organisation. Take the findings table and re-rate each item by asking what it would cost this business if exploited. A medium-rated finding on the system holding client contracts can outrank a high-rated finding on an isolated development server. Then separate operational fixes, which belong in normal work, from structural items that need a project, because mixing them guarantees the structural work stalls. Where your priority order differs substantially from the tester’s, raise it at the debrief.
What is a verification retest and do we need one?
A retest is a focused re-examination of the specific findings after you have remediated them, confirming they are genuinely closed and producing an updated report or addendum. Yes, it is worth doing, for two reasons. Partial remediation is common — a patch applied to three of four affected systems, a permission corrected in one environment but not another — and without a retest you are relying on your own assertion that the fixes worked. It also produces much stronger evidence for clients, insurers and auditors. It typically costs a fraction of the original engagement and is usually offered within a thirty to ninety day window, which is a practical reason not to let remediation drift.
Can we share the penetration test report with clients or insurers?
You should not share the report itself. It is a detailed document describing how to compromise your organisation, complete with evidence and reproduction steps, and it should stay access-controlled and internal on a need-to-know basis. What you provide externally is an attestation letter or summary from the testing firm, confirming that an engagement took place, its scope and date, and that identified issues were remediated and verified. Most firms issue these on request, and an engagement that included a retest produces a considerably stronger letter than one that did not.
How often should a UK business run a penetration test?
Annual testing is a widespread convention rather than a derived answer, and the better driver is rate of change. An organisation deploying application changes weekly has a different need from one whose infrastructure has been static for two years. Material events are usually a stronger trigger than a date: a migration, a significant new customer-facing application, a merger or acquisition, a substantial change to the network, or entering a market with new regulatory requirements. Where a contract or a regulatory framework specifies a frequency, that sets a floor rather than defining what is appropriate, and the scope should still be built around genuine risk.
Related reading
More guidance on securing, testing and governing UK business IT:
A test scoped around what you actually need to know
Cloudswitched runs CREST-accredited and standard penetration testing for UK businesses across infrastructure, web applications, cloud and Microsoft 365 — with a report written to be acted on and a retest that proves the fixes landed.
Talk to a Penetration Testing Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
