An organisation’s cybersecurity does not depend solely on the number of security controls it has in place. Firewalls, endpoint protection, access controls and network monitoring solutions can significantly reduce risk, but, on their own, they don’t guarantee that an environment can withstand an attack. Organisations therefore need ways to test how their security measures perform in practice.
One of the most important tools for this type of assessment is penetration testing (pentesting). It involves controlled simulations of real-world attacks designed to identify vulnerabilities and determine whether they could be exploited to gain unauthorised access to systems, data or infrastructure.
A pentest is not the same as automated vulnerability scanning, however. One of its key benefits is that a tester can connect several seemingly minor weaknesses and assess their potential real-world impact on an organisation’s security.
What is penetration testing?
Penetration testing is a controlled and authorised simulation of a cyberattack designed to identify and practically validate vulnerabilities in systems, applications, networks and other elements of IT infrastructure.
Unlike vulnerability scanning alone, a pentest does not simply flag a configuration or component as potentially vulnerable. The tester attempts to safely establish whether and how a particular weakness could actually be exploited.
Depending on the scope, testing may cover:
- web and mobile applications,
- APIs,
- internal and external networks,
- servers and network devices,
- cloud environments,
- authentication and access control mechanisms,
- selected elements of an organisation’s infrastructure.
Pentests are carried out by specialists in offensive security, often referred to as ethical hackers. Their activities are agreed with the organisation in advance, and the scope of the test, permitted techniques and rules of engagement should be clearly defined before testing begins.
It is important to distinguish between two things: identifying a vulnerability and establishing whether it can be exploited. Automated tools can flag thousands of potential issues, but not all of them represent a genuine security threat. A pentest helps determine which weaknesses could actually lead to a security breach and what their potential impact might be.
Why should organisations carry out pentests, and what the process is?
The primary goal of penetration testing is to identify weaknesses before a real attacker can exploit them. But the aim is not simply to produce a list of vulnerabilities.
A pentest can also show whether existing security controls work as intended. An organisation may, for example, have appropriate access control rules in place, but only an attempt to bypass them can show whether they have actually been configured correctly.
Test results can help answer questions such as:
- Could an attacker gain access to a critical system?
- Could a user account be compromised?
- Could a vulnerability in one application provide access to other systems?
- Does network segmentation actually limit an attacker’s ability to move through the environment?
- Is data stored in the cloud adequately protected?
Penetration testing stages
The exact methodology will depend on the scope and type of test, but a typical penetration test involves several key stages.
1. Planning and scoping
First, the organisation defines what will be tested, which techniques are permitted and which systems are out of scope. This is also when the business objectives of the test are established, along with the rules for protecting the environment during testing.
2. Reconnaissance and information gathering
The testers gather information about the environment being tested. Depending on the type of pentest, this may include analysing available services, domains, IP addresses, technologies and publicly available information about the organisation.
3. Vulnerability identification
The next step is to look for potential weaknesses. This can involve a combination of automated tools and manual analysis.
4. Controlled exploitation
One of the defining features of a pentest is the ability to practically validate identified vulnerabilities. You have to determine whether they can be exploited within the agreed scope and rules of the test.
5. Impact and risk assessment
Not every vulnerability represents the same level of risk. You should consider factors such as whether access can be gained, the potential consequences of exploitation and the importance of the affected system.
6. Reporting
The findings are documented in a report covering the identified vulnerabilities, evidence of their existence, risk ratings and recommendations for remediation.
7. Remediation and retesting
Once vulnerabilities have been fixed or otherwise mitigated, a retest can be carried out to confirm that the issue has actually been resolved.
This final step is particularly important. A pentest should not end with the delivery of a report. Its real value comes when the findings lead to tangible actions that reduce risk.
Types of pentest: Black Box, Grey Box and White Box
One of the main ways to classify penetration tests is by the amount of information available to the tester before the procedure begins.
| Test type | Tester’s knowledge | Characteristics |
|---|---|---|
| Black Box | Little or no prior knowledge | Simulates an attack from the perspective of an external attacker |
| Grey Box | Limited knowledge | The tester is given some information about the environment |
| White Box | Full knowledge and documentation | Detailed analysis with access to relevant technical information |
Testing can also be divided into external and internal penetration tests. An external test focuses on resources accessible from outside the organisation, while an internal test can assess what an attacker could do after gaining access to the network or operating with a defined level of internal access.
There is no single best approach. The right choice depends on the objective of the test, the scope of the environment and the organisation’s risk profile.
Areas covered by penetration testing: applications, infrastructure, APIs and cloud
Penetration testing can cover a wide range of IT environments and components. The scope should reflect the organisation’s architecture and how its systems are used by employees, customers and partners.
Web and mobile applications
Application penetration testing focuses, among other things, on authentication, authorisation, session management, access controls and data handling. Many testers use the OWASP Web Security Testing Guide, an open guide to web application and web service test scenarios, as a reference point.
A tester may assess whether a user can access functions or data they should not have access to, or whether existing security controls can be bypassed.
Mobile applications introduce additional considerations, such as how data is stored on the device and how the application communicates with its backend.
APIs
APIs are increasingly becoming a critical part of application architecture. They connect systems, applications and services. As such, weaknesses in their security can lead to unauthorised access to data or functionality.
API penetration testing may cover authentication and authorisation mechanisms, access controls, input handling and the potential misuse of excessive privileges.
IT infrastructure and networks
Infrastructure penetration tests can cover both Internet-facing systems and internal environments. A tester may assess service configurations, server security, network devices, network segmentation and the potential for an attacker to move between systems.
This helps determine not only whether an individual system has a vulnerability, but also what impact exploiting it could have across the wider infrastructure.
Cloud environments
Moving to the cloud doesn’t remove the need for security testing. It does, however, change the types of risks and misconfigurations that need to be considered.
In AWS, Azure or Google Cloud environments, testing may cover areas such as:
- IAM and permissions,
- resource exposure,
- network configuration,
- storage and databases,
- access to cloud services,
- insecure resource configurations.
Cloud environments also make the shared responsibility model particularly important. The cloud provider is responsible for securing certain parts of the underlying infrastructure, but the organisation remains largely responsible for how its resources are configured and used.
Pentest, vulnerability assessment and Red Teaming: what is the difference?
The term pentest is sometimes used interchangeably with vulnerability assessment or Red Teaming. There are, however, some important differences between them.
| Approach | Main objective | Nature of the activity |
| Vulnerability Assessment | Identify and classify vulnerabilities | Primarily detection and analysis |
| Pentest | Determine whether vulnerabilities can be exploited | Controlled exploitation |
| Red Teaming | Assess an organisation’s resilience to a realistic attack | Multi-stage simulation of an attacker’s actions |
Vulnerability assessment is typically focused on identifying potential weaknesses. It can use automated scanners and other tools to analyse large environments quickly.
Pentesting takes this a step further by attempting to verify whether specific vulnerabilities can actually be exploited. This provides a better understanding of their potential real-world consequences.
Red Teaming has a broader objective. Rather than simply looking for vulnerabilities in a particular system, it simulates the actions of a real-world adversary and assesses the organisation’s ability to detect and stop an attack. Depending on the scope, this can include technical, physical and social engineering elements.
These approaches should not be seen as competing alternatives. They can complement each other as part of a broader security testing programme.
Social engineering as part of security testing
Technology is only one part of cybersecurity. In many cases, the human element can be a weak link that leads to a compromise of otherwise well-protected systems. Attackers may try to manipulate employees into revealing information, clicking a malicious link or carrying out a specific action.
Social engineering refers to techniques that exploit human behaviour rather than directly targeting a system. Phishing is one of the best-known examples.
Social engineering tests can help assess how an organisation responds to these types of attempts. However, their scope needs to be agreed particularly carefully in advance. You need to define which activities are permitted, which employees can be included in the test, and how their data and privacy will be protected.
Social engineering does not have to be part of a standard pentest. It is often carried out as a separate element of a security testing programme or as part of a broader Red Team exercise.
Penetration testing reports and vulnerability management
One of the most important outputs of a pentest is the report. It should not, however, be treated simply as a technical list of issues.
A good penetration testing report should help the organisation understand:
- what vulnerability was identified,
- which system or component it affects,
- how it was confirmed,
- how significant it is,
- what its potential impact could be,
- what action should be taken.
What to do after receiving the report?
The first step is prioritisation. Not every vulnerability requires an immediate response. Priority should be based not only on the technical classification of a vulnerability, but also on its business context.
Next, assign ownership for remediation actions and set clear deadlines. Depending on the situation, the appropriate response may be to fix the vulnerability, change a configuration, introduce an additional security control or temporarily mitigate the risk. Once the changes have been implemented, I recommend carrying out a retest to confirm that the vulnerability has actually been resolved.
If a vulnerability cannot be fixed, the organisation may also make a conscious decision to accept the risk. However, this shouldn’t happen by default or simply be left unresolved. The decision should be documented and based on a clear understanding of the potential consequences.
This is why a pentest should be treated as part of the vulnerability management process, rather than as a one-off exercise that ends when the report is delivered.
Penetration testing and cybersecurity risk management
Simply finding a vulnerability does not tell you how significant the risk is to the organisation. The same weakness can have very different implications in two different systems. A vulnerability in a publicly accessible application supporting critical business processes may represent a much greater risk than the same vulnerability in an isolated test environment.
Therefore, you should interpret the finding of a pentest in the context of:
- the criticality of the system,
- its exposure to the Internet,
- the type of data it processes,
- the potential impact on the business,
- existing security controls,
- the potential for an attacker to move further through the environment.
This approach allows you to move from asking “How many vulnerabilities were found?” to a much more useful question: “Which vulnerabilities pose the greatest risk to our organisation, and which ones should we address first?”
This is what makes penetration testing findings a valuable source of information for cybersecurity risk management. They allow you to compare formal risk assessments with the real-world potential for weaknesses to be exploited within your environment.
Penetration testing and NIS2, DORA and ISO 27001
Pentests can also help organisations meet regulatory and cybersecurity standards requirements. However, this does not mean that every organisation covered by a particular regulation needs to carry out the same type of test in the same way.
| Regulation / standard | Scope and objective | Role of penetration testing |
| NIS2 | Strengthens requirements for cybersecurity risk management and the implementation of appropriate security measures | Testing and assessing the effectiveness of security controls can form part of risk management and security control validation |
| DORA | Applies to the financial sector and focuses on the digital operational resilience of financial entities | Requires digital resilience testing, including, for certain entities, Threat-Led Penetration Testing (TLPT) based on realistic attack scenarios |
| ISO/IEC 27001 | Defines requirements for an information security management system (ISMS) | Pentesting can support the assessment of security control effectiveness and identify areas for improvement as part of the continual improvement of the ISMS |
Importantly, TLPT under DORA is a more advanced form of testing than a standard pentest. While the two approaches share some similarities, they should not be treated as interchangeable.
The key point, however, is not to treat pentesting simply as a compliance exercise. A test carried out solely to satisfy a formal requirement can deliver far less value than one designed around the organisation’s actual risk profile.
Common mistakes organisations when it comes to pentests
Carrying out a good pentest does not automatically improve an organisation’s security. Much depends on what happens with the findings afterwards. In my experience, one of the most common mistakes is treating the report as the end of the process. A report can be detailed and well prepared, but without concrete remediation actions, it does little to change the status quo.
Another issue I have encountered is a focus on the number of vulnerabilities rather than their significance. Dozens of low-impact issues are not necessarily more important than a single vulnerability that could provide access to a critical system.
Other common mistakes include:
- failing to assign owners to remediation actions,
- setting no deadlines for addressing critical vulnerabilities,
- lack of prioritisation,
- failing to carry out a retest,
- conducting tests solely for compliance purposes,
- failing to connect findings with the organisation’s risk management process,
- repeating the same testing scope despite significant changes to the environment.
The key thing to remember here is that a pentest should be the starting point for a concrete process, not the end of it.
Best practices for security testing
Having looked at the most common mistakes, I also want to look at the other side of the equation. I have seen many initiatives where penetration testing, as part of a broader security process, has helped organisations reduce their exposure to risk. Based on this experience, I have identified a few basic principles that can help ensure penetration testing delivers real value.
Define a clear objective and scope. You need to know what you want to test and why. The scope should take both technical and business considerations into account.
Choose a methodology that fits the environment. A publicly accessible web application requires a different approach from internal infrastructure, while a cloud environment brings its own considerations.
Use the right expertise. Pentesting requires technical knowledge, experience and the ability to interpret findings. Automated scanning cannot replace the manual analysis carried out by an experienced tester.
Combine different approaches to security assessment. Pentesting, vulnerability assessment, monitoring, audits and Red Teaming answer different questions. Using them together can provide a more complete picture of your security posture.
Prioritise findings based on risk. The technical severity of a vulnerability matters, but it should be considered alongside the criticality of the affected system and its potential business impact.
Respond quickly to critical issues. The most serious vulnerabilities should have clearly defined remediation actions and deadlines.
Carry out retests. Fixing a vulnerability should be verified rather than simply assumed.
Treat testing as an ongoing process. IT environments are constantly changing. New applications, integrations, users and cloud services create new attack opportunities. Regular security testing is therefore essential to keeping pace with those changes.
Conclusion
Penetration testing allows you to look at your organisation’s security from the perspective of a potential attacker. Its value, however, is not simply in finding as many vulnerabilities as possible.
A well-planned pentest helps you determine whether specific weaknesses can actually be exploited, what the consequences could be and which actions should be prioritised.
Organisations gain the most value when pentest findings are connected to vulnerability management and cybersecurity risk management. In this model, testing is not a one-off exercise or a regulatory box-ticking exercise. Instead, it becomes a valuable source of insight that helps you make better-informed security decisions.
