# Incident Response, Patching, and Change Management

> Chapter 12 of the Courseiva CLOUD-PLUS curriculum — https://courseiva.com/learn/cloud-plus/incident-response-and-change-management

**Official objective:** 4.2 — Given a scenario, implement change management and incident response

## Introduction

What happens when a cloud server suddenly stops working or gets hacked? You need a repeatable plan to fix it without making things worse. This chapter explains the three core processes used by every IT team: Incident Response (putting out the fire), Patching (fixing the broken part), and Change Management (getting permission and a plan before you touch anything).

## The Kitchen Renovation Analogy

A burnt smell from the wall socket causes the lights to flicker and the oven to spark. Leading to a full kitchen emergency. In IT, when a system behaves unexpectedly, it is an incident. A quick power-down stops the immediate danger, but it doesn't fix the faulty wiring. The sparking socket is the vulnerability. A temporary fix is to tape the socket so no one uses it. The permanent fix is to replace the socket and the wired circuit. That process of replacing the socket is patching. Before you replace the socket, you must file a request with the building management to turn off the power to the entire floor for safety. You cannot just swap the socket while the power is live. That formal request and permission process is change management. When the electrician arrives, they submit their plan: they have a new socket, they have tested it, and they need 30 minutes with the power off. The building manager checks the plan, approves it, and then the power can be shut off, the socket replaced, and the power restored. After the work is done, the building manager inspects the work and logs that the change was successful. This entire sequence – from the initial spark to the final sign-off – mirrors exactly how an IT team handles a security incident, patches a software bug, and uses a change management process to do so safely.

## Core explanation

In the world of CompTIA Cloud+, you are responsible for the health of a cloud environment. That environment is a collection of virtual servers, storage, and networks that run your company's applications. When something goes wrong, you cannot just panic. You follow a process. The three processes covered in this chapter are the backbone of keeping a cloud environment stable and secure. They are Incident Response, Patching, and Change Management.

**Incident Response** is the process you follow when something bad is happening or has just happened. An incident is any event that disrupts normal service or poses a security risk. For example, a hacker breaks into a server. Or a critical application crashes. Or a user reports that their files have been encrypted by ransomware. The goal of incident response is to contain the damage, remove the threat, and return to normal operations as quickly as possible. The industry-standard model is the SANS six-step process. The SANS Institute provides a framework that most IT teams adopt. The six steps are: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.

In the Preparation phase, you set up the tools, logs, and procedures before anything happens. You make sure you have backups, monitoring software, and a communication plan. In the Identification phase, you confirm that an incident is actually happening. Someone might notice unusual network traffic, or an automated alert fires. You investigate to understand the scope. In the Containment phase, you stop the incident from spreading. This could mean isolating a server from the network or revoking a user's access. In the Eradication phase, you remove the root cause. You delete the malware, patch the vulnerability, or rebuild the compromised server from a clean image. In the Recovery phase, you bring the system back into production carefully. You monitor it to ensure the problem does not return. Finally, in Lessons Learned, you document what happened, what worked, and what did not work. You then update your procedures so the same incident is less likely to happen again.

**Patching** is the process of applying updates to software, operating systems, and firmware to fix security vulnerabilities and bugs. A patch is a piece of code that replaces or modifies existing code. Think of it like a new part for a car that fixes a known safety issue. In a cloud environment, you need to patch not just the operating system of your virtual machines, but also the applications running on them and sometimes the underlying cloud platform itself. The key challenge is that patching can sometimes break things. A patch might conflict with an existing application, causing it to crash. Therefore, you never just patch everything blindly. You follow a structured approach. This approach includes testing the patch in a non-production environment first. Then you schedule a maintenance window when the patch will be applied. You also have a rollback plan, which is a way to undo the patch if something goes wrong. A rollback might involve restoring from a backup or reverting to a previous software version.

