What Is Authorized Penetration Testing?
Penetration testing is the practice of attacking a system the same way a real intruder would, with one difference that changes everything: the owner asked for it, in writing, ahead of time.
That written permission is what makes the word "authorized" load-bearing rather than decorative. Without it, the exact same actions, port scanning, password guessing, exploiting a known vulnerability, are a crime in most jurisdictions. With it, they are a service. The difference lives entirely in a document called the Rules of Engagement, which we cover in detail in our guide to pentest contracts.
What a penetration test actually covers
A real engagement usually moves through a few distinct phases, even if the client only ever sees the final report:
- Reconnaissance. Passive information gathering plus active enumeration of what is actually running: open ports, exposed services, technology fingerprints.
- Vulnerability identification. Matching what was found against known weaknesses, whether through automated template matching or manual review.
- Exploitation. Proving a finding is real, not theoretical, by actually triggering it under controlled conditions.
- Reporting. Turning all of that into something a client's engineering team and their auditor can both act on.
Every one of those phases has to stay inside whatever scope the client actually signed off on. A test that wanders past its authorized boundary is not a more thorough test, it is a liability, for the tester and for the client. That is the entire argument for scope enforcement as a technical control, not just a paragraph in a contract.
Penetration testing versus a vulnerability scan
These two terms get used interchangeably far too often, and the difference matters more than it sounds. A vulnerability scan tells you a door might be unlocked. A penetration test walks up and turns the handle, under supervision, to confirm it actually opens. We go deeper into this distinction in vulnerability scanning versus penetration testing.
Why the human approval step exists
Confirming a finding usually means sending a real payload at a real system. That is the single riskiest moment in the entire engagement, and it is exactly the point where automation should slow down, not speed up. A tool that runs recon and vulnerability identification on its own but stops and asks a person before it confirms or exploits anything gets the balance right: fast where speed is safe, deliberate where it is not.
If you are choosing a firm or a platform to run this kind of work for you, it is worth reading our notes on what to ask before you sign.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation