Short answer: Time to Proof (TTP) is the elapsed time from the moment a penetration test scope is authorised to the moment the first critical or high finding has been reproduced with evidence. It measures how fast a test produces something a team can act on, not how long the engagement lasts. Metric defined by Barrion, 2026-09-26.
What is the Time to Proof formula?
TTP = t(first reproduced critical or high finding) − t(scope authorised)
t(scope authorised) is the timestamp at which targets, credentials and rules of engagement were approved. The finding timestamp is the moment reproduction succeeded, not the moment of first discovery. If a test produces no critical or high finding, TTP is reported as "none within" the run duration, never as zero.
Why measure proof instead of duration?
Duration hides the wait. A traditional engagement often delivers the report weeks after kickoff, and the first critical finding may have been exploitable on day two. TTP measures the gap between authorisation and the first proven finding someone can act on.
Because only reproduced findings stop the clock, a fast list of maybes doesn't improve the number. The reproduction rule is the same one behind proof-backed pentesting.
Measurement rules
| Rule | Detail |
|---|---|
| Start | Scope authorisation timestamp, not the kickoff call, the contract or the first request |
| Stop | Reproduction success for the first finding rated critical or high on the report's own scale |
| Severity | Use the report's published severity scale, recorded before the run |
| Reproduction | The finding was re-run after discovery and produced the same result. The reproduction timestamp is the stop |
| No qualifying finding | Report "none within" the run duration, and state that duration |
| Variants | TTP-report: time from authorisation to release of the full reviewed report. TTP-fix: time from authorisation to a passed retest of the first critical finding. TTP-change: see below |
| Aggregation | Report the median across runs and the sample size. Don't average across different levels or scopes |
What is TTP-change?
TTP-change is the continuous variant. It starts the clock when the app changes instead of when scope is authorised:
TTP-change = t(first reproduced critical or high finding) − t(change deployed or detected)
It only exists for teams that test continuously. If your pentest runs once a year, there's no run tied to a given change, so there's nothing to measure. For a team whose pentests run on a schedule or when a change is detected, TTP-change answers the question that matters after a release: how long did a new critical or high issue sit in production before someone had proof of it?
The same rules apply. The stop is reproduction, not first discovery, and a run with no qualifying finding reports "none within" its duration. Use the deploy timestamp where you have it, and the detection timestamp when the run was triggered by a detected change. Continuous AI pentesting explains how those runs are triggered.
How do you read a TTP value?
A TTP of 3 hours means an exploitable critical issue was proven 3 hours after the team said go. A TTP of 14 days means the same issue existed, unproven, for two weeks.
Only compare TTP between tests with the same scope type, for example web application tests with authenticated roles. And always read it next to coverage, since a narrow test can post a fast TTP. For how turnaround differs between AI and manual testing, see AI vs manual pentesting.
How Barrion does it
In Barrion, you authorise scope in the dashboard before any request is sent, and every run is timestamped. Every finding is checked against your live app before it's reported. Confirmed findings come with the request and response that prove them, and anything we couldn't confirm is clearly marked and capped in severity, so it wouldn't count toward TTP. We don't show TTP in the dashboard yet.
A run finishes within hours, and from Standard level up the reviewed report follows within one working day. The current figures are on the facts page.
Sources
All sources checked 2026-09-26.
Barrion, metric of record, facts page and AI pentesting