13. Incident Response, Forensics and Cyber Resilience

Introduction and Context

Cloud platforms, connected devices and enterprise information systems have changed the scale and character of cyber incidents. A compromised cloud identity may provide access to applications in several regions; a vulnerable Internet of Things (IoT) device may become an entry point into an operational network; and a ransomware attack may disrupt not only information systems but also manufacturing, logistics, healthcare or public services. Consequently, incident response is no longer limited to restoring an infected workstation. It is an organisational capability that combines technical investigation, executive decision-making, legal judgement, communications, business continuity and learning.

Incident response is the organised process by which an institution prepares for, detects, analyses, contains, eradicates and recovers from security incidents. Digital forensics supplies reliable methods for identifying, acquiring, preserving and interpreting evidence. Cyber resilience extends the perspective further: it concerns the ability to anticipate disruption, withstand or limit its effects, continue critical operations, recover services and adapt after the event.

These capabilities are closely related but not identical. Incident response is event-focused and operational. Forensics is evidence-focused and investigative. Resilience is mission-focused and concerned with sustained organisational performance. A mature security programme integrates all three. This chapter examines that integration across cloud, IoT and enterprise environments.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish incident response, digital forensics, business continuity and cyber resilience.

2. Design an incident-response capability for cloud, IoT and enterprise environments.

3. Apply preparation, detection, analysis, containment, eradication, recovery and post-incident learning activities.

4. Acquire and preserve digital evidence while maintaining integrity, legality and chain of custody.

5. Explain the special challenges of cloud and IoT forensics.

6. Evaluate ransomware response, crisis communication and recovery decisions.

7. Relate incident response to continuity planning, disaster recovery and organisational governance.

8. Assess the use of automation, analytics and artificial intelligence in response operations.

The Incident as an Organisational Event

An event is any observable occurrence in a system. An alert is an event interpreted as potentially relevant to security. An incident is an event, or group of events, that actually or potentially compromises confidentiality, integrity or availability, violates policy, or threatens business operations. This distinction matters because responding to every alert as a major incident would exhaust personnel, while ignoring weak signals may permit an attacker to develop persistence.

Incident classification normally considers affected assets, business criticality, data sensitivity, scope, attacker capability and operational consequences. A stolen employee password, an exposed storage bucket containing regulated information, a botnet-controlled camera and an encryption attack on a hospital network are all security events, but their urgency, authorities and response strategies differ.

A useful incident record contains a unique identifier, time references, detection source, affected assets, suspected impact, actions taken, responsible personnel, decisions and supporting evidence. Accurate records support coordination during the crisis and accountability afterwards.

Important terminology

• Indicator of compromise (IoC): An observable artefact associated with malicious activity, such as a hash, domain, IP address or registry change.
• Tactics, techniques and procedures (TTPs): The objectives, methods and operational habits used by an adversary.
• Time to detect (TTD): The elapsed time between malicious activity and its detection.
• Time to contain (TTC): The time required to restrict an incident sufficiently to prevent continued spread or material escalation.
• Time to recover (TTR): The time required to restore an agreed level of service.
• Recovery point objective (RPO): The maximum acceptable amount of data loss measured in time.
• Recovery time objective (RTO): The target time for restoring a service or process.
• Business impact analysis (BIA): A systematic assessment of the consequences of disruption and the resources needed for recovery.

A Lifecycle for Response and Recovery

A lifecycle provides structure, but real incidents are not perfectly linear. New evidence may require a return from recovery to analysis, and containment may need to be revised when an attacker changes tactics. A commonly used lifecycle includes preparation, detection and analysis, containment, eradication, recovery, and post-incident activity.

Preparation

Preparation is the foundation of effective response. It includes governance, trained personnel, tested procedures, technical controls, communication arrangements and evidence-readiness. An organisation should define an incident response policy, severity levels, authority to isolate systems, escalation thresholds and relationships with legal counsel, regulators, law enforcement, insurers, managed security providers and specialist investigators.

An incident response team may include security operations personnel, digital forensic specialists, infrastructure and cloud engineers, application owners, business continuity managers, legal advisers, communications staff, human resources representatives and senior decision-makers. A clear responsibility matrix prevents the common failure in which several teams assume that another team is directing the response.

Preparation also requires technical capability. Centralised logging, synchronised clocks, endpoint telemetry, identity monitoring, cloud audit trails, network visibility, secure administrative channels and tested backups are essential. Logs should be retained according to business, legal and regulatory requirements and protected from unauthorised alteration. Backups should be isolated from ordinary administrative credentials and tested through restoration exercises rather than merely marked as successful by a backup application.

