Skip to main content
14 speakers. 7 enterprise risk teams. One day in Charlotte, Oct. 22.Save My Seat
BlackKite: Home
Menu
Back to Glossary

Finding

A finding is a specific vulnerability, misconfiguration, or control gap identified during a security scan or review. Findings are the granular building blocks of risk assessments, typically categorized by severity and mapped to remediation guidance. In the Black Kite platform, a Finding is a specific cybersecurity control item or vulnerability identified during scanning and monitoring, categorized and assessed for impact, severity, and output status (passed or failed), typically scored using industry standards like the Common Weakness Scoring System (CWSS) or Common Vulnerability Scoring System (CVSS).

What Makes Something a Finding Rather Than Just an Observation?

A real finding is specific enough to investigate on its own, tied to a particular asset, with enough detail that someone could verify it independently. A vague concern isn't a finding until it has these pieces attached to it.

  • The specific asset, naming exactly which domain, IP address, or system the issue lives on.
  • The specific issue, described precisely enough that two different people would identify the same problem.
  • A severity rating, indicating how urgently it needs attention relative to everything else in the queue.
  • Supporting evidence, the scan result, log entry, or document that lets someone else confirm it independently.

How Does a Finding Differ From a Vulnerability?

Every vulnerability is a finding, but not every finding is a vulnerability. A vulnerability specifically refers to an exploitable technical weakness, often tied to a named CVE. A finding is the broader category that also includes misconfigurations, missing controls, expired certificates, and policy gaps that don't map to any specific vulnerability at all. An expired SSL certificate is a finding worth fixing even though nothing about it appears in a vulnerability database.

How Are Findings Prioritized When There Are Hundreds of Them?

Severity alone doesn't decide what gets fixed first. Business context does the rest of the work. A known exploited vulnerability finding on a mission-critical vendor's internet-facing system outranks a theoretical, unexploited weakness on a low-risk vendor's internal tool, even if a generic severity score would rate them the same.

Business Context Changes What a Finding Is Worth

The same technical finding means something different depending on which vendor it belongs to and what that vendor can touch. A missing security header on a marketing microsite and the same header missing on a payment processing gateway are technically identical findings that deserve very different responses.

Threat Activity Changes How Urgent a Finding Is

Black Kite's 2026 Ransomware Report tracked RansomHub's collapse from 736 disclosed victims to zero within the same year Qilin's victim count surged past 1,300, a reminder that a finding's urgency can shift as fast as the threat activity behind it does. A finding tied to a technique an active group is currently exploiting deserves a different priority than the same finding sitting quietly a year earlier.

A vendor tiering structure is what makes this kind of prioritization repeatable instead of ad hoc, since it tells a risk team in advance which vendors warrant escalating a finding immediately versus queuing it for the next review cycle.

What Happens to a Finding After It's Identified?

A finding moves through a short lifecycle, and skipping any stage of it is how issues quietly go unresolved.

  • Validated, to rule out a false positive before anyone spends time acting on it.
  • Communicated, to whoever actually has the authority and access to fix it.
  • Tracked, while remediation is in progress rather than assumed to be happening.
  • Verified closed, once the fix is confirmed independently, not just claimed by the vendor.

Communication Is Where Most Findings Stall

A finding that reaches an inbox nobody monitors, or a vendor contact with no authority to act on it, sits exactly where it landed until someone notices it never moved. The technical work of identifying a finding is often the easy part. Getting it in front of the right person is where most delay actually happens.

Verification Closes the Loop a Vendor's Word Can't

A vendor reporting that a finding is fixed and a finding actually being fixed are two different claims. Closing a finding without independently checking it treats the vendor's report as equivalent to evidence, which is exactly the assumption that lets an unresolved issue get marked resolved on paper.

What Can Make a Finding Unreliable?

A finding is only as good as the data behind it, and that data can be wrong in ways that aren't obvious from the finding itself. A scan can misidentify a service and flag a false positive. A finding can also be technically accurate but stale, describing a system that was reconfigured the day after an outside-in assessment ran. Neither failure mode announces itself. A false finding looks exactly like a real one until someone checks.

What Should a Risk Team Do When a Vendor Disputes a Finding?

A disputed finding is still an open finding until it's actually resolved one way or the other, so a disagreement shouldn't quietly become a dead end. The organization that surfaced the finding, and the one relying on the vendor it points to, carries the risk for as long as the dispute drags on unresolved.

  • Ask for the vendor's evidence, not just their assertion that the finding is wrong.
  • Re-verify independently, rerunning or rechecking the original evidence rather than taking either side's word for it.
  • Separate disputed findings from confirmed ones, so remediation on the parts everyone agrees about doesn't stall while the disagreement gets sorted out.
  • Log the resolution either way, so a vendor inventory reflects what was actually confirmed rather than what was simply argued about.

How Does Black Kite Deliver Findings to Vendors?

Black Kite routes findings to vendors through The Bridge™, sharing the specific asset and evidence behind each one rather than a generic request to "improve security." Vendors can respond directly on each finding, and remediation progress tracks through ticket status as part of the same continuous monitoring that surfaced the finding in the first place, closing the loop instead of leaving it as a one-time notification. That same finding-level detail feeds into a broader vendor risk assessment, so a risk team reviewing a vendor sees the specific evidence behind a rating change, not just the fact that something moved.

See also: RiskBusters Bust TPRM Myth: You Can't See Nth-Party Risks