The Pen Test Report That Changes Nothing
The testing vendor delivers a 70-page PDF. It lands in a shared mailbox, gets forwarded to the compliance team, and the critical findings are emailed to the infrastructure lead. Three of those criticals were in last year’s report under different vulnerability IDs. The report is a compliance artifact. Compliance buys a test to hand to a SOC 2 auditor or a cyber insurance underwriter. Security needs a fix. Different line items, different buyers, different definitions of done.
What the scoping call actually decides
The scoping call is 45 minutes, and forty of them are spent taking things out. The enterprise architecture team provides a list of IP ranges to exclude. The legacy ERP environment, the warehouse management system, the physical security badge servers. The stated reason is operational stability. A basic port scan might knock over a fragile print spooler service and stop shipping labels from printing at a regional distribution center.
The system owner carries operational risk. The security team carries compliance risk. The system owner wins the scope argument every time. But you scoped out the system that holds the data because it is the system that holds the data. Fragile and valuable are the same property, described by different people. The exclusion list is a risk register with better formatting. A clean report is a statement about the scope, not the security.
The finding has no name next to it
The report says what is broken. It does not say who pays. A high-severity finding lands in a ticket queue owned by infrastructure. The corrective action requires an application change, but the application is under vendor support and its next approved release window is months away. The finding has a severity, a description, and a recommendation. It does not have a name next to it.
Security teams buy the test and receive the report. Infrastructure and application teams have to do the unfunded work to fix the findings. Decoupled budgeting ensures that vulnerability discovery is funded out of the CISO’s budget, while vulnerability remediation requires hours funded by the CIO’s or CTO’s budget. A vulnerability assigned to a team with no sprint capacity is just an observation. Findings cannot create projects. Projects come from the portfolio. The finding has to arrive there with a cost and a sponsor, or it dies in the register.
The same bug, a new ID
At a steering meeting, a risk owner accepts a finding for another year. The record names the business process and the reason a patch cannot be applied. It does not say who is paying for the compensating control, when it will be installed, or what evidence would let the organization retire the exception. An accepted risk without an expiry is a deleted risk with paperwork.
Then comes the retest. The vendor re-runs the exact request from the original finding. It returns a 403 now. The report says closed. The same header-trust pattern exists in three other services. The retest verifies the instance, not the class. Or the vendor applies a patch, claims stop processing, the patch is rolled back in four hours, and the finding returns next year with a new ID. The same finding with a new ID is not a new finding. It is a new invoice.
Assumed breach changes the first move
If the next test is expected to produce the same finding, the organization needs to ask a different question. Stop buying red team engagements to validate the lack of a patch management program. You do not need an elite group of ethical hackers to tell you that developers are hardcoding credentials in Git repositories.
Shift from validating the perimeter to validating the attack path. Give the testers a standard corporate laptop image and a valid credential and drop them on the corporate VLAN. The question is no longer whether they can get in. It is how far they can get laterally, and whether anyone sees them. The attacker gets a phish. Your tester got a read-only account and a network diagram from 2019. Assumed breach changes the starting condition.
Purple team output has a home
Prevention testing, detection testing, and response testing ask different questions and require different outputs. Most enterprises only buy the first.
Run a purple team session. Put the external attackers on a live call with the internal SOC. The attacker runs a known technique. The defender checks the SIEM. There is no rule. The defender writes one that afternoon. The output is a rule, a name, and a two-week deadline. Detection has an owner. Prevention has a committee. The pentest output is a PDF that belongs to no one. The purple team output is a detection rule owned by the SOC.
The report is a list of decisions
A penetration test captures a single moment in a negotiated scope. The attack path is the actual environment. The report is just a list of decisions you have not yet made.
Takeaways
- Scoping exclusions are risk decisions, not operational necessities
- Findings need a cost and a sponsor to become remediation projects
- Assumed-breach and purple-team testing produce owned outputs
Questions
- Why do penetration test findings repeat year after year?
- The same findings return because scoping excludes the fragile systems that hold the data, findings are not assigned to anyone with budget to fix them, and retests verify the specific instance rather than the class of vulnerability.
- What is the difference between a penetration test and a purple team exercise?
- A penetration test produces a PDF report that belongs to no one. A purple team exercise puts attackers and the SOC on a live call, producing a detection rule owned by the SOC with a deadline.
- How should organizations scope a penetration test differently?
- Instead of validating the perimeter, give testers a standard laptop image and valid credentials on the corporate VLAN, then measure how far they can get laterally and whether anyone sees them.