Tips for setting up your Smart Alerts

Smart Alerts work best when they're tuned to the software and suppliers you rely on and the threat signals that matter most to your organisation. A well-scoped rule surfaces what you need to act on and stays quiet about everything else.

Recon has two rule types — vulnerability alerts and breach alerts. Most of the tuning below applies to vulnerability alerts, since their criteria are richer; breach-alert tips are at the end. New to Smart Alerts? Start with the What are Smart Alerts? guide for how rules are created — this guide focuses on how to configure them well.

• Scope to your inventory first
• Prioritise exploitation and attacker activity
• Catch emerging risks early
• Refine with risk and exploit scores
• Combine conditions with AND and OR
• Start from a template
• Tuning breach alerts
• Be deliberate about delivery

Scope to your inventory first

The single most effective way to cut noise on a vulnerability alert is to scope it to your inventory. In the Scope step, choose your Organisation or Personal inventory so the rule only fires for the vendors and products you actually run — rather than the whole global CVE feed. This focuses alerts on the technologies most likely to affect you.

You can narrow further in the same step — with labels (for example, alerting only on software labelled Internal or Internet-facing) or by limiting the rule to specific suppliers. Keep your inventory current for this to work well. See the Building your inventory guide for more.

Prioritise exploitation and attacker activity

Not every vulnerability carries the same risk. Many teams prioritise ones showing signs of active exploitation, available exploit code, or attacker interest. In the Criteria step, useful intelligence tags to watch include:

• CISA KEV — listed in CISA's Known Exploited Vulnerabilities catalogue; confirmed actively exploited in the wild.
• PPE (Potential Public Exploitation) — signals suggest the vulnerability may already be abused in real-world attacks.
• POC (Proof-of-Concept) — public proof-of-concept or exploit code has been identified, increasing the likelihood of exploitation.
• KTA (Known Threat Actor) — associated with a known threat actor, suggesting it may be discussed, analysed, or used by attackers.

Together these tags help you prioritise based on real exploitation and attacker behaviour, not just severity scores.

Catch emerging risks early

Some vulnerabilities draw attention before exploitation begins. Watching these signals helps you get ahead of them:

• SPOT (Cytidel Spotlight) — flagged by Cytidel's threat analysts as particularly relevant.
• NVD — not yet published in the National Vulnerability Database, so it may come from early disclosures such as vendor advisories or security research — an early-warning signal.

If your environment is Microsoft-heavy, the TUE (Patch Tuesday) tag is also useful for focusing on newly disclosed Microsoft vulnerabilities.

Refine with risk and exploit scores

You can sharpen any rule using scoring metrics in the Criteria step:

• Risk rating
• CVSS score
• EPSS score

Use these to focus alerts on vulnerabilities with higher potential impact or a higher likelihood of exploitation — for example, only alerting on Significant risk, or on a high EPSS score.

Combine conditions with AND and OR

Criteria are organised into two groups, and a CVE fires only when it meets every condition in the AND group and at least one condition in the OR group. Using them well is what makes a rule precise:

• All of the following (AND) — every condition must be met. Use it to require something (e.g. "must be CISA KEV").
• Any of the following (OR) — at least one must be met. Use it to cast a wider net (e.g. "PPE or Significant risk").

As a rule of thumb: put your non-negotiables in the AND group to stay focused, and use the OR group to catch several related signals at once.

Start from a template

If you're not sure where to begin, use Start from a common pattern > Apply template in the Criteria step. It sets up a sensible baseline you can edit.

Worked example — a high-priority vulnerability rule:

• Details: name it something clear like "Priority"; choose Personal or Org visibility.
• Scope: Organisation inventory, so it only covers your tracked software.
• Criteria: CISA KEV in the All of the following (AND) group, with Potential Public Exploit and Significant risk rating in the Any of the following (OR) group.
• Notifications: email (and a webhook if you want it in Teams or Slack).

The result is a focused rule that surfaces exploited and high-risk vulnerabilities affecting your environment — a strong starting point you can tighten or loosen over time.

Tuning breach alerts

Breach alerts watch your suppliers for breach news and ransomware leaks. A few tips:

• Watch by priority, not one-off lists. Setting a rule to cover suppliers by priority (for example, all your P1 suppliers) means new suppliers you add at that tier are monitored automatically — no need to edit the rule. Keep your supplier priorities up to date under Monitoring > Suppliers.
• Split rules by how you'd respond. If different incidents should reach different people, create separate rules per tier — e.g. a P1 rule routed to your incident team and a broader rule to a shared inbox.
• Keep both sources on — News reports and Ransomware.live victim listings catch different signals, so leave both enabled unless you have a reason not to.

Worked example — a critical-supplier breach rule:

• Details: "P1 supplier breaches", Org visibility.
• Monitoring: By priority → P1; sources: News reports + Ransomware.live victim listings.
• Notifications: email routed to your security lead, plus a webhook into your incident channel.

Be deliberate about delivery

Every rule needs at least one delivery method — you can't save one without choosing one — and email is selected by default. You can pick one method or several: email, a webhook, or both. It doesn't have to include email, so a webhook-only rule that posts straight into Teams or Slack is perfectly fine. Every matching alert also appears in Recon under Alert History, so nothing is ever lost.

Be intentional about who gets notified and how. For high-urgency rules, use email and/or a webhook so alerts reach people the moment they fire — and on Org rules, route email to the specific team members who own that risk, rather than everyone. For broader, lower-urgency rules, keep recipient lists tight and rely more on reviewing Alert History in-platform. Choosing Personal vs Org visibility also controls how widely a rule's alerts are shared. This keeps your most important alerts in front of the right people without creating fatigue.

Need help tuning your rules? Email us at [email protected].