Recall

What recall means in scanning and detection

Recall measures how many real weaknesses a scanner or detection process finds out of all the weaknesses that are actually present. It is a completeness metric, so it answers a different question from precision: recall focuses on missed findings, not on false alarms.

In practice, recall matters because a tool that misses too much creates a false sense of coverage. A tool can look efficient on paper while still leaving serious exposure behind if its rules, signatures, or test cases only catch an easy subset of the problem.

Why low recall is dangerous

Low recall means real issues are slipping past review, which is especially dangerous when teams use the scanner as a primary gate for release or remediation. Missed vulnerabilities can persist into production, remain unpatched, or become invisible in prioritisation workflows because they were never surfaced in the first place.

High recall is valuable only when the organisation can still trust the signal. If a team sees too many missed issues in repeated testing, confidence in the scanner drops and the output starts to function as a partial hint rather than a reliable control.

Tools and control frameworks often stress that detection quality depends on both discovery and follow-up. For example, NIST SP 800-53 Rev 5 Security and Privacy Controls pairs detection and monitoring expectations with broader control effectiveness, while NIST Cybersecurity Framework 2.0 frames visibility as part of a wider identify, detect, respond, and recover posture.

How recall is assessed in security tooling

Recall is usually judged against a known set of true issues, such as a benchmark dataset, a manually reviewed sample, or a re-tested environment where ground truth is known. That makes the metric useful, but also dependent on the quality of the test set: if the sample is narrow or unrealistic, recall can look better than the tool's real-world performance.

Security teams should also distinguish recall for the scanner itself from recall for the overall process. A scanner may miss fewer problems after tuning, but the end-to-end workflow can still lose findings through filtering, deduplication, suppression rules, or weak triage habits.

When the subject is vulnerability discovery rather than an individual tool, broader validation sources can help. The OWASP API Security Top 10 is useful when API exposure is being checked, and SLSA helps when the concern is whether build or supply-chain weaknesses are being surfaced consistently.

Interpreting recall alongside precision

Recall should never be read alone. A high-recall scanner that floods analysts with noisy findings can still fail operationally because the team cannot investigate everything. The practical question is whether the organisation has found an acceptable balance between missing too little and reporting too much.

That balance is why recall is best treated as a quality signal for the detection pipeline, not as proof of security. Strong recall supports better coverage, but only when paired with review capacity, prioritisation, and confirmation that findings are genuinely actionable.

Practitioner Guidance

What practitioners should watch for: If recall is improving only because the tool is being made noisier, the programme may be trading completeness for overload. Tuning should be judged on whether more real issues are surfaced without making the alert or findings stream unmanageable.

Governance implication: Treat recall as a control-quality metric that belongs in scanner validation, tuning review, and periodic re-testing. The useful decision is not whether recall is “good” in isolation, but whether the organisation can sustain enough completeness to support remediation without losing analyst trust.

Related resources from NHI Mgmt Group

• Why is syntax recall a weaker signal than architectural judgement?
• Why do precision and recall create blind spots in scanner selection?
• How do teams decide between ROC and precision-recall curves?
• Should organisations prioritise recall or precision when choosing a SAST platform?