Penetration testing in 2026: methods, scope, TLPT and what separates a professional from a scan

Pentest, red team, TLPT and purple team

These four terms are often used interchangeably, although they describe services with different purposes, costs and prerequisites in organisational maturity. The distinction is not academic: it decides whether the service you commission answers the question you actually have.

A pentest is a planned engagement, coordinated with the client, within a defined scope - a web application, an internal network, an Active Directory estate. The defending team usually knows it is happening, and the goal is to find and describe technical weaknesses together with the path to exploiting them. A red team engagement goes further: the offensive team plays the part of a specific adversary and uses that adversary's full repertoire, including social engineering and physical entry. The crucial difference is that the object of study stops being the infrastructure and becomes the organisation's ability to detect the attack and respond to it - which is why the defenders are usually not told.

TLPT, threat-led penetration testing, is a red team engagement wrapped in regulatory rigour. The process framework is TIBER-EU ^[4], published by the European Central Bank in 2018, and DORA ^[2] made that approach mandatory for designated financial entities. The test rests on verified intelligence about threats aimed at the particular institution, runs with the formal involvement of the supervisory authority, and ends with a defined set of reports. A purple team exercise inverts the logic of the other three: the offensive and defensive teams work together in real time, and the aim is not to surprise the defence but to improve detection. It is the cheapest way of turning the results of an earlier test into an actual change in monitoring configuration.

For most organisations a sensible order is straightforward. Local authorities and smaller public bodies can start with an external and internal pentest at a frequency derived from risk, major changes and applicable requirements. Entities covered by the Polish national cybersecurity system act may add a scope-limited red team engagement once they have monitoring worth testing. Under article 26 of DORA, TLPT at least once every three years is mandatory only for the financial entities identified by the competent authority under the applicable criteria, not for every entity within a listed financial subsector.

Methods: which framework to choose

There is no single universal pentest methodology, and no serious provider claims to use one exclusively. In practice several are combined, because each describes a different part of the work well.

The most operational is PTES ^[6], which divides a test into seven phases - from pre-engagement, through reconnaissance, threat modelling, vulnerability analysis and exploitation, to post-exploitation and reporting. Its strength is the pre-engagement phase, which covers what is most often neglected: agreeing the scope, the rules of engagement and the emergency procedure. The older OSSTMM 3 ^[7] from 2010 contributes something the others lack - a formal attack surface metric that lets successive tests be compared numerically rather than only descriptively. NIST SP 800-115 ^[8] is less detailed but carries the weight of a recognised reference and structures network testing well; it has an article of its own.

For the application layer the reference remains OWASP WSTG ^[9] version 4.2 - a checklist of web application tests organised into twelve categories, from reconnaissance and configuration, through authentication and authorisation, to business logic, the client side and APIs. Its mobile counterpart is the OWASP MASTG together with the MASVS requirements model. For regulated testing the process framework is TIBER-EU ^[4], and the CREST standard ^[10] helps verify a provider's competence.

The practical choice therefore follows the object under test rather than the provider's preference: the external attack surface is tested to PTES supplemented by WSTG, the internal network and Active Directory to PTES and NIST SP 800-115, mobile applications to MASTG, and financial sector engagements to TIBER-EU. Declaring a methodology means little if no trace of it is visible in the report.

How much should the tester know

The second axis of choice is how much information the tester is given before starting. In a black box engagement they get nothing and begin exactly where a real attacker from the internet would. That model reproduces the initial conditions of an attack most faithfully, but a substantial share of the paid time goes on reconnaissance the organisation could have supplied in an hour. In a white box engagement the tester has architecture documentation, source code and privileged accounts, which gives the highest coverage and the most findings, at the cost of realism.

In practice grey box dominates, with the tester given user accounts and basic knowledge of the architecture. That matches the most common real scenario - an adversary who has already obtained someone's credentials - and lets the budget go on checking the safeguards rather than guessing at them. The rule is simple: the more the test is meant to measure detection, the less information; the more it is meant to measure completeness of the safeguards, the more.

For a typical local authority with a few dozen workstations and a handful of servers, the sensible arrangement is grey box from the inside and black box from the internet. White box is worth reserving for bespoke applications, where the business logic and the permission model are unique and, without knowing them, the tester can only guess which transition between process steps is an abuse.

What the report has to contain

A pentest report is not a list of vulnerabilities sorted by CVSS score. It is a document written for three different readers asking three different questions.

The board needs two pages without jargon: how many attack paths lead to serious consequences, what the worst realistic scenario is, and how the organisation's overall resilience compares. The security team needs something else - a description organised by attack chains rather than by individual findings. A chain is the sequence of steps from entry point to consequence, and it is the chain that shows how three medium-severity weaknesses together produce a critical outcome that none of them produces alone. The remediation team, in turn, needs a list of items, each with a description, evidence, reproduction steps, a recommendation and a mapping to MITRE ATT&CK ^[5] and CWE.

The best test of report quality is reproducibility. "Administrative privileges were obtained" is not a finding; a finding is a timestamped sequence of commands that somebody with the right access can repeat and see the same result. A red team report adds a detection timeline - a minute-by-minute record of what the defenders noticed and what they missed. That is usually the most valuable part of the whole document, because it points at specific gaps in monitoring (see the SOC article). A TLPT report follows the structure imposed by TIBER-EU ^[4]: a threat intelligence report, a test report, a summary for the supervisory authority and a closing document with a remediation plan.

