Facebook-f Twitter

Call us!

610-444-8256

Penetration Testing Explained: The 7 Stages, the 3 Types, and What a Real Test Finds

A penetration test is an authorized, simulated attack on your own systems, run by people whose job is to get in the way a criminal would and then hand you the map. It is the difference between believing your defenses work and having watched somebody try to break them.

This page answers the questions businesses actually ask before they buy one: what the stages are, what the types mean, how a test differs from a scan, what you get at the end, how often to run one, and what moves the price. If you already know all that and just want a test scoped, our penetration testing service page is the shorter road.

What Penetration Testing Means, and Why People Call It Ethical Hacking

What is meant by penetration testing is straightforward: it is an authorized, simulated cyberattack on your own systems, run to find and prove real weaknesses before a criminal finds them. That is the whole definition, and ethical hacking is the same activity under a friendlier name.

What penetration testing means, defined in one line
  • The objective is proof, not a list. The purpose of the exercise is to demonstrate what an attacker could actually reach, which is a different claim from saying a weakness theoretically exists.
  • Authorized is the word carrying the weight. The identical actions without written permission are a crime; the authorization is what separates a penetration test from an intrusion.
  • Ethical hacking, pen testing and offensive security are used more or less interchangeably in the market, so do not let a vendor charge you twice for the same work under two names.
  • It is a point-in-time exercise. A test tells you where you stood on the day it ran, which is why frequency matters as much as the test itself.
  • Threat led testing goes one step further. Its fundamental elements are real adversary intelligence, scenarios drawn from it, and objectives written in business terms rather than technical ones, and it models the specific adversaries realistic for your sector rather than running a generic playbook.

Basic penetration testing, the kind most businesses start with, is simply the external network flavor of exactly this. The two most common vulnerabilities a test turns up are unpatched or misconfigured internet-facing services and credentials that work in more places than anyone intended. Neither is exotic, and both are how most real breaches actually start.

The 7 Stages of a Penetration Test, Start to Finish

A professional penetration test runs in seven stages, and the first and last matter as much as the hacking in the middle.

The seven stages of a penetration test from scoping to retest
  1. Scoping and rules of engagement. You agree what is in scope, what is off limits, when testing happens, and who to call if something breaks, all in writing before anyone touches a system.
  2. Reconnaissance. The tester gathers everything publicly knowable about your organization, from exposed services and subdomains to employee names that make convincing phishing targets.
  3. Scanning and enumeration. Automated tooling maps live hosts, open ports, running services and known weaknesses, producing the candidate list the human then works through.
  4. Exploitation. The tester actually attempts the break-in, which is the step that separates a real test from a report full of theoretical risk.
  5. Post-exploitation. Having got in, the tester escalates privileges and moves laterally to establish how far a real intruder could travel and what they could reach.
  6. Analysis and reporting. Findings are written up with severity ratings, evidence, business impact and prioritized remediation steps.
  7. Remediation and retest. You fix what was found and the tester verifies the fixes actually closed the hole, which is the stage most often skipped and the only one that proves anything changed.

If a proposal you are reading does not describe stage one or stage seven, you are being sold a scan with a nicer cover page.

The 3 Types of Penetration Testing: Black Box, Grey Box and White Box

The three types describe how much the tester is told before they start, and that single variable changes what the test can find and what it costs.

Black box, grey box and white box penetration testing compared
  • Black box. The tester gets nothing but your company name, which most closely simulates a simple outside attacker but spends a chunk of the budget rediscovering things you could simply have told them.
  • Grey box. The tester is given limited information such as standard user credentials or a network diagram.
  • White box. The tester gets full visibility including architecture and physical access, which finds the most and costs the most. White box would help identify systems vulnerable to a malicious insider or malicious access to a trusted person’s computing device or user account.

Cutting across all three is where the test is launched from. An external penetration test attacks your internet-facing perimeter the way a stranger would. An internal penetration test starts from inside the network and answers a different and increasingly relevant question: what happens after somebody clicks the wrong link, or after a contractor plugs into your network.

Organizations get the most value from the white box internal test, because that is the scenario modern ransomware actually follows, and it comprehensively includes searching for black box and grey box vulnerabilities.

