Incident response is the organised process of identifying, containing, and recovering from a security breach. Security monitoring is the continuous watch over your systems that detects the breach in the first place. Understanding how these two capabilities work together is critical for a CISA candidate because auditors must evaluate whether an organisation can detect and respond to attacks quickly enough to limit damage.
Jump to a section
A simple way to picture Incident Response and Security Monitoring
You have exactly 3 minutes from the moment your phone buzzes with a motion alert to decide whether a burglar is in your home or if it is just your cat knocking over a plant. This is the pressure of incident response.
Your home security system has five layers. First, sensors on every door and window (detection) send signals to a central hub (the security information and event management, or SIEM, system). Second, that hub uses rules to classify events: a window opening at 2 PM on a Tuesday is normal (the cleaner is there), but the same window opening at 3 AM is critical. Third, when a critical event triggers, the hub alerts a monitoring team at a remote station (the security operations centre, or SOC). Fourth, the team does not call the police immediately — they first check the indoor camera (analyse the log) to confirm it is a person, not a stray branch. Fifth, only after visual confirmation do they dispatch the police (initiate the incident response plan) and lock down the system (containment).
This analogy maps precisely to IT security monitoring. The sensors are your network firewalls and intrusion detection systems. The central hub is your SIEM. The rule-based classification is the correlation engine that filters noise. The remote monitoring team is the SOC analyst. The police dispatch is the formal incident response process with escalation and containment. Without the monitoring layer, you only discover the burglary when you return home — hours or days later, when the thief is long gone and the damage is done.
Incident response and security monitoring are two sides of the same coin. Security monitoring is the ongoing, automated surveillance of an organisation’s IT environment. It uses tools that collect and analyse data from servers, networks, applications, and user activities to spot anything unusual. Incident response is the structured, step-by-step plan that kicks into action once something unusual is confirmed as a genuine security incident.
Consider a simple example. An employee, Sarah, logs into the company payroll system at 3:00 AM from an IP address in another country. Sarah lives in the UK and never works overnight. A security monitoring tool called an intrusion detection system (IDS) picks up this log-in event. The IDS does not act by itself — it sends the event to a central platform called a Security Information and Event Management (SIEM) system. The SIEM correlates this event with other data, such as the fact that Sarah has never logged in from outside the UK and that her last log-in was 8 hours earlier in the London office. The SIEM flags the event as high-risk and creates an alert.
That alert is sent to a Security Operations Centre (SOC) — a team of analysts who monitor alerts 24/7. The SOC analyst investigates: they check the IP address reputation, look for other unusual activity from Sarah’s account, and possibly call Sarah to verify. If the investigation confirms it is a compromised account, an incident is declared. This triggers the incident response plan. The plan has five standard phases, based on the widely recognised framework from the National Institute of Standards and Technology (NIST):
Preparation: Before any incident happens, the organisation writes policies, buys tools, trains staff, and runs practice drills. This phase ensures the team is ready.
Detection and Analysis: The monitoring tools and SOC analysts identify a potential incident and determine whether it is real. This is where the SIEM, IDS, and human judgement combine.
Containment, Eradication, and Recovery: Once an incident is confirmed, the team acts to stop it spreading (containment), remove the attacker’s access or malware (eradication), and restore normal operations (recovery).
Post-Incident Activity: After the incident is resolved, the team writes a report, identifies what went wrong, and updates policies and tools to prevent a repeat.
The SIEM is the most important monitoring tool. It ingests logs from firewalls, servers, applications, and other devices. Logs are simple text records of events: a user logged in, a file was downloaded, a connection was refused. A single organisation can generate millions of log entries per day. The SIEM’s value is that it can filter out the noise and surface only the events that match known attack patterns (called signatures) or that deviate from normal behaviour (called anomalies).
Why do organisations need both monitoring and response? Because an attack can happen in seconds. A 2023 industry report found that the average time to identify a breach was 207 days. That means attackers can lurk inside a network for months, stealing data, before anyone notices. Monitoring shortens that time. Response limits the damage once the breach is found. Without monitoring, you cannot respond in time. Without a response plan, a detected threat is just a scary alert with no action.
For the CISA exam, you must remember that incident response is a formal, documented process, not an ad hoc scramble. Organisations should have an incident response policy, a designated team, and a communication plan that includes legal counsel, public relations, and law enforcement if needed. Security monitoring is the technical backbone that feeds the detection phase. The two capabilities together form the organisation’s ability to defend itself in real time.
Preparation
Before any incident occurs, the organisation develops policies, procures monitoring tools (such as a SIEM), trains staff, and conducts tabletop exercises. This phase ensures the team is ready to act quickly and decisively when a real incident happens.
Detection and Analysis
Monitoring tools collect logs and events from across the IT environment. The SIEM correlates these events and generates alerts. A human analyst then investigates the alert to determine whether it is a genuine security incident or a false positive.
Containment, Eradication, and Recovery
Once an incident is confirmed, the team acts immediately to stop it from spreading (containment), remove the attacker's foothold or malware (eradication), and restore affected systems to normal operation (recovery). This phase is time-sensitive.
Post-Incident Activity
After the incident is resolved, the team conducts a thorough review. They document what happened, how it was handled, and what went wrong. The output is a set of recommendations to update policies, tools, or training to prevent a recurrence.
Continuous Improvement
The findings from post-incident reviews are fed back into the preparation phase. Detection rules are updated, playbooks are revised, and staff receive additional training. This cycle ensures the organisation's monitoring and response capabilities mature over time.
An IT professional — typically a security analyst or a SOC manager — works with both monitoring tools and response procedures every day. Let us walk through a realistic scenario at a mid-sized e-commerce company.
The company uses a SIEM tool like Splunk or Microsoft Sentinel. The SOC has three shifts of analysts who monitor a central dashboard that shows alerts, prioritised by severity. Alerts come in as tickets. A typical day starts with the analyst reviewing the overnight queue. They see 15 low-priority alerts (failed log-ins from known internal users) and 2 medium-priority alerts (unusual outbound traffic from a server that normally only receives traffic).
The analyst investigates the medium-priority alerts first. They click on the alert, which opens a timeline of related events. They see that server X, which hosts the company’s product catalogue, sent 500 MB of data to an IP address in Russia at 2:00 AM. The analyst checks the server’s log. It shows that a new scheduled task was created at 1:55 AM by an administrative account. That account belongs to a system administrator named James. The analyst calls James, who says he did not create any scheduled tasks. This confirms that the administrative account is compromised.
The analyst declares an incident in the incident response platform. This triggers an automated action: the server is isolated from the network (containment). The SOC manager is notified. The incident response team convenes on a conference call. They follow the organisation’s incident response plan, which includes:
Gathering all logs from the affected server and the compromised account.
Taking a forensic image of the server’s memory and disk for later analysis.
Resetting the passwords for the compromised account and all accounts with similar privileges.
Scanning the network for any other systems that may have been accessed by the same attacker.
Notifying the legal team because customer data might have been exfiltrated.
After the incident is contained, the team analyses the root cause. They discover that James’s account password was weak and he had not enabled multi-factor authentication (MFA). The team writes a post-incident report recommending that all administrative accounts be required to use MFA and that the company implement a privileged access management (PAM) tool that rotates passwords automatically.
The IT professional’s role in monitoring is not just to watch dashboards. It is to tune the SIEM so that it produces fewer false positives (alerts that look dangerous but are actually benign). False positives waste time. One way to tune is by creating exceptions for known safe activities, such as a scheduled backup that generates large data transfers every night. The analyst also updates detection rules when new threats are discovered. For example, if a new ransomware strain is reported to use a specific file name, the analyst adds a rule that alerts whenever that file name appears in a download.
In summary, the real-world job is a cycle: monitor, investigate, respond, recover, and improve. Each incident teaches the team something, and that knowledge is fed back into the monitoring rules and the response plan.
The CISA exam tests your understanding of incident response and security monitoring in the context of evaluating controls. You will not be asked to configure a SIEM. Instead, you will be asked to assess whether an organisation’s design and procedures are adequate. The exam focuses on these key areas:
The phases of incident response: You must know the NIST phases (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity). Expect questions that describe a scenario and ask which phase is missing or which step belongs in which phase.
The role of the SIEM: CISA loves questions about the SIEM as a centralised monitoring tool. They may ask what the SIEM does (correlates logs, generates alerts) versus what it does not do (block traffic, patch systems).
Detection methods: Be able to distinguish between signature-based detection (matching known patterns) and anomaly-based detection (spotting deviations from a baseline). Exam questions will use terms like “behavioural analysis” or “heuristic detection” to test this.
Key metrics: The mean time to detect (MTTD) and mean time to respond (MTTR) are standard metrics. Questions may ask which metric shows how quickly the organisation spots an incident (MTTD) versus how quickly it contains it (MTTR).
Escalation procedures: The exam expects you to know that not every alert becomes an incident. There is a triage process. Organisations should have a formal escalation matrix that defines who is notified based on severity.
Common traps the exam sets:
They describe a situation where the monitoring team detects a breach but the response team is slow. The question asks what the organisation should improve. The correct answer is usually the response plan or the escalation process — not the monitoring tool, because the monitoring already worked.
They list a set of tools and ask which one is most suitable for real-time monitoring. The answer is a SIEM, not a vulnerability scanner (which is a point-in-time check) or a firewall (which blocks traffic but does not analyse logs).
They describe a post-incident review and ask what the primary goal is. The answer is “to identify improvements and update procedures,” not “to assign blame” or “to punish the employee.” CISA emphasises learning and improvement.
Key definitions to memorise for the exam:
Incident: A security event that results in harm or poses an imminent threat of harm.
Event: Any observable occurrence. Not all events are incidents.
Alert: A notification from a monitoring tool that an event matches a detection rule.
False positive: An alert that incorrectly indicates malicious activity (a common problem).
False negative: A real attack that the monitoring tool fails to detect (more dangerous).
Playbook: A predefined set of steps for handling a specific type of incident (e.g., ransomware playbook).
The most heavily tested concept is the distinction between a detection control and a response control. Monitoring is a detective control — it finds problems. The incident response plan is a corrective control — it fixes problems. Audit questions will ask you to classify a given tool or process into one of these control categories.
Security monitoring is a detective control that identifies unusual activity; incident response is a corrective control that activates after an incident is confirmed.
The five phases of the NIST incident response framework are Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity.
A SIEM (Security Information and Event Management) tool collects and correlates logs from multiple sources to generate alerts, but it does not block attacks.
Mean Time to Detect (MTTD) measures how quickly an organisation spots a breach; Mean Time to Respond (MTTR) measures how quickly it contains and resolves it.
Not every alert is an incident — human triage and investigation are required before declaring an incident and activating the response plan.
Post-incident activity should focus on lessons learned and process improvements, not on assigning blame to individuals.
These come up on the exam all the time. Here's how to tell them apart.
SIEM (Security Information and Event Management)
Collects and correlates logs from many sources (servers, firewalls, apps).
Provides a centralised dashboard for monitoring the entire environment.
Primarily a passive monitoring tool that generates alerts.
EDR (Endpoint Detection and Response)
Installed directly on endpoints (laptops, desktops, servers).
Focuses on detecting threats at the device level using behavioural analysis.
Can actively respond by isolating an endpoint or killing a malicious process.
False Positive
An alert incorrectly indicates malicious activity that is actually benign.
Wastes analyst time and can lead to alert fatigue.
Caused by overly broad detection rules or misconfigured tools.
False Negative
A real attack goes undetected by the monitoring tools.
More dangerous than a false positive because the attack proceeds unnoticed.
Caused by inadequate detection rules or gaps in log coverage.
Signature-Based Detection
Compares activity against a database of known attack patterns (signatures).
Effective for detecting known threats but misses novel attacks.
Low false positive rate for known malware.
Anomaly-Based Detection
Establishes a baseline of normal behaviour and flags deviations.
Can detect previously unknown (zero-day) attacks.
Higher false positive rate because legitimate changes may appear anomalous.
MTTD (Mean Time to Detect)
Measures the time from the start of an attack to its discovery.
A low MTTD indicates effective monitoring and alerting.
Reducing MTTD is the primary goal of security monitoring.
MTTR (Mean Time to Respond)
Measures the time from discovery to containment or resolution.
A low MTTR indicates an efficient and practised incident response team.
Reducing MTTR is the primary goal of incident response planning.
Mistake
Security monitoring and incident response are the same thing.
Correct
Security monitoring is the continuous detection of unusual activity, while incident response is the structured process that activates only after a genuine incident is confirmed. Monitoring feeds detection; response handles action.
Beginners see them as one unified function because they often appear together in job titles and tools. They are actually distinct processes with separate goals, metrics, and teams.
Mistake
A SIEM can automatically stop an attack in progress.
Correct
A SIEM is a monitoring and analysis tool, not a prevention tool. It generates alerts and dashboards, but it does not block traffic or quarantine systems. Those actions require separate tools like firewalls or endpoint protection platforms.
The name 'Security Information and Event Management' sounds powerful, and learners assume 'management' includes active blocking. In reality, the SIEM is a passive collector and correlator.
Mistake
If a monitoring tool generates an alert, it means an incident has occurred.
Correct
An alert is just a suspicion. Many alerts are false positives or benign anomalies. An incident is only declared after human investigation confirms malicious activity. The triage process is critical.
Newcomers equate detection with confirmation. They do not realise that the volume of alerts is high and that most are noise. The exam tests this by asking what happens after an alert fires.
Mistake
The goal of incident response is to identify and punish the person who caused the breach.
Correct
The primary goal of incident response is to contain the damage, eradicate the threat, and restore normal operations. Determining root cause and updating defences is the follow-up. Blame is counterproductive.
In everyday life, when something goes wrong, we look for who is at fault. In IT security, the focus is on process improvement, not individual fault, because attackers exploit systemic weaknesses.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An event is any observable occurrence in a system, such as a user logging in or a file being downloaded. An incident is a specific type of event that results in harm or poses an imminent threat, such as a confirmed data breach or ransomware infection. Not all events are incidents.
No. A SIEM is a monitoring tool that collects and analyses logs to generate alerts. It does not block traffic or quarantine systems. Blocking is done by separate tools like firewalls, intrusion prevention systems (IPS), or endpoint detection and response (EDR) platforms.
A false positive is an alert that incorrectly flags benign activity as malicious. For example, a legitimate software update might trigger a rule designed to detect malware downloads. False positives waste analyst time and must be reduced by tuning the monitoring rules.
The first action is containment — stop the incident from spreading. This might involve disconnecting the affected system from the network, disabling compromised accounts, or blocking malicious IP addresses. Quick containment limits the damage.
The CISA exam expects that organisations should test their incident response plan at least annually, and more frequently if the environment changes significantly. Testing can take the form of tabletop exercises (discussion-based) or full simulations (technical drills).
MTTD stands for Mean Time to Detect. It measures the average time between when an attack begins and when the organisation becomes aware of it. A lower MTTD means the organisation can respond faster, which reduces potential damage.
You've finished Incident Response and Security Monitoring. Continue through the CISA study guide to build a complete picture of the exam.
Done with this chapter?