Triage a Security Incident
Work through the incident list: assign an owner, acknowledge that you are looking, and resolve with a disposition and a note. Every action is recorded.
Before you start
Only administrators can assign, acknowledge or resolve. Viewers see the same state with the actions disabled. An assignee must be an active administrator who has signed in at least once; an administrator who only uses single sign-on appears in the picker after their first sign-in. For how incidents are formed, see Security posture.
Find the incidents that need work
- Open the list. Go to Security → Activity → Correlated findings. The list shows Verdict, Status, Assignee and Disposition columns. It sorts by verdict by default: incidents that need action come first and incidents the Judge marked Likely benign come last, so real work is on top.
- Filter. The status filter starts on New and Acknowledged. Choose Resolved or All statuses to see finished work. Set Assignee to Assigned to me, Unassigned or one administrator, and Disposition to a single outcome. Filters, sorting and paging run on the server and stay in the page URL, so you can bookmark a view.
Read the time to acknowledge and resolve
The strip above the list shows open incidents with the age of the oldest (counted over the most recent 31 days when you pick a longer range, since open incidents are read from the findings), and the median time to acknowledge (MTTA) and to resolve (MTTR) for incidents first seen in the range you pick: 7, 30 or 90 days. The clock starts at the incident's first finding. MTTA stops at the first acknowledgement, so an incident resolved without one is not counted there. MTTR stops at the resolve and counts only resolved incidents. Each card also shows the p90 and the mean. Viewers can read the strip.
Incidents that a suppression rule covered while they were open are left out of the times, and the strip says how many.
Triage an incident
- Open the incident. Select a row. The drawer opens with the verdict and why, then the actions that fit it. See Read the verdict.
- Assign it. Select Assign to me, or Assign... and pick an administrator. Assigning someone else sends them an email and an in-app notification. Unassign removes the owner.
- Acknowledge it. Select Acknowledge to show that someone is looking. It applies to a New incident and records the time to acknowledge.
- Escalate it. Select Escalate to assign the incident to yourself and acknowledge it in one step.
- Resolve it. Select Resolve..., choose a disposition, and write a note about what you found and did. The note is required for every disposition. For a likely-benign incident the button reads Resolve as benign and the form opens with the disposition set and the note filled from the Judge's reasoning; edit it before you resolve. For False positive and Benign, you can also say what you dispute. See Dispute a Judge guard override.
| Disposition | Use it when |
|---|---|
| True positive | The activity was malicious or violated policy. |
| False positive | The detection was wrong. |
| Benign | The activity was real, expected and acceptable. |
Dispute a Judge guard override
A guard can hold a Judge downgrade, so the finding keeps its configured action. When you read the finding and decide the hold was wrong, or the detection itself was wrong, record it when you resolve the incident:
- Read the explanation. Select a finding in the incident. Its drawer shows the model's recommendation, the effective outcome and the rule and evidence that triggered the guard. See Read a held downgrade. Select Review in incident to open the incident that holds the finding, whether you opened the finding from the incident or on its own. The button doesn't appear when no incident holds the finding, for example because a suppression rule hides it.
- Resolve it. Select Resolve... and choose False positive (the detection or the guard was wrong) or Benign (the activity was legitimate).
- Say what you dispute. Under What do you dispute?, choose The detection, The guard override or Both. This is optional. Write your reasoning in the note.
The dispute, the disposition and your note appear in the Triage history timeline, for example "resolved as false positive, disputing the guard override". The Judge's recommendation and the effective outcome stay on the finding, so all three stay separate.
Resolving records your review and nothing else. It doesn't retrain the Judge, turn off a guard, create an exemption, change enforcement or suppress later findings. To stop similar incidents from reaching the list, create a suppression rule on purpose. Reviewed false positives are a good source of cases for testing changes to the Judge or the guard against both ordinary development workflows and hostile approval claims, but nothing uses them automatically.
Read the verdict
Each incident opens with a verdict box: one of Act now, Needs review or Likely benign, a sentence saying why, and the facts it was based on. Under it are the actions for that verdict, then who, when, the technique and what the control did in plain words, the steps of the newest sequence match in order, and other incidents for the same actor (a user acting through an agent in another cluster is a different actor, so those are not listed).
| Verdict | It means | First action |
|---|---|---|
| Act now | The Judge escalated a match, or severity is critical, or severity is high and a control did not stop every finding. | Escalate |
| Needs review | Nothing clears it yet: no Judge verdict, a mixed or untrusted verdict, a guard held the Judge's downgrade, or a control stopped every call and you should check whether it repeats. | Escalate |
| Likely benign | Every match the Judge reviewed was marked benign, none was escalated, and severity is medium or lower. The Judge may have reviewed only some of the incident's findings; the basis line says how many. | Resolve as benign |
Evidence that cannot be read back lowers the confidence shown, never the verdict. Suppress similar, for administrators, opens the suppression dialog filled in from the incident. See Suppress noisy security incidents.
Cut off the agent
When the incident is real and an agent or service account is still acting, select Revoke agent access... under the actions. The dialog lists exactly what it cuts off, and you restore access from the identity page. See Contain an agent from an incident. The action is not offered for a person's own account; use Notify user on the finding instead.
Clear the noise in bulk
When the page shows several incidents of one pattern that the Judge marked benign, Likely benign on this page offers Resolve N for each pattern. Choose one, review the note (filled from the Judge's reasoning), and confirm. Each incident is resolved on its own with its own history entry and configuration audit event, so one failure never undoes the others. The security briefing's Clear the noise rows use the same action: for a pattern the Judge marked benign, Resolve N as benign opens this dialog for exactly the incidents in that row. Administrators only; everyone else sees Review. The result lists what was resolved, skipped (already resolved, or no longer judged benign) and failed (for example, changed while resolving). A call resolves at most 200 incidents. If more match, the result says how many remain and offers Resolve next batch.
When findings keep coming
An incident that is New or Acknowledged keeps its status and assignee for new findings with the same actor, pattern and target for up to 31 days after its last triage action, even after a quiet gap of more than 30 minutes, so work you have started is not lost. Resolve it to close it out.
After you resolve
A resolved incident is final and cannot be reopened or edited. If the same actor, pattern and target produce more findings later, they open a new incident. Its drawer shows Follows incident with a link to the resolved one, so the history stays connected.
The Triage history timeline in the drawer lists each action with who did it and when, including notes and any revoked agent access. Each action is also in Security → Activity → Configuration, without the note text. If an action fails because the incident changed, someone else acted first; the drawer reloads, so review it and try again.
To hand the record to an auditor, see Export the security triage record.
For the API, route authorization and retention, see Incident triage.