What Can Be Tested: Network, Cloud, Wireless and Physical

Anything with an attack surface can be tested, and the scope you pick decides which questions the test is able to answer.

What can be tested: network, cloud, wireless, physical
  • Network. Your internet-facing perimeter, your internal segments, or both, which is the most common starting scope for a business that has never tested.
  • Cloud and SaaS. Configuration, identity and permissions across your tenants, since in cloud the mistake is almost never the provider’s infrastructure and almost always the settings.
  • Wireless. Your office networks, guest segregation, and whether somebody in the parking lot can reach anything that matters.
  • Physical and social engineering. Whether a stranger can walk in, plug in, or talk your team into opening a door.
  • Hardware and operational technology. Devices and control systems, relevant if you manufacture, and a specialist engagement rather than a line item.

Third-party testing simply means the work is done by somebody other than the team that built and runs the systems, which is the point: you cannot meaningfully grade your own homework.

Vulnerability Scanning vs Penetration Testing: Not the Same Test

A scan finds known weaknesses automatically; a test puts a human using AI against them. Said plainly, no hedging. A vulnerability assessment (VA) is the scanning half; a penetration test (PT) is the proving half.

Vulnerability scanning compared with penetration testing
  • A vulnerability scan is automated and continuous. Software compares your systems against a database of published vulnerabilities and returns a list, which is genuinely useful and should be running all the time.
  • A penetration test is adversarial and human-led. A person decides which of those findings are actually reachable, chains two harmless-looking issues into one serious one, and proves it.
  • Only one of them produces evidence. A scan says a door may be unlocked. A test walks through it and shows you what was in the room.
  • They answer different questions. The scan answers what is known to be wrong. The test answers what someone could actually do about it.

That human layer is also where the job has changed most. Testers now use automation and AI to cover ground faster and to try combinations that would have been impractical by hand, which means a good test today reaches further than the same budget bought three years ago. The scan is still the floor. The test is the proof.

Both belong in a serious security program, which is why our own penetration test service pairs them rather than treating them as alternatives.

Is a Penetration Test Safe and Legal, and Who Has to Sign Off?

A penetration test is legal because you authorize it in writing, and that same document is what keeps it safe.

What makes a penetration test legal and safe
  • Written authorization from someone who can give it. Whoever signs must actually own the systems in scope, which is a real question in a group structure or after an acquisition.
  • Rules of engagement. The SOP, or standard operating procedure, for the test: what is in scope, what is explicitly off limits, what hours testing runs, and who gets called the moment something looks wrong.
  • An NDA that runs both ways. The tester will see your weaknesses, and the findings should be treated as confidential by both sides for as long as they remain exploitable.
  • Third-party systems need their own permission. Your cloud or SaaS provider sets its own testing rules, and testing a platform you rent without checking is how a legitimate engagement turns into an incident.
  • The risks of penetration testing are real but managed. Some techniques can degrade a fragile system, which is exactly why fragile systems are named up front and either excluded or tested out of hours.
  • Testing your own network yourself is legal and worth doing with automated tooling; it is not a substitute for an independent test, because you cannot find the assumptions you did not know you were making.

What a Penetration Test Report Actually Contains

A real penetration test report is a remediation plan with evidence attached, not a vulnerability list with a logo on it.

What a real penetration test report contains
  • An executive summary. One page a non-technical owner or board can act on, stating the overall risk position in plain language.
  • Scope and methodology. Exactly what was tested, from where, when, and by what standard, so the result can be compared against next year’s.
  • Findings with severity ratings. Each issue scored consistently, usually with CVSS, so you can argue about priorities using numbers rather than adjectives.
  • Proof of exploitation. Screenshots, request logs, the data that was reachable. This is the section that separates a test from a scan, and its absence tells you which one you bought.
  • Business impact. What each finding would actually mean for your operation, rather than a generic description of the vulnerability class.
  • Prioritized remediation steps. What to fix first, what can wait, and what is a compensating control rather than a fix.
  • Retest results. Written confirmation that the fixes worked, which is the real conclusion of a penetration test.

