Three Numbers a Protective Program Must Report

Detection time is the interval between the moment a threat indicator exists somewhere observable and the moment the program knows about it. The clock starts at the earliest time the indicator was discoverable, not the time an analyst happened to look. That rule is unpopular, because it charges the program for every hour an indicator sat in a forum, a court filing, or a dark web listing before anyone saw it. It is also the only rule that measures detection rather than shift coverage.

I engineered a protective intelligence platform for 18 executive principals that integrated real-time open-source monitoring, dark web surveillance, and social media threat detection. Mean time to threat identification fell from 72 hours to under 4. The 72-hour baseline was not a failure of the analysts; it was the arithmetic of manual sweeps on a rotation. The improvement came from changing how soon the clock was answered, not from asking people to look harder.

Report detection time as a distribution, not only a mean. A program with a four-hour mean and a two-week tail has a tail problem, and the tail is where the loss lives. The Cybersecurity Framework's Detect function is defined as possible attacks and compromises being found and analyzed; the tail is the set of things found late enough that analysis no longer helped.

Response time starts when the program is notified and ends when a trained responder is acting on the incident under a defined protocol. Both ends need a rule. Notification is the timestamp on the call or alert, not the moment a supervisor decided it was real. Acting under protocol means the responder has reached the point in the escalation pathway where the incident's category says they should be, not the moment someone left a desk.

I reduced average incident response time across 24/7 branch and corporate-site operations by 75%. Four changes produced it, and none of them was speed for its own sake. Dispatch protocols were redesigned so the first call carried the information a responder needed. Escalation pathways were defined by incident category, so no one had to decide who to call. Field communications were hardened so the call went through. Every response was reviewed afterwards. The review is the part programs skip. A response time that is measured but never examined stops improving within a quarter.

NIST SP 800-61 Revision 3, published in April 2025, argues that lessons learned during incident response should be shared as soon as they are identified rather than held until recovery concludes. The same applies to response time. The number belongs in the after-action review of the incident that produced it, not in a monthly dashboard nobody reads.

Two distortions to watch for. The first is category creep: when response time is reported, supervisors start classifying incidents into the category with the longest allowable response, and the number improves while the protection does not. The cure is to fix the category at intake, from the caller's description, and to audit a sample of classifications each month. The second is the stopped clock: a response that never reaches protocol because the incident was resolved informally, which records no end time and so never appears in the average. Count those separately, and report the count, because a program where a third of incidents are handled off protocol has a training problem that the response-time figure is hiding.

Mitigation effectiveness is the hardest of the three, because the outcome it measures is something that did not happen. The honest way to state it is as a change in exposure against a stated baseline, with the baseline recorded before the mitigation and the method for scoring exposure held constant. Anything else is a story.

Two figures from a client’s executive protection program show the shape. A nationwide program architected from inception on a risk-tiered framework across 12 states reduced unmitigated threat exposure by 60% in its first year, against a baseline scored before the framework was applied. Separately, a threat and vulnerability assessment program covering 22 C-suite principals combined OSINT, behavioral threat analysis, and geopolitical risk data into individualized protection architectures. It removed $1.2 million in annual over-provisioned security cost while the program held zero principal safety incidents. The second figure is the one leadership remembers, and it is only credible because the first kind of measurement existed underneath it.

Mitigation effectiveness has a companion number that must be reported alongside it: residual risk that was accepted rather than mitigated. ISO 31000:2018 frames risk management as a process of identifying, analyzing, evaluating, treating, monitoring, and communicating risk. Treating and monitoring are separate steps. A program that reports only what it treated is hiding what it decided to carry.

Reported together, the three numbers describe a cycle. Detection time says how quickly the program learns. Response time says how quickly it acts. Mitigation effectiveness says whether the acting changed anything. A program that improves one at the expense of another has not improved; a detection platform that floods dispatch with unranked alerts will lengthen response time, and the board should see both lines move.

Each number needs its clock rule written down and attached to the report, in one sentence, every time. The rule is what makes the number comparable from quarter to quarter and from program to program, and it is what an auditor will ask for first. Numbers without rules are the activity counts this article began with, dressed better.