Who you choose to test your environment matters just as much as what they test.

Ethical Threat Insight: Internal Pentest Report Red Flags

If you know a little bit about me, you know internal pentesting is kind of my thing. I’ve done more than 120 internal pentests in the last 5 years.

What I have come to realize is that not all internal pentests are created equal, especially when it comes to reporting.

Most internal pentest reports look impressive at first glance, but after you dig into them you’ll often realize they are: shallow tests, recycled content and missed opportunities.

Here’s 3 internal pentest report red flags 🚩 to look out for:

• It looks like a screenshot dump - a wall of screenshots and little to no context suggests heavy automation not expertise. Automation ran, screenshots pasted, invoice sent. (Not ideal)
• No endpoint evaluation - only network scanning performed, end-user systems and servers ignored, no evaluation of common endpoint misconfigurations. Endpoints are often neglected during internal pentests, and as a result testers miss a critical layer of your real-world attack surface.
• No idea what TTPs were blocked/detected - you got findings, in a report, with screenshots, but no list of what activity was observed, alerted on, or blocked. As a result, your internal pentest is a black box. You know what the testers did but not what your environment saw, which creates a huge gap for you.

(Bonus) No mention of what you’ve done well - a list of problems, without recognition of any of your hard work, is not giving credit where it’s due.

If the report reads like a teardown without identifying what worked, what blocked attacks, what caused frustrations for the pentester, then the report missed the mark.

The report is a direct reflecting of the testing methodology. Here’s why…

In my experience, there are two types of internal pentests:

1. The first (old way) - the pentester sends you a device to plug in to your network, they scan around, spray some exploits and try for multiple days to get access to a valid account, likely throw a Nessus scan in there too for good measure. You get a report with some findings.
2. ​The second (best way) - a true attack simulation, originating from one of your endpoints, with a valid account, which results in identifying the worst that could happen if an attacker got in. Where could they go, what could they do, what could they access, and how bad it could be? You get remediation instructions, retesting commands, as well as advice, guidance and support, even after the pentest ends.

#2 is far more valuable, practical, and honestly way more fun (for defenders and pentesters).

#2 is the only way we do it.

So how do you avoid this?

When evaluating a pentest firm, here’s what I would do:

1. Ask for a sample report for the service(s) you’re looking for. Many times, that alone can be a sign of a solid firm or not. Look for the 3 things I mentioned above.
2. Ask to speak to the team who will be doing the work. Then when they get on the call, ask them to describe their methodology to you. Do they struggle to answer? Do they lack details and clear direction? If so, keep looking.

I promise if you do those two things, you should have a good (or bad) feeling in your gut about the firm.

If you’ve been burned before by shotty pentests and are looking for a change. I’d love to work with you.

We just opened up pentesting spots for Q1 2026.

Internal pentest reports: some make you safer, others make great coffee coasters (and sad CISOs). Choose wisely. ☕📄

All the best​
Spencer Alessi

"Spirit of a hacker heart of a defender"
​All My Links | Cybersecurity SWAG​ | Work With Me​