How a Penetration Test Actually Works, Start to Finish

Movies show hacking as a frantic few minutes of typing followed by “I’m in.” Real penetration testing is slower, more methodical, and involves a surprising amount of paperwork. That structure is not bureaucracy for its own sake; it’s what makes the work legal, repeatable, and useful to the client.

A penetration test (or “pentest”) is a simulated attack on an organisation’s systems, carried out by professionals with permission, to find weaknesses before real attackers do. Here’s what one looks like from the inside, broken into the phases nearly every tester follows.

Phase 0: Scoping and authorisation

Before a single packet is sent, the tester and the client agree on exactly what will be tested. This produces a scoping document and a signed authorisation, sometimes nicknamed the “get out of jail free card.” It answers questions like:

•             Which systems are in scope? Specific IP ranges, domain names, applications, or physical offices.

•             What’s explicitly out of scope? Perhaps a fragile production database or a third-party service the client doesn’t own.

•             When can testing happen? Some clients only allow it outside business hours.

•             How aggressive can the tester be? Is a denial-of-service test acceptable? Can they attempt to phish employees?

•             Who do they call if something breaks?

Testers also agree on the type of test. In a black box test, the tester knows almost nothing, simulating an outside attacker. In a white box test, they get full documentation, source code, and credentials, allowing a deeper review. Grey box sits in between and is the most common in practice.

This phase is unglamorous, but skipping or fudging it is how testers end up in court. Everything that follows is only legal because of this agreement.

Phase 1: Reconnaissance

Now the tester starts gathering information, much of it without touching the target directly. This is often called OSINT (open-source intelligence), and it’s astonishing how much an organisation reveals about itself publicly.

The tester might look at the company’s website and job postings (which often list the exact technologies in use), search for employee names and email formats on LinkedIn, check public code repositories for accidentally leaked credentials, review DNS records to discover subdomains, and look at historical data breaches for passwords employees might have reused.

None of this involves “hacking” in the technical sense. It’s research. But it frequently shapes the entire engagement, because attackers do the same thing, and the easiest way into most organisations is knowing something you weren’t supposed to know.

Phase 2: Scanning and enumeration

With a picture of the target forming, the tester begins interacting with it directly. Scanning means finding out what’s actually there: which machines are alive, which ports are open, and which services are listening on them. Nmap is the standard tool for this.

Enumeration goes deeper. Once the tester knows a web server is running, they want to know which software and version it is, what pages and directories exist, what user accounts might be valid, and how the application behaves when given unexpected input. On a network, they might enumerate shared folders, user lists, or misconfigured services.

This phase generates a lot of data, and the tester’s skill lies in noticing what matters. An outdated version number, a forgotten test page, or a service that shouldn’t be exposed to the internet are the kinds of details that turn into findings.

Phase 3: Vulnerability analysis

The tester now cross-references what they’ve found against known weaknesses. Automated vulnerability scanners like Nessus or OpenVAS help by comparing software versions against databases of published flaws, but they produce both false positives and false negatives, so a good tester verifies everything manually.

This is also where the tester thinks about logic flaws that no scanner can detect: can a normal user access an admin page just by changing a number in the URL? Does the password reset function leak whether an email address is registered? Can a discount code be applied twice? These issues come from human reasoning about how the system is supposed to work versus how it does.

Phase 4: Exploitation

This is the part people picture when they hear “penetration test,” though it’s usually a small fraction of the total time. The tester attempts to actually use the identified weaknesses to gain access: logging in with a discovered credential, exploiting a known bug in outdated software, tricking a web application into running commands, or, if social engineering is in scope, persuading an employee to click a link.

Professional exploitation is careful. The goal is to prove a weakness is real and demonstrate its impact, not to cause damage. Testers prefer the least disruptive method that gets the job done, avoid exploits that might crash systems unless specifically approved, and document every step so it can be reproduced and, later, undone.

Phase 5: Post-exploitation

Getting a foothold is often just the beginning. Real attackers don’t stop at one compromised machine; they use it to reach more valuable targets. So the tester asks: what can I do from here?

This might involve privilege escalation (turning a low-level user account into an administrator), lateral movement (using the compromised machine to access others on the network), and assessing what sensitive data is now reachable. The tester is trying to answer the question the client really cares about: if an attacker got this far, how bad would it be?

Throughout, the tester keeps meticulous notes and screenshots. Every action must be attributable and explainable.

Phase 6: Reporting

Ask any experienced tester and they’ll tell you the report is the most important deliverable of the entire engagement. Clients don’t pay for the thrill of being hacked; they pay to know what’s wrong and how to fix it.

A good report includes an executive summary written for non-technical leadership, explaining the overall risk in plain language. It then lists each finding with a severity rating, a description of the vulnerability, evidence that it’s real (screenshots, request/response data), the potential business impact, and specific remediation advice. Findings are prioritised so the client knows what to fix first.

Writing well is an undervalued skill in this field. A tester who finds critical flaws but can’t explain them clearly has done half the job.

Phase 7: Cleanup and retest

Finally, the tester removes anything they left behind: test accounts, uploaded files, tools, or configuration changes. The client’s systems should be exactly as they found them, minus the newly discovered knowledge.

Many engagements include a retest some weeks later, where the tester checks whether the reported issues were actually fixed. It’s common to find that a fix was incomplete or introduced a new problem, which is why this step exists.

What this means for a beginner

If you’re learning ethical hacking, notice how much of this process isn’t about exploits at all. Roughly speaking, a real engagement is a lot of preparation, a lot of research and enumeration, a little bit of exploitation, and a lot of writing. Beginners often over-invest in the exploitation part because it’s exciting, then struggle in their first job when they discover that most of the value comes from being thorough and communicating clearly.

Practise the whole cycle in your lab, not just the break-in. Scope your own targets, take notes as you enumerate, and write up a short report for every machine you complete. It’s the fastest way to start thinking like a professional rather than a hobbyist.

In the next article, we’ll look at the most common vulnerabilities testers find over and over again, and why they keep showing up.