Tabletop exercises and simulations reveal weaknesses that documents conceal. Exercises should include difficult decisions: whether to disconnect a production environment, when to notify customers, how to operate if email is compromised, and how to authenticate emergency instructions.

Detection and analysis

Detection begins with a signal, but analysis determines whether the signal represents an incident and what its scope may be. Analysts correlate identity, endpoint, network, application, cloud and physical-device data. They establish a timeline, identify affected accounts and systems, assess whether the adversary remains active, and estimate business impact.

Cloud investigations require attention to control-plane activity as well as data-plane activity. A suspicious login, creation of an access key, modification of a security group, change to a storage policy or deployment of an unfamiliar workload may be more significant than an individual host alert. Investigators should determine which logs are generated by the cloud provider, which are configured by the customer and which may no longer be available because retention was not enabled in advance.

IoT analysis is complicated by device diversity, limited storage, proprietary firmware, intermittent connectivity and physical accessibility. A device may contain useful evidence in volatile memory, flash storage, local logs, gateway records or the management platform. Its physical state should be documented before power is removed, because shutdown may destroy volatile information or alter device behaviour.

Analysis should produce hypotheses rather than premature conclusions. For example, an unusual outbound connection might indicate malware, a legitimate software update, a misconfigured service or a compromised vendor account. Analysts should record confidence levels, assumptions and evidence supporting each conclusion.

Containment

Containment limits damage while preserving the ability to investigate. Short-term containment may involve disabling a credential, isolating an endpoint, blocking a domain, restricting a cloud role or segmenting an IoT network. Long-term containment may include rebuilding affected systems, applying compensating controls or moving a service to a clean environment.

Containment involves trade-offs. Immediate disconnection can stop an attack but destroy volatile evidence or interrupt safety-critical operations. Leaving a system online may preserve evidence but allow exfiltration or lateral movement. Decisions should therefore consider threat activity, safety, business criticality, evidence value and the availability of alternative services.

Identity containment is increasingly important in cloud environments. Rotating exposed secrets, revoking sessions, disabling access keys and reviewing privileged-role assignments may be more effective than isolating a single virtual machine. However, credential changes must be coordinated so that responders do not lock themselves out or interrupt recovery processes.

Eradication

Eradication removes the cause and persistence mechanisms of the incident. Activities may include deleting malicious accounts, removing scheduled tasks, replacing compromised images, patching exploited vulnerabilities, resetting credentials, correcting cloud policies and updating firmware. Eradication should be based on an understanding of the attack path. Rebuilding one server without closing the initial access route may simply invite reinfection.

In cloud environments, eradication may require examining infrastructure-as-code repositories, deployment pipelines, machine images, serverless functions, identity federation and third-party integrations. In IoT environments, it may involve firmware replacement, certificate revocation, factory reset, network redesign or replacement of devices that cannot be securely updated.

Recovery

Recovery restores services in a controlled manner. Systems should be rebuilt from trusted sources, validated, monitored and returned to production according to business priorities. Restoration should not be confused with availability alone. A system that is online but still compromised is not recovered.

Recovery decisions are guided by RTO and RPO, but these objectives should be realistic and service-specific. A critical transaction system may require a low RPO, whereas a non-critical archive may tolerate a larger data gap. Dependencies must be considered: restoring an application before its identity service, database or network controls may produce a technically available but unusable service.

Enhanced monitoring is required after restoration. The organisation should watch for renewed authentication anomalies, persistence mechanisms, unusual data access and reinfection. Business owners should confirm that restored processes and data are accurate, not merely that servers respond to technical tests.

Post-incident learning

The final stage is not an administrative afterthought. A post-incident review reconstructs what happened, why controls failed, which decisions were effective, and how the organisation should improve. It should distinguish direct technical causes from systemic causes such as excessive privilege, unclear ownership, inadequate logging, unrealistic recovery assumptions or ineffective supplier oversight.

A useful review produces assigned actions with owners, deadlines and measures of completion. It should also update playbooks, detection rules, architecture, training, procurement requirements and continuity plans. Blaming individuals for following an ambiguous process discourages reporting and prevents organisational learning.

Digital Forensics and Evidence Management

Digital forensics applies repeatable methods to identify, preserve, collect, examine and interpret digital evidence. The purpose may be internal investigation, regulatory response, civil litigation, criminal proceedings, insurance assessment or improvement of controls. Evidence must be relevant, reliable, authentic and sufficiently documented.

