What Is Penetration Testing? Types, Phases and Deliverables

By the Guardian team Updated November 2026 6 min read

Quick answer. Penetration testing is an authorized, simulated attack that finds and proves ways past a system's security. A pentest covers scoping, discovery, exploitation and a report with evidence, risk ratings and fixes, then a retest.

Watch: What Is Penetration Testing? Types, Phases and Deliverables 1:34

Video transcript

Penetration testing is an authorized, simulated attack that finds and proves ways past your security. Yet the term gets stretched to cover everything from scans to red teams.

Three things set a pentest apart: authorization, a defined scope, and proof, where weaknesses are exploited to show impact.

Pentests are usually named after their target, from external and internal networks to web apps, APIs, mobile apps and cloud.

NIST describes four phases. Planning sets the rules of engagement. Discovery gathers information and scans. Attack tries to exploit what was found. Reporting runs throughout.

A scan only checks whether a vulnerability might exist. A pentest exploits it to confirm it, then chains flaws into access no single one would give.

The report is the product. Each finding needs a risk rating, evidence with steps to reproduce, and a fix with its root cause. Then comes a retest.

For crypto and fintech, the method stays the same. The targets change: the asset worth stealing is often a key, or a system that can sign.

Guardian's offchain practice is led by Carlos Polop, who co-founded HackTricks training. Its infrastructure tests treat your cloud footprint the way an intruder would.

Not sure what to test first? Book a system review at guardian.security, an hour with a Guardian engineer. Or read the full guide below.

Penetration testing is one of the most used terms in security, and one of the loosest. Buyers meet it on everything from automated scans to red team exercises.

Knowing what a real pentest includes is how you compare quotes and judge the report you get back.

This guide follows NIST SP 800-115, the Penetration Testing Execution Standard (PTES) and OWASP's testing guides.

Penetration Testing Defined

NIST SP 800-115 defines penetration testing as security testing in which assessors mimic real-world attacks. The aim is to find ways around the security of an application, system or network.

It often means real attacks on real systems, with the tools attackers use. Most tests chain vulnerabilities across one or more systems, to reach access no single flaw would give.

The UK's National Cyber Security Centre (NCSC) describes it as a way of gaining assurance "using the same tools and techniques as an adversary might."

NCSC adds that a pentest should give assurance in your own vulnerability assessment, not be your main way of finding vulnerabilities.

Three things set a pentest apart from other security work:

Authorization: written permission from the system owner, under agreed rules.
Scope: named targets, exclusions and a time window.
Proof: weaknesses are exploited to show impact, not just flagged.

Types of Pentest

Pentests are usually named after their target.

Type	What testers attack	Common reference
External network	Internet-facing hosts and services, from outside the perimeter	NIST SP 800-115
Internal network	Systems behind the perimeter, starting from user-level access	NIST SP 800-115
Web application	Authentication, sessions, authorization, input handling and business logic	OWASP WSTG
API	Object and function level authorization, authentication, resource limits	OWASP API Security Top 10
Mobile app	Android and iOS apps and the services behind them	OWASP MASVS and MASTG
Cloud	Your accounts, permissions, storage and services on a provider	Provider policies, such as AWS's
Social engineering and physical	Staff, help desks and buildings	NIST SP 800-115

Tests are also described by how much the testers know:

Black box: testers start with little information, as an outsider would.
Gray box: the client shares some information, such as accounts or architecture.
White box: testers get full information, often including source code.

NCSC calls the two ends "opaque" or "closed box" and "transparent" or "open box" testing.

NIST adds one more split: overt tests, run with the IT staff's knowledge, and covert tests, run without it but with upper management's permission.

The Phases of a Pentest

NIST describes four phases, and notes there are many acceptable ways to group the work.

Planning: rules are set, management approval is documented and goals are agreed. No testing happens yet.
Discovery: information gathering and scanning, then analysis against known vulnerabilities and the testers' own knowledge.
Attack: testers try to exploit what they found. New access sends them back to discovery.
Reporting: logs and status updates run throughout, ending in a final report.

