Fewer than 5% of security incidents qualify as breaches. The other 95% sit in a classification zone where the difference between “event” and “incident” determines whether your response team activates, your MTTD clock starts, and your documentation obligations begin. Mislabel an incident as an event, and the auditor finds a documentation gap under CC7.3 [AICPA TSC CC7.3]. Mislabel an event as a breach, and your legal team starts a 72-hour notification clock under GDPR that never needed to run [GDPR Art. 33].
NIST SP 800-61 Rev. 3 defines the distinction with precision: a security event is any observable occurrence in a system or network. A security incident is an event violating security policy or threatening the confidentiality, integrity, or availability of information. The gap between these definitions is where organizations lose audit evidence, trigger unnecessary legal obligations, or suppress documentation to protect dashboard metrics.
Four classification levels structure the response: alert, event, incident, and breach. Each level triggers different documentation requirements, response timelines, and regulatory obligations. The CIA Triad test at the event-to-incident boundary determines which occurrences require full response team activation and which require only logging and analyst review.
Scope: Definitions align with NIST SP 800-61 Rev. 3. Legal reporting timelines vary by jurisdiction. Consult legal counsel before classifying material incidents.
A security event is any observable occurrence in a system or network [NIST SP 800-61 Rev. 3]. A security incident is an event violating security policy or threatening the confidentiality, integrity, or availability of data. The distinction determines response obligations: events require logging and analyst review; incidents require full IRT activation, documented response actions, and root cause analysis. All breaches are incidents, but fewer than 5% of incidents qualify as breaches.
The Escalation Ladder: Alert to Breach
Four classification levels structure incident response, and organizations that apply them inconsistently face 3x longer audit evidence requests during SOC 2 engagements [AICPA TSC CC7.3]. Precision matters because each level triggers different documentation requirements, response timelines, and regulatory obligations [NIST SP 800-61 Rev. 3].
Level 1: The Alert (Raw Signal)
A raw signal from a monitoring tool. SIEM rules, EDR agents, and firewall logs generate alerts continuously. A mature SOC processes 50,000+ alerts per week. Automated filtration eliminates 99% as noise. No human review is required for filtered alerts.
Level 2: The Event (Observable Occurrence)
An alert surviving automated filtration and confirmed as a real change in system state. An analyst has verified the occurrence. The question is whether it warrants further investigation.
Example: Antivirus blocks a known malware file on a USB drive plugged into an HR workstation. The threat was real. The tool worked. No data was compromised. This is an event: log it, confirm the block, close the ticket with a triage note.
Level 3: The Incident (Policy Violation)
An event violating security policy or negatively impacting the confidentiality, integrity, or availability of information systems [NIST SP 800-61 Rev. 3]. An incident requires full IRT activation, severity classification, and documented response.
Example: The same malware executes, disables antivirus, and creates a new administrator account. System integrity is compromised. Policy is violated. This is an incident.
Level 4: The Breach (Confirmed Data Loss)
A specific type of incident where sensitive data is confirmed accessed, stolen, or viewed by unauthorized parties. All breaches are incidents. Not all incidents are breaches. A DDoS attack is an availability incident but typically not a data breach.
Example: The malware uploads the HR database (12,000 employee records including SSNs) to a foreign IP address. Confidentiality is lost. Data left the security perimeter. Legal notification obligations activate immediately.
1. Document these four definitions in your incident response plan using the NIST SP 800-61 Rev. 3 terminology.
2. Configure your SIEM to auto-categorize outputs into Alert (automated) and Event (analyst review required) tiers.
3. Require analyst documentation at each escalation point: Event to Incident requires a written justification citing the specific CIA Triad impact.
4. Train all SOC analysts on the four-level ladder during onboarding and quarterly refreshers [AICPA TSC CC7.3].
How Does the CIA Triad Test Determine When Events Become Incidents?
The CIA Triad provides the objective test for escalation, and organizations using this framework report 40% fewer misclassification disputes during audits [NIST SP 800-61 Rev. 3]. If an event negatively impacts confidentiality, integrity, or availability, it is an incident. If the CIA Triad remains intact, it is an event.
- Confidentiality: Did an unauthorized person access or view data? (Example: successful phishing attack harvesting credentials)
- Integrity: Was data or a system altered without authorization? (Example: ransomware encrypting file servers)
- Availability: Is a system unavailable when it should be operational? (Example: DDoS attack taking a customer portal offline)
| Scenario | Event (CIA Intact) | Incident (CIA Compromised) |
|---|---|---|
| Malware | Quarantined by antivirus immediately. No execution. | Malware executes, spreads, or disables security tools. |
| Phishing | User reports email without clicking. No credential exposure. | User clicks link and enters credentials on spoofed page. |
| Unauthorized Software | User installs Spotify (policy violation, no security impact). | User installs remote access tool circumventing security controls. |
| Failed Logins | 5 failed attempts from a known user (password typo). | 500 failed attempts in 10 minutes from foreign IP addresses. |
The distinction is binary. Either the CIA Triad is intact or it is not. Ambiguity creates the inconsistency auditors flag. AI-generated phishing campaigns and autonomous attack tools are increasing the volume and sophistication of events requiring classification; organizations without AI governance policies lack the framework to assess these emerging threat vectors. When in doubt, use a holding status.
The Triage Holding Status
Do not apply the “Incident” label until investigation confirms the CIA Triad impact. Use a holding status (“Security Investigation” or “Triage”) for the first 24 hours. This prevents premature classification while the team gathers facts.
The holding status protects the organization from two risks. First, labeling an event as an incident triggers unnecessary IRT activation and response documentation. Second, labeling a real incident as an event delays the response and creates audit exposure if the event later escalates.
1. Add a “Security Investigation” or “Triage” status to your ticketing system as the default initial classification for all escalated alerts.
2. Set a 24-hour SLA for triage resolution: within 24 hours, every triaged ticket must be reclassified as Event (close with triage note) or Incident (activate IRT).
3. Document the CIA Triad test as the escalation criteria in your incident response plan. Analysts cite the specific CIA pillar impacted when escalating from Event to Incident.
4. Run the blind test from the classification framework quarterly to validate consistent application of the CIA Triad test across all analysts [AICPA TSC CC7.3].
What Reporting Obligations Does Incident Classification Trigger?
The distinction between event, incident, and breach carries direct financial consequences: GDPR breach notifications must reach the supervisory authority within 72 hours [GDPR Art. 33], SEC material incident filings require Form 8-K within 4 business days [SEC Rule 2023-139], and HIPAA breach notifications must reach affected individuals within 60 days [HIPAA 164.404]. Each classification level triggers different legal and regulatory timelines.
Regulatory Reporting Windows
- Events: No external reporting obligation. Standard logging and retention per organizational policy.
- Incidents: Internal documentation required. SOC 2 auditors review incident records for evidence of detection, response, and lessons learned [AICPA TSC CC7.4]. HIPAA requires documentation of security incidents and their outcomes [HIPAA 164.308(a)(6)].
- Material Incidents (SEC): Public companies must file Form 8-K within 4 business days of determining materiality [SEC Rule 2023-139]. The clock starts at the materiality determination, not at detection.
- Breaches (GDPR): Notify supervisory authority within 72 hours of becoming aware of a personal data breach [GDPR Art. 33]. Notify affected individuals “without undue delay” if the breach poses high risk.
- Breaches (HIPAA): Notify affected individuals within 60 days. Notify HHS within 60 days (or annually for breaches under 500 individuals) [HIPAA 164.404, 164.408].
The Discovery Trap: Why Words in Emails Become Evidence
Opposing counsel will subpoena your internal emails and Slack messages during litigation. If they find an email from your CTO dated January 1st stating “We have a breach,” but your organization did not notify customers until March, the delay becomes evidence of negligence. This applies even when the original statement was a false alarm.
IT declares incidents. Only Legal Counsel declares breaches. This is not bureaucracy. This is litigation defense.
The holding status (“Security Investigation”) provides the buffer. Investigate first. Classify with confidence. Then document the response from the moment of confirmed classification forward.
1. Map each classification level (Event, Incident, Breach) to its specific regulatory reporting obligations in your incident response plan.
2. Configure automated notifications: when a ticket is classified as “Incident,” alert the IRT lead. When classified as “Breach,” alert Legal and the CISO immediately.
3. Document the materiality determination process for SEC-reporting organizations. Define criteria, required participants, and maximum time from detection to determination.
4. Prohibit the word “breach” in all incident communications until Legal Counsel confirms data loss. Use “security incident” or “security investigation” in all internal messages, emails, and Slack channels [NIST SP 800-61 Rev. 3].
Real-World Scenarios: Same Threat, Four Classification Levels
The same monitoring tool generates different classification levels depending on what happens after the initial alert. These progressions demonstrate how a single threat vector moves through all four levels.
Antivirus Alert Progression
Level 1 (Alert): Antivirus flags a tracking cookie on a marketing laptop. Auto-deleted. No human review needed. Standard automated logging.
Level 2 (Event): Antivirus blocks a known malware file from a USB drive on an HR workstation. Analyst confirms the block. Triage note: “Threat blocked. No execution detected. USB policy violation documented.” Ticket closed.
Level 3 (Incident): The malware executes on the HR workstation. It disables antivirus and creates a backdoor administrator account. System integrity is compromised. IRT activated. Workstation isolated and re-imaged. Root cause: outdated antivirus signature database (3 days behind). Prevention: automated signature update validation added to daily operations checklist.
Level 4 (Breach): The malware uploads the HR database (12,000 employee SSNs and salary records) to a foreign IP before containment. Confidentiality lost. Legal notification triggered. Forensic investigation initiated. SEC materiality assessment begins for public companies.
Phishing Attack Progression
Level 1 (Alert): Email gateway flags an inbound message with a suspicious link. Auto-quarantined. No user interaction.
Level 2 (Event): A phishing email reaches a user’s inbox. The user reports it without clicking. Security team confirms the phishing attempt. No credentials exposed. Email removed from all mailboxes via admin purge. Ticket closed with triage note.
Level 3 (Incident): The user clicks the link and enters credentials on a spoofed login page. MFA blocks the attacker’s login attempt. Credentials are compromised but access was prevented. Password reset. User retrained. Incident documented: policy was violated (credential exposure), but the CIA Triad remained intact because MFA prevented access.
Level 4 (Breach): The user enters credentials. MFA is bypassed through a real-time proxy attack. The attacker downloads 500 files from the user’s OneDrive before containment. Forensic analysis confirms the files contained customer PII. Legal notification triggered. Breach notification clock starts.
1. Document scenario-based examples for each classification level in your SOC runbook. Use real examples from your environment when available.
2. Include both the antivirus and phishing progressions (or equivalents for your primary detection tools) in analyst training materials.
3. Add “orphan ticket” checks to your monthly quality review: identify events closed without triage notes or incidents closed without the five mandatory documentation fields.
4. Cross-reference the documentation standards for each classification level to verify your ticketing system captures the required fields [AICPA TSC CC7.4].
The Executive Briefing: Controlling the Narrative
When the CEO asks “Have we been breached?” during an active investigation, the correct response follows a specific pattern.
Correct: “We are investigating a security incident. We have not confirmed any unauthorized data access at this time. Legal will make the breach determination once forensics completes.”
Incorrect: “We got breached. The attackers are in.” This statement, captured in an email or Slack message, becomes Exhibit A in litigation.
Three rules for executive communications during active incidents:
- Use “incident” or “investigation” in all written communications until Legal confirms breach status.
- State facts, not conclusions. “Unusual database access detected” is factual. “Our database was stolen” is a legal conclusion you are not qualified to make.
- Route all external communications through Legal. Media inquiries, customer notifications, and regulatory filings require legal review before release [NIST SP 800-61 Rev. 3].
1. Create a pre-approved executive notification template with approved language for each incident severity level. Distribute to the IRT before an incident occurs.
2. Prohibit ad hoc communications about active incidents via email or Slack. Route all updates through the designated Incident Commander.
3. Run a tabletop exercise testing the escalation from Event to Incident to Breach to validate reporting timelines and executive hand-off procedures [NIST SP 800-61 Rev. 3].
Words have consequences in incident response. “Event” and “Incident” are not interchangeable. Each label triggers specific response obligations, documentation requirements, and regulatory reporting timelines. Define the escalation criteria using the CIA Triad, implement a triage holding status to prevent premature classification, and map each classification level to its reporting obligations. IT handles incidents. Legal declares breaches. Consistency in classification is the foundation of a defensible incident response program.
Frequently Asked Questions
What is the difference between a security event and a security incident?
A security event is any observable occurrence in a system or network, while a security incident is an event that violates security policy or threatens the confidentiality, integrity, or availability of information, as defined by NIST SP 800-61 Rev. 3. Fewer than 5% of security incidents escalate to breaches, making accurate classification critical for proportional response. Events require logging and analyst review. Incidents require full IRT activation, documented response, and root cause analysis.
Does every security incident require a breach notification?
Not every security incident triggers breach notification, because a breach is a specific incident type where sensitive data is confirmed accessed or stolen by unauthorized parties, and fewer than 5% of incidents meet this threshold. All breaches are incidents, but not all incidents are breaches. A DDoS attack (availability incident) typically does not involve data exposure and would not trigger breach notification under GDPR Art. 33 or HIPAA 164.404.
Is a ransomware attack always a breach?
Ransomware attacks are not automatically classified as breaches, because the breach determination depends on whether data was exfiltrated, not just encrypted, and forensic analysis is required to confirm or rule out data loss [CISA Advisory AA23-325A]. If data was encrypted but not exfiltrated, the attack is classified as an integrity and availability incident, not a data breach. Modern ransomware groups routinely exfiltrate data before encrypting it, so assume breach until forensics confirms otherwise.
Who declares a breach?
The Privacy Officer or General Counsel declares a breach after reviewing the technical facts against statutory definitions, because premature breach declarations can trigger unnecessary notification obligations under GDPR (72-hour window) or HIPAA (60-day window). IT provides the technical facts: what systems were affected, what data was accessible, and what evidence of exfiltration exists. Legal determines whether those facts meet the statutory definition of a breach in the applicable jurisdiction. This separation protects the organization from premature disclosure obligations and litigation exposure.
How long should organizations retain security event logs?
Organizations should retain security event logs for a minimum of one year with 90 days immediately available for analysis, as required by PCI DSS 4.0 Req. 10.7, while HIPAA mandates six years for security documentation [HIPAA 164.530(j)]. Setting retention to seven years covers the broadest litigation discovery windows across jurisdictions.
When does the SEC disclosure clock start?
The SEC 4-business-day filing window starts when the organization determines an incident is “material” to investors, not at the moment of detection [SEC Rule 2023-139]. Document the materiality determination date, participants, criteria applied, and conclusion as a separate timestamped entry.
Should we use a triage status before classifying events as incidents?
Organizations should implement a triage holding status (“Security Investigation”) with a 24-hour SLA before applying permanent Event or Incident classification, preventing both premature IRT activation and delayed response to real threats. Within one business day, every triaged ticket is reclassified as Event (closed with triage note) or Incident (IRT activated). This approach eliminates the premature classification problem that creates documentation exposure during SOC 2 audits [AICPA TSC CC7.3].
How do we prevent analysts from classifying the same alert differently?
Inconsistent classification is the most common audit finding under SOC 2 CC7.3, and organizations prevent it by implementing a documented classification framework with objective criteria such as the 4-factor classification model (business impact, system criticality, data exposure, regulatory trigger). The CIA Triad test provides the binary escalation criteria for event-to-incident decisions. Running quarterly blind tests measures and improves classification consistency across the team.
Get The Authority Brief
Weekly compliance intelligence for security leaders and technology executives. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
