Penetration testing is an authorized, simulated attack on agreed systems. It shows which weaknesses in your web applications, APIs, networks and servers an attacker could actually exploit, with evidence your team can reproduce and fix.
Penetration testing, defined
A penetration test, or pentest, is a security assessment in which a tester attempts to exploit weaknesses in systems the owner has authorized, within agreed limits. The aim is to show what an attacker could achieve, not only what might be wrong.
That is the difference from a vulnerability scan. A scan compares what it can see against known issues and reports possible weaknesses. A penetration test tries to use those weaknesses, chains them where it can, and records the impact it demonstrated and how to reproduce it.
The result is a report: the tested scope, method and dates; each finding with its evidence, severity rationale and remediation guidance; and the limitations of what was and was not tested. A clean report shows that the tested scope resisted the tested attacks, not that no vulnerability exists.
What a penetration test covers
The scope names the targets and what the tester may do to them. Common targets are web applications, APIs, networks and server infrastructure. A cloud configuration review is a separate activity from testing a server that happens to run in the cloud.
Internal and external describe reachability. An external test targets systems reachable from the internet. An internal test starts from inside the network, through an approved access path, and asks what an attacker or a compromised account could reach from there.
| Approach | What the tester receives | What it answers |
|---|---|---|
| Black-box | No credentials or internal documentation | What an outside attacker can reach and exploit |
| Grey-box | Test accounts and some context, such as roles or API specifications | What an authenticated user, or someone holding their session, can do |
| White-box | Extensive access, such as source code and architecture details | Where weaknesses sit in the design and code |
How a penetration test works
Public methodologies such as the OWASP Web Security Testing Guide and NIST SP 800-115 describe the work in similar stages. Providers name them differently, but a credible engagement covers each one and records what happened.
- Authorization and scope: written permission from the target owner, the agreed targets, roles, permitted actions and test windows.
- Discovery: mapping the reachable surface, such as hosts, services, pages, endpoints and parameters.
- Analysis: identifying weaknesses, including business rules such as who may see or change a record.
- Exploitation: attempting the attack within agreed limits and recording the request, response and impact.
- Review and reporting: confirming each finding, rating severity with a stated rationale and writing remediation guidance.
- Remediation and retest: your team fixes the issue and the tester verifies the correction.
Penetration testing compared with other security tests
These activities answer different questions, and many organizations need more than one. Choose by the question, then compare providers on the evidence they deliver.
| Activity | Question it answers | Typical output |
|---|---|---|
| Vulnerability scan | Which known weaknesses may be present? | A list of possible issues, usually without proof of impact |
| Penetration test | Which weaknesses can be exploited, and with what impact? | Reproducible findings with severity, evidence and remediation |
| Red team exercise | Can an attacker reach a defined objective, and would we detect it? | An attack narrative and detection and response observations |
| Code review or SAST | Where does the source code allow a weakness? | Code-level issues, which still need runtime confirmation of impact |
How often to run a penetration test
Many organizations test at least once a year and after significant changes to an application or infrastructure. Some standards set a cadence: PCI DSS v4.0.1 Requirement 11.4 calls for internal and external tests at least once every 12 months and after significant change. Others, such as SOC 2 and ISO/IEC 27001, leave the method and frequency to your risk assessment and assessor.
Release frequency matters too. A team that ships weekly changes its attack surface faster than an annual test can follow, so targeted retests after significant changes help close the gap.
What to check before you buy
Ask to see a sample report before you sign. It shows the depth of evidence, how severity is justified and whether a named person approved the findings. Then confirm the commercial terms against your scope rather than a headline price.
- Who authorizes the test, and how scope changes are agreed.
- Who performs the testing, and who reviews and approves each finding.
- Which methodology is followed, and how coverage and limitations are recorded.
- What evidence each finding carries, and whether your team can reproduce it.
- What retesting is included, and for how long.
ShieldProbe Assess tests agreed web applications, APIs, networks and servers, internal or external. AI authors findings and a named consultant approves each one before you see it. Agreed scope can be reported in 48 hours once access is ready, under the engagement terms.
Primary references
- OWASP Web Security Testing Guide
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- PCI SSC document library: PCI DSS v4.0.1
Standards change, so check the current version of each source when you plan your own testing.
Before you commission a test
- Write down the targets, roles and permitted actions.
- Choose black-box or grey-box access for each target.
- Ask who reviews and approves each finding.
- Agree the report contents and retest terms.