Pentest: penetration testing explained, from black box to TLPT

A pentest, or penetration test, is a simulated and authorised attack on an information system, application or network, carried out to check whether its flaws can really be exploited and how far they lead. It is one of the activities of a cybersecurity audit, and the most tangible one: where a document review notes that a rule is not applied, a pentest shows what an attacker would do with it. Here are the different kinds of test, how they run, what to demand in the report, how often to test, and how the threat-led penetration test (TLPT) required by DORA takes the idea further.

Specialists, known as testers or pentesters, reproduce an attacker's techniques against a scope agreed in advance: a website, a mobile app, an IP address exposed on the internet, an internal network. Their goal is not to list every possible weakness but to demonstrate real attack paths: start from a flaw, exploit it, chain another one, and measure the impact achieved (reading data, taking over a server, obtaining an administrator account).

NIST's guide to security testing (SP 800-115) describes it as assessors mimicking real-world attacks to circumvent the security features of an application, system or network, using the tools and techniques of attackers. It is often confused with two related practices:

A pentest does not replace risk analysis: it checks protections, whereas risk analysis decides which ones are needed. But each feeds the other. A well-targeted pentest starts from the most feared scenarios, and its results correct the likelihood assumptions of the analysis.

Two questions define a penetration test: where the attacker starts and what they know at the outset.

By starting point

• External test: from the internet, against everything exposed (websites, email, remote access, firewalls). It is the view of an anonymous attacker, and the most urgent one, as ransomware entering through edge devices shows.
• Internal test: from inside the corporate network, with a workstation or a network socket. It simulates a machine compromised by phishing or a malicious insider, and measures how easily one can move on to the directory or sensitive servers.
• Application test: a web or mobile app, or an API. Testers examine authentication, permissions, session handling and injections. The OWASP testing guide, from an open foundation dedicated to application security, is the reference.
• Other scopes: wireless networks, connected devices and industrial systems, or social engineering (fake emails, phone calls) and physical intrusion, which require especially careful scoping.

Black, grey or white box

In a black box test, testers only get the target's name: realistic, but part of the time goes into discovering what you could have told them. In a grey box test, they have a user account, which lets them test what a customer or employee could do beyond their rights. In a white box test, they have the architecture, configuration and sometimes the source code: the test covers more ground in the same number of days. For a business application, grey box is often the best compromise; France's ANSSI, in its PASSI framework, requires the test mode and simulated attacker profiles to be set at scoping.

Published methods such as NIST SP 800-115 split testing into four phases: planning, discovery, attack and reporting, with loops between discovery and attack each time new access is gained. In practice, an engagement runs like this:

1. Scoping and authorisation. Exact scope (addresses, applications, accounts), exclusions, time windows, test mode, emergency contacts and safeguards for production. Nothing starts without a signed document.
2. Reconnaissance. Gathering public and technical information: subdomains, exposed services, versions, technologies, email addresses.
3. Vulnerability discovery. Automated tools and manual analysis to spot candidate flaws: outdated versions, weak settings, application logic errors.
4. Exploitation and lateral movement. Testers confirm flaws by exploiting them in a controlled way, then use each access gained to go further, up to the agreed objectives.
5. Debrief and report. Findings presented as soon as testing ends, then a written report with each flaw's severity and proposed fixes.
6. Remediation and retest. The team fixes, then the testers check that each flaw is really closed.

