10. Security Operations, Incident Response and Resilience

Introduction and Context

Cybersecurity is not achieved merely by deploying preventive controls. Even well-designed architectures contain vulnerabilities, misconfigurations, compromised identities, insider risks, and dependencies that may fail in unexpected ways. Security operations therefore provide the continuous capability to observe an environment, identify suspicious activity, validate security events, contain harm, restore services, and learn from disruption. Incident response and cyber resilience extend this capability beyond detection: they connect technical investigation with organizational decision-making, crisis communication, business continuity, and institutional learning.

For doctoral-level study, security operations should be understood as a socio-technical system rather than simply a security operations centre (SOC) or a collection of monitoring tools. Its effectiveness depends on the relationship between governance, people, processes, data quality, technology, organizational culture, and adversary behavior. A technically sophisticated SIEM may produce little value if asset inventories are incomplete, logging is inconsistent, analysts lack authority, or management has not defined acceptable disruption. Conversely, a modest technical environment can achieve meaningful resilience when responsibilities, escalation paths, recovery priorities, and learning mechanisms are clear.

This chapter examines vulnerability and exposure management, telemetry, SIEM, detection engineering, SOC operations, threat hunting, incident response, digital forensics, crisis management, disaster recovery, and cyber resilience as connected capabilities. The central argument is that security operations should be designed around risk-informed decisions and measurable outcomes rather than around alert volume or tool ownership.

Learning Objectives

By the end of this chapter, readers should be able to:

1. Explain the relationship between vulnerability management, exposure management, monitoring, detection, response, and resilience.

2. Evaluate the architecture and limitations of telemetry, SIEM, SOAR, and related SOC technologies.

3. Design detection logic using threat-informed and risk-based principles.

4. Distinguish alert triage, threat hunting, incident response, digital forensics, crisis management, and disaster recovery.

5. Apply structured frameworks to investigate and contain cyber incidents.

6. Assess the organizational, ethical, legal, and governance implications of security operations.

7. Develop metrics and improvement strategies for resilient security operations.

From Vulnerability Lists to Exposure Management

Vulnerability management traditionally involves discovering assets, scanning for weaknesses, prioritizing findings, remediating or accepting risk, and verifying closure. A vulnerability is a weakness that could be exploited; exposure is a broader condition in which an asset, identity, service, or data resource is reachable, misconfigured, insufficiently protected, or otherwise positioned for harm. Exposure management therefore integrates vulnerabilities with exploitability, asset criticality, identity privilege, internet reachability, compensating controls, threat intelligence, and business impact.

A risk-based formulation can be expressed conceptually as:

Risk priority = likelihood of exploitation × potential impact × exposure context

This is not a precise mathematical truth. It is a decision model that prevents organizations from treating every high-severity scanner result as equally urgent. A medium-severity vulnerability on an internet-facing identity provider may deserve faster action than a critical vulnerability on an isolated, non-production system. Prioritization should consider active exploitation, exploit availability, asset importance, data sensitivity, lateral-movement potential, and remediation feasibility.

An effective exposure-management lifecycle includes asset discovery, classification, vulnerability assessment, attack-path analysis, prioritization, treatment, validation, and reporting. Treatment may involve patching, configuration changes, segmentation, access restriction, compensating monitoring, application redesign, or formal risk acceptance. Risk acceptance should be time-bound, documented, authorized by an accountable owner, and reviewed when circumstances change.

A recurring operational weakness is the separation of vulnerability teams from SOC and incident-response teams. Vulnerability intelligence can improve detection engineering, while incident investigations can reveal overlooked weaknesses. For example, an investigation showing that stolen credentials were used through a legacy remote-access gateway should result not only in credential resets but also in exposure reassessment, stronger authentication, improved logging, and architectural review.

Telemetry as the Foundation of Detection

Telemetry is the collection of observable data generated by systems, applications, users, networks, cloud services, and security controls. Common sources include endpoint events, authentication logs, DNS queries, proxy records, firewall flows, email security events, cloud audit trails, database activity, identity-provider logs, vulnerability data, and application traces.

Telemetry has several dimensions of quality. It must be sufficiently complete, accurate, timely, attributable, searchable, protected from unauthorized alteration, and retained for an appropriate period. A log that arrives three days late may be useful for forensic reconstruction but useless for real-time containment. A log that records a successful login without the user, source, device, authentication method, or target resource may be inadequate for investigation.

