What a Penetration Test Actually Finds (and How to Act on It)

A scan is not a test

The most common misunderstanding we correct in kickoff calls is that a vulnerability scan and a penetration test are the same purchase at different price points. They are not. A scanner is an automated tool that compares your systems against a database of known signatures and returns a list of findings, usually ranked by CVSS score. It runs in hours, it runs on a schedule, and it never asks whether two low-severity findings can be combined into a critical one. It is a necessary hygiene control, and it belongs in a continuous vulnerability management program.

A penetration test is a human exercise. A tester takes the same starting position an attacker would and tries to reach a defined objective: domain admin, a customer database, funds movement, whatever matters to your business. The scanner tells you a door is unlocked. The tester walks through it, finds the key to a second door behind it, and tells you the two together expose payroll. That difference — signatures versus reasoning — is the entire value.

If a "pen test" report you receive is just cleaned-up scanner output with a logo on the cover, you bought a scan. Real testing produces evidence of exploitation, not a probability that exploitation might work.

What a real tester actually finds

Automated tools are good at breadth and bad at context. Human testers spend their time on exactly the things a scanner cannot reason about.

Chained attack paths

The signature findings are rarely the story. A single medium-severity issue looks ignorable in isolation; the finding that matters is the sequence. A typical chain we report looks like this:

1. A forgotten staging server exposed to the internet, discovered through attack surface management rather than in the asset inventory.
2. Default credentials on that server's admin console.
3. A configuration file on disk containing a service account password.
4. That service account reused with local admin rights across the production fleet.

No individual step is dramatic. The chain hands over the environment. Scanners report the four items as separate rows, often at different severities, and the relationship between them — the actual risk — never appears.

Business-logic flaws

These are defects in how your application is supposed to work, so no signature exists for them. Examples we find repeatedly:

• Changing an account number in a request URL and viewing another customer's invoices (broken object-level authorization).
• Applying a discount code an unlimited number of times, or after it expired.
• Completing a multi-step checkout by skipping the payment step and posting the confirmation request directly.
• Escalating from a standard user to an administrator by editing a role value the server trusts without re-checking.

A scanner cannot know your business rules, so it cannot know when they are broken. This is where manual application security testing earns its cost.

Weak, reused, and default credentials

Credentials remain the front door. The Verizon DBIR has for years attributed a large share of breaches to stolen or weak credentials, and testing confirms it constantly. Testers find service accounts with passwords that never expire, shared local admin passwords identical across every workstation, credentials committed to a code repository, and MFA that is enabled for email but not for the VPN. Password spraying one common password against every account often succeeds before lunch.

Misconfiguration and drift

Most environments are not compromised through exotic zero-days; they are compromised through defaults nobody changed and settings that drifted over time. Overly permissive cloud storage, unsegmented networks where one compromised laptop can reach the database, legacy authentication protocols left enabled, and firewall rules added "temporarily" three years ago. These are the findings that make an attacker's job trivial, and they are the cheapest to fix once you can see them.

How to read the report

A good report is structured for two audiences. The executive summary should be readable by someone non-technical and answer one question: how bad is it, in business terms. The technical body should let your engineers reproduce every finding.

For each finding, look for four things:

• Business impact, not just a CVSS number. "Remote code execution on a test box with no data" and "read access to the customer database" can carry the same score and radically different urgency.
• Reproduction steps detailed enough that your team can trigger the issue and, later, confirm it is gone.
• Evidence — request and response captures, screenshots, extracted data samples — proving the tester actually did it rather than theorized it.
• Specific remediation, ideally naming the configuration or code change, not a generic "apply patches."

Be more suspicious of a thin report than a thick one. A test that finds "no critical issues" on a complex environment usually means limited scope or limited effort, not that you are secure.

Prioritize, fix, and retest

A report is an input, not an outcome. The work is what you do next.

1. Triage by exploitability and impact together. A critical finding an attacker can reach from the internet outranks a critical one that requires physical access to your server room. Fix reachable-and-damaging first.
2. Fix the root cause, not the instance. If a reused service-account password was the pivot, rotating that one password is not the fix; the fix is removing password reuse and moving privileged accounts under privileged access management.
3. Feed patterns back into the program. A recurring class of finding — say, broken authorization — is a signal to change how you build and review, not just to patch the three instances found.
4. Retest. Reputable providers include a remediation retest that verifies your fixes against the original reproduction steps. Without it, you have a list of intentions, not confirmed closures. Track every finding to closure with an owner and a date.

Expect the highest-severity items to close in weeks, not quarters. If your remediation timeline routinely stretches past a quarter, the constraint is usually process, not engineering.

Pen test vs. red team

These get used interchangeably and should not be. The difference is objective.

• A penetration test aims for coverage of a defined scope in a defined window. Success is a thorough map of what is exploitable across that scope. You want breadth and a clear report.
• A red team aims for a single objective — reach the crown jewels — while staying undetected, and it deliberately tests your detection and response as much as your defenses. Success is measured in whether your security operations team noticed and how fast they reacted.

Sequence matters. Running a red team before you have handled the findings from a straightforward pen test wastes money proving what a cheaper test already told you. Most organizations should get penetration testing into a regular cadence — at least annually and after significant change — before investing in adversary emulation.

Where this fits

A penetration test is a point-in-time measurement. It is most valuable inside a program that already runs continuous scanning, tracks its external footprint, and closes findings on a clock. Testing without that program produces a report that ages the moment it is delivered; testing with one produces steadily shrinking attack surface year over year.

If you want a test scoped to what actually matters to your business — with evidence, prioritized remediation, and a retest that proves the fixes held — our team runs penetration testing for organizations across the US. Contact us to scope an engagement.