Evidence sources

Evidence may include volatile memory, disk or flash storage, operating-system artefacts, application logs, authentication records, network flows, packet captures, email, cloud audit logs, object access records, container metadata, source-code repositories, mobile devices, IoT gateways and physical access records. No single source is complete. A network record may show communication but not the command executed; an endpoint artefact may show execution but not the data transferred.

Volatile evidence, such as memory contents, active processes, network connections and temporary tokens, may disappear when a device is powered down. Non-volatile evidence remains after shutdown but may be altered by normal system activity. Collection order should therefore be planned according to the environment and investigative objectives.

Acquisition and preservation

A forensic acquisition should be as complete and reproducible as practical. Investigators record who collected the evidence, when and where it was collected, the tools and versions used, the source system, acquisition method, storage location and cryptographic hash. Hashes help demonstrate that a file or image has not changed, although a matching hash alone does not prove that the evidence is truthful or complete.

The original should be protected, and examination should generally occur on a verified copy. Chain of custody records every transfer and handling event. Access should be restricted, and evidence storage should use appropriate encryption, integrity controls and retention procedures. Investigators must avoid unnecessary collection of personal information and should define the scope of the investigation before acquiring broad datasets.

Cloud forensics

Cloud evidence differs from traditional forensic evidence because the investigator may not control the underlying hardware, hypervisor, storage system or provider logs. Evidence may be distributed across regions and accounts, and resources can be ephemeral. A virtual machine may be terminated, a container replaced, or a serverless execution completed before collection begins.

Cloud forensic readiness should be designed before an incident. It includes enabling relevant control-plane and data-access logs, selecting suitable retention periods, forwarding records to an independent account or security platform, documenting provider responsibilities, preserving snapshots and establishing procedures for legal requests. Investigators should understand the shared-responsibility model: the provider secures aspects of the underlying service, while the customer remains responsible for configuration, identities, data and workloads according to the service model.

Cloud evidence may include identity-provider records, API calls, role assumptions, storage access, security-group changes, workload snapshots, container registries, orchestration logs, DNS records and billing anomalies. Provider support may be required to obtain information unavailable through customer interfaces.

IoT and operational technology evidence

IoT investigations require coordination between cyber specialists, device engineers and sometimes safety personnel. Collection must not create physical danger or interrupt essential control processes. Evidence can exist in sensors, gateways, mobile applications, management consoles and supplier systems. Firmware versions, device certificates, configuration changes and physical tampering indicators may be as important as traditional file artefacts.

Where devices cannot support robust logging, investigators must correlate indirect evidence: network flows, wireless-controller logs, gateway timestamps, maintenance records and cloud-management events. Time synchronisation should be assessed because inaccurate clocks can produce misleading timelines.

Ransomware, Crisis Communication and Decision-Making

Ransomware combines unauthorised access, data encryption, extortion and, increasingly, threats to publish stolen information or disrupt operations. The response must address both technical recovery and organisational coercion. Leaders should avoid assuming that payment guarantees decryption, deletion of stolen data or future immunity. Payment decisions require legal, financial, ethical and operational analysis, including sanctions and reporting obligations where applicable.

Early priorities are to protect life and safety, establish an authoritative command structure, identify the attack scope, preserve evidence, contain spread and protect clean backups. Responders should determine whether encryption is still active, whether privileged credentials are compromised, whether data was exfiltrated and whether recovery environments are reachable by the attacker.

Crisis communication should be accurate, timely and coordinated. Internal personnel need practical instructions, such as alternative communication channels and authentication procedures. Customers, suppliers, regulators and employees should receive information appropriate to their roles. Communication teams should avoid speculation, unsupported claims and promises that investigation cannot justify. If normal email is compromised, an out-of-band channel with verified contact lists is essential.

A crisis decision log records major decisions, assumptions, alternatives considered, authorisation and subsequent outcomes. This improves coordination and supports later review. It also protects against hindsight bias: decisions should be evaluated according to the information reasonably available at the time.

Cyber Resilience, Continuity and Disaster Recovery

Business continuity is concerned with maintaining critical functions during disruption. Disaster recovery focuses more specifically on restoring technology, data and services. Cyber resilience includes these capabilities but adds anticipation, resistance, adaptive response and learning in the presence of intelligent adversaries.

A BIA identifies critical processes, dependencies, maximum tolerable downtime, acceptable data loss, minimum staffing and manual workarounds. The resulting priorities should guide architecture and recovery investment. For example, a payment service may require geographically separated recovery capability, while a development environment may be restored later.

