Incident Fields

This page covers every field available on an incident record in the Adversarial platform.

Status

The Status field tracks where the incident is in its lifecycle. Four values are available:

New — A new incident requiring attention and investigation to determine severity, any needed escalation, and notification activities. Triage should be prioritized using the Severity field. During this phase, populate the Title and Description fields. These enable assessment of true severity. Based on assigned severity, assign specific person/groups.
In Progress — A dedicated person or team has been assigned and mitigation effort has been initiated.
Review — The owner can move to Review once the incident has been concluded. This is the last status prior to closure. Depending on severity, additional teams or leadership may want to review.
Closed — The owner moves to Closed once all necessary activities, reviews, and approvals have been concluded.

Title

The Title should be a brief overview and trigger recollection of specific details when presented in summary reports. The Title is a key input for AI Suggest Scoring and appears in the generated compliance report.

Description

The Description captures detailed information — often in timeline format — about how the incident was discovered, what is known about it, and data revealed throughout the investigative lifecycle. It is a key input to AI Suggest Score, weighed against the CIRP.

Severity

Severity drives escalation, reporting, and workflow processing. It is classified from SEV-5 through SEV-1. An incident can remain unscored until a severity is set; unscored incidents are reported as their own bucket. New incidents with unknown severity should begin as SEV-4.

Severity 5 (SEV-5): Informational — False positives that do not constitute attempted unauthorized activity. Used as the final severity for candidate incidents determined to be false positive after investigation. Can also be used for automated ingestion of false positive incidents for reporting volume.
Severity 4 (SEV-4): Low — Confirmed instances of attempted unauthorized activity or violations of policy. Also used as the default initial severity rating of candidate incidents needing further investigation.
Severity 3 (SEV-3): Medium — The presence of either targeted malicious intent OR operational impact. Examples: a concerted adversary performing research (targeted intent only) or opportunistic campaigns causing some impact (impact only).
Severity 2 (SEV-2): High — The combination of targeted malicious intent AND operational impact together. A motivated adversary is aware of the organization, attempting a compromise, and successful to some extent. Should be rare, warrant significant escalation, and serve as the threshold for reviewing reporting requirements. Example: successful exfiltration of confidential data.
Severity 1 (SEV-1): Critical — Catastrophic with widespread and/or prolonged material impact. Should be reviewed against reporting and disclosure requirements related to incident materiality.

Source

A dropdown field capturing the source of discovery. Examples: Customer Reported, SIEM, EDR, Managed Detection and Response (MDR), Identity Provider (IDP), Content Delivery Network (CDN). The platform provides a default list, and administrators can add or remove sources — or reset the list to the defaults — in Settings > Incidents.

Dates

Occurred Date — The date the incident began. Typically discovered after adequate investigation. Not the same as the Detected Date. Important for the Incident Chart.
Detected Date — The date the incident became known. If automated notification, the date of notification may be used. Important for the Incident Chart.
Responded Date — The date the incident responder responded.
Contained Date — The date at which the impact is substantially abated. Does not have to include all remedial actions from root-cause analysis; those risks are tracked separately in the Risk Register. Important for the Incident Chart.
Created Date — System field, not editable.
Updated Date — System field, not editable.

Threat Objectives

The Threat Objectives (TO) field links an incident to specific adversary objectives. On an incident a threat objective is either set or not — click once to mark it as strongly correlated, click again to clear it. The two-step low/strong scale applies to risks, not incidents.

The goal is to help measure residual risk and drive conversation around threat prioritization. Notifications are another reason — for example, if a Data Disclosure TO prompts notification, the “data owner” and “data viewer” should be entered in incident comments.

AI Suggest Score also proposes Threat Objectives, assigned at strong correlation — but only when the incident has none yet. Objectives you have already set are never overwritten by a scoring run.

Responsible Parties

Opened By — The name of the user who created the incident.
Assigned To — The user responsible for the incident.

Comments

An additional field for historical context and collaboration details. With the Description capturing initial investigation, Comments include ongoing lifecycle updates. AI severity reasoning is stored on the incident record alongside the score. When you run AI Suggest Score yourself from the side-panel editor and save, the reasoning is also posted as a comment for the record’s activity trail; the centered editor and automatic scoring from an integration sync write it to the record only.

Risk Register Referral

Within the detailed view, users can create risks identified during the incident. When a risk is created from an incident:

Initially Reported Urgency mirrors the incident’s severity (it stays unset if the incident is unscored)
Title reads “Risk identified during INC-XXXX: Incident title”
Description and threat objectives match the incident
Source is set to “Incident”

The recommended path after resolution: edit pertinent fields, score the RSK, and begin remediation.

Existing risks can also be associated using the relationship referral section.