cc7-3 High priority Security / System Operations

Detected security incidents are evaluated and classified

Not every alert is an incident, and not every incident has the same severity. This criterion requires a process for evaluating detected security events, determining which ones constitute incidents, classifying their severity, and escalating appropriately. Without a triage process, teams either over-respond to noise or miss real incidents buried in alerts.

8h estimated effort

incident-response triage classification security-events

Complete first: cc7-2

Implementation steps

1

Define incident classification criteria

Document what constitutes a security incident and how incidents are classified by severity. A P1 incident might be: active data exfiltration, ransomware, or confirmed credential compromise of an admin account. A P2 might be: suspicious login from unknown location, unexpected admin access grant. Define the criteria so that anyone on the team can apply them consistently.

confluence notion google-docs
2

Establish an alert triage process

Define who reviews security alerts, how often, and how they escalate. Alerts should have an owner. When an alert fires, it should be investigated: is this a true positive or false positive? If true positive, does it meet the threshold for an incident? Document the triage decision. For critical alerts, define a maximum response time (e.g., acknowledge within 15 minutes).

pagerduty opsgenie jira linear
3

Log and track security event evaluations

Maintain a record of security events that were investigated, what the investigation found, and how the event was classified. Even events that turn out to be false positives should be logged. This record demonstrates that alerts are being actively reviewed and supports post-incident analysis.

jira linear notion confluence