Incident detection, triage, and analysis. This is how you find out that something bad has happened to your organisation’s computer systems, decide how serious it is, and figure out exactly what went wrong. For the CISM exam, this is where you prove you can separate a genuine emergency from a false alarm — and that skill is worth its weight in gold to any employer.
Jump to a section
A simple way to picture Incident Detection, Triage, and Analysis
What happens when an ambulance arrives at a hospital with a patient who might be having a heart attack?
The process that follows is a perfect map for how security teams handle a potential breach. First, the ambulance crew radios ahead — that’s the initial detection. They’ve spotted a problem (chest pain, irregular pulse) and they alert the hospital. The hospital doesn’t know yet if it’s a real heart attack or just bad indigestion, but they prepare.
When the patient arrives, a triage nurse immediately checks vital signs, asks key questions, and assigns a priority colour: red (life-threatening), yellow (serious but stable), or green (minor). This is exactly what a Security Operations Centre (SOC) does with an incident alert. The triage nurse doesn’t treat the patient — they just decide how urgent it is and who should see them next. A red-tagged patient goes straight to the trauma team; a green-tagged patient waits in a chair.
Then the analysis phase begins. The emergency doctor runs tests: an ECG, blood work, a chest X-ray. They look for patterns, compare symptoms to known conditions, and rule out false alarms. In IT, analysts examine log files, check network traffic, and correlate data from multiple sources. The doctor’s diagnosis (heart attack, panic attack, or something else) determines the treatment plan. A false alarm means the patient goes home; a real attack triggers a full response. The hospital doesn’t treat a complaint — it treats a confirmed diagnosis, just as a security team doesn’t act on a raw alert — it acts on a verified incident.
Let’s start with the big picture. Every organisation has valuable information stored on computers — customer data, financial records, trade secrets. Attackers try to steal, damage, or lock up that information. To protect it, you need to know when an attack is happening or has already happened. That’s what incident detection, triage, and analysis is all about.
Incident detection is the step where you first notice something unusual. It could be an alarm from a security tool, a user reporting that their computer is acting strangely, or a system automatically flagging suspicious behaviour. Think of it as the smoke detector going off in your house. The smoke detector doesn’t tell you where the fire is or how big it is — it just says: “Something is happening.” That’s detection.
The tools used for detection are called intrusion detection systems (IDS). An IDS watches network traffic or computer activity and compares it against known patterns of attacks. If it sees traffic that matches a signature — a specific pattern that resembles a known attack — it raises an alert. Another type of detection tool is a security information and event management (SIEM) system. A SIEM collects logs (records of events) from many different computers and applications, then uses rules to identify suspicious combinations. For example, a SIEM might notice that a user logged in from New York at 9:00 AM and then logged in from London at 9:05 AM — which is physically impossible. That would trigger an alert.
Once an alert is generated, you move to triage. Triage is the process of sorting alerts by how serious they are. Not every alert is a real incident. Some are false positives — legitimate activity that looks like an attack but isn’t. For example, an administrator running a backup script might trigger an alert because the script accesses many files at once, which looks like ransomware. The triage analyst’s job is to quickly decide: is this a real attack, a false alarm, or something that needs more investigation?
Triage is often performed by a level 1 analyst in a Security Operations Centre (SOC). The SOC is a team of people who monitor the organisation’s security around the clock. During triage, the analyst checks basic information: what triggered the alert, which systems are involved, what time it happened, and whether there’s any obvious explanation. They might look at a few log entries to see if the activity is expected. If the activity matches a known false-positive pattern, the alert is closed. If it looks suspicious, the alert is escalated to a level 2 analyst.
Analysis is the deep-dive investigation performed by level 2 or level 3 analysts. Their job is to confirm whether the alert represents a real security incident, and if so, to understand exactly what happened. This is where you gather forensic evidence. Forensic analysis is the careful collection and examination of data from computers, networks, and storage devices to determine the cause and impact of an incident.
During analysis, you might examine log files to trace an attacker’s movements. You might look at network traffic captures (pcap files) to see what data was sent out of the organisation. You might analyse the contents of a computer’s memory (RAM) to find malicious software that is hiding there. The goal is to answer five key questions: what happened, when did it happen, how did it happen, what systems were affected, and what data was compromised. This information is crucial for deciding how to respond and how to prevent it from happening again.
These three stages — detection, triage, and analysis — form a funnel. A huge number of raw alerts come in (maybe thousands per day). Triage filters out the noise, leaving a smaller set of potential incidents. Analysis then confirms which of those are real, producing a final set of confirmed incidents that require action. Without this process, security teams would be overwhelmed by alerts and would miss the truly dangerous attacks.
Alert Generation
A security tool (IDS, SIEM, antivirus) detects an anomaly or matches a known attack pattern and creates an alert. This is the raw trigger that starts the entire process. Without this step, no incident is ever noticed.
Initial Triage
A level 1 SOC analyst reviews the alert. They check basic context: what system is affected, what time it occurred, and whether there is an obvious benign explanation. They decide to close it (false positive) or escalate it.
Escalation
If the alert looks suspicious, the level 1 analyst assigns a priority level (e.g., low, medium, high, critical) and passes it to a level 2 analyst. The priority determines how fast it must be analysed.
In-Depth Analysis
The level 2 analyst gathers detailed logs, network captures, and other evidence. They reconstruct the timeline of events, identify the attack vector, and determine the scope of the compromise. They confirm whether the alert is a real incident.
Documentation and Reporting
The analyst writes a formal report summarising findings: what happened, what was affected, the attack method, and recommended next steps. This report is handed to the incident response team to begin containment and recovery.
Let’s walk through a real scenario at a medium-sized company that sells products online.
It’s 10:00 AM on a Tuesday. The SOC’s SIEM system generates an alert: “User ‘jsmith’ has logged in from an IP address in Russia at 9:58 AM. This is the first time this user has logged in from this country.” The SIEM has a rule that flags logins from unusual geographic locations as potentially compromised accounts.
The level 1 analyst receives the alert. Their triage process goes like this:
First, they check the user’s travel plans. Is John Smith on a business trip to Russia? A quick look at the HR system shows he’s in the office today — his badge swiped in at 9:30 AM.
Second, they check if John Smith recently logged in from other locations. Looking at his login history, the analyst sees logins from the US office for the past two weeks, all during business hours.
Third, they check the IP address against threat intelligence feeds. The IP address in Russia is known to be associated with a phishing campaign targeting the company’s industry.
Based on this triage, the analyst decides this is likely a compromised account and escalates it to level 2.
The level 2 analyst begins analysis. They pull up detailed logs for John Smith’s account. They see that at 9:58 AM, the attacker logged in and immediately changed the password and email forwarding rules. The attacker then tried to access the customer database, but was blocked because John Smith didn’t have permission to access that system. Next, the attacker attempted to transfer money to a new vendor account — but the finance system requires two-factor authentication for transfers over £1,000, and the attacker couldn’t complete that step.
The analyst collects all this evidence: timestamps, IP addresses, the exact commands run, the systems accessed. They also take a forensic image (a bit-for-bit copy) of John Smith’s laptop to check if malware is present. The analysis confirms that John Smith’s account was compromised via a phishing email he received yesterday — he clicked a link that stole his username and password.
The analyst writes a report summarising the incident: what happened, what was affected (John Smith’s account, but no data breach or financial loss), what the attacker tried to do, and recommendations (reset the account, enforce multi-factor authentication for all users, and run phishing awareness training). This report is handed to the incident response team, who execute the response plan.
In this real-world case, detection caught the anomaly, triage prioritised it correctly, and analysis proved it was a real incident with clear evidence. Without any of these stages, the attacker might have succeeded in stealing customer data or money.
The CISM exam, in domain 4 (Incident Management), tests your understanding of the detection, triage, and analysis process in a very specific way. You won't be asked to configure a SIEM or write a Python script. Instead, you'll be tested on concepts, roles, and the order of operations.
Here are the exact concepts the exam loves to test:
The difference between an event and an incident. An event is any observable occurrence in a system (e.g., a user logging in). An incident is an event that violates security policy (e.g., a user logging in from a restricted IP address). The exam will present scenarios and ask you to classify something as an event or an incident.
The triage process. You need to know that triage is about prioritising alerts, not investigating them fully. The goal is to decide which alerts require immediate attention. The exam may ask what the first step is when an alert is received: the answer is triage, not full analysis.
The role of the SOC analyst. Level 1 analysts perform triage and escalate. Level 2 analysts perform analysis. The exam might ask who is responsible for containing an incident — that’s typically the incident response team, not the SOC analyst doing analysis.
False positives vs false negatives. A false positive is an alert that fires when no real incident exists. A false negative is a real incident that generates no alert. The exam will ask which is more dangerous (false negative) and how to reduce false positives (through tuning detection rules).
The importance of logging. The exam tests that without adequate logging, detection and analysis are impossible. You should know that logs must be protected from tampering, and that organisations need a log retention policy (how long to keep logs).
Common traps the exam sets for you:
Confusing detection with prevention. A detection tool (like an IDS) does not block attacks — it only alerts. If a question asks about preventing an attack, the answer will involve a firewall or an intrusion prevention system (IPS), not an IDS.
Confusing triage with response. Triage is deciding what’s urgent; response is actually doing something about it. The exam will give a scenario where an alert comes in and ask what the next step is. If triage is listed as an option, that’s usually correct over jumping straight to response.
Confusing analysis with root cause analysis. Root cause analysis happens after the incident is contained, to find the underlying weakness. Analysis during the incident is about understanding what is happening right now.
Key definitions to memorise for the exam:
Alert: a notification from a security tool that something might be wrong.
Incident: a confirmed security violation.
Event: any observable occurrence.
False positive: an alert with no real incident.
False negative: an incident that does not generate an alert.
Triage: the process of prioritising alerts based on severity.
Forensic analysis: the detailed investigation to gather evidence.
Escalation: passing an alert from a lower-level analyst to a higher-level one for deeper investigation.
Detection is about spotting anomalies, not confirming attacks — that comes later in analysis.
Triage sorts alerts by urgency and potential impact, not by the technical complexity of the attack.
A false positive wastes time; a false negative can cost the organisation everything.
Analysis answers five questions: what, when, how, which systems, and what data was affected.
Logs are the foundation of detection and analysis — without them, you are blind.
Escalation passes an alert to a more skilled analyst, not necessarily to someone with more authority.
The SOC's job is to detect and analyse, not to respond — response is handled by a separate incident response team.
Forensic evidence must be collected carefully to preserve its integrity for legal proceedings.
These come up on the exam all the time. Here's how to tell them apart.
Event
Any observable occurrence in a system (e.g., a log entry, a login attempt).
May be benign or malicious — the nature is unknown until analysed.
Events are recorded in logs and are the raw material for detection.
Not all events are security-relevant.
Incident
A confirmed security violation that harms or threatens the organisation.
Always malicious or against policy — requires a response.
Incidents are identified from events through analysis and correlation.
An incident is a subset of events that matter to security.
Detection
The act of noticing that something might be wrong.
Happens after the potentially malicious activity has occurred.
Performed by tools like IDS and SIEM.
Prevention
The act of stopping an attack before it succeeds.
Happens before the activity causes harm.
Performed by tools like firewalls and IPS (intrusion prevention systems).
Triage
Quick, high-level assessment to prioritise alerts.
Takes minutes to complete per alert.
Decides which alerts need deeper investigation.
Analysis
In-depth forensic investigation to confirm and understand an incident.
Takes hours or days to complete.
Determines the full scope, impact, and root cause.
Mistake
If our IDS or SIEM doesn't alert us, then no incident has occurred.
Correct
A lack of alerts does not mean no incidents have occurred. Attackers can evade detection by using encrypted traffic, living off the land (using legitimate tools), or exploiting zero-day vulnerabilities that have no known signature. This is called a false negative.
People naturally trust their tools. When a tool says 'nothing is wrong', it's comforting to believe it. The reality is that detection tools are imperfect and must be supplemented with manual reviews, threat hunting, and user reports.
Mistake
Once an alert is escalated to a level 2 analyst, the triage phase is over and analysis begins immediately.
Correct
Triage is an ongoing process that continues even after escalation. A level 2 analyst may perform further triage to refine the priority before diving into full analysis. For instance, they might check if the alert affects a critical server or a test environment, which changes the urgency.
The term 'triage' is often misunderstood as a single step that happens once. In reality, it's a continuous filtering process at every level of the SOC. A level 2 analyst might triage multiple escalated alerts before choosing which to analyse first.
Mistake
The goal of analysis is to find out who the attacker is so they can be arrested.
Correct
The primary goal of analysis is to understand the impact, scope, and method of the attack so that the organisation can contain it and prevent recurrence. Identifying the specific person behind an attack is usually secondary, often impossible, and not the responsibility of the SOC. Law enforcement handles attribution.
Movies and TV shows portray cybersecurity experts as hackers who track down criminals by name. Beginners absorb this narrative. In real incident response, you focus on protecting your organisation, not catching bad guys.
Mistake
All security alerts should be investigated fully to ensure nothing is missed.
Correct
It is impractical and inefficient to investigate every alert. Most alerts are false positives. Triage filters them out so analysts focus on the highest-risk alerts. Investigating every alert would waste time and resources, leading to analyst burnout and slower response to real incidents.
Beginners often think thoroughness equals better security. However, in a SOC with thousands of daily alerts, you cannot treat everything as equally important. The skill is in prioritising, not in investigating everything.
Mistake
If an alert is closed as a false positive, no further action is needed.
Correct
When an alert is a false positive, the analyst should document why it was false and recommend tuning the detection rule to reduce future false positives. Ignoring false positives means the same useless alerts will keep firing, wasting time and potentially masking a real attack.
It feels natural to close a nuisance alert and move on. But in security, each false positive is a signal that your detection logic is imperfect. Failing to tune rules is a missed opportunity to improve the system.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IDS (intrusion detection system) monitors network traffic for malicious patterns and generates alerts. A SIEM (security information and event management) collects logs from many different sources and uses correlation rules to identify complex threats. A SIEM can ingest alerts from an IDS, but an IDS cannot perform the log correlation that a SIEM does.
During triage, you prioritise based on the potential impact and the confidence of the alert. Alerts involving critical systems (like a database server) or data exfiltration indicators get higher priority than alerts on low-risk systems. You also consider whether the alert matches a known attack pattern or appears to be a false positive.
A false positive is an alert that fires when there is no real security incident. It is bad because it consumes analyst time and attention. Too many false positives can lead to alert fatigue, where analysts start ignoring alerts, potentially missing a real attack.
Yes, incidents can be detected through manual reports from users. For example, an employee might notice that their files have been renamed and cannot be opened, indicating ransomware. User reports are an important detection source, especially for attacks that evade automated tools.
A level 1 SOC analyst performs initial triage on incoming alerts. They check basic context, determine if the alert is a false positive, and escalate suspicious alerts to level 2. They do not perform deep forensic analysis; that is the job of level 2 and level 3 analysts.
There is no single answer, but common practice is to keep logs for at least 90 days to one year. The retention period depends on legal requirements, industry regulations, and the organisation's risk appetite. Longer retention helps in analysing incidents that span months or in meeting compliance obligations.
You've finished Incident Detection, Triage, and Analysis. Continue through the CISM study guide to build a complete picture of the exam.
Done with this chapter?