Resilient architecture commonly uses network segmentation, least privilege, immutable or offline backups, redundant identity services, tested golden images, multi-region options, manual operating procedures and supplier contingencies. Redundancy alone is not resilience: if all redundant systems share the same compromised identity provider or deployment pipeline, an attacker may control them simultaneously.

Recovery exercises should test realistic failure modes, including corrupted backups, unavailable cloud regions, compromised administrators, loss of corporate email and incomplete asset inventories. Metrics may include TTD, TTC, TTR, percentage of critical assets with tested recovery procedures, backup restoration success, privileged-account coverage and completion of corrective actions. Metrics should be interpreted carefully; reducing response time is not beneficial if it increases evidence destruction or unsafe operational decisions.

Governance, Ethics and Professional Responsibility

Incident response operates within legal and ethical boundaries. Organisations may have obligations concerning privacy, breach notification, records retention, employment law, sector regulation, export controls and cross-border data transfer. Legal counsel should be involved early when privilege, notification or law-enforcement engagement may become relevant, but legal involvement should not be used to conceal poor preparation or suppress legitimate safety information.

Investigators should apply proportionality and purpose limitation. Collecting every employee message or personal file may create new privacy risks. Monitoring should be authorised, documented and limited to a legitimate security objective. Evidence must not be altered to produce a convenient narrative, and professionals must disclose material uncertainty.

Third-party relationships require explicit response provisions. Contracts should address notification times, log access, preservation, cooperation, forensic authority, subcontractors, data location, service restoration and liability. Cloud and IoT suppliers may hold critical evidence, so these requirements should be negotiated before procurement rather than during a crisis.

Automation, Analytics and Artificial Intelligence

Security orchestration and automation platforms can enrich alerts, revoke tokens, isolate endpoints, create cases and execute approved playbooks. Automation is valuable for repetitive, time-sensitive actions, but high-impact actions should have safeguards, approval thresholds and rollback procedures. An automated rule that disables every account exhibiting an unusual login may interrupt legitimate emergency work or recovery operations.

Analytics can identify baselines and relationships across identity, cloud, endpoint and network data. Machine-learning systems may assist anomaly detection, malware classification, prioritisation and timeline construction. Their outputs remain hypotheses. Models can be affected by incomplete telemetry, changing behaviour, adversarial manipulation and biased training data. Analysts must retain responsibility for interpretation, evidence preservation and consequential decisions.

Generative AI may help summarise logs, draft timelines, search playbooks and translate technical findings for executives. Sensitive evidence should not be sent to an unapproved service, and generated conclusions must be verified against primary records. Provenance, access controls and retention policies are necessary when AI is used in an investigation.

Illustrative Case Study: Ransomware Across a Hybrid Enterprise

Background

A fictional logistics company operates warehouse-management applications in a public cloud, connected scanners and cameras in regional warehouses, and an enterprise identity service used by employees and suppliers. Its security team has centralised endpoint alerts but retains cloud audit logs for only a short period. Backups exist, although restoration tests have been limited.

Situation

At 02:10 on a Monday, warehouse terminals begin displaying ransom notes. Several virtual machines are encrypted, and an administrative cloud account creates new access keys. Warehouse cameras are intermittently unavailable. The security operations centre receives alerts for unusual authentication from a supplier account but initially treats them as low priority.

Analysis

The response leader declares a major incident and establishes an out-of-band communications channel. The team confirms that the supplier account was used to access the identity platform and assume a privileged cloud role. Cloud audit records show changes to security groups and access to backup repositories. Endpoint evidence indicates that encryption began after a remote-management tool was deployed. Network analysis suggests that some data was transferred before encryption.

The team faces a difficult containment choice: shutting down all warehouse networks would stop further encryption but halt dispatch operations. Instead, it segments affected warehouses, disables the supplier account, revokes active sessions, removes newly created keys and blocks the management tool. Safety personnel confirm that the camera disruption does not create an immediate physical hazard.

Strategy and solution

Investigators preserve cloud logs, snapshots of selected virtual machines, identity records and representative device images. They calculate hashes and record custody transfers. The company informs its insurer, legal advisers and relevant authorities, while communications staff prepare fact-based messages for employees and customers.

The recovery team rebuilds the identity and management components from trusted configurations, rotates privileged credentials, validates immutable backups and restores the warehouse application according to business priority. IoT devices are returned to a restricted network and updated or replaced where firmware integrity cannot be established. Before reconnection, each service undergoes vulnerability scanning, configuration review and enhanced monitoring.