PTES splits the same work into seven phases: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting.

Planning produces the rules of engagement: scope, timing, contacts and stop conditions. Our rules of engagement template lists what goes in them.

Testing carries real risk: NIST warns that systems may be damaged. So a test can be designed to stop where the next action would cause damage.

Pentest vs Scan, Audit and Red Team

Activity	Question it answers	How it works
Vulnerability scan	Which known weaknesses might be present?	Tools match systems against vulnerability databases
Pentest	What can an attacker actually reach?	People exploit weaknesses to confirm and chain them
Audit or code review	Does the code or configuration meet its requirements?	Experts read code, configurations and documents
Red team	Would we detect and stop a real attacker?	A covert, goal-driven simulation of an adversary

NIST draws the line between the first two. A scanner checks only for the possible existence of a vulnerability; a pentest exploits it to confirm it.

OWASP adds that automating black-box testing "is not (nor will ever be) completely effective."

Reviews and pentests complement each other. OWASP lists completeness and accuracy among the advantages of source code review.

It calls pentesting, while useful, "too little too late" in the development life cycle.

A red team is closer to what NIST calls covert testing, which examines the damage an adversary can cause rather than every vulnerability.

For contracts, see smart contract audit vs pentest.

What You Receive

The report is the product. PTES splits it in two:

Executive summary: overall posture, risk ranking, general findings and a strategic roadmap.
Technical report: the scope, the attack path, the impact of each finding and how to fix it.

Each finding should carry:

A risk rating, using a scoring method agreed before testing.
Evidence, and the steps to reproduce it.
A fix, and the root cause behind the weakness.

NIST wants every mitigation recommendation to include the outcome of root cause analysis.

NCSC adds one more item: an opinion on how accurate your own vulnerability assessment is.

Then comes the retest. NIST says retesting validates that fixes were completed, and only a mirror of the original test can verify them.

Pentesting Crypto and Fintech Systems

The method does not change for a crypto company or a fintech. The targets do.

The asset worth stealing is often a key, or a system that can sign. Binance says the attacker behind its October 29, 2026 loss reached an internal wallet signing service.

Our Binance hack explainer traces how. A crypto pentest follows the same kind of path, from apps and cloud to whatever signs.

Exploits that touch funds are proven on a fork or testnet, not with real money.

Our guide to web3 penetration testing covers that scope and method in detail.

What if an attacker already holds a developer laptop or a cloud token? An assumed breach pentest starts there.

Pentesting With Guardian

Guardian's offchain services are led by Carlos Polop, Head of Offchain Services. He co-founded and built HackTricks training into one of the most popular online cybersecurity training and certification sites.

Guardian's offchain engagements include pentests of infrastructure, web apps, APIs, browser extensions and offchain automation, plus SDK and OpSec audits.

Web application tests map the app function by function, at every privilege level, ideally from the source repository.

Infrastructure tests treat your cloud footprint the way an intruder would: "as a set of accounts to escalate through until something signs."

Not sure what to test first? Book a system review: an hour with a Guardian engineer, then a written summary of what stood out and what a first ninety days would cover.

Frequently Asked Questions

What is the difference between a pentest and a vulnerability scan?

A scan uses automated tools to flag known weaknesses that might be present, and NIST notes high false positive rates. In a pentest, people exploit weaknesses to confirm them and chain them into deeper access.

Is a penetration test the same as a red team exercise?

No. A pentest tries to find and prove as many weaknesses as it can within a set scope. A red team is a covert, goal-driven simulation that also tests detection and response.

How often should you run a penetration test?

NIST says a yearly network pentest may be sufficient, with regular scanning in between. It also recommends testing applications after significant changes, and when the threats you face change.

What does a pentest report include?

PTES splits it into an executive summary and a technical report. Each finding should carry a risk rating, evidence, reproduction steps, a fix and its root cause. A retest should follow.

Sources

Find out what an attacker can reach

Guardian's offchain team, led by Carlos Polop, who co-founded and built HackTricks training, pentests your apps, APIs, cloud and the systems that sign.

Talk to Guardian Book a system review