How Fast Should a Pentest Provider Triage and Report a Critical Vulnerability? (Benchmarks Inside)
A security director at a healthcare SaaS company found out his penetration testing provider had identified a critical vulnerability on a Tuesday. The formal report arrived the following Monday. Six days passed between discovery and delivery. In that window, the vulnerability was real, the environment was live, and no one on the internal team knew they needed to act.
He did not switch providers because of the vulnerability. He switched because of the six days.
That story is not unusual. Triage and reporting speed is one of the least-discussed dimensions of penetration testing quality, and it is one of the areas where providers vary most. Businesses tend to evaluate providers on methodology, credentials, and price. Fewer ask the question that matters most when something serious is found: how fast will we know about it?
Capture The Bug works with businesses across Australia, New Zealand, and the United States where this question has become part of every procurement conversation. The benchmarks below reflect what a genuinely responsive engagement model looks like, and where the gaps tend to appear.
Why Triage Speed Matters More Than Most Businesses Realise
A penetration test runs against a live environment. That is the point. The tester is attempting to do what an attacker would do, against real systems, with real data flows, against real infrastructure. When a critical vulnerability is found during that process, the vulnerability does not pause while the provider writes it up.
The window between discovery and notification is a window of unmanaged risk. The business is operating normally. The internal team has no reason to take defensive action. The exposure is real, confirmed, and undisclosed.
For lower severity findings, that window matters less. A medium severity misconfiguration that requires local access to exploit is not an immediate operational concern. A critical finding that allows unauthenticated remote access, exposes customer data, or breaks authentication entirely is a different situation. Treating both with the same reporting timeline is a process failure, not a policy choice.
The distinction between a provider who flags critical findings immediately and one who holds them for the final report is not minor. It reflects whether the engagement model is built around the client's security outcomes or around the provider's operational convenience.
What the Benchmarks Actually Look Like
There is no single industry-wide standard that governs triage and reporting timelines for penetration testing engagements. CREST methodology sets quality and documentation requirements but does not mandate a specific hour-by-hour timeline for critical finding notification. That means the timeline a business receives depends almost entirely on the engagement model the provider operates.
Across the engagements Capture The Bug has conducted and the client situations it has assessed, the following benchmarks represent what a well-run engagement looks like in practice.
For critical severity findings, the client should receive direct notification within four hours of the finding being confirmed. Not a draft report. Not a summary queued for the end-of-week review. A direct communication that names the vulnerability, describes the exposure, and provides enough context for the internal team to make an immediate decision about whether to suspend the affected system, restrict access, or escalate internally.
For high severity findings, notification within twenty-four hours is a reasonable standard. The finding is significant but typically does not require the same immediate operational response as a critical. The internal team should still know before the week is out, not at the end of the engagement.
For medium and low severity findings, inclusion in the structured report at the end of the engagement is standard practice. These findings matter and they need to be remediated, but they do not carry the same urgency that would justify interrupting the testing flow for direct notification.
These are not aggressive benchmarks. They represent a minimum standard for a provider whose engagement model is genuinely oriented around client outcomes rather than report delivery schedules.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
What Slow Triage Actually Costs
The cost of slow triage is not always immediate and obvious. Sometimes it is measured in days of unnecessary exposure that were entirely preventable. Sometimes it surfaces later, in a regulatory inquiry that asks when the vulnerability was identified versus when the business was notified.
For APRA-regulated entities in Australia, there are notification and incident response obligations that attach to certain classes of vulnerability. For CDR participants, the standards around data security and incident response are specific and documented. For businesses in the United States operating under HIPAA, SOC 2 requirements, or financial services regulations, similar obligations exist.
A provider who holds a critical finding for six days before notifying the client is not just providing a poor service. In regulated environments, they may be contributing to a compliance gap the client does not even know exists until an auditor asks the question.
The internal team cannot act on information they do not have. They cannot escalate, remediate, restrict access, or notify the appropriate internal stakeholders based on a report that has not been delivered yet. The provider controls the timeline. The business carries the exposure.
What the Reporting Document Itself Should Contain
Triage speed addresses the urgency question. The report quality addresses the utility question. Both matter. A fast notification that says "we found something critical" without enough context for the internal team to act is faster than nothing but still falls short of what the engagement should deliver.
For critical and high severity findings, the interim notification should include the name and location of the vulnerability, the evidence that confirms it was identified and demonstrated, the realistic impact if an external party were to exploit the same path, and an initial remediation direction specific enough to inform an immediate response.
The full report that follows should include all of the above in documented form, plus the business context that a CISO needs to communicate the finding to leadership or a board. Finding reports that use generic language, describe vulnerability categories rather than specific instances, and provide one-line remediation guidance do not meet this standard regardless of how quickly they arrive.
Capture The Bug builds both components into the engagement model at capturethebug.xyz/Services/penetration-testing. The notification timeline addresses urgency. The full documented report addresses utility. The retest process, which follows remediation, addresses verification. All three are parts of the same engagement, not separate services priced independently.
Questions to Ask a Provider Before the Engagement Begins
Triage and reporting speed should be part of the conversation before a provider is selected, not something discovered after a critical finding sits in a draft report for six days.
The questions that surface the most relevant information are direct. Ask the provider what their standard process is when a critical vulnerability is identified during an active engagement. Ask whether direct notification is part of their standard engagement model or whether it requires a separate arrangement. Ask how the interim notification differs from the full report and what is included in each. Ask whether the same tester who identified the finding is responsible for the notification and the full documentation, or whether the finding passes through an internal review process before it reaches the client.
A provider who has a clear, specific answer to all four questions has an engagement model built around the client's security outcomes. A provider who responds with vague assurances about quality and communication without naming a specific timeline does not.
At capturethebug.xyz/Services/penetration-testing, the engagement model specifies the notification standard before the test begins. Clients know the timeline they are working with before the first day of testing, not after a finding is already sitting in a draft queue.
The Benchmark to Hold Any Provider To
The simplest version of this standard is one that any business can apply regardless of the provider they are evaluating.
For a critical finding, direct client notification within four hours of confirmation is the benchmark. For a high severity finding, within twenty-four hours. For all findings, a report that is specific to the environment tested, evidenced, actionable, and written to a standard that holds up under regulatory or board-level scrutiny.
If a provider cannot commit to the four-hour window for critical findings in writing before the engagement begins, that is information worth having before a contract is signed.
The six days the healthcare SaaS security director lost were not unusual. They were the predictable outcome of an engagement model that treated triage speed as an afterthought. The switch he made was not about finding a provider with better credentials on paper. It was about finding one where the engagement model was built around what happens when something serious is found, not just around what the final report looks like.
That is the standard every penetration testing engagement should be held to.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
How quickly should a penetration testing provider notify a client of a critical vulnerability?
A well-run engagement model should include direct client notification within four hours of a critical finding being confirmed during an active test. This is not the final report. It is a direct communication with enough detail for the internal team to make an immediate operational decision, including whether to suspend the affected system or restrict access while remediation is prepared.
What is a reasonable timeline for high severity finding notification?
For high severity findings that do not require immediate operational response, notification within twenty-four hours is a reasonable standard. The finding is significant and the internal team should know before the end of the current business day, not at the conclusion of the engagement. Medium and low severity findings are typically included in the structured final report.
What should an interim critical finding notification include?
At minimum, it should include the name and location of the vulnerability, the evidence that confirms it was identified and demonstrated in the test environment, the realistic impact if exploited externally, and an initial remediation direction specific enough to inform an immediate response. A notification that only names the vulnerability without context does not give the internal team enough information to act.
Are there regulatory implications if a provider delays notifying a client about a critical finding?
Yes, in regulated environments. APRA-regulated entities in Australia, CDR participants, and businesses operating under HIPAA or SOC 2 requirements in the United States have specific obligations around incident response and vulnerability management. When a provider holds a critical finding before notifying the client, the client is operating with unmanaged exposure they cannot act on. In a regulatory inquiry, the gap between discovery and notification is a documented timeline, not a procedural detail.
How is an interim notification different from the full penetration testing report?
An interim notification addresses urgency. It provides enough information for the internal team to take immediate action on a critical or high severity finding before the full engagement is complete. The full report addresses utility. It documents all findings with environment-specific evidence, actionable remediation guidance, and business context written to a standard that holds up under regulatory or board-level review. Both are part of the same engagement, not separate deliverables.
What questions should I ask a pentest provider about their triage and notification process?
Ask what their standard process is when a critical finding is identified during an active engagement. Ask whether direct notification is included in their standard model. Ask what the interim notification contains versus the full report. Ask whether the same tester who found the vulnerability is responsible for the notification and documentation, or whether it passes through an internal review queue first. A provider with a clear answer to all four questions has an engagement model designed around client outcomes.
Is there an industry-wide standard for penetration testing triage timelines?
There is no single mandated hour-by-hour standard across the industry. CREST methodology sets quality and documentation benchmarks but does not specify exact notification windows for critical findings. That means the timeline a business receives depends on the provider's engagement model. Asking for the provider's critical finding notification commitment in writing before the engagement begins is the most reliable way to understand what they are actually committing to.
