Introduction

Incidents raises two kinds of question: why is nothing here, and why is this here. The first is almost always coverage; the second is almost always a control that needs tuning.

No incidents at all

An empty incident list is the most misread screen in the product, because the reassuring interpretation and the alarming one look identical.

1. Does any policy cover any asset? — A policy with no assets governs nothing. Check from the asset side — an agent's Policies tab — because that starts from what you care about.

2. Does the covering policy have controls? — Policies are created empty. One with no controls is live and inert.

3. Is the policy enabled? — And are its controls enabled? Two switches at two levels.

4. Is the agent sending traces? — Controls evaluate traffic. No traffic, no evaluation.

5. Are the controls pointed at surfaces your agents use? — A tool-surface control on an agent that calls no tools will never fire — correctly.

Note: Absence of incidents is not evidence of good behaviour. It is equally consistent with nothing being watched. Coverage evidence — which assets, which policies — is a separate artefact from incident evidence, and an auditor will want both. See Evidence & Export.

A control is set to Block, but the content got through

If content got through, the incident shows Flagged because the asset is on Observe · Advisory. Check the asset's Connection type.

Blocking requires a connection that supports enforcement. The product states the rule under the action picker: "Outcomes other than Flag only run on agents connected in Control mode. On Observe-only agents the control can flag, but cannot intervene."

So a blocking control on an advisory connection detects and records without preventing, and its incidents say Flagged, not Blocked. Check the agent's connection tier before concluding the control is broken — see Governing Vendors Without a Control API.

Too many incidents

Full treatment in Tuning Policy Noise.

Severity is blank

Severity is stamped by the control that raised the incident, not computed by Incidents. A control with no grading configured produces incidents with no severity, and the cell renders a dash. Fix it on the control; existing incidents keep the severity they were stamped with, which is what makes them evidence.

Frequently asked

1. Why can I only edit three fields? — Status, assignee and notes. Everything else is immutable, and that immutability is what makes an incident admissible — see Incident Data Model.

2. My triage did not save — Edits stage locally and persist on Save. Closing the drawer discards them.

3. Can I delete an incident? — No. False Positive is the correct way to record that it should not have been raised.

4. Can I bulk-triage? — Not today. One record at a time.

5. Will anyone be told when an incident is raised? — No. There are no notifications — see Escalation & Notifications.

6. Why does the same incident appear in several places? — The global list, the agent's and model's Incidents tabs, the policy's Incidents tab and the Overview summary card are all views of one record. Triaging it anywhere triages it everywhere.

7. What is Confidence, and how does it differ from Severity? — Severity is how bad it would be if real. Confidence is the control's configured threshold (Low / Medium / High; High when none is set) — it describes the control, not the individual finding.

8. The trace link no longer works — Telemetry expires after thirty days; the incident does not. Capture what you need into the notes during triage.

Related

• Triage: Assign, Note, Close

• Severity & How It Is Assigned

• Where Controls Run