Incident Fields
This page covers every field available on an incident record in the Adversarial platform.
Status
Section titled “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.
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 CyberGov deck.
Description
Section titled “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 used with the CIRP as an embedding in AI Suggest Score.
Severity
Section titled “Severity”Severity is a mandatory field that drives escalation, reporting, and workflow processing. It is classified from SEV5 through SEV1. New incidents with unknown severity should begin as SEV4.
- Severity 5 (SEV5): 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 (SEV4): 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 (SEV3): 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 (SEV2): 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 (SEV1): Critical — Catastrophic with widespread and/or prolonged material impact. Should be reviewed against reporting and disclosure requirements related to incident materiality.
Source
Section titled “Source”A dropdown field capturing the source of discovery. Examples: Customer Reported, MDR, SIEM, CDN, IDP. Source values are pre-defined and cannot be customized.
- 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
Section titled “Threat Objectives”The Threat Objectives (TO) field links an incident to specific adversary objectives. There are two levels of correlation: click once for low correlation (light gray), click again for strong correlation (darker color).
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.
Threat Objectives are automatically assigned when using AI Suggest Score. The AI identifies relevant threat objectives based on the incident details and assigns them with appropriate correlation levels.
Tags are item-level labels for organizing and filtering. They are available in both the Risk and Incident Registers. Tags are created at the organization tenant level and shared across users.
Bulk Edit options for tags:
- No Change
- Add New
- Replace All
- Find & Remove
- Remove All
To filter by tags, click the filter icon and select the “Tags” field. Save the result as a view. To manage tags, use the Tags section within Settings.
Responsible Parties
Section titled “Responsible Parties”- Opened By — The name of the user who created the incident.
- Assigned To — The user responsible for the incident.
Comments
Section titled “Comments”An additional field for historical context, collaboration details, and AI reasoning memorialization. With the Description capturing initial investigation, Comments include ongoing lifecycle updates.
Risk Register Referral
Section titled “Risk Register Referral”Within the detailed view, users can create risks identified during the incident. When a risk is created from an incident:
- IRU is set to Critical
- 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 or relevant AKRs can also be associated using the relationship referral section.