Should Pentesters Report Out-of-Scope Findings?

Every penetration test starts with a defined scope. A list of IPs, domains, or applications the client has authorized for testing. It sets expectations, protects both parties legally, and keeps the engagement focused. Scope serves a real purpose, and we respect it.

But here is a question that keeps coming up on our team at Thoropass, and one we think the industry does not discuss openly enough: what happens when reconnaissance surfaces something critical on an asset that sits just outside that boundary?

The honest answer is that most pentesters face this more often than they admit. And the instinct to say "it's out of scope, not my problem" is understandable, but it deserves scrutiny.

Attackers do not read your Statement of Work. When a threat actor begins planning a campaign, they start by mapping the entire ecosystem around the target: subdomains, related infrastructure, third-party integrations, adjacent applications. They are not constrained by the URL you handed your security team. They will find what is next door, and they will use it to get in.

A pentest that artificially blinds itself during reconnaissance is less realistic and less valuable than one that acknowledges this reality.

‍

Our Methodology: Where We Draw the Line

The position we have landed on at Thoropass is one we believe is both defensible and aligned with how real attacks unfold: scope defines where we actively test and exploit, not what we are allowed to see.

Reconnaissance is part of any serious methodology. During the information gathering phase of every engagement, we collect publicly accessible information about the target, including subdomains, email addresses, and technology stacks, using techniques like OSINT, Google Dorking, and passive enumeration methods. We explain this explicitly during scoping calls. It is step two of our standard process, and it does not stop at an arbitrary domain boundary.

When that recon surfaces a clear exposure on a closely related asset, staying quiet is negligence. If we spot something and say nothing, we have failed the client regardless of what the SOW says.

What we do instead is straightforward. We flag the finding, explain exactly how we found it, usually through purely passive means or incidentally to work already within scope, and give the client the information they need to understand the risk. Then we let them decide. They can expand the scope and have us validate it formally, include it as an informational finding, or simply take the heads-up and handle it internally. The decision stays with them.

A recent example illustrates this well: during a passive reconnaissance phase, one of our pentesters identified a hardcoded credential embedded in client-side JavaScript on an asset adjacent to the one under test. The credential exposed sensitive authentication mechanisms that could have been leveraged to gain unauthorized access to backend services, a critical risk by any standard. Strictly following scope rules, we had no mandate to report it. Instead, we notified the client, explained the finding and how we came across it, and asked how they wanted to proceed. That conversation led to the issue being addressed before it could be exploited.

This is increasingly relevant as AI accelerates the reconnaissance phase of our engagements. Our AI-powered tooling can now enumerate related assets and surface interesting signals around the primary target faster than ever, which means findings like this are becoming more common, not less. The speed gains let us keep our human effort focused on the main scope, where the depth of testing matters most, while still maintaining visibility into the surrounding environment.

‍

Not everything that surfaces during recon clears the bar

The threshold we apply comes down to two questions. First, how severe is the finding? A hardcoded credential or an exposed admin panel on a related asset is worth flagging. A minor misconfiguration on a loosely connected subdomain probably is not.

Second, how closely related is the asset to the one we were hired to test? Something that shares the same domain, infrastructure, or user base is part of the same risk surface. Something that happens to be owned by the same company but operates independently is a different conversation.

There is also the liability question. Pentesters sometimes worry that flagging something outside scope exposes them legally, and clients sometimes wonder whether receiving that information creates obligations they were not prepared for. The real risk actually runs the other way. A pentester who observes a critical exposure and says nothing has withheld information that could have prevented a breach.

A client who is never told about a vulnerable adjacent asset cannot make an informed decision about their own risk, and this is particularly true for organizations that do not yet have mature External Attack Surface Management programs in place, whether that is a startup working with a lean security budget or a growing team that has not yet built full visibility into their own perimeter. Transparency, paired with a clear explanation of how the finding was discovered and a firm boundary around what was and was not tested, is far safer for both parties than silence that looks like compliance.

‍

Our Recommendation to Clients: Let Your Pentester See Next Door

If you take one thing from this post, let it be this: give your pentesters room to tell you what they see outside the fence.

This is not a pitch for a larger engagement or more billable hours. We are not asking to test everything in your infrastructure. We are asking for the ability to say "we noticed something over here, and you should know about it," and for that not to be treated as overreach.

The best security partnerships are advisory ones. A pentester who flags a critical exposure on an adjacent asset and then lets you decide what to do with it is doing exactly what a trusted advisor should do. A pentester who stays silent because it was not in the SOW is giving you a false sense of coverage.

Scope exists to focus the work. It should never become a reason to withhold information that could prevent a breach.

When your pentester finds something next door, listen. You still decide what happens next.

‍