Organizations should design telemetry according to investigative questions rather than collecting everything indiscriminately. Relevant questions include: Which identity accessed the resource? From which device and location? Was the action normal for that identity? What process initiated the connection? What data was accessed or transferred? Which control allowed or blocked the action? Data minimization is also important because excessive collection increases cost, privacy exposure, and analytical noise.

A telemetry strategy normally specifies source ownership, event fields, collection method, normalization, time synchronization, retention, access control, integrity protection, and service-level expectations. Time synchronization is especially important: inconsistent clocks can make a sequence of events appear impossible or lead investigators to infer the wrong causal order.

SIEM, SOAR, and the SOC Operating Model

A security information and event management system aggregates, normalizes, correlates, retains, and analyzes security-relevant events. Its value lies not in centralization alone but in enabling a coherent interpretation of activity across otherwise separate systems. Correlation might connect a suspicious authentication, an endpoint process, a privilege change, and an unusual data transfer into one investigative narrative.

A SOC is the organizational capability responsible for monitoring, detection, analysis, coordination, and often response. Its operating model may be internal, outsourced, co-managed, or distributed across regional teams. Typical roles include monitoring analysts, incident responders, detection engineers, threat hunters, digital forensic specialists, threat intelligence analysts, platform engineers, and SOC leadership. Effective models define ownership boundaries with infrastructure, identity, application, legal, privacy, communications, human resources, and business continuity functions.

Security orchestration, automation, and response (SOAR) platforms coordinate repetitive actions such as enriching an indicator, querying an asset owner, opening a case, disabling a session, or isolating an endpoint. Automation should be graduated according to confidence and consequence. Low-risk enrichment can be automated broadly; disruptive actions such as disabling an executive account or isolating a production server should normally require stronger confidence, authorization, or human approval.

The SOC should be designed around cases and decisions, not merely alerts. A case contains the evidence, reasoning, actions, approvals, uncertainties, and outcome associated with a suspected event. Case management supports accountability and post-incident learning. It also prevents repeated investigation of the same activity by different analysts.

Detection Engineering and Threat-Informed Analysis

Detection engineering is the disciplined creation, testing, deployment, tuning, and retirement of analytic logic intended to identify malicious or risky behavior. A detection should specify its hypothesis, data sources, logic, expected false positives, severity, response guidance, owner, and validation method.

A mature detection program begins with threat-informed questions. Instead of asking only whether a known malware hash appears, analysts ask how an adversary might obtain access, escalate privilege, move laterally, persist, evade controls, or exfiltrate information. Adversary-behavior frameworks can help organize these questions, but they should not become checklists detached from local risk.

Detection quality involves several trade-offs. High sensitivity may increase false positives and analyst fatigue; high specificity may miss novel techniques. Detections should therefore be evaluated using measures such as precision, recall, alert-to-incident conversion, mean time to triage, coverage of important attack paths, and time since last validation. A detection that has never been tested against realistic activity is an assumption, not an assurance.

Detection-as-code practices improve repeatability. Logic can be version-controlled, peer-reviewed, automatically tested against sample events, deployed through controlled pipelines, and monitored for performance. Detection content should be retired when its data source is removed, its false-positive rate becomes unacceptable, or its risk rationale no longer applies.

SOC Operations, Triage, and Threat Hunting

Triage is the process of determining whether an alert represents benign activity, suspicious activity, a policy violation, or a confirmed incident. Analysts should establish what happened, when it happened, which assets and identities were involved, whether the activity is ongoing, and what potential impact exists. Severity should reflect business risk and urgency, not merely the severity label assigned by a vendor.

A useful triage discipline separates observation from interpretation. “A privileged login occurred from a new device at 02:14” is an observation. “The administrator account was compromised” is an interpretation requiring supporting evidence. This distinction reduces premature closure and improves the quality of investigative records.

Threat hunting is a proactive, hypothesis-driven search for malicious or anomalous activity that has not necessarily generated an alert. A hunt may begin with intelligence about a technique, an unusual pattern in organizational data, a suspected control gap, or a strategic concern. The hunt cycle includes forming a hypothesis, identifying data requirements, querying and investigating, validating findings, and converting useful results into improved detections or controls.