**Change Management** is the formal process of controlling changes to the IT environment. Every change – from updating a configuration file to deploying a new server to applying a patch – must go through this process. The purpose is to prevent accidental misconfigurations, unplanned downtime, and security incidents caused by careless updates. A change request typically includes a description of the change, the reason for it, the expected impact, a risk assessment, and a rollback plan. A change advisory board (CAB) is a group of people who review and approve or reject change requests. In a small company, the CAB might just be the IT manager. In a large enterprise, it includes representatives from different departments such as security, networking, and application support. Changes are categorised as standard, normal, or emergency. A standard change is low-risk and pre-approved, like a routine password reset. A normal change requires CAB approval and is scheduled. An emergency change is for critical issues like a security vulnerability that is being actively exploited and requires immediate action. Emergency changes can bypass the full approval process but are reviewed afterward.

These three processes work together. Incident response often reveals a vulnerability that needs a patch. Deploying that patch requires a change management request. A well-run change management process reduces the number of incidents. Patching regularly reduces the severity of incidents when they occur. Understanding how these concepts interlink is essential for the CV0-004 exam.

## Real-world context

Imagine you are a cloud administrator for a mid-sized e-commerce company. One Tuesday morning, your monitoring system alerts you that the company's main web server is returning errors and customers cannot complete purchases. This is an incident. You log into the system and see that the server's CPU usage is at 99%. You quickly investigate and find a rogue process that is consuming all resources. You suspect malware. Your first step is to isolate the server. You disconnect it from the load balancer so traffic no longer reaches it. This is containment. You then take a forensic snapshot of the server's memory and disk for later analysis. You then rebuild the server from a clean operating system image. This is eradication. You restore the application data from a backup taken four hours earlier. This is recovery. You monitor the new server for an hour, and it runs normally. You then move to lessons learned. You discover that the malware entered through an unpatched vulnerability in a plugin used by your website.

Now you have a vulnerability that needs a patch. You check the vendor's website and find that a patch was released two weeks ago. You download the patch. But you cannot simply install it on your production server. You must follow change management. You create a change request in your IT service management tool, like ServiceNow or Jira Service Management. Your request states: 'Apply security patch X to the web server plugin to fix critical vulnerability CVE-2024-12345. Risk: Low, as this patch is for the same plugin used by thousands of other customers. Rollback plan: Restore server from pre-patch backup. Scheduled maintenance window: Saturday 2:00 AM for 30 minutes.' This request is sent to the change advisory board.

The CAB meets on Wednesday. The security representative approves it because the vulnerability is critical. The network representative asks if the patch will require a reboot. You confirm it does not, so the network representative approves it. The change is approved for Saturday. On Saturday at 2:00 AM, you apply the patch to a test server first. The test passes. You then apply it to the production server. The server remains online. You verify the plugin version and confirm the vulnerability is patched. You close the change request, marking it as successful. The next week, you update your incident response runbook to include a step to check for vendor patches immediately after identifying a vulnerability. This entire cycle – incident, patch, change – is what a cloud professional does daily. The CV0-004 exam expects you to know the order of these steps and the terminology used at each point.

## Exam focus

The CV0-004 exam tests your ability to apply these concepts in scenario-based questions. You will be given a description of a situation and asked to identify the correct next step or the correct process. They love to test the sequence of incident response steps. A trap they set is asking you to 'eradicate' a threat before you have 'contained' it. In the exam, always choose containment first. You must stop the bleeding before you clean the wound.

They also frequently test the difference between a 'standard' change and an 'emergency' change. A standard change is pre-approved and low risk, like restarting a service. An emergency change is for an active security threat and can be approved by a single person. They will give you a scenario where a critical vulnerability is being exploited, and the correct answer is to initiate an emergency change. Do not wait for the full CAB meeting.

Another popular topic is 'rollback plan'. Every change request must have a rollback plan. The exam will present a change proposal without one, and you must identify that as a problem. They also test 'change advisory board (CAB)' membership. You should know that a CAB includes people from different departments, not just the IT team.