Outcome

Dispatch operations resume in stages. The investigation concludes that supplier-account compromise, excessive privilege and inadequate monitoring of cloud role changes enabled the attack. The company does not treat restoration as the end of the incident; it maintains heightened monitoring and conducts a review with the supplier.

Learning points

The case demonstrates that identity containment can be more important than isolating individual servers, that IoT devices can be operationally affected without being the original entry point, and that short cloud-log retention can permanently limit investigation. It also shows why tested immutable backups, out-of-band communication and predefined decision authority are resilience controls rather than merely technical conveniences.

Common Failure Modes and Best Practices

Frequent failures include failing to define what constitutes a major incident, allowing attackers to retain privileged sessions, relying on untested backups, collecting evidence without documentation, rebuilding systems before understanding persistence, treating cloud logs as automatically available, and communicating speculation as fact. Another mistake is measuring success only by technical uptime while ignoring data integrity, safety and recurrence.

Best practice is to maintain an asset and dependency inventory; implement centralised, protected logging; use strong identity controls and phishing-resistant authentication for privileged access; segment IoT and operational networks; protect backups from ordinary credentials; rehearse response and recovery; preserve evidence systematically; maintain supplier contact information; and assign every improvement action to an accountable owner. Senior leaders should review resilience as an enterprise risk, not delegate it entirely to the security operations centre.

Current Developments and Emerging Directions

Incident response is increasingly shaped by ephemeral cloud workloads, software supply-chain compromise, identity-based attacks, extortion without encryption, attacks on managed service providers and the convergence of IT with operational technology. Organisations are moving toward continuous control-plane monitoring, identity threat detection, cloud-native investigation tools and automated evidence collection.

Regulatory expectations are also placing greater emphasis on timely reporting, documented governance, third-party risk and demonstrable recovery capability. At the same time, adversarial use of automation and generative AI increases the speed and scale of phishing, reconnaissance and social engineering. The strategic implication is clear: resilience depends not only on faster tools but also on reliable architecture, exercised procedures, disciplined governance and informed human judgement.

Chapter Summary

Incident response is an organised capability for managing security incidents from preparation through learning. Its lifecycle includes detection and analysis, containment, eradication and recovery, supported by governance, communications and technical readiness. Digital forensics provides disciplined methods for collecting and interpreting evidence, with special attention to volatile data, chain of custody, cloud control-plane records and IoT limitations. Ransomware response must address safety, identity compromise, evidence, backups, legal duties and crisis communication. Cyber resilience links incident response with business continuity and disaster recovery by ensuring that critical functions can withstand disruption and recover safely. Automation and AI can improve speed and analysis, but their outputs require human verification, privacy safeguards and accountable decision-making. Mature organisations practise their plans, protect evidence and backups, learn from incidents and treat resilience as an enterprise responsibility.

Key Terms

Incident response: Organised management of preparation, detection, containment, eradication, recovery and learning after a security incident.

Digital forensics: Scientific and repeatable examination of digital evidence for investigative or legal purposes.

Cyber resilience: The ability to anticipate, withstand, recover from and adapt to cyber disruption.

Indicator of compromise: An observable artefact associated with suspected malicious activity.

Chain of custody: Documented history of evidence collection, possession, transfer and handling.

Volatile evidence: Information that may disappear when a device or process is stopped, such as memory contents.

Forensic image: A bit-for-bit or otherwise formally acquired representation of digital storage used for examination.

Cloud forensics: Collection and analysis of evidence from cloud services, identities, workloads and provider records.

Control plane: Cloud management layer through which resources, identities and configurations are created or changed.

Data plane: Layer in which applications, workloads and stored data operate.

Ransomware: Malware or an extortion operation that denies access to data or systems, often combined with data theft.

Business impact analysis: Assessment of disruption consequences, critical processes, dependencies and recovery needs.

Recovery time objective: Target time within which a service should be restored.

Recovery point objective: Maximum acceptable period of data loss measured in time.

Containment: Actions that limit an incident’s spread or impact while response continues.

Eradication: Removal of malware, persistence, vulnerabilities or unauthorised access associated with an incident.

Crisis communication: Coordinated exchange of accurate information with internal and external stakeholders during disruption.

Immutable backup: Backup designed so that ordinary users or compromised systems cannot alter or delete it.

Tabletop exercise: Discussion-based simulation used to test decisions, roles and response procedures.