Hunting is not unrestricted curiosity. It requires scope, authorization, privacy safeguards, and a plan for handling sensitive findings. A hunt that examines employee communications or personal data without a defined purpose can create legal and ethical problems even if no malicious activity is found.

Incident Response as Coordinated Decision-Making

Incident response is the organized process of preparing for, detecting, analyzing, containing, eradicating, recovering from, and learning from security incidents. Preparation includes plans, authority, contact lists, evidence procedures, exercises, tooling, communications templates, and relationships with external parties. Without preparation, the first hours of an incident become an improvised negotiation over who may act.

A practical response model contains the following phases:

• Preparation: establish capabilities, roles, playbooks, legal guidance, and recovery priorities.
• Identification and analysis: validate the event, determine scope, construct a timeline, and estimate impact.
• Containment: limit spread and ongoing harm while preserving essential evidence and business functionality.
• Eradication: remove malicious mechanisms, correct exploited weaknesses, and eliminate persistence.
• Recovery: restore services in a controlled order, validate security, and monitor for recurrence.
• Post-incident improvement: document decisions, identify root and contributing causes, and assign corrective actions.

Containment is often divided into short-term and long-term measures. Short-term containment may isolate an endpoint or block an indicator. Long-term containment may involve network segmentation, credential architecture changes, or temporary replacement of a vulnerable service. A technically effective containment action can still be harmful if it disrupts safety-critical or revenue-critical operations; response must therefore be risk-informed and coordinated with business owners.

Incident classification should distinguish events from incidents. An event is an observable occurrence; an incident is an event or series of events that threatens confidentiality, integrity, availability, compliance, or organizational trust and requires coordinated action. Classification thresholds should be defined before a crisis, while allowing escalation when new evidence changes the assessment.

Digital Forensics and Evidentiary Reasoning

Digital forensics applies systematic methods to identify, preserve, collect, examine, analyze, and report digital evidence. Its purpose may be technical, disciplinary, regulatory, civil, or criminal. Investigators must preserve integrity and document provenance so that findings can be understood and challenged.

Forensic reasoning is stronger when it distinguishes facts, inferences, hypotheses, and unknowns. A process execution record may establish that a program ran, but not necessarily who intentionally launched it or what purpose they had. Investigators should record alternative explanations and seek evidence that could disconfirm their preferred theory.

Important practices include maintaining a chain of custody, using validated tools, preserving volatile evidence when appropriate, hashing acquired data, recording time zones, documenting collection methods, restricting access, and maintaining an investigation log. The order of volatility principle suggests that short-lived evidence, such as memory or active network connections, may need to be collected before persistent storage, although operational safety and legal authority always govern the decision.

Forensics must be integrated with response rather than treated as an academic exercise. Excessive preservation can delay containment, while immediate system destruction can eliminate evidence. The correct balance depends on the threat, business impact, legal requirements, and likelihood that evidence will be needed.

Crisis Management, Disaster Recovery, and Cyber Resilience

Crisis management addresses major incidents whose consequences exceed routine operational authority. It includes executive decision-making, stakeholder communication, regulatory coordination, public messaging, safety considerations, and prioritization under uncertainty. A crisis-management team should not attempt to perform every technical task; it should establish strategic direction while technical teams investigate and respond.

Disaster recovery focuses on restoring technology services and data after disruption. Business impact analysis identifies critical processes, dependencies, maximum tolerable downtime, recovery time objectives (RTOs), and recovery point objectives (RPOs). RTO expresses how quickly a service should be restored; RPO expresses the maximum acceptable loss of data measured in time. These objectives should reflect business requirements rather than the capabilities of existing backup systems.

Cyber resilience is broader than recovery. It is the capacity to anticipate, withstand, adapt to, recover from, and learn through adverse cyber conditions. Resilience may involve graceful degradation, redundant communication channels, offline backups, identity recovery procedures, manual workarounds, segmented architecture, alternate suppliers, and rehearsed decision-making. A resilient organization does not assume that prevention will always succeed; it limits blast radius and preserves essential functions when controls fail.

Backups are not automatically recoverable. They must be protected from unauthorized alteration, separated from production compromise, monitored for failure, and tested through realistic restoration exercises. Recovery validation should include identity services, dependencies, configuration integrity, malware persistence checks, and business-owner acceptance.