Key definitions to memorise for the exam include:
- **Incident**: Any event that disrupts normal service.
- **Vulnerability**: A weakness that can be exploited.
- **Threat**: Something that can exploit a vulnerability.
- **Patch**: Code that fixes a vulnerability.
- **Change**: Any addition, modification, or removal of an IT asset.
- **Rollback**: The procedure to undo a change.
- **Standard Change**: Low risk, pre-approved.
- **Emergency Change**: High urgency, bypasses normal approval.

Trap patterns include:
- Choosing 'recovery' before 'eradication'. Recovery comes after you remove the threat.
- Applying a patch without testing it first. The exam always expects you to test in a non-production environment.
- Thinking incident response ends after recovery. It ends after lessons learned.
- Confusing 'change management' with 'version control'. Version control is about tracking code; change management is about the process of deploying that code.

The exam also tests that you understand the relationship between these processes. For example, a question might say: 'After an incident, a vulnerability was found. What should the administrator do next?' The correct answer is: 'Submit a change request to patch the vulnerability.' They are testing that you know the sequence: incident leads to patching, and patching requires change management.

## Step by step

1. **Preparation** — You set up tools, logging, and communication plans before an incident happens. This includes installing monitoring agents, configuring backup systems, and writing incident response runbooks. Without preparation, you will struggle to identify and contain incidents quickly.
2. **Identification** — You detect a potential incident via alerts, user reports, or log analysis. You investigate to confirm that it is genuinely an incident and not a false alarm. You note initial indicators like unusual network traffic or an unauthorised login attempt.
3. **Containment** — You stop the incident from spreading. This can involve disconnecting a server from the network, disabling a compromised user account, or blocking an IP address. Isolation is the priority, even if you do not yet fully understand the root cause.
4. **Eradication** — You remove the root cause of the incident. This may mean deleting malware, patching a vulnerability, or rebuilding a compromised server from a clean image. You ensure no traces of the threat remain in the environment.
5. **Recovery** — You carefully restore the system to normal operation. You bring the server back online, restore data from backups, and monitor closely for any signs of recurrence. You do not rush this step – you verify stability before declaring full recovery.
6. **Lessons Learned** — You document what happened, what worked, and what could be improved. You update incident response procedures, patch policies, and change management templates based on this experience. This step prevents the same incident from happening again.

## Comparisons

### Incident Response vs Change Management

**Incident Response:**
- Reactive: triggered by an event that is happening or has just occurred.
- Focuses on stopping damage and restoring service quickly.
- Ends with 'lessons learned' to improve future response.

**Change Management:**
- Proactive (usually): planned before making a change.
- Focuses on risk assessment and approval before any action.
- Ends with verification that the change was successful and documented.

### Standard Change vs Emergency Change

**Standard Change:**
- Low risk, pre-approved by the CAB.
- Does not require individual approval each time.
- Examples: password reset, adding a new user to a group.

**Emergency Change:**
- High urgency, often due to a security threat or critical outage.
- Requires expedited approval, often from a single designated person.
- Example: applying a critical patch to stop an active exploit.

### Patch Management vs Version Control

**Patch Management:**
- Process of deploying updates to fix bugs or improve security.
- Involves testing, scheduling, and rollback plans.
- Applies to deployed software and systems.

**Version Control:**
- Process of tracking and managing changes to source code.
- Involves branching, merging, and tagging code revisions.
- Applies to code repositories before deployment.

## Diagram

_This flowchart shows the relationship between incident response steps and the change management process triggered by a vulnerability discovered during an incident._

```mermaid
flowchart TD
    A[Incident Occurs] --> B[Contain]
    B --> C[Eradicate]
    C --> D[Recover]
    D --> E[Lessons Learned]
    E --> F[Identify Vulnerability]
    F --> G[Create Change Request]
    G --> H{CAB Approves?}
    H -->|Yes| I[Test Patch in Staging]
    H -->|No| J[Revise Request]
    I --> K[Apply Patch in Production]
    K --> L[Document Success]
```

