Most people picture a penetration test as a hooded figure in a dark room, typing fast, breaking into a system in ninety seconds. The reality is slower, quieter, and far more disciplined. It starts with paperwork and permission. Most of the work is patient reconnaissance. And the goal is not really to break in.
I have spent more than fifteen years in IT, nine of them in security consulting, and here is the part that surprises people: I do not test a system just to gain access to it. I test it to produce business recommendations an organization can act on. An engagement is an opportunity to see how well a security team actually implemented its controls, policies, and procedures when someone pushes on them. Gaining access is just the proof. The value is in explaining why a finding matters and what to do about it.
A good ranger does not just study the castle walls to climb them. They study the walls to tell the lord exactly where the stone is weak, and what it will cost to fix before someone else finds the same gap.
Here is how a real engagement runs, from the first conversation to the final retest.
Scoping: What Is Being Tested, and Why
Every engagement begins with scope. When a request comes in, the first job is to define the scope of work and write a project charter that lays out exactly what the engagement involves. Then comes a project kickoff, a detailed conversation with the client to understand what they actually expect. That conversation is not a formality. It is the single best defense against scope creep later.
What you are really trying to learn in scoping:
-
What the client actually wants. A compliance checkbox, genuine risk reduction, and validation after a breach are three different engagements. Knowing which one you are being hired for changes everything that follows.
-
What is in scope and what is out. Internal network or external perimeter? A web application or the whole environment? These boundaries have to be written down and agreed on.
-
Timeline and cost drivers. The size of the scope, the type of testing, and the depth of the work all shape the quote. Good questions up front produce an accurate one.
The most common mistake I see is a vague scope. A loosely defined engagement gets tested weeks later, and then the results get disputed because nobody agreed on the boundaries in the first place. Time spent being precise at the start saves a painful argument at the end.
Rules of Engagement
This is the part outsiders understand least, and it is where a professional engagement separates itself from reckless “hacking.”
Once the scope is set, the rules of engagement define how the test will actually run: who is involved, who the points of contact are, and what kind of engagement it is. That last point matters more than most clients realize:
-
A penetration test identifies a vulnerability and then exploits it to demonstrate real business impact. The client’s team usually knows it is happening.
-
A red team simulates a real attacker who knows nothing about the organization going in, and often only a single person inside the company is even aware the engagement is underway. The point is to test detection and response, not just the walls.
-
A physical penetration test puts a tester on site, trying to get through doors instead of firewalls. This is where the “get out of jail” letter comes in: written authorization you carry at all times, so that if you are caught, you can prove you were hired to be there. It is not a joke, and it is not optional.
Beyond the type of test, solid rules of engagement always include a few things. Agreed testing windows. A list of systems that are off limits. Emergency contact information for the client, provided before testing starts, in case something breaks or something is found.
And some things stop a test cold. If a tester discovers an active attacker already inside the environment, testing stops immediately. The engagement shifts into the client’s incident response plan, and the budget that was set aside for testing gets redirected toward digital forensics and whatever else the response requires. Similarly, if a tester lands on genuinely sensitive data, the engagement pauses. You give the point of contact enough detail to remediate, and you document it carefully in the report rather than digging further.
Knowing when to stop is as professional as knowing how to get in.
The Testing Itself
A penetration test mirrors what a real threat actor does. It starts with reconnaissance, much of it through OSINT, open source intelligence. This is where you enumerate everything an organization has exposed to the internet: DNS records, email addresses, who works there, and more. Nothing is touched yet. You are building a map.
Once those targets are identified, a vulnerability scan looks for weaknesses that might be exploitable. From there you build a threat model, share it with the client, and only after that is confirmed do you move to exploitation.
Here is a distinction that matters, and it is the heart of this whole craft: scanning is not attacking. Discovering that a system might be vulnerable is reconnaissance. You do not get to attack a system without proper authorization. A vulnerability is discovered, then reported, and only then is it tested to see whether it leads to real access. That testing is exploitation, and it is a deliberate, authorized step, not a reflex. (If you want the full breakdown of that difference, I wrote a separate guide on exactly where scanning ends and attacking begins.)
Say an exploit succeeds and gives you access to a host, moving you from the outside into the internal network. Now post-exploitation begins, and it is the same process all over again from a new vantage point: reconnaissance, enumeration, vulnerability analysis, threat modeling, exploitation. From inside, you start to see what else can be reached: a domain controller, financial systems, web servers, the DMZ.
What the time really looks like might disappoint the hooded-hacker crowd. Reconnaissance takes enormous effort, and much of it leads nowhere. You find something that looks promising and follow it down a rabbit hole, only to hit a dead end. A system fingerprints as vulnerable to remote code execution, you get a little excited, and then deeper banner enumeration shows the version actually running is not vulnerable at all. Back to the map.
But the opposite happens too, and it is why thoroughness pays. Take a finding that looks trivial on its own: Link-Local Multicast Name Resolution, an information-level issue most people would wave off. Tie it to another small weakness, SMB signing not being required, and suddenly you can capture authentication hashes and use pass-the-hash techniques against a whole range of systems: domain controllers, web servers, application servers, databases, finance servers. Two minor issues, chained, become a serious compromise. That chaining is what separates a real test from a scan report, and it is exactly what a real attacker would do.
The Report
The test is only as valuable as the report that comes out of it. A strong one contains an executive summary, findings rated by severity, evidence for each, and clear remediation steps.
The remediation guidance should be built so a team can actually act on it. I like a 30/60/90 day plan that prioritizes in the right order: fix the vulnerabilities that were actually exploited first, then critical, then high, then medium and low. That sequencing matters, because it puts the proven, dangerous gaps at the front of the line instead of burying them in a flat list.
Most reports fail in one of two ways. Either they are unreadable to the executives who approve the budget, or they are useless to the engineers who have to do the fixing. A good report serves both audiences, and it rates severity honestly. I will not inflate a finding to make an engagement look scarier than it was. Credibility is the whole product.
The Retest
The retest is the step most organizations skip, and skipping it is where risk quietly survives.
Its purpose is simple: confirm that the issues identified were actually remediated, and surface any new gaps that the fixes may have introduced. It is not a repeat of the entire engagement. It focuses on the findings that were clearly used to gain access, and verifies they are genuinely closed.
When a client skips the retest, your only hope is that they took the report to heart and worked through the fixes on their own before the next engagement. Sometimes they do. Often, the same findings are waiting the following year. “Fixed” and “fixed and verified” are not the same thing, and the gap between them is exactly where an attacker lives.
What to Take From This
If you are a business owner buying a penetration test, you do not need to understand exploitation to hire well. You need to ask the right questions. Before you sign with a tester, ask:
-
Will you write a clear scope and project charter before any testing begins?
-
What are your rules of engagement, and what happens if you find an active attacker or sensitive data?
-
Will the report be readable by both my executives and my engineers?
-
Will you give me a prioritized remediation plan, not just a list of findings?
-
Is a retest included, and what does it cover?
A tester who answers those confidently is one who understands that the goal was never just to break in. It was to leave your walls stronger than they found them.
This is the anchor post for the Ranger’s Guild. In the coming weeks I will go deeper on each stage: reconnaissance and OSINT, writing a report people actually use, and the chained findings that turn small issues into real access. If there is a part of the process you want pulled apart first, tell me in the comments.
