- A penetration test simulates a real attacker; a vulnerability scan only identifies known weaknesses
- External network tests are the most common starting point for businesses new to security testing
- Pen tests are required by ISO 27001, NIS2 (Article 21, measure 6), PCI DSS, and Cyber Essentials Plus
- A test report is only useful if you act on the findings within a defined remediation window
- Retesting after remediation confirms the fix worked; skipping it leaves the risk unresolved
What penetration testing actually is
A penetration test is a structured, authorised attempt to compromise your systems, applications, or people using the same techniques a real attacker would use. A qualified tester (or a team of them) is given a defined scope and objective, then works to breach it, document every step, and report on what they found. The output is not a list of theoretical risks. It is evidence of what an actual attacker could do to your business today.
The word "penetration" refers to penetrating your defences, not poking at them. A penetration tester does not stop when they find a weakness. They attempt to exploit it, escalate privileges, move laterally through your network, and reach the most valuable systems or data they can access. The test stops when the agreed scope is exhausted or a critical finding warrants immediate disclosure to the client.
Penetration testing differs from other security checks because it combines technical expertise, creative problem-solving, and an adversarial mindset that automated tools cannot replicate. The tester's question is concrete: if I were genuinely trying to cause harm here, how far could I get? A rigorous answer to that question is the value of the engagement.
The difference between a pen test and a vulnerability scan
These two terms are frequently confused, and the confusion matters because they produce very different outputs. A vulnerability scan is an automated process: a tool checks your systems against a database of known weaknesses, configuration errors, and outdated software versions. It generates a list of potential issues ranked by severity. The scan does not attempt to exploit anything. It does not tell you whether a vulnerability is actually reachable by an attacker, whether it can be chained with other weaknesses, or what an attacker could do with it if they succeeded.
A penetration test begins where a vulnerability scan ends. The tester reviews the landscape of potential weaknesses and then actively attempts exploitation. They look for combinations: a medium-severity configuration error that, paired with a credential from a phishing simulation, grants access to a finance system. No automated scanner catches that chain. A skilled tester does. Penetration tests regularly surface findings that surprise organisations already running vulnerability scans: the scan listed the pieces; the tester showed what an attacker could build from them.
Running automated scans continuously gives you an ongoing view of known weaknesses across your estate. Penetration testing, periodic and manually intensive, shows what an attacker can actually do with them. You need both, and neither substitutes for the other.
Black-box testing means the tester begins with no prior knowledge of your systems, simulating an external attacker who knows only what is publicly available. It produces realistic findings about what an outsider could achieve, but it takes longer and may miss internal weaknesses.
Grey-box testing gives the tester partial information, such as user-level credentials or network diagrams, simulating a compromised employee or a contractor account. This is the most common approach because it balances realism with efficiency.
White-box testing provides full access to architecture documentation, source code, and system credentials. It is the most thorough approach for uncovering deep technical vulnerabilities and is commonly used for application security reviews before a product launch.
Types of penetration test
Penetration tests are not one-size-fits-all. The appropriate type depends on where your greatest exposure lies and what your compliance obligations require. Most businesses begin with one type and expand their testing programme as their security maturity grows.
External network penetration testing
This is the most common starting point and tests everything exposed to the public internet: your firewalls, VPN gateways, email servers, web-facing services, and any other systems reachable from outside your network. The tester works from outside your perimeter, exactly as a remote attacker would. Findings typically include misconfigured services, exposed administrative interfaces, outdated software with known exploits, and weak authentication on remote access systems.
External network testing is the baseline for most compliance frameworks and is the right first test for organisations new to security testing. It answers the most pressing question: can an attacker get in from the internet?
Web application penetration testing
If your business runs a customer portal, an internal application, an e-commerce platform, or any web-based service, that application deserves its own dedicated test. Web application testing follows the OWASP methodology, checking for injection vulnerabilities (SQL, command, LDAP), broken authentication, insecure direct object references, security misconfiguration, cross-site scripting, and a range of business logic flaws that automated scanners consistently miss.
Business logic flaws deserve special mention. These are vulnerabilities specific to how your application works, such as a checkout flow that can be manipulated to apply unlimited discounts, or an account management function that lets users view other customers' data by changing a URL parameter. No scanner finds these. They require a tester who understands your application's intended behaviour and probes for deviations from it.
Social engineering testing
Technical defences only matter if they cannot be bypassed by manipulating your staff. Social engineering tests assess whether employees can be deceived into revealing credentials, clicking malicious links, or granting physical access to unauthorised individuals. Phishing simulations are the most common format: a carefully crafted email campaign mimics a real attack to measure click rates, credential submission rates, and how quickly the security team detects and reports the campaign.
Spear-phishing tests target specific individuals, typically finance staff, executives, or IT administrators, with personalised content that references real details about the target or their organisation. These tests are consistently humbling. Organisations with strong technical security often discover that a convincing email to one person is all an attacker needs.
Physical penetration testing
Physical testing assesses whether an attacker could gain unauthorised access to your premises, server rooms, or workstations by physically entering your building. Testers attempt to tailgate employees through secure doors, impersonate couriers or IT contractors, or access unlocked workstations in common areas. Physical tests are less common but critical for organisations handling sensitive data on-site, including healthcare providers, financial institutions, and data centre operators.
Physical tests often reveal that technical security is rendered irrelevant by a propped fire door or a receptionist who waves visitors through without checking credentials. The combination of physical and technical access is particularly dangerous: an attacker who reaches an unattended workstation inside your office has effectively bypassed your entire network perimeter.
When your business needs one
The honest answer is: sooner than most businesses think. Many organisations wait until a compliance audit or a near-miss incident forces the issue. By that point, the findings are rarely limited to minor configuration errors. The more useful framing is to treat penetration testing as a periodic health check rather than a reactive measure triggered by external pressure.
There are specific circumstances that create a clear need for testing. If your business processes card payments, PCI DSS requires at least annual external and internal network penetration tests, plus application tests following any significant changes. If you fall within NIS2 scope (see our NIS2 guide for a full explanation of scope), Article 21 measure 6 explicitly requires policies to assess the effectiveness of your cybersecurity measures through regular testing. ISO 27001 Annex A.8.8 and A.5.36 both point to regular testing of security controls as a requirement for certification. Cyber Essentials Plus, the UK government's flagship certification, includes a vulnerability assessment component that goes beyond the basic Cyber Essentials questionnaire.
A penetration test is not evidence that you are secure. It is evidence of exactly how far an attacker can get today, which is the only starting point for meaningful improvement.
Beyond compliance, a penetration test is warranted before launching a new application or service to the public, after a significant infrastructure change or cloud migration, following a security incident to confirm that the attacker's route has been fully closed, and after any merger or acquisition that brings new systems into your environment. New systems carry unknown histories and inherited vulnerabilities. Testing them before integrating them fully is considerably cheaper than discovering a problem after the fact.
What happens during a penetration test
Most professional penetration tests follow a structured methodology, regardless of the provider. Understanding the phases helps you prepare your team and set realistic expectations for what you will receive at the end.
Scoping. Before any testing begins, you agree on exactly what is in scope (which systems, applications, or locations can be tested), what is explicitly out of scope, the testing window, and the rules of engagement. This includes whether you want your IT team to be aware of the test (overt) or kept in the dark to also assess your detection capability (covert). Everything agreed here becomes the contract that governs the engagement.
Reconnaissance. The tester gathers as much information as possible about the target before touching it. For an external network test, this means DNS enumeration, certificate transparency log analysis, OSINT on your organisation and employees, and identifying all internet-facing assets. This phase often surprises clients: testers frequently find forgotten subdomains, exposed development environments, or employee credentials published in data breach dumps before a single packet has been sent to the target.
Exploitation. Using the intelligence gathered, the tester actively attempts to breach the agreed scope. This is the phase most people picture: running exploits, attempting authentication bypass, and testing for injection vulnerabilities. A skilled tester documents every step they take, every command they run, and every finding they make. This documentation is what makes the final report credible and actionable.
Post-exploitation. Once initial access is achieved, the tester explores how far they can go. Can they escalate from a standard user account to a domain administrator? Can they move from one network segment to another? Can they reach sensitive data stores or backup systems? Post-exploitation maps the full blast radius of the initial compromise and is often where the most significant findings emerge.
Reporting. The test concludes with a detailed report covering an executive summary (designed for non-technical readers), a technical findings section with full evidence for each vulnerability, a risk rating for each finding, and specific remediation guidance. A good report does not just list what is broken. It explains the business impact in terms a board member can understand, and it tells your team exactly what to do to fix each issue.
What to do with the results
Receiving a penetration test report is not the end of the process. It is the beginning of the more important half. A report that sits unread in a shared drive for six months is worse than no report at all: you now have documented evidence that known vulnerabilities exist in your environment, which can be used against you in the event of a breach.
Start by triaging the findings. Critical and high-severity issues should be assigned to a named owner and a remediation deadline within 24 to 48 hours of receiving the report. These are the vulnerabilities an attacker could use to cause material damage quickly. Medium and low findings can follow a longer remediation window, but they should be tracked in your risk register with clear ownership and target dates, not left to drift.
Remediation is only complete once it has been verified. A finding marked "fixed" without verification is an assumption, not a fact. The correct process is to remediate the issue, confirm the fix internally, and then request a retest from the original testing team. A retest is typically scoped narrowly to the specific vulnerabilities addressed and costs considerably less than the original engagement. Skipping the retest is a common shortcut that leaves organisations uncertain whether their fixes actually worked.
Finally, use the report as an input to your broader security strategy. Penetration tests reveal patterns, not just individual findings. If multiple findings relate to patch management, that points to a process failure. If several vulnerabilities were found on systems that your team did not know were internet-facing, that points to an asset discovery gap. Addressing root causes prevents the same class of finding appearing in next year's report.
The CREST international accreditation body certifies penetration testing providers and individual testers, and maintains a searchable directory of approved companies. The NCSC publishes guidance on commissioning and scoping external security assessments for organisations unfamiliar with the process.