The timeline of a penetration test is shorter than most people expect. Most engagements run one to three weeks end to end, depending on scope, and the report lands within a week or two of testing finishing. In our experience the findings fall into two buckets. The first is projects, the ones already on your list that stalled on budget or on needing a specialist. The second is the mundane work: training people, turning on verbose logging, and turning all that telemetry into alerts somebody actually reads. Knowing which bucket each finding sits in is what makes the report usable.

How Often Your Business Should Run a Penetration Test

Annually is the working baseline, and any material change to your environment resets the clock. How regular penetration testing benefits a company is simple: each test is only true on the day it ran, so a cadence is what turns a snapshot into a trend you can manage.

Five events that reset the clock on penetration testing
  • At least once a year. Your systems change, your staff change, and the published attack surface changes underneath you even when you do nothing.
  • After any major infrastructure change. A cloud migration, a new firewall, an office move, a merger, or a significant application release all invalidate the last result.
  • When a framework sets the schedule. If you are subject to a compliance regime, the regime decides, and it usually wins the argument.
  • After a security incident. Once you have been hit, the question is no longer whether you are exposed but whether you closed the thing that let them in.
  • When your cyber insurer asks. Insurers increasingly want evidence of testing, and the renewal conversation is easier with a report in hand.

If a compliance framework applies to you, it will usually set the interval for you, which is the subject of the next section.

Which Compliance Frameworks Require a Penetration Test

Several do, and where a framework applies it usually decides your schedule for you.

Which compliance frameworks require a penetration test
  • PCI DSS. Explicitly requires internal and external penetration testing at least annually and after any significant infrastructure or application change, so if you handle card data this is not optional.
  • ISO 27001. Does not name penetration testing outright, but expects technical vulnerability management and evidence that controls are effective, and annual testing is the normal way organizations satisfy an auditor on that point.
  • CMMC. Built on NIST SP 800-171, which requires periodic security control assessment; testing is the practical evidence, and defense contractors should assume an assessor will look for it.
  • SOC 2. Not mandated in the criteria, but auditors routinely expect it, and its absence turns into a conversation you would rather not have during fieldwork.
  • HIPAA. Requires an accurate risk analysis rather than a test specifically, though testing is one of the few ways to produce defensible evidence for that analysis.
  • Cyber insurance. Not a framework, but increasingly the party actually asking, and a current report makes renewal conversations shorter.

If you sell to the Department of Defense or sit anywhere in a defense supply chain, testing sits inside a much larger set of obligations. Our CMMC compliance page covers what that involves, and CMMC Demystified explains the framework itself.

What a Penetration Test Costs and What Moves the Price

There is no single price, because a penetration test is priced on scope and skill rather than on a per-seat rate, and the scope is set by you.

At Pegasus Technologies, a full penetration test covering internal and external across all three types runs $3,600 to $5,400 for a single site, and that includes one retest within the year so you can prove your fixes actually worked. Additional sites, or networks above 250 devices, cost more.

Six levers that move the price of a penetration test
  • The number of live targets. This is the biggest lever by a distance: how many external IPs, internal subnets, applications or cloud tenants are in play.
  • Internal or external, or both. An internal test needs access arranged and takes longer, so it costs more than testing the perimeter alone.
  • How much the tester is told. Black box burns hours on reconnaissance, while white box spends the same hours going deeper.
  • Whether a retest is included. Some quotes stop at the report and charge again to verify your fixes, which is worth checking before you compare two numbers.
  • The reporting standard required. A test that has to satisfy an auditor carries documentation overhead that an internal-assurance test does not.
  • Manual depth versus automated coverage. The cheapest quotes are usually a scan with a report attached, which is a fine product as long as you know that is what you are buying.

Getting started is less involved than most people expect. To test your perimeter, all we need is your public IP range, and it tends to be eye-opening to see exactly what a criminal can see. If you want to know what happens when somebody who means no harm plugs into your internal network, we can show you that too.

A penetration test is not a purchase that ends in a certificate. It ends in a list of things to do, in priority order, with evidence for each one. That list is the point.

If you want to know where you actually stand, talk to the Pegasus team or call 610-444-8256. We will scope a test honestly, tell you if a scan is all you need, and hand you a plan you can execute with us or without us.