What Is a Security Incident

Every organisation's monitoring infrastructure generates an enormous volume of events. A moderately sized enterprise may log millions of events per day across endpoints, network devices, identity systems, and cloud services. The entire discipline of security operations exists to convert that raw volume into a manageable signal: events that warrant attention, alerts that require triage, and incidents that require a structured response.

The triage step between alert and incident declaration is where most organisations struggle. Declaring too many incidents exhausts the response team and erodes the credibility of the process. Declaring too few allows genuine threats to persist unaddressed. Effective triage criteria include: does the evidence indicate a policy violation has occurred or is underway? Is a specific asset or data type at risk? Does the pattern match a known threat behaviour? If the answers are yes, the event crosses the threshold into an incident.

NIST SP 800-61 defines an incident as 'a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.' The SANS PICERL model uses similar language. ISO 27035 describes an incident as 'an unwanted or unexpected information security event or series of events that has a significant probability of compromising business operations and threatening information security.' The definitions converge on the same core idea: a security incident is a departure from an acceptable security state that requires a response. The formal IR lifecycle begins at the moment of declaration.

A data breach is an incident in which an unauthorised party gains access to, copies, transmits, or discloses protected data. The definition covers a wide range of scenarios: a hacker who exfiltrates a database of payment card numbers; an employee who emails a spreadsheet of customer records to a personal account; a misconfigured S3 bucket that makes medical records publicly accessible; a physical theft of an unencrypted laptop containing personnel files.

Breach notification law is the most consequential legal consequence of a data breach. The EU General Data Protection Regulation (GDPR) requires notification to the supervisory authority within 72 hours of becoming aware of a breach likely to result in risk to individuals' rights, and direct notification to affected individuals when the risk is high. In the United States, breach notification requirements are set by a patchwork of state laws, with California's CCPA and its enforcement amendment among the strictest. India's Digital Personal Data Protection Act 2023 (DPDPA) imposes breach notification obligations on data fiduciaries, with timelines set by the Data Protection Board. The UK post-Brexit Data Protection Act 2018 mirrors GDPR timelines. In all jurisdictions, the clock starts from when the organisation becomes aware, not from when the breach actually occurred.

Not every breach is immediately visible. Many are discovered weeks or months after the initial intrusion, through threat intelligence, customer reports, or law enforcement notification. The 2020 SolarWinds supply-chain breach, in which attackers compromised software updates to gain access to thousands of organisations' networks, went undetected for approximately nine months. Dwell time, the period between initial compromise and detection, averages weeks to months across the industry and is a key metric that incident response programmes aim to reduce.

Ransomware is malware that denies access to data or systems and demands payment, typically in cryptocurrency, for restoration. Early ransomware, such as the 2013 CryptoLocker, simply encrypted files on the victim's machine. Modern ransomware incidents are more complex: attackers first spend time inside the network conducting reconnaissance and exfiltrating data, then deploy the encryption payload. This double-extortion approach means a ransomware incident almost always includes a data breach component, triggering notification obligations in addition to the availability impact.

The 2017 WannaCry attack exploited an unpatched Windows vulnerability to spread across networks, encrypting files on hundreds of thousands of machines in more than 150 countries, including the UK National Health Service. The 2021 Colonial Pipeline attack encrypted operational systems controlling a major US fuel pipeline, causing a six-day shutdown and fuel shortages across the US East Coast. Both cases illustrate how a ransomware incident against infrastructure can escalate to a public safety event within hours.

Initial access methods for ransomware consistently include phishing emails carrying malicious attachments or links, exploitation of public-facing applications with unpatched vulnerabilities, and compromised remote access credentials. Once inside, attackers use legitimate tools such as PsExec, PowerShell, and Cobalt Strike to move laterally and escalate privileges before deploying the ransomware payload. This means the forensic trail of a ransomware incident typically begins days to weeks before the encryption event that triggers the response.

Insider threat incidents involve people with legitimate access to an organisation's systems. They divide into two categories with different motivations, different indicators, and different response approaches. Malicious insiders intentionally cause harm: they steal intellectual property before resigning to join a competitor, exfiltrate customer data for sale, or sabotage systems during a dispute. Negligent insiders cause harm accidentally: they send sensitive files to the wrong email address, misconfigure cloud storage permissions, click phishing links, or leave devices unattended.

The 2013 Edward Snowden case is the most widely cited malicious insider incident: a contractor with privileged access to NSA systems copied and exfiltrated classified documents using legitimate credentials and authorised tools, evading detection for months. At a smaller scale, insider data theft is common in financial services, healthcare, and technology firms, where departing employees download client lists or product files to personal devices. The 2022 Morgan Stanley incident resulted in a $35 million SEC settlement after a contractor improperly disposed of hardware containing unencrypted customer data.

Responding to a suspected insider incident requires care that external intrusions do not. The response team must preserve forensic evidence without alerting the subject, coordinate with HR and legal from the start, and maintain confidentiality to avoid defamation risk or tipping off the insider. Jurisdictions differ on what monitoring is lawful: the EU's GDPR limits workplace monitoring; the UK's Investigatory Powers Act 2016 sets boundaries for organisations; India's DPDPA imposes conditions on processing employee data. Legal review before or at incident declaration is essential in insider cases.

Availability incidents make systems or services inaccessible to authorised users. The most common external cause is a Distributed Denial of Service (DDoS) attack, in which an attacker directs traffic from many sources at a target, overwhelming its capacity. DDoS attacks range from volumetric floods measured in terabits per second to more targeted application-layer attacks that exhaust server resources with smaller traffic volumes. Internal causes of availability incidents include hardware failure, software bugs, and misconfiguration: these are not attacks, but they can rise to the level of an incident if they violate a security policy about service availability or if they affect data integrity.

Critical infrastructure sectors face specific regulatory treatment for availability incidents. In the United States, sectors including energy, water, healthcare, and financial services are subject to sector-specific incident reporting rules administered by CISA, FERC, and other regulators. The EU's Network and Information Systems (NIS2) Directive, effective from October 2024, mandates incident notification for essential and important entities across a wide range of sectors. In India, CERT-In (the Computer Emergency Response Team) requires organisations in notified sectors to report incidents within six hours of detection, one of the strictest timelines globally.

The response to an availability incident differs from a data exfiltration incident. The primary objective is service restoration, not evidence preservation. However, if the availability incident is caused by an attacker, evidence of the attack method must be preserved before remediation to support attribution, legal proceedings, or insurance claims. Incident responders must balance these objectives, and the resolution is almost always to preserve a forensic copy of the affected systems before restoring from backup.

Severity classification determines how fast an incident is escalated, how many resources are committed, who is notified, and whether external regulators or counsel must be engaged immediately. Most organisations use a four or five-tier system, commonly labelled P1 through P4 or Critical, High, Medium, Low. The classification is applied at the time of incident declaration and can be revised as the scope becomes clearer.

Severity is determined by three factors applied in combination: scope (how many systems, users, or data records are affected), sensitivity (what classification level does the affected data carry), and velocity (how quickly is the incident spreading or causing harm). A breach of 50 records of public information may be P4. A breach of 50 medical records is P2 or P1, depending on jurisdiction. The same criteria that drive severity also drive whether regulatory notification timelines are activated, so accuracy in the initial classification matters. Systematic approaches to classification are codified in triage and incident prioritisation frameworks.

Classification is documented in the incident record from the first entry. This documentation is essential for post-incident review and, in breach cases, for demonstrating to regulators that the organisation responded proportionately and within required timelines. A pattern of under-classification followed by late escalation is a red flag in regulatory investigations and insurance assessments alike.