An Illustrative Case: Ransomware in a Distributed Health Network

Background

The following fictional case concerns Northbridge Health Network, a multi-site provider operating hospitals, clinics, laboratories, and a cloud-hosted patient-record platform. The organization had endpoint protection, centralized logging, vulnerability scanning, and daily backups. Its recovery plan had been approved but had not been exercised across all clinical dependencies.

Situation and Problem

At 03:20 on a weekday, the SOC detected unusual authentication activity involving a service account. Shortly afterward, several administrative servers began encrypting files. The initial alert was classified as medium severity because the service account had previously generated automated connections. Within thirty minutes, clinical scheduling and laboratory interfaces became unavailable.

The investigation found that an internet-facing remote-access appliance had an unpatched weakness. Attackers had obtained access, harvested credentials, moved laterally through a legacy administrative network, and used a legitimate management tool to deploy ransomware. Logging from the appliance was incomplete, and several servers had inconsistent time settings.

Analysis

The incident demonstrated that vulnerability severity alone had not captured exposure. The appliance was externally reachable, connected to privileged administrative systems, and insufficiently monitored. The service account’s activity appeared normal because it possessed broad permissions and had no behavioral baseline. Backups existed, but some were reachable through the same identity infrastructure affected by the attack.

The response team established an incident command structure. Clinical safety was made the first priority, followed by containment of lateral movement, preservation of evidence, restoration of essential services, and stakeholder communication. The team avoided indiscriminately shutting down clinical systems because doing so could create patient-safety risks.

Approach and Solution

Short-term containment included disabling affected remote access, revoking exposed credentials, isolating confirmed systems, blocking known command-and-control infrastructure, and separating backup administration from the compromised identity domain. Investigators captured volatile evidence from selected systems and created forensic images of representative compromised hosts.

The SOC created an emergency detection for unusual use of the management tool, privileged access from unapproved segments, and rapid file-encryption behavior. The infrastructure team restored identity services in a clean environment, validated backup integrity, and recovered essential clinical applications in an order determined by the business impact analysis. Communications staff issued coordinated updates to employees, patients, regulators, and partners without speculating beyond verified facts.

Outcome

Essential clinical services were restored in stages. The organization later redesigned remote access, introduced stronger authentication, reduced service-account privileges, improved network segmentation, standardized time synchronization, expanded cloud and appliance telemetry, and required recovery exercises involving clinical leaders. It also changed its vulnerability process so that internet reachability and attack-path relationships influenced prioritization.

Learning Points

The case illustrates that incident response is not merely malware removal. It requires technical evidence, business prioritization, authority, communication, recovery engineering, and post-incident change. It also shows why resilience must be assessed through realistic exercises rather than inferred from the existence of policies, tools, or backups.

Measurement, Governance, and Professional Judgment

Metrics should support decisions rather than reward superficial activity. Useful measures may include mean time to detect, mean time to contain, mean time to recover, percentage of critical assets with adequate telemetry, detection precision, unresolved high-risk exposures, successful restoration-test rate, and percentage of corrective actions completed by their due dates. Metrics should be interpreted carefully: a reduction in alert volume may indicate better tuning or weaker visibility.

Governance should define risk appetite, authority to isolate systems, evidence-handling requirements, escalation thresholds, notification duties, retention rules, and accountability for accepted risk. Security operations may process sensitive personal information, employee activity, health information, financial data, or privileged communications. Monitoring must therefore comply with applicable privacy, labor, sectoral, and data-protection requirements. Proportionality, purpose limitation, access control, transparency, and retention discipline are essential.

Organizations should also consider the ethics of automated response. A model or rule that incorrectly disables accounts, blocks medical devices, or labels an employee as malicious can cause significant harm. Human oversight, explainability, testing, appeal mechanisms, and post-action review are appropriate safeguards for high-consequence decisions.

Challenges and Common Failure Modes

Several recurring problems weaken security operations. Tool accumulation without operating discipline creates fragmented data and unclear ownership. Alert fatigue arises when detections are not tuned to organizational context. Incomplete asset inventories make both vulnerability prioritization and incident scoping unreliable. Excessive dependence on vendor severity scores obscures business impact. Lack of executive sponsorship delays containment decisions. Unrehearsed plans fail when contact details, authority, or dependencies are tested under pressure.

