You have met the attacks — brute force, denial-of-service, SQL injection and more. A natural question follows: how does an organisation find out whether its own systems can survive those attacks — before a real criminal comes knocking? The answer is penetration testing (usually shortened to pen testing).
A penetration test is authorised, ethical hacking. Security professionals are invited to attack a system — deliberately, using the same techniques a criminal would — but with one enormous difference: they have written permission, they stay inside an agreed scope, and their goal is to find weaknesses and report them so they can be fixed, not to steal or destroy. A pen tester is often called an ethical hacker or a white-hat.
Think of a bank hiring a professional burglar to try to break into its own vault. The burglar tries every trick — picking locks, testing alarms, spotting the unlocked back door — and then hands the bank a report: "here is exactly how I got in, and here is how to stop the next person." Nothing is stolen. The bank is stronger afterwards. That is a pen test.
Real attackers will not warn you before they strike, and they only need to find one weakness. Defenders have to find and fix all of them. A pen test tips that unfair balance back towards the defender: it puts a skilled, motivated attacker on your side, working to a deadline, whose job is to tell you the bad news while there is still time to act.
It is the difference between waiting to find out your smoke alarm is broken during a real fire, and testing it on a quiet Sunday afternoon. Organisations pen-test before launching a new website, after a big change, and regularly on critical systems, precisely because a weakness you know about is one you can fix.
These nicknames come from old cowboy films, where the hero wore a white hat and the villain a black one.
How much should the tester be told before they start? There are two ends of a spectrum, and the choice changes what the test discovers.
In a black-box test, the tester is given almost nothing — just a target, such as a web address. They know no more than a real outside attacker would, so they must do all their own reconnaissance. This is the most realistic simulation of an external criminal, and it is good at answering "what could a stranger on the internet do to us?" Its weakness is time: the tester may spend most of the engagement simply finding the system's shape, and may never reach a flaw that inside knowledge would have exposed at once.
In a white-box test (sometimes "clear-box"), the tester is given inside knowledge — network diagrams, source code, user accounts, documentation. Nothing is hidden. This is far more thorough: with the blueprints in hand the tester can examine every corner and is good at answering "what could a knowledgeable insider, or an attacker who has already gained a foothold, do?" Its weakness is realism — a real outsider would not start with the blueprints.
A grey-box test sits between the two: the tester gets some information, such as a standard user login, balancing realism against thoroughness. Neither extreme is "best"; an organisation picks the mix that matches the question it most wants answered.
However much the tester is told, a real engagement follows a recognisable rhythm. You do not need the fine detail for A-level, but you should know the shape of it — four conceptual phases that loop back into a cycle of continual improvement. Step through the diagram:
Gathering information about the target — what systems exist, what technologies they use, which services are exposed, even which staff might be targeted by social engineering. In a black-box test this is where most of the early effort goes; in a white-box test much of it is simply handed over.
Probing the target more actively to map out its structure and spot potential weaknesses — which network ports are open, what software versions are running, where known vulnerabilities might lie. Reconnaissance asks "what is out there?"; scanning asks "which of these looks weak?"
Attempting to actually use a weakness to gain access — carefully, within scope, to prove the weakness is real rather than merely theoretical. A responsible tester demonstrates the risk (for example, that they could reach sensitive data) without causing damage, deleting data, or disrupting the live service.
The most important phase of all. The tester writes up every weakness found, how serious each one is, how it was reached, and — crucially — how to fix it. A pen test that finds ten flaws but explains none of them is worthless; the whole point is to leave the organisation able to improve. The findings then feed back into fixes, and later into the next test — hence the cycle.
Automated vulnerability scanners are a genuine tool — they are fast and check for thousands of known issues — but a pen test is more than that. A scanner reports what might be a weakness; a skilled human tester chains findings together, understands the business context (which data actually matters?), spots flaws in logic that no scanner recognises, and confirms which weaknesses are genuinely exploitable. The scanner is one instrument in the tester's toolkit, not a replacement for the tester.
Here is the point that matters most, and it is a legal one, not a technical one. Every technique a pen tester uses is identical to what a criminal does. The only thing that separates ethical hacking from a crime is permission.
In the UK, accessing a computer system without authorisation is an offence under the Computer Misuse Act 1990. It does not matter that you meant well, that you caused no damage, or that you reported what you found — accessing a system you have no permission to access is already the crime. So before any real test begins, the tester and the organisation agree, in writing:
This paperwork is not bureaucracy for its own sake — it is the entire legal foundation of the work. Without it, the most careful, well-meaning "test" in the world is simply hacking.
Penetration testing is legal only with explicit written permission and an agreed scope. The exact same actions — scanning a server, probing for weaknesses, trying to log in — are a crime under the Computer Misuse Act 1990 when done without authorisation. Intentions do not count and "no harm done" is no defence: it is the permission, not the outcome, that makes it lawful.
Never test a system you do not own and have not been given clear, written permission to test — not a friend's website, not your school's network, not a company you admire. And stay strictly inside the agreed scope: the goal of a pen test is always to improve security, never to cause harm.
Penetration testing turns the attacker's own methods into a defence. A trusted professional, with written permission and an agreed scope, works through reconnaissance → scanning → exploitation → reporting to find weaknesses before a criminal does. Whether they work black-box (like an outsider, most realistic) or white-box (with inside knowledge, most thorough), the aim never changes: hand the organisation an honest list of its weaknesses and how to close them, so that every test leaves the system stronger than before.