A pentest, short for penetration test, is an authorised simulated attack on a system, application or network. Security professionals act, in a controlled way, as an attacker would, to find weaknesses before a real attacker does. The aim is not to cause damage or to show off clever tricks. It is to answer a practical question: if someone tried to break in, what would they actually be able to reach?
This guide explains what a pentest is, how it differs from a vulnerability scan, the main types of testing, the usual phases, and what a good report should give you. It is written for buyers and decision-makers, not for people learning how to attack systems.
What Is a Pentest?
In a pentest, testers use the access and information agreed in advance to probe defences. They may test a website, a network, a wireless network, a cloud account, or the way staff respond to a deceptive message. The test is planned, time-limited and carefully scoped, so the organisation knows what will be tested, what is off limits, and what should happen if something goes wrong.
A useful pentest therefore tests more than software. It also tests configuration, access controls and human processes. A strong password policy is of little help if an old account still works, a cloud storage setting is public, or a helpful employee shares a code that should stay private. The value lies in seeing how those weaknesses combine in practice.
Pentest vs Vulnerability Scan: Depth vs Breadth
A vulnerability scan and a pentest are related, but they are not the same thing. A scan is usually automated. It checks systems against a list of known weaknesses and produces a list of possible issues. That breadth is useful for regular hygiene, because it can cover many systems quickly and repeat the same checks over time.
A pentest goes deeper. A human tester follows up on findings, checks whether they are real, and tries, within the agreed rules, to see what an attacker could do next. A scan may flag a possible weakness; a pentest can show whether it leads to real access, to sensitive data, or only to a dead end. That distinction matters when you must decide what to fix first.
| Approach | What it does | Best for |
|---|---|---|
| Vulnerability scan | Automated check for known weaknesses across many systems | Regular, broad coverage |
| Pentest | Human testing of whether weaknesses can actually be used | Depth, realism and prioritised risk |
Most mature organisations use both. Scans provide frequent breadth, while a pentest provides periodic depth. Neither, on its own, proves that a system is secure. A clean scan can still miss a logic flaw in an application, and a pentest covers only the systems and time period in its scope.
Types of Pentest
The right type depends on what you need to protect and where the greatest risk sits.
External network pentest
An external test looks at systems that are reachable from the internet, such as websites, email gateways and remote-access services. It asks how far an outsider with no internal access could get, and which internet-facing weaknesses matter most.
Internal network pentest
An internal test assumes some access inside the network, for example from an office computer or a compromised account. It checks whether access can be widened, whether sensitive systems are properly separated, and whether internal controls rely too much on the outer boundary.
Web application pentest
A web application test focuses on how an application handles logins, sessions, user input, permissions and data. Many serious issues are not in the underlying server, but in the way the application itself decides who may see or change something.
Wireless pentest
A wireless test examines Wi-Fi networks and their configuration. It looks at whether an attacker nearby could join the network, intercept traffic, or use a poorly configured access point as a way into the wider organisation.
Social engineering pentest
A social engineering test, agreed in advance, checks how people respond to deceptive messages or requests. It is not about blaming staff. It shows whether training, reporting routes and verification steps work when someone is under pressure or in a hurry.
Cloud Pentest
A cloud pentest tests cloud accounts, services and configurations, rather than only traditional servers. Testers may review who can access cloud resources, how identities and permissions are set up, whether storage or databases are exposed, and whether logging would reveal suspicious activity.
Cloud testing needs extra care, because the environment is shared with the provider. Cloud providers have their own rules for what may be tested, and those rules must be checked before testing begins. Testing must stay within the agreed cloud scope and must not disrupt other customers or provider services.
A cloud pentest is especially useful after a migration or a major redesign. Misconfiguration, overly broad permissions and forgotten test accounts are common cloud risks, and they are often invisible in a simple checklist. A practical test shows which of those issues an attacker could actually use.
The Phases of a Pentest
Although every provider works a little differently, most pentests follow a similar pattern.
- Planning and scoping. The organisation and tester agree on targets, limits, timing, contacts and what must not be touched.
- Reconnaissance. Testers gather publicly available and agreed information about the target to understand its shape and exposure.
- Exploitation attempts. Within the agreed rules, testers try to use weaknesses to gain further access and judge their real impact.
- Reporting. Findings are explained in business terms, with evidence, risk ratings and clear fixes in priority order.
- Retest. After fixes are made, the most important findings are checked again to confirm that they are actually closed.
That final step is often skipped, and it should not be. A fix that looks right in a ticket may not work in practice, and a retest is the simplest way to prove that the risk has fallen.
Black Box, Grey Box and White Box Testing
These terms describe how much information the tester is given at the start. In a black box test, the tester starts with little or no inside information, much like an external attacker. It is realistic, but it can take longer and may miss issues hidden deep inside a system.
In a white box test, the tester is given detailed information, such as designs, source code or administrative access. This is more thorough and efficient, because the tester can focus on the most important areas rather than spending time on discovery.
A grey box test sits between the two. The tester receives some information, such as a normal user account, but not full internal access. Many organisations choose this balance, because it is realistic enough to be useful while still making good use of limited testing time.
What a Good Pentest Report Contains
A good report is not just a list of technical flaws. It should start with a clear summary for decision-makers: what was tested, what was not tested, the most serious risks, and what to do first. Each finding should explain what was found, why it matters, how serious it is, and how to fix it.
It should also be honest about limits. A pentest cannot prove that no weaknesses remain, and it cannot cover every system at every moment. A report that claims otherwise should be treated with caution. Evidence, careful risk ratings and a sensible order of fixes are worth more than a long list of low-risk issues.
Rules of Engagement and Why Written Authorisation Matters
Before any testing starts, the rules of engagement must be written down and signed. These cover the systems in scope, the methods allowed, the times testing may happen, who to contact in an emergency, and how sensitive data must be handled. If a tester finds a serious issue, there must also be an agreed way to report it immediately, rather than waiting for the final report.
Written authorisation matters because a pentest without permission is illegal. The same activity that is lawful and useful when authorised becomes an offence when it is not. Any reputable provider will insist on clear written permission, and any organisation should insist on it too. Do not accept a test that starts with a handshake alone.
How Often Should You Test?
There is no single answer that fits every organisation. As a general guide, many organisations test at least once a year, and more often after a major change, a new application launch, a merger, or a serious incident. Systems that hold sensitive data or face the internet usually deserve more frequent attention than low-risk internal tools.
Regular vulnerability scanning should sit between pentests, so that new issues are not left until the next annual test. The right rhythm depends on risk, change and regulation, but the principle is simple: test when the risk has changed, not only when the calendar says so.
Conclusion
A pentest is a practical, authorised way to learn how your defences behave under pressure. It complements scanning, covers networks, applications, people and cloud services, and turns technical findings into decisions about what to fix first. Done properly, with clear scope and written permission, it gives leaders evidence they can act on, rather than reassurance they cannot test.
Frequently Asked Questions
What is a pentest in simple terms?
A pentest is an authorised simulated attack by security professionals. They test systems, applications and networks, within agreed rules, to find weaknesses before real attackers do.
Is a pentest the same as a vulnerability scan?
No. A vulnerability scan is an automated listing of possible known weaknesses. A pentest uses human testing to check whether those weaknesses can actually be used and what damage they could cause.
What is the difference between black box, grey box and white box testing?
Black box testing starts with little inside information, white box testing uses detailed internal information, and grey box testing uses partial information, such as a normal user account.
Can a cloud pentest be done without the provider’s permission?
No. Cloud providers have their own rules for what may be tested, and testing must stay within the agreed scope. Check those rules and obtain written authorisation before any cloud testing begins.
Does a clean pentest mean a system is secure?
No. A pentest covers an agreed scope at a particular time. It reduces risk and highlights priorities, but it cannot prove that no other weaknesses exist or will appear later.