## Common misconceptions

- **Misconception:** Patching is something you do only when there is a problem. **Reality:** Patching is a proactive maintenance activity, not just a reactive fix. Vendors release patches for bugs that have not caused incidents yet. (Beginners often think of patching like fixing a hole in a tyre after a puncture. They do not realise that most patches are preventive, like replacing tyres before they wear out.)
- **Misconception:** Incident response is the same as disaster recovery. **Reality:** Incident response handles immediate threats (like a hack or a crash). Disaster recovery is for major outages (like losing an entire data centre) and focuses on restoring services from backups at an alternate site. (Both terms involve 'bad things happening', so beginners lump them together. The exam tests them as separate processes with different timelines and scopes.)
- **Misconception:** Change management is just paperwork that slows down progress. **Reality:** Change management reduces risk and unplanned downtime. Failing to use it often leads to more time lost fixing problems than it saves by skipping the process. (In a fast-paced environment, people want to act quickly. They see the approval process as bureaucracy rather than a safety mechanism. The exam highlights its value in preventing outages.)
- **Misconception:** After an incident is resolved, the process is over. **Reality:** A proper incident response includes a 'lessons learned' phase. You must document what happened and update your procedures to prevent recurrence. (Many beginners stop the process once the service is back up. They miss the crucial step of improving the system, which is a key exam point.)

## Key takeaways

- Incident response follows a strict six-step order: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.
- Containment always comes before eradication in incident response.
- A change advisory board (CAB) approves or rejects normal and emergency changes.
- Every change request must include a rollback plan.
- Emergency changes bypass the normal approval process but are reviewed after implementation.
- Patching is a proactive security measure that requires testing in a non-production environment first.

## FAQ

**What is the difference between an incident and a problem?**

An incident is a single unexpected event that disrupts service (like a server crash). A problem is the underlying root cause that may lead to multiple incidents. Incident response handles the crash; problem management investigates why the server keeps crashing.

**Do I need permission to apply a security patch?**

In a professional environment, yes. All patches require a change request unless it is a standard, pre-approved change. This ensures the patch is tested and a rollback plan exists before it is applied to production systems.

**What is a rollback plan?**

A rollback plan is a documented procedure to undo a change if it causes problems. For example, if patching a server breaks an application, the rollback plan might tell you to restore the server from a backup taken before the patch was applied.

**Can I skip the change management process for an emergency?**

No, you still use change management, but you use the emergency change process. This allows you to get expedited approval (often from one designated person) without waiting for a full CAB meeting. You must still document the change afterward.

**What does CAB stand for?**

CAB stands for Change Advisory Board. It is a group of people from different areas of the business (IT, security, operations) who review and approve or deny change requests to ensure they are safe and planned properly.

**Is patching only for operating systems?**

No, patching applies to operating systems, applications, firmware, databases, and even cloud infrastructure templates. Any piece of software that has a known vulnerability should be patched, especially in a cloud environment.

## Check your understanding

1. **What is the first step you should take during incident response after you confirm an incident is occurring?**

   Answer: Containment. You must isolate the affected system to prevent the incident from spreading before you attempt to eradicate the threat.

2. **When deploying a new security patch, what must be included in the change request besides the description of the patch?**

   Answer: A rollback plan. The change request must specify how to undo the patch if it causes a problem, such as restoring from a pre-patch backup.

3. **What type of change bypasses the full CAB meeting but still requires documentation?**

   Answer: An emergency change. It is used for urgent situations like an active security breach and can be approved by one authorised person.

4. **Why is it important to test a patch in a non-production environment before applying it to production systems?**

   Answer: To check that the patch does not conflict with applications or cause new problems. Testing in a staging environment prevents potential downtime in production.

5. **What is the final step in the incident response process?**

   Answer: Lessons learned. After recovery, you review what happened, document the incident, and update procedures to prevent future occurrences.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/cloud-plus/incident-response-and-change-management