A penetration test usually starts before anyone tries to break into anything. The tester first needs to understand what they’re allowed to touch, because testing the wrong system can create a very different kind of problem. So the scope gets agreed on first.
Planning Comes First
The security team and the penetration tester sit down and define the target. This could be a website, an internal network, a mobile app, or something else the company wants checked. The tester also learns about the rules of the engagement, including what should be avoided and when testing is allowed.
Setting the Scope
• The target is clearly named, which sounds obvious until a company has several similar systems running.
• Testing windows are agreed in advance so normal users aren’t caught in the middle of a security test.
• Some systems stay off-limits. That boundary matters, especially in a large company.
Finding the Attack Surface
Once the rules are clear, the tester starts gathering information about the target. They look at what is exposed and how the system appears to be built. For a website, that could mean checking pages and identifying technologies behind the application.
And this stage isn’t always loud. A tester may spend a lot of time observing the target before actively testing it. The goal is to understand where an attack could begin.
Scanning and Discovery
Automated tools often speed things up here. They can spot common weaknesses and areas that deserve a closer look. But a tool doesn’t understand the business the way a person does, so the tester reviews what it finds rather than blindly trusting every result.
Trying to Exploit Weaknesses
This is where the pen test starts feeling like an actual attack. The tester attempts to prove whether identified weaknesses are real and whether they could lead to meaningful access.
They might test authentication controls. They may examine how an application handles unexpected input. If something looks promising, they’ll investigate further while staying inside the agreed scope.
Reporting What Actually Happened
After testing, the tester turns the technical work into a report that people can use. This part gets overlooked, but honestly, a brilliant test is less useful if nobody understands what happened afterward.
• Evidence from successful tests shows what the weakness actually allowed, rather than leaving the security team with a vague warning.
• Findings are explained in plain language too, because the person fixing an issue isn’t always the person who discovered it.
• Severity gets assigned based on the potential impact and likelihood of exploitation, not simply because a scanner gave something a scary-looking number.
The company then fixes the weaknesses that were found. Sometimes that means changing code. Sometimes access rules need attention. And sometimes the biggest fix is surprisingly small.
A follow-up test can check whether those fixes really worked. That’s the part I like most about penetration testing. It closes the loop instead of leaving everyone with a report sitting untouched in a folder.