What Is Penetration Testing? Types, Phases and Reports Explained

KEY TAKEAWAYS

01A pentest is an authorized, human-led attack that proves weaknesses by exploiting them.02It's a time-boxed sample: strong evidence about what was tested, silent about everything else.03Types are named by target. Most organizations need several, chosen by what they run.04Scope and rules of engagement decide most of a test's value before testing starts.05Findings only stay true if they're retested after fixes and between engagements.

1. What penetration testing is, and isn't

A penetration test, or pentest, answers a practical question: if a real attacker targeted this system, how far could they get, and how? Testers use the same techniques attackers use, within written rules agreed in advance, and stop short of causing harm.

Three things make it a pentest rather than any other kind of security assessment. It is authorized, with scope and limits signed off by the system owner. It is human-led, relying on tester judgment rather than a tool's checklist. And it is exploitative: testers prove a weakness by using it, then show what that access leads to.

Why organizations run pentests

The common reasons are compliance requirements, customer security reviews, launching a new product, checking that an incident is truly closed, and assessing an acquired company. Underneath all of them is the same goal: replacing assumptions about security with evidence.

COMMON MISCONCEPTION

"We passed the pentest, so we're secure." A pentest is a time-boxed sample. It shows what testers found in the scope and time they had, on the days they tested. A clean report means "no serious issues found here, then," not "none exist."

2. Pentesting vs vulnerability scanning vs red teaming

These three are often confused because they all look for weaknesses. They differ in who does the work, what they're trying to achieve and what you get back.

ASPECT

Vulnerability scan

Penetration test

Red team

Who does it

An automated tool

Skilled human testers

A team emulating a specific adversary

Goal

List known weaknesses

Find and exploit as many as possible in scope

Reach an objective without being caught

Exploits?

Yes, safely, to prove impact

Yes, as needed for the objective

Typical frequency

Weekly to continuous

Annually and after change

Occasionally, in mature programs

You get

A list of potential issues

Proven findings and an attack narrative

A test of detection and response

3. Types of penetration testing

Pentests are usually named after their target. Each type needs different skills and answers a different question, so most organizations run several.

External networkInternet exposure →

What can an attacker on the internet reach and exploit before having any credentials?

Internal network and AD

How far does an attacker get from one compromised laptop or account?

Web applicationLesson →

Can users break authentication, authorization or business logic?

APILesson →

Can one caller read or change another's data, or call functions above their role?

Cloud

Do IAM, network and service settings let an attacker move between resources and accounts?

Mobile application

What does the app store, trust and send, and how do its backend APIs hold up?

Social engineering

Will people and processes resist phishing, pretexting or help desk abuse?

Wireless and physical

Can someone nearby join the network or walk into a restricted area?

Red team

Would defenders detect and stop a determined adversary pursuing a goal?

4. How a penetration test works: the seven phases

Most testers follow the Penetration Testing Execution Standard (PTES) or a close variant. The phases are consistent across providers; the difference between a good test and a weak one is mostly how much time goes to exploitation and post-exploitation.

Pre-engagement

Agree scope, objectives, rules of engagement, testing windows and emergency contacts.

THE CLIENT PROVIDES · an asset list, approvals and contacts.

Intelligence gathering

Map domains, hosts, services, people and technologies from public and provided sources.

THE CLIENT PROVIDES · documentation, for grey or white box tests.

Threat modeling

Identify what matters most and which attacker paths could reach it.

THE CLIENT PROVIDES · business context and the most important assets.

Vulnerability analysis

Find weaknesses with tooling and manual review, and decide which are worth exploiting.

THE CLIENT PROVIDES · accounts for each role and test data.

Exploitation

Prove weaknesses by exploiting them safely within the agreed rules.

THE CLIENT PROVIDES · someone reachable if something breaks.

Post-exploitation

Chain access toward objectives such as privileges, lateral movement or sensitive data. This is where impact is proven.

THE CLIENT PROVIDES · agreement on how far testers may go.

Reporting and retest

Document findings with evidence and fixes, walk through them, then retest the remediations.

THE CLIENT PROVIDES · owners and timelines for each fix.

5. Black, grey and white box testing