Shared-responsibility model: Allocation of security duties between a cloud provider and its customer.

Review Questions

Short Answer Questions

1. How does cyber resilience differ from incident response?

2. What is the purpose of maintaining a chain of custody?

3. Why are cloud control-plane logs important during an investigation?

4. Define RTO and RPO.

5. State two reasons why IoT forensics is difficult.

Long Answer Questions

1. Explain the incident-response lifecycle and the decisions involved at each stage.

2. Discuss the preparation requirements for a cloud, IoT and enterprise incident-response capability.

3. Describe the principles of digital evidence acquisition and preservation.

4. Analyse how ransomware affects technical recovery, governance and crisis communication.

5. Explain how business continuity, disaster recovery and cyber resilience complement one another.

Analytical / Application Questions

1. A company discovers that an attacker has created privileged cloud access keys but has not yet encrypted systems. What containment and evidence-preservation actions should be prioritised, and why?

2. An IoT manufacturer cannot retrieve device logs after a suspected compromise. Identify alternative evidence sources and explain how investigators should address uncertainty in the timeline.

3. An organisation has redundant cloud services but all accounts are managed through one compromised identity provider. Evaluate the resilience of this design and recommend improvements.

22. Multiple Choice Questions with Answers

Question 1

Which action best represents preparation for cloud incident response?

A. Waiting until an incident occurs before enabling audit logs

B. Forwarding relevant cloud logs to a protected, independently controlled account

C. Deleting old logs to reduce storage costs

D. Allowing all administrators to change retention settings

Correct Answer: B. Forwarding relevant cloud logs to a protected, independently controlled account

Question 2

Why may immediate power removal be problematic during an IoT investigation?

A. It always encrypts the device storage

B. It may destroy volatile evidence and alter the device state

C. It automatically notifies the cloud provider

D. It prevents any later firmware update

Correct Answer: B. It may destroy volatile evidence and alter the device state

Question 3

Which statement best distinguishes containment from eradication?

A. Containment limits spread, whereas eradication removes the cause and persistence

B. Containment restores services, whereas eradication communicates with customers

C. Containment applies only to cloud systems, whereas eradication applies only to endpoints

D. Containment is performed after recovery, whereas eradication precedes detection

Correct Answer: A. Containment limits spread, whereas eradication removes the cause and persistence

Question 4

An organisation discovers that a compromised administrator created new cloud access keys. What is the most appropriate immediate priority?

A. Publish a public statement naming the attacker

B. Revoke or disable the exposed credentials and review related sessions and privileges

C. Delete all cloud audit logs to prevent further exposure

D. Restore every server before investigating identity activity

Correct Answer: B. Revoke or disable the exposed credentials and review related sessions and privileges

Question 5

What does a cryptographic hash primarily help demonstrate in evidence handling?

A. That the evidence is complete and truthful in every respect

B. That a particular digital object has not changed since hashing

C. That the attacker’s identity has been proven

D. That the evidence was collected legally

Correct Answer: B. That a particular digital object has not changed since hashing

Question 6

Which recovery design provides the strongest protection against ransomware alteration of backups?

A. Backups using the same administrator credentials as production systems

B. Backups accessible through every ordinary user account

C. Tested immutable or offline backups separated from production administration

D. Backups stored only on the encrypted production host

Correct Answer: C. Tested immutable or offline backups separated from production administration

Question 7

A company restores a server, but the attacker’s compromised identity remains active. What does this illustrate?

A. Successful eradication

B. A recovery action that may leave the attack path open

C. A completed post-incident review

D. A valid reason to discard all evidence

Correct Answer: B. A recovery action that may leave the attack path open

Question 8

Which metric specifically measures the target time for restoring a service?

A. RPO

B. TTD

C. RTO

D. TTC

Correct Answer: C. RTO

Question 9

Why should AI-generated incident summaries be verified by analysts?

A. AI systems cannot process any security data

B. Generated outputs may reflect incomplete telemetry, errors or unsupported conclusions

C. Verification prevents the use of cryptographic hashes

D. AI summaries are automatically legal evidence

Correct Answer: B. Generated outputs may reflect incomplete telemetry, errors or unsupported conclusions

Question 10

During a major incident, normal corporate email may be compromised. Which practice is most appropriate?

A. Continue using email without authentication changes

B. Use a verified out-of-band communication channel and maintain a decision log

C. Allow every employee to create an unrecorded communication group

D. Delay all communication until technical recovery is complete

Correct Answer: B. Use a verified out-of-band communication channel and maintain a decision log