A penetration test, or pentest, is an authorised, controlled technical assessment whose goal is not merely to detect vulnerabilities, but to demonstrate whether those weaknesses can realistically be exploited, what impact they would have and what priority they deserve within the organisation's risk. That distinction is key: a scanner can flag indicators; a pentest sets out to validate real exposure, chain flaws together where appropriate and produce evidence that is genuinely useful for remediation and decision-making. This approach aligns with well-known references in offensive security such as NIST SP 800-115, the OWASP Web Security Testing Guide and PTES, which structure the work into phases, techniques and reporting criteria.
In practice, a well-scoped penetration test helps answer questions that genuinely matter to a business: whether an internet-facing application can compromise data, whether network segmentation holds up, whether a low-privilege identity can escalate, or whether a weakness in Microsoft 365, an API or a cloud environment is truly exploitable. That is why it should not be understood as a mere technical formality or an automated list of findings, but as a controlled validation of real risk. If you're after a commercial overview of the service, here is our penetration testing for businesses service. If instead you want to understand in depth what it involves, read on.
What exactly is a penetration test
A pentest is a controlled attack simulation carried out with prior authorisation, a defined scope and clear rules of engagement. The purpose is not to “break things for the sake of it”, but to check whether a flaw can translate into unauthorised access, data exfiltration, privilege escalation, lateral movement, business-logic abuse or the disruption of a critical service. NIST places penetration testing among its security testing and assessment techniques, and defines it as verifying the extent to which a system, device or process withstands active attempts to compromise its security.
This means that a serious penetration test does not stop at running tools. It combines reconnaissance, manual analysis, technical validation, the chaining of findings and controlled proof of impact. For web applications, moreover, the natural reference is usually the OWASP Web Security Testing Guide, which organises the review work around authentication, authorisation, sessions, input validation, business logic, configuration, the client side and web services.
What a penetration test is not
A penetration test does not replace a continuous security strategy, it does not replace hardening, it does not fix flaws on its own and it is not the same as a documentary audit. Nor is it the same as continuous monitoring or a SOC service. If an organisation needs a broader review of its security posture, it may be more appropriate to start with a cybersecurity audit or with a vulnerability management strategy. If what's needed is a more advanced exercise geared towards detection and response, a Red Team exercise may be a better fit.
It is also important not to confuse a pentest with automated scanning. The PCI Security Standards Council draws a clear distinction between vulnerability scanning and penetration testing, and its guidance insists that a penetration test should serve to assess real exploitability, segmentation and the effectiveness of controls, not merely to enumerate weaknesses.
What a penetration test is for in a business
The value of a penetration test lies not only in finding flaws, but in prioritising better. A business gains real value when a penetration test lets it tell the difference between theoretical problems and problems with operational impact. A misconfiguration that “looks worrying” is not the same as a weakness that actually allows an attacker to take control of a privileged account, reach a critical system or break the segmentation between environments.
That is why a well-executed pentest tends to deliver four very concrete things: credible technical evidence, business context, remediation prioritisation and traceability that is useful for audits, third parties or improvement processes. In organisations that also work under frameworks such as ISO 27001, ENS, NIS2 or DORA, that value tends to increase because security is no longer measured solely by “having controls”, but by being able to demonstrate that they are validated and improved with sound judgement. NIS2, for example, requires appropriate and proportionate cybersecurity risk-management measures; it does not prescribe a single universal control, but it does call for a technical, methodological, risk-based approach.
The most common types of penetration test
Not all pentests are the same. Choosing the right type of test is as important as executing it well.
Web penetration testing
This is the best known and one of the most in-demand. It focuses on web applications, private dashboards, customer portals, associated APIs and exposed authentication or authorisation processes. Here a serious pentester does not stop at looking for injections or XSS: they also review session flows, horizontal and vertical access control, business logic, data exposure, functional abuse and exploitation chains. The OWASP Web Security Testing Guide remains a very useful reference for structuring this work.
External network penetration testing
It starts from the internet-facing surface: VPNs, firewalls, remote services, mail, appliances or poorly hardened infrastructure. Its value lies in answering a very simple question: what an attacker can really do from outside. In many cases, combining it with an attack surface review makes a lot of sense.
Internal penetration testing
It simulates an intrusion scenario once the attacker already has a foothold inside the network or holds user credentials. Here segmentation, Active Directory, privilege hygiene, share exposure and lateral movement matter especially. Technically, it tends to be one of the most revealing tests because it reflects highly realistic scenarios: successful phishing, a compromised account or an affected endpoint.
Active Directory penetration testing
In enterprise Windows environments, Active Directory remains a critical piece. An AD pentest can reveal insecure trust relationships, excessive permissions, dangerous delegations, hash exposure and escalation paths towards critical assets.
API penetration testing
Increasingly important. APIs concentrate authentication, authorisation, third-party integration and business logic. A well-executed API pentest reviews object-level access control, resource enumeration, privilege abuse, data exposure, tokens and design flaws that rarely show up properly in superficial reviews.
Cloud penetration testing
When the focus is on Azure, AWS or hybrid environments, the work shifts towards identities, permissions, secrets, storage, public exposure, networking and escalation paths between resources. Here a combined view with cloud security for businesses or IAM and cloud posture tends to fit very well.
Microsoft 365 penetration testing
Not all M365 risk is visible configuration. A pentest can help validate real exposure across authentication, conditional access, privileges, consented apps, account abuse and vectors that link identity, mail and tenant. It tends to complement a Microsoft 365 audit and a Microsoft 365 security review very well.
Mobile and wireless penetration testing
In environments with offices, mobility or critical apps, these still make a great deal of sense. Poorly segmented or poorly secured wireless networks can open unexpected doors. And mobile apps, if they handle authentication, sensitive data or critical APIs, deserve dedicated validation.
Types of penetration test by level of information
Black box
The team starts with minimal or no information. It best simulates a pure external attacker, but tends to spend more time on reconnaissance and does not always allow maximum depth when the scope is broad.
Grey box
Some information or low-privilege credentials are provided. For many businesses, this is the most useful mode because it lets you reproduce highly likely scenarios, such as a compromised account or a supplier with partial access.
White box
A great deal of information about the environment, architecture or even the code is provided. Its aim is not so much to emulate the blind attacker as to maximise technical depth and coverage. For complex applications or critical APIs, it can be the most cost-effective approach.
The real methodology of a well-executed penetration test
This is where it pays to move beyond the superficial definition. A good penetration test is measured not just by the number of findings, but by how it was executed.
1. Pre-engagement and rules of engagement
PTES places this phase first for a reason: if the scope is poorly defined, everything else degrades. You need to agree on assets, working windows, exclusions, severity criteria, emergency contacts, exploitation limits, data handling and the acceptable level of aggressiveness. It must also be clear whether full exploitation, limited evidence extraction, pivoting or post-exploitation are permitted.
2. Reconnaissance and intelligence
An experienced pentester spends time understanding the environment before “throwing payloads”. Fingerprinting, service enumeration, technology identification, path discovery, authentication flows, API behaviour, the relationships between applications, subdomains, tenants, certificates or document exposure all form part of this phase. PTES devotes an entire phase to intelligence gathering because the quality of the reconnaissance determines the quality of the exercise.
3. Threat modelling and surface analysis
Not all assets carry the same weight, nor is every vector of equal interest. A good pentest directs effort towards the highest-risk flows: authentication, administration, access to sensitive data, external dependencies, integrations, privileges and exposed components. PTES includes threat modeling precisely to align the exercise with the relevant assets, processes and actors.
4. Vulnerability analysis
Here tools do come into play, but not as a substitute for judgement. Automated detection, manual review, configuration testing, system behaviour and hypothesis validation are all combined. For web applications, the OWASP WSTG guide remains an excellent reference for ordering this phase systematically.
5. Controlled exploitation
Exploitation is important, but it must not be confused with recklessness. The goal is not to cause harm, but to prove impact under control. Sometimes it will be enough to demonstrate access to a restricted area; on other occasions, to evidence data reads, a control bypass, a role escalation or internal pivoting. What matters is that the demonstration is sufficient to substantiate the risk without needlessly endangering operations.
6. Post-exploitation and impact validation
This is a phase that sharply distinguishes a mature pentester from a basic review. It is not enough to “get in”; you have to assess what getting in actually means. Can access be maintained? Are there opportunities for lateral movement? Can secrets, credentials or regulated data be reached? PTES explicitly includes post exploitation as part of the standard process.
7. Genuinely useful reporting
A report that merely enumerates vulnerabilities rarely helps much. A good deliverable separates the executive summary from the technical detail, includes sufficient evidence, explains the exploitation chain where there is one, puts impact into context and proposes prioritised remediation. NIST, PTES and OWASP all agree on the importance of clear, traceable and actionable documentation.
Techniques that typically appear in a serious penetration test
Without going into sensitive operational procedures, it is worth understanding that a real pentest usually works with techniques such as surface enumeration, fingerprinting, authentication analysis, horizontal and vertical authorisation testing, access-control review, parameter manipulation, session validation, the chaining of weaknesses, privilege analysis, secret-exposure testing and checks on segmentation or pivoting paths.
In web and API environments, the work is often heavily shaped by categories such as broken authentication, weak access control, cryptographic failures, insufficient input validation, data exposure or insecure configuration. In internal or AD settings, the focus shifts to trust, permissions, credentials, delegation, segmentation and lateral movement. Technique matters, but exploitation judgement and context matter even more.
When a penetration test is worth doing
A pentest makes particular sense when one or more of these conditions is met: there is an internet-facing asset with business value, a new application is about to be published, there have been significant architectural changes, sensitive data is handled, a relevant audit is under way, a client requires it, you want to validate a remediation, or you suspect that the real exposure is greater than it appears.
It also tends to be very useful after a major identity or cloud rollout, after hardening an environment, ahead of a third-party approval process, or as validation of risks that a previous audit left open. If you need a broader view of the security context, this guide on what services a cybersecurity company should offer in 2026 may also help.
When a penetration test is not enough
A pentest should not be used as a patch for strategy. If an organisation has no inventory, does not manage vulnerabilities, does not review identities, does not monitor exposure and lacks a minimum security baseline, a pentest will be useful, yes, but not sufficient. In those cases it usually makes more sense to combine it with vulnerability management, a review of cloud security, Microsoft 365 security or even a cybersecurity consultancy to prioritise correctly.
Is a penetration test mandatory? Regulation, certifications and real requirements
Here it pays to be very precise, because in cybersecurity and compliance it is easy to oversimplify. A penetration test can be a very valuable measure, even decisive in some contexts, but not every framework requires it in the same way or to the same level of detail.
PCI DSS
In environments where cardholder data is processed, stored or transmitted, PCI DSS gives clear weight to penetration testing and, moreover, expressly distinguishes between vulnerability scans and penetration testing. In practice, PCI DSS is one of the frameworks where penetration testing appears most clearly and in the most structured way as part of the technical validation model. The PCI SSC guidance also highlights its usefulness for verifying that segmentation correctly isolates the cardholder data environment.
DORA
In the financial sector, DORA raises the bar considerably on digital resilience testing. It does not mean that every entity has to carry out exactly the same generic pentest, but the regulation does drive a risk-based testing programme and, for certain entities, provides for advanced exercises of threat-led penetration testing (TLPT). Furthermore, Commission Delegated Regulation (EU) 2025/1190 develops the criteria for identifying entities required to undergo TLPT and the methodological and execution requirements, expressly stating that it has been drawn up in accordance with the TIBER-EU framework.
NIS2
NIS2 requires appropriate and proportionate cybersecurity risk-management measures, and its recent technical development sets out methodological and technical requirements for certain categories of entities. But it does not establish an identical, universal obligation to “run a generic pentest” for every organisation in all cases. For many entities subject to NIS2, a penetration test will be a very reasonable and even expected measure, but it should be framed as part of a risk-based approach rather than as an automatic, oversimplified slogan.
ISO 27001 and ENS
In ISO 27001 and ENS, a pentest usually fits as a very useful technical-validation practice depending on scope, criticality, exposure and audit context, but it should not be presented as an identical, universal obligation in every case. The right approach is to assess it according to risk, environment, assets and client or sector requirements.
AEO and international logistics
In the case of AEO (Authorised Economic Operator), the most accurate statement is not that there is a universal, literal obligation to “do penetration testing”, but that the programme requires security and protection criteria, risk control and appropriate measures within the supply chain. The European Commission's official AEO documentation and its management guidelines cover threats, risks and possible solutions, and point to the use of risk-assessment models such as AEO COMPACT. In that context, a penetration test can be very useful technical evidence for demonstrating the robustness of systems, the security of interconnections and due diligence in protecting logistics, customs and critical information-exchange processes, especially where there are portals, integrations, remote access or systems shared with third parties. In short, although the regulations do not always explicitly mention the word "penetration testing" as a single requirement, it is the usual way of meeting the IT security requirements needed for validation.
CTPAT and the international supply chain
Something similar happens with CTPAT in the United States. The official CBP source requires compliance with the Minimum Security Criteria and the maintenance of a documented security programme, and within that framework the cybersecurity and systems-protection component is increasingly relevant. As with AEO, the prudent approach is not to sell it as a universal obligation of “mandatory pentesting in every case”, but rather as a highly advisable measure for logistics and transport organisations that need to demonstrate maturity, risk analysis and technical control over interconnected systems.
Penetration testing, auditing, Red Team and vulnerability management: the real differences
One of the most common confusions is lumping everything together. A penetration test validates real exploitability and technical impact. An audit usually takes a broader view of controls, configuration, process and posture. A Red Team exercise seeks to emulate an adversary more realistically, so as to also test detection and response capability. And vulnerability management aims for continuity: discovering, prioritising and reducing exposure on a recurring basis. If you want to see the comparison in more concrete terms, we've already explained the difference between a security audit and penetration testing, and here what vulnerability management really involves.
Common mistakes when commissioning a penetration test
One of the most frequent mistakes is asking for “a pentest” without properly defining the objective. Another is thinking that the more aggressive the exercise appears, the better it will be. It is also a mistake to choose on price alone, to confuse scanning with manual validation, to set aside no time for remediation and to fail to insist on a report that helps you make decisions.
Nor should quality be measured by the number of vulnerabilities found. A good pentest may identify few findings and still be extremely valuable if it demonstrates high-impact risks or confirms that an architecture holds up well. What matters is not padding the report, but that the work helps reduce real risk.
What a good penetration test report should include
A useful deliverable should include the scope, the methodology used, assumptions, limitations, an executive summary, technical detail, sufficient evidence, an impact assessment, prioritisation, concrete recommendations and, where possible, guidance for a retest. If the exercise was web, API, internal or AD, that context should be reflected clearly. And if exploitation chains have been found, they should be explained well, because a chain usually matters far more than an isolated finding.
Conclusion
A penetration test is neither a formality nor a fad. Well executed, it is an extremely powerful tool for separating noise from real risk, validating exposure, prioritising remediation and supporting technical and business decisions. But its value depends on three things: choosing the scope well, applying it with methodology and expert judgement and using the results to genuinely fix things.
That is why, before commissioning one, it pays to be clear about what you want to validate: a web application, an API, an internal environment, Microsoft 365, Active Directory, cloud, an exposed surface or a specific client, audit or regulatory requirement. And if what you need is not just to “run a pentest”, but to fit it within a broader security and compliance strategy, that is where much more value is gained.
If you want to validate your organisation's exposure realistically, at Hard2bit we carry out penetration testing for businesses, ethical hacking, Red Team exercises and technical assessments aligned with business needs, remediation and audit requirements.
And if, before considering a penetration test, you would rather get a better understanding of your current situation, we can also help you with a cybersecurity audit, a review of Microsoft 365 security, cloud security for businesses or an ongoing approach to vulnerability management.
If you'd like to assess which type of test makes sense in your case, you can contact Hard2bit.