Incident Register

While the maintenance of the company Threat Profile and the operation of a mature risk identification and remediation strategy through the RAMP are intended to minimize the likelihood of a severe cybersecurity incident occurring, a robust incident tracking system is essential to catalog suspicious events, ensure they are properly investigated, and record critical facts and timelines throughout the incident management lifecycle.

The Adversarial platform provides an Incident Register supporting the manual or automated recording of events of interest. An Incident Register is a dynamic table or database-driven tool that facilitates the documentation and workflow involved in managing incidents throughout their lifecycle.

Just as the Risk Register’s operation is instructed and evidenced by the RAMP, the Incident Register is governed by a Cybersecurity Incident Response Procedure (CIRP) instantiated for the customer.

What Is the Incident Register

A Cybersecurity Incident (INC) is an event involving an actual or suspected attempt of unauthorized activity or violation of policy. Incidents are distinct from risks, which are conditions that may potentially lead to an incident and are governed by separate risk management procedures.

Likewise, threat intelligence concerning events external to the organization or breaking potential vulnerabilities do not constitute incidents. Intelligence may drive assessment of applicability and exposure in the form of risk, but an incident is only generated if, during that review, it was determined that a risk was previously exploited in some manner.

Incidents vs Risks

Incidents and risks serve different purposes in the platform:

• Risks are conditions that may potentially lead to an incident. They are governed by separate risk management procedures and tracked in the Risk Register.
• Incidents involve an actual or suspected attempt of unauthorized activity or violation of policy. They are tracked in the Incident Register and governed by the CIRP.

Threat intelligence concerning events external to the organization does not constitute an incident. Intelligence may drive assessment of applicability and exposure in the form of risk, but an incident is only generated if it was determined that a risk was previously exploited in some manner.

Incident Lifecycle

New incidents may be generated by automated processes like integrations or manually. The lifecycle progresses through four stages:

1. New — A new incident requiring attention and investigation. Triage should be prioritized using the Severity field.
2. In Progress — A dedicated person or team has been assigned, and the incident is associated with a specific individual: the designated owner responsible for ensuring it is processed per the CIRP. The In Progress state remains valid so long as additional investigation, research, testing, or related activity is being conducted. Notes about the investigation should be collected as Comments.
3. Review — After an incident has been concluded, the owner may move it to Review. This is the last status prior to closure. Depending on severity, additional teams or leadership may want to review.
4. Closed — The owner moves to Closed once all necessary activities, reviews, and approvals have been concluded.