Skip to main content

Incident Management

Triage policy violations and discovery findings through a structured workflow: open → investigate → resolve or mitigate. Every state change is logged with a timestamp and actor for compliance evidence (ISO 27001 A.16, SOC 2 CC7.3).

Where to find it in the app​

Dashboard → Incidents & Detections → Incidents tab.

The Incidents & Detections page has two tabs:

  • Detections — the live detection feed (what was caught, when, by which rule).
  • Incidents — the investigation queue. Open this tab to see, create, and work incidents. Within the Incidents tab there is a secondary view — Behavioral Review — for incidents linked to behavioral anomaly cases.

What becomes an incident​

An incident is a tracked, assigned, time-bound investigation. Not every detection becomes one — most are simply logged. Incidents are reserved for events that need a human to look at them. Rivaro creates incidents three ways:

SourceHow it gets created
From a findingOpen a discovery finding in Administration → AI Estate → DISCOVERY and use the "Promote to incident" action. Findings like vulnerable models, exposed keys, or shadow assets are good candidates.
From a detectionOpen a high-severity detection in the Detections tab and click Promote to incident. Use this for credential exposure, prompt-injection blocks, suspected exfiltration.
ManualOn the Incidents tab, click New incident. Use as a placeholder while you investigate something Rivaro didn't catch automatically.

Incident states​

OPEN ─────────▶ INVESTIGATING ─────────▶ RESOLVED
                       │
                       └──────────────▶ MITIGATED
StatusMeaning
OPENCreated but not yet picked up
INVESTIGATINGSomeone is actively reviewing — the assignee is recorded
RESOLVEDRoot cause identified and addressed — root cause documented in notes
MITIGATEDA control was applied (block, quarantine, policy change) without full root-cause closure — common for "we stopped the bleeding" cases

Incident fields​

FieldDescription
idNumeric incident ID
statusOne of OPEN, INVESTIGATING, RESOLVED, MITIGATED
severityCRITICAL, HIGH, MEDIUM, LOW — inherited from the originating finding/detection
findingThe originating detection or discovery finding
agentIdThe agent involved (if any)
createdAt / createdByWhen and who opened the incident
investigatorWho picked up the investigation
resolver / mitigatorWho closed or mitigated the incident
notesFree-text investigation log
occurrencesRepeat events that share the same fingerprint — incident counts grow without spawning duplicate incidents

Workflow​

1. Open the incident​

If the incident originated from a finding or detection, click into it from the source page and choose Promote to incident. Otherwise, click New incident on the Incidents tab. The new incident lands in OPEN status and is visible to anyone with access to your organization.

2. Start investigation​

Open the incident from the list. Click Start investigation. Status moves to INVESTIGATING and your user is recorded as the investigator with a timestamp. From this point, the incident is "claimed" — teammates can see who's working it.

3. Add notes during investigation​

Every incident has a Notes section. Use it to log every step of your investigation — what you checked, what you ruled out, who you talked to. Notes append; previous entries are preserved. This text becomes part of the compliance audit trail, so be specific.

4a. Resolve (root cause closed)​

When you've identified the root cause and addressed it, click Resolve. Add a short summary in the resolution notes (e.g. "Agent misconfiguration fixed in run config; verified with re-test"). Status becomes RESOLVED.

4b. Mitigate (control applied, root cause not fully closed)​

When you've applied a control (quarantined the agent, added a policy rule, rotated a key) but haven't fully tracked down the root cause, click Mitigate instead. Status becomes MITIGATED. The expectation is that someone will eventually return and Resolve it.

The distinction matters for compliance reports: a mitigated incident still has an open root-cause investigation; a resolved incident does not.

Filtering and searching​

The Incidents tab supports filtering by:

  • Status (OPEN, INVESTIGATING, RESOLVED, MITIGATED)
  • Severity (CRITICAL, HIGH, MEDIUM, LOW)
  • Date range (defaults to last 30 days)
  • Agent (incidents tied to a specific agent)
  • Assignee (incidents you own, incidents owned by your team)

The header strip shows the live count of unresolved incidents broken down by severity — this is the same widget that surfaces on the Command Center dashboard.

Occurrences and deduplication​

If the same fingerprint (detection type + actor + asset) fires repeatedly while an incident is OPEN or INVESTIGATING, Rivaro records each event as an additional occurrence rather than spawning duplicate incidents. The incident's occurrence count grows; the timeline on the incident detail page shows every event; but the assignee gets one investigation to run instead of fifty.

Once an incident is RESOLVED or MITIGATED, a new event with the same fingerprint does create a new incident — because that means the fix didn't hold.

Behavioral Review​

Within the Incidents tab, a secondary view called Behavioral Review surfaces incidents tied to behavioral anomaly cases — situations where an agent's actions deviated from its constitution or expected behavior class. Use it when you want to look at the same incidents through a behavior-pattern lens rather than a chronological queue.

Notification routing​

Incidents fire notifications via the same channels attached to the underlying policy rule that triggered the originating detection. To route incidents to PagerDuty, Slack, or ServiceNow, attach a notification channel to the rule in Policies & Authority — see Notifications & Integrations.

For ISO 27001 A.16 incident-register compliance, every state change in this workflow appears in the exported register with timestamps and actors. Generate the register from Compliance Reporting.

Next steps​