The "box" describes how much testers know at the start. It changes what a fixed budget buys you.

Black box Testers start with only the targets, like an outside attacker. BEST FOR · External network tests and red teams.

Grey box Testers get accounts per role and some documentation. BEST FOR · Most web, API and cloud tests.

White box Testers get source code, architecture and configuration. BEST FOR · High-risk systems and post-incident checks.

Grey box is the most common choice. Giving testers accounts for each role and some documentation means less paid time on discovery and more on the authorization and logic flaws that matter.

6. Scoping and rules of engagement

Most disappointing pentests were scoped badly rather than tested badly. Before testing starts, both sides should agree on these points in writing.

Targets Exact hosts, applications and accounts in scope, and what is explicitly out.

Objectives What a successful attack would look like, so testers aim at what matters.

Accounts and data Test accounts for each role, and which test data testers may create or change.

Testing windows When testing may run, and any blackout periods.

Limits Prohibited techniques, rate limits and how far post-exploitation may go.

Stop procedure Who to call, and how testing pauses if something goes wrong.

7. How to read a pentest report

A useful report has two parts: an attack narrative that shows how findings connected into real impact, and individual findings written so an engineer can reproduce and fix each one. Below is one finding with each part labeled.

SAMPLE FINDING IN-03 Kerberoastable service account with a crackable password T1558.003 · CWE-521

Critical

SUMMARYFor leadership

A service account with a weak password can be cracked offline by any domain user, and has admin rights on 40 servers.

AFFECTEDExact scope

svc-backup in the CORP domain; local admin via policy on the Servers group.

REPRODUCESo engineers can confirm

As any domain user, request a service ticket for the account and crack it offline with the approved wordlist.request ticket for svc-backup SPN crack offline → password recovered in 41 min

IMPACTWhy it matters here

With the password, testers logged in as admin on srv-db-03, found cached domain admin credentials and reached full domain compromise.

DETECTIONWhat defenders saw

The ticket request and logons were logged in the SIEM but raised no alert.

FIXSpecific and testable

Move the service to a managed service account, remove its admin rights, and alert on weak-encryption ticket requests for privileged accounts.

Illustrative finding · synthetic environment

Reading severity

Severity in a good report combines how easy the weakness is to exploit with what it leads to in your environment. A CVSS score alone describes the weakness in general; the tester's rating should explain why it matters here.

8. How often to test, and what to do in between

Many compliance programs and customers expect a pentest at least once a year and after significant changes. That is a minimum. For systems that change every week, an annual test describes a few weeks of the year.

Between tests, four habits keep findings from going stale: close findings only on retest evidence; turn past findings into repeatable checks so fixed issues can't quietly return; use automated validation for known techniques; and scope the next test around what changed. See how quickly coverage decays for a web application.

9. Try it: plan a pentest

Choose a reason for testing and what you run. The planner suggests test types, an approach and a cadence, and explains each choice.

WHY YOU'RE TESTING

WHAT YOU RUN

SUGGESTED PLAN

Web application pentestAuthorization and business logic are where scanners stop. Grey box

Cloud pentestIAM paths, exposed services and misconfigurations between accounts. Grey box

Cadence: at least annually and after significant change Check your framework's wording on scope and frequency with your assessor.

A learning aid, not compliance advice. Confirm specific requirements with your assessor.

10. Check your understanding

Three quick questions. Pick an answer to see the explanation.

Q1A client's pentest report has no critical findings. What does that tell them?

Q2Which approach usually gives the most value per tester-day for a web application?

Q3What most distinguishes a red team from a pentest?

11. Glossary

Scope The systems, accounts and techniques a test is allowed to cover.

Rules of engagement The written agreement on how testing is carried out, including limits and contacts.

Exploitation Using a weakness to gain access or capability, to prove it is real.

Post-exploitation What testers do after initial access: escalating privileges, moving laterally, reaching data.

Lateral movement Moving from one compromised system to others in the same environment.

Privilege escalation Gaining higher permissions than the starting account was given.

Attack narrative The part of a report that tells the story of how findings chained into impact.

Retest A follow-up check that confirms a reported weakness has been fixed.

What is penetration testing?