If you have no plan for when your organisation gets hacked, a single ransomware attack can shut down your entire business for weeks and cost millions in ransom payments and lost sales. Incident response and recovery planning is the practice of building a detailed, rehearsed playbook for exactly what to do when an attack happens, so your team can stop the damage, kick the attacker out, and get back to normal as fast as possible. For the SC-100 exam, you need to know how to design these plans for cloud environments like Microsoft Azure, where systems are spread across the internet and attackers can strike from anywhere.
Jump to a section
A simple way to picture Incident Response and Recovery Planning
A fire chief does not wait for a building to be on fire to decide what to do. Before any emergency, the chief has already mapped out every hydrant in the district, planned escape routes, assigned specific crews to specific tasks (one team extinguishes, another searches for trapped people, another coordinates with the hospital), and run practice drills so often that every firefighter knows their role without thinking. The chief also stores backup hoses at a separate station in case the first one is inaccessible.
When a real fire starts, the chief does not panic. The team follows the pre-written plan: detection (someone pulls the alarm), triage (is the fire contained or spreading?), containment (close fire doors), eradication (put out the flames), and recovery (ventilate smoke, inspect structural damage, file a report). After the fire is out, the chief leads a debrief to ask: what went well, what went wrong, and how do we improve the plan for next time?
This maps precisely to incident response and recovery in cybersecurity. The fire chief's pre-written plan is your incident response plan. The crew roles are your incident response team. The backup hoses at a separate station are your off-site backups and secondary data centres. The post-fire debrief is the post-incident review that turns every attack into a learning opportunity. Without this preparation, even a small kitchen fire becomes a catastrophe.
Incident response is the process of detecting, analysing, containing, and recovering from a cybersecurity attack. Recovery planning is the part of that process that focuses specifically on getting your systems and data back to normal after the immediate threat is neutralised. Together, they form the backbone of every organisation's ability to survive a cyber attack.
Think of it like this: everyone knows they need to lock their doors at night. But what do you do if you come home and find a window smashed and your laptop missing? Do you just clean up the glass and buy a new laptop? Not if you want to catch the thief, secure the house against the next break-in, and prove to your insurance company what was stolen. Incident response is the structured way of handling that situation so you minimise losses, learn from the event, and prevent recurrence.
For the SC-100 exam, the core framework you need to understand is the NIST (National Institute of Standards and Technology) incident response lifecycle. Although there are other frameworks, Microsoft aligns closely with NIST, and exam questions are built around its four phases:
Preparation: This is everything you do before an attack happens. You write your incident response plan, assemble your incident response team, acquire tools like security information and event management (SIEM) systems (which collect logs from all your systems and alert you to suspicious activity), and run tabletop exercises (practice sessions where the team talks through a hypothetical attack scenario). Without preparation, the rest of the phases are useless because nobody knows what to do.
Detection and Analysis: This is where you discover that something is wrong. Logs from your systems show unusual traffic patterns. An antivirus tool flags a suspicious file. A user reports that their computer is behaving strangely. The security team must analyse the data to confirm whether it is a real incident (a genuine security breach) or a false positive (an alert that looks serious but turns out to be harmless). This phase also involves triage: determining how severe the incident is and how quickly you need to respond.
Containment, Eradication, and Recovery: This is the action phase. Containment means stopping the attack from spreading further. For example, you might isolate an infected computer by disconnecting it from the network. Eradication means removing the attacker's access and cleaning up the affected systems. This could involve deleting malicious files, resetting compromised user passwords, and patching the vulnerability the attacker exploited. Recovery is the specific process of restoring normal operations, such as restoring data from backups, bringing systems back online, and monitoring closely to ensure the attacker does not return.
Post-Incident Activity: After the immediate crisis is over, the team conducts a post-mortem (sometimes called a lessons learned meeting). You ask: what happened? Why did it happen? What did we do well? What could we have done better? What changes do we need to make to our security controls or incident response plan to prevent this from happening again? This phase is critical because every incident is a chance to improve.
Why does this exist? Before formal incident response planning existed, organisations often reacted chaotically. An IT administrator might notice a problem, start clicking around randomly, accidentally delete evidence, and fail to contain the attack. Attackers could move laterally (spread from one system to another) for weeks before anyone noticed. Recovery might take months because nobody knew which backup was the most recent or cleanest. Incident response planning replaces that chaos with a repeatable, well-practised process that reduces damage, speeds up recovery, and satisfies legal and regulatory requirements.
For the SC-100 exam, you must also understand the difference between BCDR (Business Continuity and Disaster Recovery) and incident response. Business continuity is about keeping the business running during a disruption (e.g., rerouting calls to a backup call centre). Disaster recovery is about restoring IT systems specifically after a major event like a natural disaster. Incident response is about handling a security incident specifically. The three overlap, but they are distinct planning domains. The exam will test you on how these plans relate to each other, especially in cloud environments where you can use features like Azure Site Recovery (which automates failover to a secondary region) and Azure Backup (which creates point-in-time copies of your data).
A key principle in incident response is least privilege: users and systems should only have the minimum access needed to do their jobs. This principle limits how far an attacker can spread if they compromise a single user account. If a marketing intern's account is stolen but the intern only has read access to a folder of brochures, the attacker cannot use that account to delete the entire database.
Another critical concept is the assume breach mentality: instead of trying to build an impenetrable fortress, design your systems assuming an attacker is already inside. This changes your strategy from pure prevention to early detection and rapid response. Microsoft's security tools like Microsoft Sentinel (a cloud-native SIEM) and Microsoft Defender for Cloud (a cloud security posture management tool) are built around this philosophy.
Finally, remember that incident response is not just a technical problem. It involves legal teams (to handle regulatory notifications like GDPR data breach reporting), communications teams (to manage public relations and customer notifications), and executive leadership (to approve funding for remediation and recovery efforts). The exam expects you to know how these non-technical stakeholders fit into the incident response plan.
Detection and Alerting
Configure Microsoft Sentinel with analytics rules that look for known attack patterns, such as multiple failed login attempts followed by a successful login from an unusual country. When a rule triggers, an alert is generated and sent to the security team. This step is the starting point for the entire incident response process, because you cannot respond to an attack you do not know about.
Triage and Classification
The security team reviews the alert to determine whether it is a genuine security incident or a false positive. They classify the severity based on the affected assets — for example, a compromise of a domain administrator account is higher severity than a compromised guest user. This step ensures that resources are prioritised toward the most dangerous incidents first.
Containment
The team takes immediate action to stop the attack from spreading. In Azure, this might involve disabling a compromised user account in Microsoft Entra ID, applying a network security group that blocks all inbound and outbound traffic to a compromised virtual machine, or taking a forensic snapshot of a disk before isolating it. The goal is to contain the damage while preserving evidence for later analysis.
Eradication and Investigation
Once the attack is contained, the team removes the attacker's foothold. This includes deleting malicious files, revoking attacker-created credentials, patching the vulnerability that was exploited, and scanning the entire environment to confirm no other backdoors remain. The investigation runs in parallel to determine the root cause and the full scope of the breach.
Recovery and Restoration
The team restores affected systems from clean backups using Azure Backup or Azure Site Recovery. They first restore to a test environment to verify the data is clean and free of malware. Once confirmed, they promote the restored systems to production. Monitoring is ramped up to look for signs that the attacker has returned.
Post-Incident Analysis and Improvement
The team holds a formal lessons-learned meeting to review what happened, what worked well, and what went wrong. They update the runbooks, adjust security configurations, and add new detection rules to catch similar attacks faster. This step closes the loop and turns a single incident into a permanent improvement to the organisation's security posture.
An IT professional, specifically a Cybersecurity Architect, spends a significant portion of their time designing and testing incident response and recovery plans. They do not just write a document and file it away. They treat the plan as a living asset that is constantly updated based on new threats, changes to the cloud infrastructure, and lessons learned from actual incidents.
Here is a concrete scenario. Sarah is a cybersecurity architect at a mid-sized e-commerce company that uses Microsoft Azure to host its online store. The company has 500 employees and processes customer payment data. Sarah is tasked with designing the incident response and recovery strategy.
Step-by-step, here is what Sarah actually does:
First, Sarah performs a risk assessment to identify what needs protecting. She lists the crown jewels: the customer database (containing names, addresses, and payment card data), the product catalogue, the order processing system, and the administrative accounts that control Azure resources. She also identifies regulators that might get involved, such as the Payment Card Industry Security Standards Council (PCI SSC), because the company stores credit card data.
Second, Sarah designs the incident response plan. She defines the incident response team members: a technical lead from IT, a legal representative, a communications manager, and an executive sponsor. She writes runbooks, which are step-by-step checklists for specific types of incidents. For example, one runbook covers the exact process for responding to a ransomware attack on the database. Another covers a distributed denial-of-service (DDoS) attack that overwhelms the website with fake traffic. Each runbook includes who to call, what logs to check, what tools to use, and how to escalate if the incident is more severe than expected.
Third, Sarah implements technical controls to support the plan. She configures Microsoft Sentinel to collect logs from all Azure resources and set up automated alerts for suspicious activities, such as a user logging in from an unusual location or a sudden spike in data export traffic. She enables Azure Backup with a retention policy that keeps 90 days of backups, and she configures those backups to be stored in a separate Azure region so that if the primary region is compromised, the backups are safe. She also sets up Azure Site Recovery to automate failover to a secondary region if the primary region is destroyed by a natural disaster or taken offline by an attack.
Fourth, Sarah tests the plan. She schedules a tabletop exercise with the incident response team. The scenario: an attacker has gained access to an employee's Microsoft Entra ID account (which is the cloud-based identity and access management service) and is exfiltrating customer data. During the exercise, the team talks through each step of the runbook. They discover that the runbook does not specify who is responsible for contacting the payment card processor to shut down transactions. Sarah updates the runbook immediately.
Fifth, Sarah conducts a live drill. She works with the IT team to simulate a ransomware attack on a non-production environment (a copy of the real system used only for testing). The team must follow the runbook to detect the attack, contain it by disabling the affected virtual machine, eradicate the malware, and restore the data from Azure Backup. The drill reveals that the restore process takes eight hours instead of the target of two hours. Sarah investigates and finds that the backup configuration is not set to restore to a different subnet, causing network conflicts. She fixes the configuration and re-runs the drill until the restore time meets the target.
Throughout all this, Sarah documents everything. The final incident response plan is a living document stored alongside the runbooks in a shared cloud repository that the entire team can access from anywhere. She also ensures that new employees receive incident response training as part of their onboarding, so that even the junior IT staff know the basics: who to call, what to preserve, and how to start the containment process without making things worse.
For the SC-100 exam, you are expected to be able to design this plan on paper. You need to know which Azure services to recommend for each phase of the incident response lifecycle, how to secure those services, and how to ensure the plan complies with regulations like GDPR or HIPAA.
The SC-100 exam tests your ability to design incident response and recovery solutions in the Azure cloud environment. The questions are not about memorising a single definition or a list. They are scenario-based. Microsoft gives you a business requirement, a set of constraints, and a list of possible Azure services or configurations, and you must choose the correct answer that meets the overarching security objectives.
Here are the specific concepts you need to master for this exam objective:
Know the NIST incident response lifecycle backwards and forwards. Questions will describe an action (e.g., restoring data from a backup) and ask which phase it belongs to. The trap: some actions straddle phases. For example, containment might involve taking a forensic image of a virtual machine's disk before shutting it down. The correct answer is that the forensic imaging is part of containment (because you are preserving evidence while also limiting damage), not part of post-incident activity.
Understand the relationship between Azure services and the incident response phases. The exam loves to test which Azure service maps to which phase. For example:
Preparation: Use Azure Policy to enforce security configurations, Microsoft Sentinel to define analytics rules, and Microsoft Entra ID to manage identities with least privilege.
Detection and Analysis: Use Microsoft Sentinel for log collection and alerting, and Microsoft Defender for Cloud for vulnerability scanning and security posture assessments.
Containment, Eradication, and Recovery: Use Azure Backup and Azure Site Recovery for restoring data and systems. Use Azure Network Security Groups (NSGs) and Azure Firewall to isolate compromised virtual networks.
Post-Incident Activity: Use Azure Monitor and Log Analytics to query historical logs for root cause analysis.
Be clear on the difference between a security incident and a security event. A security event is any observable occurrence in a system (like a user entering the wrong password twice). A security incident is a confirmed security breach or a serious violation of security policy that requires a coordinated response. The exam will present logs and ask you to classify whether the situation warrants activating the incident response plan. The correct answer pattern is: if the event indicates a confirmed breach or violation of policy (not just an anomaly), it is an incident.
Understand how incident response plans differ between on-premises environments and cloud environments. In the cloud, you cannot physically unplug a server. Instead, containment involves actions like disabling a user account in Microsoft Entra ID, applying a network security group that blocks all traffic to a virtual machine, or deleting a compromised Azure resource. Cloud recovery is faster because you can spin up new virtual machines from a clean image quickly. But cloud environments also introduce new challenges, such as the shared responsibility model: you are responsible for securing your data and configurations, while Microsoft secures the underlying cloud infrastructure. The exam will test whether you know which parts of the response you control and which parts are handled by Microsoft.
Know the key terms: RTO (Recovery Time Objective) is the maximum acceptable amount of time a system can be offline after an incident. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss measured in time (e.g., losing at most 15 minutes of transactions). The exam will tie these to business requirements: if a business says they cannot afford to lose more than 5 minutes of data, you must design a recovery solution with an RPO of 5 minutes or less, which typically requires synchronous replication (data copied to a secondary site in real time) rather than hourly backups.
The exam tests your ability to design a secure backup and restore strategy. For example, you must know to use immutable backups (backups that cannot be modified or deleted, even by administrators) to protect against ransomware that tries to delete backups. You must also know the 3-2-1 backup rule: three copies of your data, on two different storage media, with one copy stored off-site (in Azure, this means storing backups in a separate region).
Common traps in exam questions:
Confusing incident response with disaster recovery. A ransomware attack is an incident; a hurricane that destroys a data centre is a disaster. The response plans are different, though they share some recovery steps.
Choosing a solution that is too expensive or complex for the business requirement. For example, if a small business only needs to restore one database that changes rarely, recommending a real-time replication solution is overkill. The correct answer is often the simplest, most cost-effective solution that meets the stated RTO and RPO.
Forgetting to involve non-technical stakeholders. Questions that ask who should be part of the incident response team always include legal and communications as correct answers.
Finally, Microsoft emphasises the concept of a security operations centre (SOC). The exam will test your understanding of how a SOC should be structured and what tools it uses. Know that a SOC uses a SIEM (like Microsoft Sentinel) to centralise log analysis and uses a SOAR (Security Orchestration, Automation, and Response) platform to automate common response actions, such as automatically disabling a compromised user account when a high-severity alert fires.
Incident response has four phases from NIST: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity — and every design decision maps back to one of these phases.
Recovery Time Objective (RTO) is the maximum time a system can be down, and Recovery Point Objective (RPO) is the maximum acceptable data loss in minutes or hours — both are set by business requirements, not technical preferences.
Use Azure Backup with immutable storage and store a copy of your data in a separate Azure region to protect against ransomware that tries to delete your recovery points.
Microsoft Sentinel is a cloud-native SIEM that centralises log collection and alerting for detection and analysis across your entire Azure environment.
The assume breach mentality means you design your incident response plan expecting that an attacker is already inside your network, shifting focus from pure prevention to early detection and rapid containment.
Incident response is a cross-functional effort involving IT, legal, communications, HR, and executive leadership — never design a plan that treats it as a solo IT project.
Each incident type (ransomware, DDoS, data breach, insider threat) should have its own runbook with specific containment steps, because the same generic process cannot handle every scenario effectively.
Tabletop exercises and live drills are non-negotiable: a plan that has never been tested will fail under pressure, so schedule and document testing as part of your preparation phase.
These come up on the exam all the time. Here's how to tell them apart.
Incident Response
Focuses on responding to a security breach (e.g., a hacker exfiltrating customer data)
Involves containment, eradication, and forensic investigation to understand the attacker's methods
Triggers legal and communications teams for regulatory notifications and public relations
Disaster Recovery
Focuses on restoring IT systems after a major natural or technical disruption (e.g., a hurricane or power outage)
Involves failover to a secondary data centre and restoration from backups without forensic focus
Primarily handled by IT operations with less involvement from legal or communications unless required by compliance
Recovery Time Objective (RTO)
The maximum acceptable time a system can be offline after an incident (e.g., 4 hours)
Drives decisions about automated failover technologies like Azure Site Recovery
If the system is down longer than the RTO, the business suffers unacceptable operational or financial loss
Recovery Point Objective (RPO)
The maximum acceptable amount of data loss measured in time (e.g., lose at most 15 minutes of data)
Drives decisions about backup frequency and replication type (synchronous vs asynchronous)
If more data is lost than the RPO allows, the business may lose transactions or customer records that cannot be recreated
SIEM (Security Information and Event Management)
Collects, normalises, and analyses logs from many sources to detect suspicious activity
Generates alerts for the security team to investigate manually
Examples: Microsoft Sentinel, Splunk, IBM QRadar
SOAR (Security Orchestration, Automation, and Response)
Automates responses to common threats using playbooks (e.g., automatically disable a compromised user account)
Integrates with SIEM and other tools to execute actions without human intervention
Examples: Microsoft Sentinel SOAR capabilities, Palo Alto XSOAR
Assume Breach
Designs systems assuming an attacker is already present in the network
Prioritises early detection, rapid containment, and minimal blast radius through segmentation and least privilege
Acceptable because no perimeter is 100% effective against sophisticated attackers
Prevention-First Security
Focuses on building a strong perimeter and preventing any attacker from entering
Invests heavily in firewalls, antivirus, and access control policies at the boundary
Risk of being caught off guard if the perimeter is breached, with no detection or response capabilities inside
Mistake
Incident response is only about stopping the immediate attack, so once the attacker is kicked out, the work is done.
Correct
The full incident response process includes a post-incident review to document lessons learned and update security controls. Without this step, you will likely be attacked the same way again.
Beginners think of incident response as a firefighting activity (put out the fire and go home). They miss the formal learning loop that turns each incident into a permanent security improvement.
Mistake
An incident response plan is just a document you write once and store in a shared folder in case something goes wrong.
Correct
A plan must be a living document that is tested regularly through tabletop exercises and live simulations. Without testing, the plan is worthless because teams will not know how to execute it under pressure.
Many people come from non-technical backgrounds where plans are static (like a marketing strategy document). They do not realise that incident response is a practised skill, not just a theoretical framework.
Mistake
Cloud backups are automatically safe from cyber attacks, so you do not need special protections like immutability.
Correct
Ransomware attackers increasingly target backup systems. If they can delete or encrypt your backups, you cannot recover. You must use immutable backups (which cannot be modified or deleted) and store at least one copy in a separate, isolated environment such as a different Azure region.
Beginners assume that because the cloud is managed by a large company like Microsoft, the data is inherently safe. They do not understand the shared responsibility model: Microsoft secures the cloud infrastructure, but you are responsible for securing your data and configurations within it.
Mistake
An incident response plan should be the same for every possible type of attack.
Correct
A good plan includes multiple runbooks tailored to specific incident types (ransomware, DDoS, data breach, insider threat, etc.). Each runbook has different steps for containment, eradication, and communication. A generic plan leads to confusion during a real event.
Beginners gravitate toward simplicity and want a single checklist that covers everything. They do not recognise that different attack vectors require fundamentally different containment and eradication steps (e.g., isolating a compromised user account is different from blocking DDoS traffic at the network perimeter).
Mistake
Incident response is purely a technical IT problem that the IT team handles alone.
Correct
A full incident response team includes legal (for regulatory notifications and data privacy compliance), communications (for external messaging and customer notifications), HR (for insider threat investigations), and executive leadership (for resource approval and crisis management).
This misconception stems from a narrow view of cybersecurity as a technology-only domain. Beginners do not realise that every security incident has legal and reputational consequences that require coordination across departments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A security event is any observable occurrence in a system, such as a user typing an incorrect password. A security incident is a confirmed breach or a serious violation of security policy that requires a coordinated response, such as evidence that an attacker has successfully logged into an account they should not have access to.
You need one overarching incident response plan that defines your teams, roles, and general process, plus a set of runbooks (detailed checklists) for specific attack types like ransomware, DDoS, and data breach. A single generic procedure is not detailed enough to handle the specific containment and eradication steps required for different attack vectors.
At least once per year for a full live drill that simulates a realistic attack, and quarterly for tabletop exercises where the team talks through a scenario without touching real systems. More frequent testing is recommended if your environment changes significantly, such as after migrating a major system to the cloud.
The shared responsibility model means Microsoft secures the underlying cloud infrastructure (physical servers, network, data centres), while you are responsible for securing everything you put in the cloud (your data, your configurations, your user accounts). During an incident, you cannot assume Microsoft will handle containment for you; you must have your own procedures for isolating your resources.
Ransomware attackers often try to delete or encrypt backup files to prevent you from recovering your data without paying the ransom. Immutable backups are stored in a format that cannot be modified or deleted for a set period, even by an administrator, so they remain a clean, safe recovery point even if the attacker gains admin access.
Microsoft Entra ID is the identity and access management service that controls who can sign in to cloud services. During an incident, you can use Entra ID to instantly disable compromised user accounts, revoke session tokens, and enforce multi-factor authentication (MFA) on all accounts to prevent further unauthorised access.
You've finished Incident Response and Recovery Planning. Continue through the SC-100 study guide to build a complete picture of the exam.
Done with this chapter?