How Cyntelligence decides what matters to you.

The platform processes the same public data sources as competitors. The differentiator is post-ingestion processing that converts global intelligence into organization-specific priorities — computed, explained, and different for everyone.

Relevance × Confirmation × Threat Anchored to SSVC · EPSS · KEV The model never assigns severity
Verify it in a POC Read the trust dossier
01 — The unit of relevance

Relevance starts with who you are.

Each deployment maintains an org profile — the lens every global signal is scored through. Five components, curated by your analysts, kept current.

B

Brands

Names, product variations and spelling variants — for certificate and dump monitoring.

D

Domains

Owned domains, subdomains, subsidiary and group-company holdings.

V

Vendor watchlist

The technology stack that decides which vendor CVEs are local vulnerabilities.

R

Sector & region

Industry, operational geography, regulatory jurisdiction — for targeting signals.

K

Keywords

Analyst-curated terms for dark-web and paste-site monitoring.

FIELD NOTE — internal testing showed subsidiary-aware profiles detected threats that single-brand approaches missed entirely.

02 — Matching discipline

The system must be able to say no.

Raw data becomes structured facts through deterministic code, not generation: IOCs use validated pattern-matchers with false-positive exclusion; CVEs are enriched from vulnerability databases; threat actors resolve to canonical identities so aliases don't double-score. Then conservative matching decides what is truly yours.

R1

Word-boundary matching

Profile keywords match as anchored tokens, never substrings — “ACME” won’t fire on “placement”.

R2

Canonical entities

Actors, malware and techniques resolve to a canonical identity before matching, collapsing aliases.

R3

Stable dedup keys

Findings deduplicate on a stable identity, so the same fact never re-alerts.

R4

Trigger validation at alert birth

Evidence is validated against the raw source before an alert is ever created.

03 — Anchored severity

Severity is anchored to standards, not to a model.

SSVCCISA’s decision-tree methodology producing Act / Attend / Track from exploitation state, exposure and mission impact.
EPSSEmpirical probability that exploitation occurs in the wild.
KEVCISA’s Known-Exploited catalog — ground truth of active exploitation.
CVSS / CPETechnical severity and vendor-watchlist matching.

CORE PRINCIPLE — the local LLM is not allowed to assign severity. It phrases and prioritizes within the bounds the standards set.

04 — The scoring model

Alert severity = relevance × confirmation × threat.

Three multiplicative factors. Because they multiply, a high threat with zero relevance still scores near zero — which is how introducing this framework collapsed one critical-alert queue by two orders of magnitude. Try it:

SEVERITY CALCULATORadjust the factors →
RelevanceR
Does this concern your organization?
ConfirmationC
Is it real?
ThreatT
How bad if true?
0.75Relevance× 0.70Confirm× 1.00Threat SCORE53
SSVC · ATTEND Relevant and confirmed, high threat — queued for attention, not a page.

SOURCE AUTHORITY — feeds with consistent early reporting get precedence; aggregators and re-publishers are down-weighted to separate independent reporting from repetition.

05 — Worked example

Same KEV-listed CVE. Two very different mornings.

One edge-appliance CVE, freshly added to KEV. Watch it land at the top of one queue and quietly into a digest in the other.

Org ATelecom · GCC region
Appliance in vendor watchlistHIT
Exposed instance in internal scanVISIBLE
Actor targets sector & regionMATCH
SSVC · ACTQueue position#1 — top, with evidence chain
Org BFintech · EU
Appliance in vendor watchlistNO MATCH
Exposed instance in internal scanNONE
Actor targetingELSEWHERE
SSVC · TRACKFiled intothe weekly digest
06 — Limits, stated plainly

Scoring augments judgment. It doesn't replace it.

Depends

Profile & collection quality

Relevance scoring is only as good as profile accuracy and the quality of data collection. Garbage profile, garbage priorities.

By design

Open & community sources only

The platform uses open and community sources — no proprietary primary collection. We operationalize; we don't run undercover analysts.

Trade-off

Conservatism trades recall for precision

Matching discipline is deliberately strict. That means fewer false alerts — and, honestly, the occasional edge case suppressed. Analyst curation covers dark-web keywords.

Verify this document in a POC

  1. Test the profile

    Build a real profile including suspected missed subsidiaries; observe how the queue responds.

  2. Confirm the “no”

    Check that non-applicable headline CVEs file quietly rather than alerting.

  3. Audit the triggers

    Trace high-severity alerts back to raw-source evidence, and review SSVC paths for top-queue CVEs.

//DIFFERENT WAR ROOM

Same feed. Your priorities.

Request a 14-day POC See how we compare
REQUEST 14-DAY POC // NO CARD
DESIGN CONCEPT — NOTHING IS ACTUALLY SENT
✓

Request logged locally.

Fitting, no? In the real product this is where the builder emails you back within a day. This is a design concept — nothing left your machine.
❯ ESC

THE TRACE · LOCAL INFERENCE · REASONING SHOWN STEP-BY-STEP

Try: “which of our vendors were hit by qilin” · “fortios exposure” · “what changed on our perimeter this week”