Time to awareness is the elapsed time between a vulnerability becoming public and the moment your team knows which of your systems are affected. It sits before remediation time and is often the larger unknown. You cannot fix quickly what you do not know you have.
Why it deserves its own metric
Remediation time starts when a finding exists in your tracker. But a new CVE may have been public for hours or days before any scan picked it up. That gap is invisible in most reports, and it is where a fast moving exploit does damage.
Two organizations with the same remediation time can have very different exposure if one learns of issues in an hour and the other in a week.
The two parts
- Detection lag: from public disclosure to a finding appearing in your system for an affected asset.
- Triage lag: from that finding appearing to someone confirming which services and owners are affected.
Measure them separately. Different fixes apply. Detection lag shrinks with fresh vulnerability data, continuous scanning, and an accurate inventory. Triage lag shrinks with clear ownership and a dependency inventory you can query.
How to measure it
- Pick a sample of recent high profile disclosures, for example those on the CISA known exploited catalog or notable advisories.
- For each, record the disclosure time from the advisory.
- Record when your scanner first flagged an affected asset.
- Record when an owner confirmed the impact.
- Compute both lags. Report the median and the slowest.
With only a handful of events a quarter, show each event as a row instead of an average.
What good evidence looks like
A drill is a fine start. Pick a past disclosure, ask "which of our services used this component?" and time the answer. If the answer takes days of searching, the metric is already telling you something. A current software bill of materials for each deployable shortens that search.
What to do with the result
| Finding | Likely fix |
|---|---|
| High detection lag | Scan continuously, refresh vulnerability data daily, widen coverage |
| High triage lag | Name owners per service, keep SBOMs current, make them searchable |
| Both low | Move attention to remediation time |
Present it simply
One line for executives: "For the last three major disclosures, we knew which services were affected within a stated time." Add the slowest example and what you changed afterwards.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new disclosure is matched to affected assets, which is the step this metric times.
Quick check
Is time to awareness the same as MTTD?
The terms overlap. Here it is specific to new vulnerability disclosures matched to your assets, not to detecting an attack.
How often should we run a drill?
Quarterly is a reasonable start. Use a recent real disclosure so the exercise is concrete.
Last reviewed: 19 October 2026.
