Scope a first penetration test to one internet facing application or API, write down the goals and rules of engagement, clean up easy findings beforehand, and plan time for fixes and a retest. A narrow, well defined test teaches more than a broad vague one.
What a penetration test is for
NIST SP 800-115 describes its purpose as helping organizations plan and conduct technical security tests, analyze findings and develop mitigation strategies, including finding vulnerabilities and verifying compliance with a policy. A penetration test is a person actively trying to break in, within agreed limits. It is different from an automated scan, which lists known issues but does not chain them.
Decide why you want one
| Reason | What it changes |
|---|---|
| A buyer asked for one | Scope what the buyer cares about, and ask what report format they accept |
| You launched something new | Focus on the new feature and its data |
| You want an independent view | Pick your riskiest app and let the tester choose paths |
| Compliance mapping | Check the framework text for what it actually requires |
Do not buy a test only because a competitor claims one. Know your reason first.
Scope in four decisions
- Targets. List the exact application, API base URLs and environments. Prefer a staging copy with realistic data, and say whether production is in or out.
- Depth. Unauthenticated only, or with test accounts at each role? Role testing finds the access control bugs that matter most.
- Methods. Say what is off limits: denial of service, social engineering of staff, physical access.
- Timing and contacts. Test window, a named contact on your side, and an emergency stop rule.
Put it in a short written agreement with the tester. Get permission from any hosting or third party provider whose terms require notice.
Prepare first
Fix what a scanner already finds, so the tester's time goes to deeper issues. Prepare test accounts, documentation of the main flows, and a list of known weak areas. Tell your team so alerts from the test are not mistaken for an attack, or are mistaken on purpose if you want to test your detection.
Reading the report
Ask for findings with reproduction steps, impact in plain words and a fix suggestion. Triage by exposure and impact, not label alone. Put each accepted finding into the backlog with an owner. Record any you accept, using a risk acceptance record.
Retest
Budget time to fix and then ask the tester to confirm the fixes. A report without a retest leaves you guessing whether the fix worked.
How often
Annually for your main customer facing app is a common rhythm, and again after major changes. Automated scanning between tests keeps the baseline clean. See the demo for how a web scan looks.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Run the scan and compare what an automated test reports with what a human tester would chain together.
Quick check
Is a vulnerability scan the same thing?
No. A scan automates checks for known issues. A penetration test is human led and chains weaknesses.
Should we test production?
Often a staging copy is safer. If you test production, agree limits and a stop rule in writing.
Sources
Last reviewed: 19 October 2026.
