Insights · Buyer's guide

How to plan and buy a penetration test

A penetration test is a controlled attempt to break into your systems the way a real attacker would, to find out which weaknesses can actually be exploited. A good result depends less on the tools than on a clear scope, a tester with the right skills and a report your team can act on.

Updated: 6 November 2026

What a pentest is, and what it is not

The UK National Cyber Security Centre describes a penetration test as a way to gain assurance about a system by trying to breach it with the tools and techniques an adversary would use. It also stresses that a pentest is not the main way to find vulnerabilities. It checks the day-to-day work you already do, and it only reflects the state of your systems on the days of the test.

A vulnerability scan is different. A scanner reports individual weaknesses automatically and often produces false positives. NIST points out that scanners look at issues in isolation, while a penetration test shows how several small weaknesses combine into real risk. In practice you need both: regular scanning for breadth, and a pentest for depth.

A red team exercise is a third thing. NIST's glossary defines a red team as a group authorised to emulate the attack capabilities of a potential adversary. Such exercises usually test detection and response across people, process and technology, often without the defenders knowing. A pentest, in contrast, aims to find as many exploitable weaknesses as possible within an agreed scope.

Types of penetration tests

Pick the type from the asset you need to protect and the attacker you worry about, not from a catalogue. Most providers offer these:

• External network test: attacks your internet-facing systems such as VPN, mail and remote access.
• Internal network test: assumes an attacker already has a foothold, for example a compromised laptop, and checks how far they get, including Active Directory.
• Web application test: examines login, session handling, access control and business logic of a site or portal.
• API test: covers authentication, authorisation and data exposure of the interfaces behind web and mobile apps.
• Cloud test: reviews configuration, identity and permissions in your cloud accounts, within the rules of the cloud provider.
• Mobile app test: checks the app, its local storage and its communication with the back end.
• Social engineering test: tests people with phishing, phone calls or physical access attempts. It needs explicit management approval and clear limits.

Black, grey and white box

In a black box test the testers get little more than addresses and act like an outsider. In a white box test they receive extensive information such as architecture, internal addresses, source code or accounts. Grey box sits in between, for instance with a normal user account.

The BSI guide for IT security penetration tests generally recommends white box testing, because black box tests can miss weaknesses and cost more for the same coverage. NIST uses the terms overt and covert instead: overt tests are known to IT staff and are cheaper and more common, covert tests are known only to management and show what an attacker could really do.

Automated versus manual testing, and the role of AI

Automation is strong at breadth: finding open ports, outdated software, known misconfigurations and common web flaws quickly and repeatably. It is weak at business logic, chained attack paths and judging whether a finding really matters in your environment. The NCSC notes that pentesting cannot be entirely procedural and that quality depends heavily on the skill of the testers.

AI-assisted tooling is now part of the market. At least one major web testing vendor presents its AI offering as an extension of human-led testing, not a replacement. Ask any provider where automation and AI are used and who checks the results.

Common neutral examples of tools are Nmap for network discovery, Burp Suite for manual web testing, ZAP as a free and open source web scanner, and the Metasploit Framework, which is open source with a commercial edition, for exploitation.

Methodologies and standards to refer to

Name a methodology in your request so that results are comparable. The OWASP Web Security Testing Guide covers web applications; its latest published release is 4.2 from December 2020, and the project says version 5.0 is in development. The Penetration Testing Execution Standard describes seven stages from pre-engagement through intelligence gathering, threat modelling, vulnerability analysis, exploitation and post exploitation to reporting.

NIST SP 800-115, published in 2008 and still listed as final, describes four phases: planning, discovery, attack and reporting. In Germany, the BSI publishes a practical guide for IT security penetration tests, version 1.2 from November 2016, which covers preparation, execution, reporting and a checklist for commissioning a provider.

Scoping, report and retest

The NCSC advises involving risk owners and technical staff who know the system, sharing your latest vulnerability assessment, and writing down the test boundaries, test types, timeframe in resource days, team requirements and reporting needs. Agree rules of engagement: allowed times, forbidden techniques, emergency contacts and what happens if a serious issue is found during the test.

What drives effort is mostly size and complexity, not company size: the number of systems, applications, user roles and API endpoints, the depth of testing, the amount of information shared up front, access constraints such as out-of-hours windows and the reporting depth you ask for. Describe these clearly so quotes are comparable.

A useful report contains the following:

• A management summary in plain language with the overall risk picture.
• A description of the test object, period, conditions and limitations.
• Each finding with evidence, steps to reproduce, a rating such as high, medium, low or informational, and a concrete fix.
• Clear marking of findings that could not be confirmed.

Choosing a provider and planning the retest

Ask who exactly will do the work and what experience they have with your type of system. The BSI guide asks for independence from the tested system and its operators, a team of at least two people for a four-eyes principle, and a written contract with confidentiality and data protection rules. Individual certifications can support your judgement, for example OffSec's hands-on OSCP, whose exam is a 24-hour practical test, or the accreditation of member companies by CREST. The BSI guide itself lists BSI personnel certification, CREST and CEH as examples. A certificate shows a baseline, it does not replace references and a sample report.

Good questions to ask: How do you protect our data and your own test infrastructure? What do you do when you find a critical issue mid-test? Is a debrief and a retest part of the offer? The BSI guide recommends repeating tests every two to three years, but also after major changes it makes sense to test earlier. Fixes should be verified with a retest, and the provider should state in advance how that is handled.