Penetration Testing: The Complete Guide

What is penetration testing?

A penetration test (or "pentest") is an authorised, time-boxed security assessment in which skilled testers attempt to compromise a defined set of systems using the same techniques a real attacker would. The goal is not to produce a list of theoretical weaknesses — it is to determine what an attacker could actually achieve, and to hand you the evidence and remediation detail needed to close those paths.

The word "authorised" is what separates a penetration test from a crime. Every legitimate engagement begins with a written scope and rules of engagement signed by someone with authority over the systems being tested. That document defines which assets are in scope, which techniques are permitted, when testing may occur, who to contact if something breaks, and how sensitive data discovered during testing must be handled.

Penetration test vs vulnerability assessment vs red team

These three are routinely confused, and buying the wrong one is a common and expensive mistake. They answer genuinely different questions.

A practical rule: run vulnerability assessments continuously for hygiene, penetration tests periodically for assurance, and red team operations only once you have a detection capability worth testing. Paying for a red team exercise before you have monitoring in place mostly buys you an expensive way to learn you have no monitoring.

Types of penetration testing

Penetration testing is not one service. Scope determines the skills, tooling and duration required, and each type answers a different exposure question.

Black box, grey box, or white box?

These terms describe how much information the tester is given before starting.

• Black box — no prior knowledge beyond the target scope. Realistic for an external attacker, but a meaningful share of the engagement is spent on reconnaissance rather than finding bugs.
• Grey box — the tester receives credentials and basic architecture detail. This is the best value for most organisations: it skips wasted discovery time and reaches authorisation and business-logic flaws that black-box testing rarely gets to.
• White box — full access to documentation, configuration and often source code. Highest coverage per day spent, and the right choice when assurance matters more than realism.

Choosing black box because it "feels" like a real attack is usually a false economy. An attacker has unlimited time; your engagement does not. Grey box testing typically finds more real, exploitable issues in the same number of days.

Methodology and standards

Credible testing follows a documented, repeatable methodology rather than an ad-hoc tool run. Ask any prospective provider which of these they work to — a vague answer is a meaningful signal.

• OWASP Web Security Testing Guide (WSTG) — the de facto reference for web application testing coverage.
• OWASP Mobile Application Security Testing Guide (MASTG) — the equivalent for iOS and Android applications.
• OWASP API Security Top 10 — the standard reference for the API-specific issue classes that web-focused testing tends to miss.
• PTES (Penetration Testing Execution Standard) — defines the phases of an engagement from pre-engagement interaction through reporting.
• NIST SP 800-115 — the "Technical Guide to Information Security Testing and Assessment"; frequently referenced by US public-sector and regulated buyers.
• OSSTMM — the Open Source Security Testing Methodology Manual, an operationally rigorous alternative methodology.
• MITRE ATT&CK — a knowledge base of real adversary tactics and techniques, widely used to structure red team objectives and to map findings to realistic threat behaviour.
• CVSS — the Common Vulnerability Scoring System, used to express severity consistently. Note that CVSS measures technical severity, not business risk; a "medium" on an internet-facing crown-jewel system can matter more than a "high" on an isolated test box.

What actually happens during an engagement

A well-run penetration test follows a predictable lifecycle. Knowing it helps you tell a real engagement from a scan-and-forward.

1. Scoping — Agree what is in scope, what the objectives are, and what "done" looks like. Under-scoping is the most common cause of a disappointing test.
2. Rules of engagement — Written authorisation, testing windows, permitted techniques, escalation contacts, and handling rules for any sensitive data encountered.
3. Reconnaissance — Map the real attack surface — hosts, endpoints, technologies, users and exposed information.
4. Vulnerability identification — Combine tooling with manual analysis to identify candidate weaknesses, then verify them by hand to eliminate false positives.
5. Exploitation — Safely prove which issues are genuinely exploitable, capturing evidence as you go. Destructive actions are agreed in advance, never improvised.
6. Post-exploitation & chaining — Establish what the compromise actually reaches — privilege escalation, lateral movement, and access to sensitive data. This is where a real test earns its fee.
7. Reporting — Document findings with evidence, severity, business impact and specific remediation guidance for both engineers and executives.
8. Remediation support & retest — Answer the engineering team's questions during fixes, then retest to confirm the issues are genuinely closed.

What a good penetration test report contains

The report is the deliverable — it is what you are actually paying for, and it is what your auditors, customers and board will read. A report that is just exported scanner output is a red flag.

• Executive summary — what was tested, what was found, and what it means in business terms, readable by a non-technical audience.
• Scope and methodology — exactly what was and was not tested, the dates, and the standards followed. Auditors look specifically for this.
• Findings with evidence — reproduction steps, request/response detail or screenshots, and the affected assets, so engineers can verify and fix without guesswork.
• Severity and business impact — a consistent rating scheme, with impact expressed against your environment rather than in the abstract.
• Specific remediation guidance — actionable fixes, not "apply input validation". Where a fix requires architectural change, that should be said plainly.
• Attack narrative — how individual findings chained into a meaningful compromise. This is what turns a list of bugs into an understood risk.
• Retest results — confirmation of what was fixed, which is the evidence auditors and enterprise customers actually want to see.

How often should you run a penetration test?

There is no universal interval, but there are clear triggers. Most regulated organisations settle on at least annually, supplemented by testing on significant change.

• At least annually — the baseline expectation of most compliance frameworks, including PCI DSS and common SOC 2 audit practice.
• After significant change — a new application, a major architectural change, a cloud migration, or a new authentication system.
• Before a major launch — testing before exposure is dramatically cheaper than incident response after it.
• When a customer or auditor requires it — enterprise procurement and security questionnaires increasingly demand a current report.
• After a breach or near-miss — to establish whether the original entry path, and others like it, are genuinely closed.

Annual testing alone is weak assurance for teams shipping continuously. If you deploy weekly, pair periodic deep testing with continuous vulnerability assessment so you are not blind for eleven months of the year.

How to choose a penetration testing provider

Quality varies enormously, and the difference is not visible from a quote. These questions separate genuine testing from a re-badged scan:

• What proportion of the engagement is manual testing rather than automated scanning?
• Which methodology do you follow, and can I see a sanitised sample report?
• Who will actually perform the test, and what is their experience?
• Is retesting of remediated findings included, or charged separately?
• How do you handle sensitive data discovered during testing?
• Will you be available to my engineers during remediation?
• How do you scope — by asset count, by days, or by a fixed price that does not reflect complexity?

Be cautious of quotes that are dramatically cheaper than the market without an explanation of reduced scope. A one-day automated scan sold as a penetration test will pass a procurement checkbox and leave the actual risk untouched.

Frequently asked questions

Related services

Keep reading

• How much does a penetration test cost?
• OWASP Top 10: what still matters
• Cloud misconfigurations: the silent breach
• Zero trust: a practical starting point