Qevlar recommends a short list of concrete actions for every investigation it completes, based on the verdict it reached and the evidence behind it. Each recommendation names an action, explains why the investigation justifies it, and identifies the assets or indicators it applies to.
Recommendations are produced when the report is generated. A report has at most five next steps.
Why it matters
- Verdict-aware — the verdict determines which kinds of action can be recommended, so an inconclusive investigation is never told to close the ticket.
- Evidence-backed — every recommendation carries the observation that justifies it, so it can be assessed without reopening the investigation.
- Scoped — recommendations identify the specific observables they apply to, rather than describing an action in general terms.
- Executable in place — where Qevlar has an automated path for an action and the required integration is connected, the action can be run from the report.
- Forward-looking — recommendations cover detection tuning, organizational context and data source gaps, not only incident response.
Where to find next steps
Platform UI
Open an investigation report and select the Next steps tab. The tab shows a badge with the number of recommendations.
The Summary tab also displays a Next steps card with the count and a link to the tab.
API
The investigation report returned by the public API includes a remediation_next_steps field on the report object, containing the recommendation descriptions in the order they appear in the platform.
Reading a next step
Each recommendation is displayed as a card with the following elements.
- Category icon — the action category the recommendation belongs to.
- Label — the name of the action, such as Disable account or Add rule exclusion.
- Description — what to do, written for this investigation.
- Why? — hover to display the justification: what the investigation observed that makes the action appropriate, and the reasoning applied.
- Observables — the assets and indicators the action applies to, shown as tags. Selecting a tag opens that observable's detail panel.
Observable tags appear only where an observable from the investigation is directly relevant to the action. Recommendations whose target is not an investigation observable, such as Patch vulnerable software or Reconnect or repair connector, have no tags.
Recommendations are listed in the order Qevlar recommends carrying them out.
Action categories
Every recommendation belongs to one of eleven categories.
- Contain — limit immediate impact, usually reversibly. Disable account, Revoke sessions and tokens, Isolate asset from network, Quarantine file, Block indicator, Remove delivered message.
- Eradicate — remove the threat from the environment, including destructive actions. Delete malicious object, Remove persistence, Remove mailbox rule, Remove unauthorized SSH keys, Request takedown.
- Recover — return affected entities to a known-good state. Restore or roll back, Rebuild device, Repair security agent.
- Harden — reduce the chance of recurrence. Enforce MFA, Apply least-privilege, Patch vulnerable software, Implement network segmentation, Expand logging coverage.
- Contact — involve a person outside the SOC. Contact user's manager to confirm intent, Notify user of malicious activity, Escalate to IT or security team, Notify external parties.
- Monitor — increase scrutiny without acting yet. Add entity to watchlist, Raise monitoring sensitivity for entity.
- Close — close the ticket. Recommended only for verdicts that reached a conclusion.
- Tuning — adjust the detection that produced the alert. Add rule exclusion, Adjust rule threshold, Refine detection logic, Re-scope rule, Deprecate or disable rule.
- Context — record a durable fact so future investigations resolve correctly. Add known-good entity to context, Record sanctioned behaviour as expected, Add business-unit or asset norm.
- Integrate — address a data gap that limited the investigation. Onboard new data source, Reconnect or repair connector, Extend log coverage of existing source.
- Other — an action the investigation justifies that fits no other category. Can appear on any verdict.
What is recommended for each verdict
The verdict determines which categories are available.
Malicious
Recommendations follow the response lifecycle: contain, eradicate, recover, contact, harden, close.
At least one Contain recommendation is included, and a Close recommendation comes last. Eradicate, Recover, Contact and Harden are included only where the investigation's evidence supports them, so a short list means nothing further was justified rather than that recommendations are missing.
Not harmful
Up to two Tuning recommendations, and a Close.
Tuning is recommended only where the investigation identified an adjustable detection, automation or enrichment behaviour. For user-reported alerts, this is not the case.
Inconclusive
The verdict means telemetry could not determine intent, so recommendations are aimed at obtaining that context.
- One Contact recommendation, listed first. It defaults to the user's manager rather than the user, who may be the subject of the investigation.
- One to three Contain recommendations, phrased conditionally — "If confirmed malicious, …" — so containment is prepared in advance of confirmation.
- One Context recommendation, so that a similar pattern resolves correctly in future investigations.
- Optionally up to two Monitor recommendations for the period before intent is confirmed.
An inconclusive investigation never recommends closing the ticket.
Missing data
One to five Integrate recommendations, naming the specific source the investigation required, and optionally a Context recommendation recording the gap.
A missing data investigation never recommends closing the ticket.
When the verdict changes
If feedback changes an investigation's outcome after its report was generated, the recommendations no longer correspond to the current verdict.
The tab then displays a warning naming the date the verdict changed, and the action buttons and feedback controls on every recommendation are disabled. The recommendations remain visible, as the reasoning behind them is often still relevant.
Giving feedback on a recommendation
Each recommendation has a thumbs up and thumbs down control beside its label. Selecting thumbs down prompts for a comment describing what was wrong with the recommendation.
Feedback is sent to Qevlar as product feedback on the recommendation. It is not stored on the investigation, so it does not persist on the card after a page reload and is not visible to other users in the workspace. Anything that needs to be retained should also be recorded on the ticket.