Your pentest report has one finding. Was that good news or a bad test?

I recently saw a LinkedIn post describing a penetration test that cost $15,000 and resulted in a single finding: a cross-site scripting issue demonstrated with an alert box that just said “hi.”

Fifteen grand for a pop-up greeting. Hallmark should consider expanding into cybersecurity.

The most concerning part was not that the report read like a hastily scribbled sticky note. It was the follow-up. According to the post, the executive team reviewed the report and actually felt reassured.

Beyond the false sense of security, there is a secondary disaster that unfolds slowly. It is a downstream tax that hits three different desks: the engineers trying to triage the finding, the risk team trying to assign a severity, and the auditor trying to verify compliance. A lazy proof of concept does not just fail to answer the right questions. It actively generates work for everyone who touches the report after the pentester has cashed their check.

First, a Somewhat Contrarian Take

Pentesters often mock the classic alert(1) proof of concept. It has become shorthand for shallow testing. But to be fair: an alert box is not inherently wrong.

An alert box visually proves that arbitrary JavaScript executed in the victim’s browser. In real-world XSS scenarios, malicious code runs silently in the background. There are no visual cues or elements that make for a pretty screenshot. There is only token theft or background requests the user never sees. Using an alert provides an undeniable signal that execution occurred. For developers observing the test, it makes the vulnerability tangible. It answers the binary question: Did code run?

The problem is not the alert. The problem is stopping there.

What Gets Lost When You Stop at “Hi”

When a proof of concept ends with a pop-up, the most important questions are left unexplored. And the cost of that omission does not stay in the pentester’s lane. It spills over onto the desk of the engineer who has to act on it.

A XSS that pops an alert looks harmless. Most devs see it and cannot immediately envision what damage it could cause, so it mentally gets filed away as low risk. But what if that injection point can be chained with another weakness? What if it can be converted into stored a XSS or used to access tokens from localStorage?

The engineer staring at alert("hi") does not know any of that without a demonstration of actual impact. Rather than the creative work of crafting a impactful proof of concept being done by the tester, that burden is left to the developer. It becomes an impromptu threat modeling exercise for whoever picked up the ticket. Usually, someone who does not have the attacker’s perspective required to do it well.

Severity is easily misjudged when a proof of concept fails to demonstrate what is actually exploitable. The finding either gets over-prioritized because nobody wants to bet wrong, or under-prioritized because it looks like a harmless pop-up. Neither outcome is good. One creates unnecessary remediation urgency. The other buries a real risk.

A skilled tester does not stop at Can I execute JavaScript?, but asks, What can I do with this? That answer is what lets an engineering team make an informed, defensible decision about how urgently to act.

The Ripple Effect

The final invoice for a lazy pentest arrives months after the check has cleared. It comes when the report lands in an auditor’s inbox. An auditor reviewing a report as part of a SOC 2 or ISO assessment is trying to answer one question. They need to know if the evidence demonstrates that meaningful testing occurred.

The result is an endless back and forth. Meeting time is spent debating a single pop-up. Emails are exchanged to explain details of risk that were glossed over in the report. The auditor has to waste billable time determining if they are looking at a bad pentest or an organization trying to wave away a legitimate finding. And when they realize the pentest was indeed garbage, they are apt to suggest their client find a new partner who won’t waste everyone’s time next year.

A lazy proof of concept is not just incomplete. It is work that has been offloaded from the pentester onto the engineers who triage it, the risk team that has to assign it a severity, and the auditors who have to validate it. The $15,000 fee bought a document that created more work than it resolved.

What a Meaningful XSS Proof of Concept Should Show

A strong XSS proof of concept demonstrates risk in a controlled way.

That might include extracting session identifiers or demonstrating how an attacker could issue authenticated requests without user awareness. It could involve simulating a phishing scenario by rendering a fake timeout modal that collects credentials, or showing how a victim can be silently redirected to a malicious site.

A meaningful proof of concept shows developers exactly what is at stake, gives executives a grounded understanding of risk, and gives auditors evidence they can actually rely on.

It also pushes beyond trivial payloads. Real attackers do not limit themselves to basic <script> tags. They test alternative vectors, attempt filter bypasses, encode payloads, and evaluate whether client-side protections like content security policies actually work. Demonstrating that filters can be bypassed or that defenses are brittle provides far more value than a single finding, and is far more likely to drive real remediation.

A good pentest does not stop at proof of execution. It explores exploitability. This depth is what transforms a report from a bureaucratic obstacle into a security asset.

The Single Finding

There is another dimension to this story. The report reportedly contained only one issue.

It is absolutely possible to test an application thoroughly and find very little. Some teams genuinely bake security into the design process. They validate inputs carefully, enforce strong authentication, implement proper session handling, and have thought through access control from the start. When security is shifted left into architecture and design, results improve.

But when a report contains a single finding with a minimal proof of concept and nothing else, it raises a fair question: Was the application exceptionally secure, or was the engagement exceptionally shallow?

Mapping to ASVS Changes the Dynamic

Most penetration test reports stop at listing vulnerabilities. This leaves a massive gap in the narrative, especially when findings are limited.

Conducting the web app penetration test using the OWASP Application Security Verification Standard provides the missing structure. When testing follows a recognized standard, silence in a category signals that controls were reviewed and found sufficient. It proves they were not simply ignored.

An ASVS-informed report also helps trace vulnerabilities back to specific control deficiencies. Instead of a stand-alone issue, the finding is anchored to a recognized security expectation. That strengthens conversations with auditors, and gives developers a clearer understanding of why the issue matters and what needs to change.

Just as importantly, it documents what the team did well. If authentication controls are strong, if session invalidation works correctly, if access controls are consistently enforced, that should be captured. A good report does not just highlight weaknesses, but also validates strengths. And when findings are sparse, that structured coverage is what proves the work was comprehensive.

The High Cost of Easy Answers

Executives want reassurance. That is reasonable. They are accountable for risk and compliance. But reassurance should come from demonstrated rigor rather than the absence of findings in a thin report. It should come from evidence that attack paths were explored, controls were evaluated against recognized standards, and impact was thoughtfully assessed.

Reassurance should not come from the absence of serious findings in a thin report.

For teams preparing for SOC 2 or ISO reviews, the goal is not merely to obtain a pentest report. It is to obtain credible evidence that meaningful testing occurred.

A report should satisfy an auditor’s skepticism rather than fueling it. It should provide stakeholders with a clear view of risk without burying them in jargon. Most importantly, it should give developers a roadmap they can actually follow.

An alert box can be a useful first step in demonstrating an XSS visually. It should never be the final word. And the pentester who makes it the final word is not just delivering an incomplete report. They are quietly billing the rest of the cost to everyone else in the room.

The Checklist Your Auditor Wishes You Had

If your current reports leave auditors asking follow-up questions, it is time to raise your expectations.

Our free guide, Audit-Proof Your Pentest, gives you 17 questions that reveal whether you are working with a real security partner or just another checkbox vendor.

Learn how to spot shallow testing hidden behind polished reports, identify red flags in communication, and choose a partner who delivers evidence your auditor will actually trust.