The administrative side of the engagement (checking the provider's suitability, contract, closing meeting, data destruction) is covered in our article on cybersecurity audits, which follows the seven steps of the PASSI framework. The diagram below shows what happens during the technical part.

Technically, a pentest and a real attack look alike. What sets them apart is authorisation. Most countries criminalise unauthorised access to computer systems. In France, accessing or remaining fraudulently in all or part of an automated data processing system carries three years' imprisonment and a €100,000 fine under Article 323-1 of the Criminal Code, and more if data is altered or operations disrupted. Article 323-3-1 also covers holding and distributing attack tools, unless there is a legitimate reason, notably research or IT security.

Hence three precautions. The authorisation must be signed by someone empowered to bind the owner of the system. It must cover systems hosted by third parties: a hosting or cloud provider often has its own rules, and testing its infrastructure without consent is a problem. Finally, any action that could cause downtime (denial of service, unstable exploits) must be expressly accepted, with a reachable contact who can stop everything.

A pentest report is read at two levels. Ask for:

• an executive summary: overall assessment, successful attack scenarios told simply, major risks, limits of the test (what was not tested and why);
• one sheet per flaw: description, affected systems, evidence (screenshots, requests), exploitation conditions, severity, recommended fix and priority;
• the attack path when several flaws were chained: the combination often creates the risk, not each flaw on its own;
• a reminder of the frame: scope, dates, test mode, accounts provided.

To rate severity, many providers use the Common Vulnerability Scoring System (CVSS), maintained by FIRST, the global forum of incident response teams. Version 4.0, published on 1 November 2023, gives a score from 0 to 10 based on ease of exploitation and technical impact. A CVSS score says nothing about your business, though: a critical flaw on an isolated test server can wait, a medium one on the payroll application cannot. Map each finding to your own scales, those of your risk matrix, to decide the order of fixes.

No law requires every company to run an annual pentest. Frequency depends on your exposure, how fast your systems change and which frameworks apply to you:

• Payment cards: PCI DSS (requirement 11.4) asks for internal and external tests at least every twelve months and after any significant infrastructure or application change, plus fixing exploitable flaws and testing again.
• Financial sector: DORA (Articles 24 and 25) requires a resilience testing programme that covers, at least once a year, all systems supporting critical or important functions; penetration tests are among the tests listed.
• NIS 2 entities: Article 21 of the directive requires policies and procedures to assess the effectiveness of cybersecurity measures. A pentest is one of the most convincing ways to meet it (see our NIS 2 article).
• ISO 27001: the standard requires managing technical vulnerabilities and security testing during development; penetration tests are common evidence for your ISMS.

Outside these frameworks, a common practice is to test exposed and critical systems every year, and to trigger a test at each significant change: new application, redesign, new remote access. Your customers may also require it: the summary of your latest penetration test is among the evidence requested in a supplier security questionnaire or a security assurance plan.

In France, ANSSI, the national cybersecurity agency, qualifies information system security audit providers (PASSI) against a public framework, version 2.2 of which dates from 1 August 2024. Penetration testing is one of five activities that can be qualified, alongside architecture, configuration and source code audits and organisational and physical audits, at a substantial or high level. A provider is only qualified for certain activities: check its scope in ANSSI's catalogue.

Qualification is only mandatory in some settings, such as inspections of French operators of vital importance. Elsewhere it remains a useful benchmark: verified skills, confidentiality rules, a controlled process. Whatever the provider, ask a few simple questions: who will the testers be, which method, what safeguards in production, how will the data collected be protected then destroyed, and is the retest included in the price?

On price, there is no public scale and the ranges that circulate online are not sourced. The cost depends on the number of testing days, which depends on scope, test mode and assurance level; our article on cybersecurity audits covers these factors.

DORA goes further for the financial entities their authority designates: at least every three years, they must run a threat-led penetration test (TLPT). Three things set it apart from a standard pentest:

• it starts from threat intelligence: a specialised provider studies the attacker groups targeting the entity and derives realistic scenarios;
• it targets production: the live systems supporting critical functions, including those run by providers;
• it tests the defence too: the red team operates for at least twelve weeks without the defenders being told, then both teams replay the attacks together.

Delegated Regulation 2025/1190 sets out the phases, and the European Central Bank aligned its TIBER-EU framework with these requirements in February 2025. Our DORA guide chapter on resilience testing and TLPT (in French) describes the full process. For most entities, though, the annual testing programme, pentests included, remains the bulk of the obligation.