The most common mistakes

The commonest mistake is buying a vulnerability scan under the name of a pentest. Running an automated scanner and transcribing its output into a document is work worth a fraction of the price of a penetration test, and it creates a false sense of having checked. A professional test starts with threat modelling and manual verification; the scanner is a supporting tool in it, not the source of the content. Automated scanning has its own perfectly sensible role - described in the article on vulnerability scanning - but it is a complementary role, performed far more often and far more cheaply.

The second common mistake is too narrow a scope. An engagement limited to a single web application leaves out DNS, open source reconnaissance, the internal network and the employee vector. According to DBIR 2026 ^[11] the most frequent initial breach vector was exploitation of a vulnerability at 31 per cent, ahead of credential abuse at 13 per cent - precisely the areas such a scope excludes.

The third mistake concerns the provider. The job title is not a protected term in this profession, so it is worth checking certifications, accreditation ^[10] and experience in an environment resembling your own. A special case is commissioning the test from your own IT provider: it is often cheaper and more convenient, but it produces a report assessing the work of its own author, which removes the very function the test was bought for.

The remaining three mistakes concern what happens around the test. Testing production without an agreed emergency plan can take a service down - old network hardware is sometimes sensitive to traffic nobody would call an attack. A report with no retest of selected findings leaves open the question of whether the fixes worked at all. Finally, after every test it is worth checking what your own monitoring recorded of its activity and which alerts were ignored; that is the only opportunity to measure detection against an attack whose details you already know.

Legislation that requires testing

None of the instruments in force in Poland uses the word "pentest" as an obligation for organisations generally, but several require an outcome that is hard to reach without one. NIS2 ^[1], in article 21(2), lists both vulnerability handling (point e) and policies to assess the effectiveness of the measures adopted (point f) among the risk management measures; in Poland the applicable instrument is the amended national cybersecurity system act, in force in its new wording since 3 April 2026 (see the NIS2 article). The GDPR ^[12], in article 32(1)(d), requires regular testing, assessing and evaluating the effectiveness of technical and organisational measures, which covers applications processing personal data.

The most concrete requirements come from the financial sector. DORA ^[2] divides testing into two levels: a baseline digital operational resilience testing programme binding on all covered entities, and TLPT, required at least once every three years of entities designated by the competent authority - in Poland the Polish Financial Supervision Authority (see the DORA article). Beyond EU law the card industry has its own requirements: PCI DSS version 4.0 mandates penetration testing at least annually and after significant changes.

ISO/IEC 27001:2022 ^[13] is not legislation, but its annex A names controls whose demonstrated effectiveness leads straight to testing - A.5.7 on threat intelligence and A.8.29 on security testing in development and acceptance. The AI Act ^[3] forms a category of its own: article 15 requires high-risk systems to achieve an appropriate level of accuracy, robustness and cybersecurity, demonstrated among other things through adversarial testing (see the AI Act article).

Where the market is heading

The fastest growing area is testing systems built on large language models. As they move into everyday work, a class of problems has appeared that a classical pentest does not cover: prompt injection through input data, circumventing model restrictions, leakage of data from context, and abuse of the permissions granted to integrations. The AI Act ^[3] gives this work a regulatory basis for high-risk systems, but the methods here are visibly less mature than in web application testing.

The second direction is the shift from a single test to a continuous service billed by subscription, with results delivered as they are found and fed into the ticketing system. The model works well where the application changes frequently and an annual test cycle always examines an out-of-date version. It does not replace an in-depth test, though: it changes the frequency, not the depth.

The third direction is a move away from generic testing towards scenarios modelled on the adversaries genuinely interested in the organisation. In the financial sector TIBER-EU ^[4] fills that role; in other sectors the starting point is often the threat landscape analysis published by ENISA ^[14] together with the reports of CERT Polska ^[15], which describe campaigns actually observed against Polish targets.

What to settle before commissioning a test

The value of a test is decided by a dozen or so choices made before the contract is signed. It is worth working through them in this order.

Start with scope and purpose. The scope is a specific list of addresses, domains, applications, network segments and - if the test includes social engineering - groups of staff, together with an equally clear statement of what stays outside it. The purpose is often skipped, yet it shapes the whole engagement: a test meant to confirm compliance looks different from one meant to assess overall resilience, which in turn differs from an in-depth examination of a single application. The purpose determines the access model and the chosen methodology, and both decisions should leave a trace in the report.

The second group of questions concerns the provider and how the test is run. Establish the qualifications of the specific people rather than of the company, and write down the rules of engagement: testing hours, a contact reachable while they run, the escalation path and the range of permitted actions. Decide separately whether the tester may exploit the vulnerabilities found, move laterally once access is obtained, and work on real data - these are decisions of a different weight from scanning alone.

The third group concerns what is left afterwards. Beyond the report format, agree in advance whether a retest of the highest-severity findings is included in the price and within what period, and settle the confidentiality and liability terms: a non-disclosure agreement, a named responsible person on the provider's side, insurance, and a procedure for deleting the data collected during the work.