INC-002 Incident Detection and Triage
Description
Processes and technical controls are in place to detect potential security incidents from multiple sources: automated monitoring alerts, internal reports, threat intelligence, and third-party notifications. Detected events are assessed against defined criteria to determine whether they qualify as incidents. Triage decisions are documented.
Rationale
Detection and triage are the entry points of incident response. Weak detection means incidents escalate unnoticed; weak triage means resources are misdirected.
Applicability (9 profiles)
Framework Mappings (13)
| SEF-06 | Event Triage Processes | full |
| SEF-06 | Event Triage Processes | full |
| HIPAA-164.308.a.5.ii.B | Protection from Malicious Software | informative |
| HIPAA-164.308.a.6.ii | Response and Reporting | informative |
| 5.25 | Assessment and decision on information security events | full |
| NIS2-Art.21.2.b | Incident Handling | informative |
| NIS2-Art.23.3 | Significant Incident Criteria | informative |
| NIS2-CIR-3.4 | Event Assessment and Classification | partial |
| NIS2-CIR-Art.3 | Significant Incident Criteria for the Relevant Entities | informative |
| IR-4 | Incident Handling | partial |
| IR-5 | Incident Monitoring | full |
| CC7.3 | Evaluates Security Events | full |
| CC7.4 | Responds to Identified Security Incidents | informative |
Evidence (2)
Security monitoring and alerting configuration showing automated detection rules are in place across monitoring sources to surface potential security incidents.
Example: SIEM detection rule configuration export (e.g., Splunk saved searches, Elastic Security rules, AWS GuardDuty findings configuration) showing enabled rules covering core incident types with alert routing to the incident response team
Test: Review the security monitoring configuration. Verify: (1) automated detection rules are enabled for common incident types; (2) rules cover multiple input sources (cloud platform logs, application logs, network logs, EDR); (3) alerts are routed to a monitored queue or on-call channel; (4) confirm a sample of real events in the last 30 days generated alerts as expected.
Triage decision records showing detected events were assessed against incident criteria and triage outcomes were documented.
Example: Incident tracking system (Jira, PagerDuty, or equivalent) records for the last 90 days showing events received from all detection sources, triage decision (incident/non-incident), decision rationale, and analyst name
Test: Query the incident triage records for the last 90 days. Verify: (1) events from all detection sources appear in the tracking system; (2) each event has a documented triage decision with rationale; (3) events triaged as incidents are escalated to incident records; (4) response SLAs for initial triage are documented and met.
Questions (2)
Are processes and technical controls in place to detect potential security incidents?
Detection capability should not rely solely on automated alerting. Internal reporting channels and mechanisms to receive third-party notifications are also required.
Which incident detection sources are covered by your triage process?
Automated alerts alone are insufficient. A robust detection process includes internal reporting channels and the ability to receive and triage external notifications.