Other failures include treating threat intelligence as a list of indicators rather than as contextual knowledge, collecting logs without protecting their integrity, assuming that cloud providers monitor customer-specific activity, preserving evidence without documenting provenance, and declaring recovery complete before validating security and business functionality. Post-incident reviews also fail when they seek blame instead of identifying systemic contributing factors.

Emerging Directions

Security operations are increasingly influenced by cloud-native architectures, identity-centric attacks, software supply-chain risk, operational technology, extended detection and response, and artificial intelligence. AI can assist with event summarization, query generation, anomaly analysis, malware classification, and case prioritization. However, generated explanations may be incomplete or incorrect, and attackers can manipulate data or exploit automation. AI should therefore augment analyst judgment, not replace governance, evidence validation, or accountability.

Continuous exposure validation, attack-path analysis, privacy-preserving analytics, detection-as-code, and recovery testing through realistic adversary emulation are likely to become more important. The strategic trend is toward integrating prevention, detection, response, and recovery into a measurable resilience system rather than managing each as an isolated security program.

Best-Practice Principles

A mature program generally follows these principles:

• maintain an authoritative inventory of assets, identities, dependencies, and owners;
• prioritize exposures using business criticality and attack-path context;
• collect purposeful, high-quality telemetry and protect its integrity;
• design, test, measure, and retire detections systematically;
• treat cases as accountable investigative records;
• rehearse incident response and recovery with technical and business participants;
• automate low-risk, repeatable work while preserving human control over high-impact actions;
• separate backup and recovery administration from ordinary production identity paths;
• integrate legal, privacy, communications, safety, and executive stakeholders;
• convert incidents and exercises into assigned, verified improvements.

Chapter Summary

Security operations provide the continuous capacity to observe, interpret, and act on cyber risk. Vulnerability management becomes more effective when expanded into exposure management, where exploitability, reachability, asset criticality, identity privilege, and business impact are considered together. Telemetry quality determines what an organization can detect and prove. SIEM platforms, SOAR tools, and SOC teams create value only when supported by clear ownership, sound data, tested detections, and disciplined case management.

Detection engineering should be threat-informed, measurable, and continuously validated. Threat hunting complements alert-driven monitoring by testing hypotheses about hidden adversary activity. Incident response coordinates identification, containment, eradication, recovery, and learning, while digital forensics preserves evidence and supports defensible conclusions. Crisis management connects technical response to organizational authority and communication. Disaster recovery restores services; cyber resilience additionally enables adaptation, graceful degradation, and learning. Effective programs combine technology with governance, professional judgment, ethical safeguards, realistic exercises, and continual improvement.

Key Terms

Exposure Management: A risk-based practice for identifying and reducing weaknesses, reachability, misconfiguration, and attack paths across assets and identities.

Telemetry: Observable data generated by systems, users, applications, networks, and security controls.

SIEM: A platform that collects, normalizes, correlates, analyzes, and retains security events.

SOAR: Technology that orchestrates workflows and automates selected security-response actions.

SOC: An organizational capability responsible for security monitoring, analysis, detection, and response coordination.

Detection Engineering: The disciplined design, testing, deployment, tuning, and retirement of detection logic.

Threat Hunting: Proactive, hypothesis-driven investigation for malicious or anomalous activity.

Security Event: An observable occurrence relevant to system, information, or organizational security.

Security Incident: An event or series of events requiring coordinated action because it threatens security or organizational operations.

Triage: The process of validating, prioritizing, and assigning an alert or suspected incident.

Digital Forensics: Systematic examination and analysis of digital evidence.

Chain of Custody: Documentation showing how evidence was collected, controlled, transferred, and preserved.

Containment: Actions intended to limit ongoing damage or adversary movement.

Recovery Time Objective: The targeted maximum time within which a service should be restored.

Recovery Point Objective: The maximum acceptable period of data loss measured in time.

Cyber Resilience: The capacity to anticipate, withstand, adapt to, recover from, and learn through cyber disruption.

Attack Path: A sequence of relationships or conditions that may allow an adversary to reach a valuable target.

Alert Fatigue: Reduced analyst effectiveness caused by excessive, repetitive, or low-value alerts.

Review Questions

Short Answer Questions

1. How does exposure management differ from traditional vulnerability management?

2. Identify four qualities of useful security telemetry.

