Time to revoke: the two timestamps a closed ticket cannot give you

The instrumentation demand hides in the word "confirmed". Both ends of the interval are checks against the credential's issuer rather than events in your own workflow: the clock starts when the organisation verifies that the credential works, and stops when it confirms the credential can no longer be used ^[3]. A ticket queue records neither of those. It records that somebody said so, and the guide is explicit that closing a ticket, deleting a file or removing the secret from a repository does not stop the clock ^[4].

Four timestamps per incident give you three consecutive intervals ^[1]: detection to validation is triage, validation to owner assignment is routing, owner assignment to invalidation is the work ^[6]. Time to revoke as defined covers only the second and third of those, because it begins at validation and not at detection ^[2]. That is a deliberate choice, and it has a side effect: a team sitting on a large pile of never-validated findings can post a respectable median. The guide's remedy is the companion number in the same reporting set, the percentage of exposed secrets that remain valid after detection ^[7].

Median and P90 are meant to be read as a pair. The median is chosen precisely because a handful of extreme outliers does not move it ^[8], which is another way of saying it will not show you the incidents that matter most. P90 is where the guide puts the risk: secrets with unclear owners, sensitive access, or operational dependencies that keep them valid too long ^[9]. Owner coverage is what tells you which of those three the tail actually is. If coverage is high and P90 is still long, the problem is technical dependency, not routing.

The SLA tiers only work downstream of two decisions someone has to make before any clock can be graded: whether the credential is valid, and how sensitive the access is. The examples given are hours for critical valid production secrets and one business day for high-risk valid secrets ^[10]. And the escalation count in the same set ^[7] is the most honest line on the report, because it counts the cases where the pipeline did not resolve the incident on its own.

This is also why the metric cannot be folded into existing dashboards. MTTD answers how quickly a secret was found ^[12]. MTTR depends on the local definition of resolution, which the guide says can be a closed ticket, a cleaned file, a merged pull request or a completed rotation ^[11]. A secret can be scrubbed from a repository, cleaned out of a pull request or deleted from a local file while the credential itself still authenticates ^[13], so a healthy MTTR and a live API key, cloud credential, service account token, OAuth secret, private key or database connection string are entirely compatible ^[14]. The guide follows an earlier piece in The Hacker News that introduced time to revoke as a CISO metric; this one is the measurement version ^[15].