3. What is the purpose of detection engineering?

4. Distinguish a security event from a security incident.

5. Define RTO and RPO.

Long Answer Questions

1. Explain how telemetry, SIEM, detection engineering, and SOC processes interact in a mature monitoring capability.

2. Describe the phases of incident response and discuss the decisions involved in containment.

3. Explain how digital forensics supports incident response while potentially creating operational trade-offs.

4. Compare disaster recovery with cyber resilience.

5. Discuss the governance and ethical issues associated with automated security response.

Analytical / Application Questions

1. An organization has many critical vulnerabilities but limited remediation capacity. Develop a prioritization method using exposure, asset criticality, exploitability, and compensating controls.

2. A SOC receives thousands of alerts but rarely identifies confirmed incidents. Analyze possible causes and propose a measurement-led improvement plan.

3. During a ransomware incident, business leaders want immediate shutdown of all systems while investigators want to preserve evidence. Explain how an incident commander should evaluate and coordinate these competing objectives.

22. Multiple Choice Questions with Answers

Question 1

Which factor most clearly distinguishes exposure management from a vulnerability list based only on scanner severity?

A. The number of security tools deployed

B. The relationship between exploitability, reachability, asset criticality, and business impact

C. The age of the vulnerability database

D. The number of alerts generated by the SOC

Correct Answer: B. The relationship between exploitability, reachability, asset criticality, and business impact

Question 2

Why is time synchronization important during incident investigation?

A. It reduces the storage size of logs

B. It guarantees that every alert is malicious

C. It supports accurate reconstruction of event sequence and causality

D. It eliminates the need for forensic imaging

Correct Answer: C. It supports accurate reconstruction of event sequence and causality

Question 3

Which activity is most characteristic of threat hunting?

A. Automatically closing all low-severity alerts

B. Searching proactively for activity based on a defined hypothesis

C. Patching every system immediately after a scan

D. Restoring backups after a confirmed outage

Correct Answer: B. Searching proactively for activity based on a defined hypothesis

Question 4

What is the principal purpose of detection engineering?

A. To increase the number of alerts regardless of quality

B. To design, validate, tune, and manage analytic logic that identifies risky or malicious behavior

C. To replace all human incident responders

D. To preserve forensic images permanently

Correct Answer: B. To design, validate, tune, and manage analytic logic that identifies risky or malicious behavior

Question 5

Which response action generally requires the greatest caution because of its potential operational consequences?

A. Adding contextual enrichment to an alert

B. Opening a case record

C. Disabling a privileged account or isolating a critical production server

D. Recording the event timestamp

Correct Answer: C. Disabling a privileged account or isolating a critical production server

Question 6

What does an RPO primarily describe?

A. The maximum acceptable time to restore a service

B. The maximum acceptable amount of data loss measured in time

C. The number of analysts required for recovery

D. The time required to complete a forensic investigation

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 7

In the illustrative ransomware case, why was the remote-access appliance a high-priority exposure?

A. It was isolated from all administrative systems

B. It was internet-facing, connected to privileged systems, and insufficiently monitored

C. It had no relationship to identity systems

D. It was used only for offline backups

Correct Answer: B. It was internet-facing, connected to privileged systems, and insufficiently monitored

Question 8

Which statement best reflects sound forensic reasoning?

A. An observed process automatically proves the user’s intent

B. Investigators should distinguish facts, inferences, hypotheses, and unknowns

C. Evidence integrity is unimportant if the incident is technically obvious

D. All systems should be destroyed immediately after imaging

Correct Answer: B. Investigators should distinguish facts, inferences, hypotheses, and unknowns

Question 9

Why should SOAR automation be graduated according to confidence and consequence?

A. All security actions have identical operational effects

B. Low-risk enrichment and high-impact disruption require different levels of authorization

C. Automation cannot perform enrichment tasks

D. Human review is never appropriate in security operations

Correct Answer: B. Low-risk enrichment and high-impact disruption require different levels of authorization

Question 10

Which characteristic most strongly indicates cyber resilience rather than simple disaster recovery?

A. Having a written backup policy

B. Restoring one server after a planned test

C. Maintaining essential functions through disruption, adapting, recovering, and learning

D. Purchasing a second SIEM platform

Correct Answer: C. Maintaining essential functions through disruption, adapting, recovering, and learning