Incident Handling Process practice questions

Netstat -an

Why it fails: Netstat lists active TCP/IP connections and listening ports; it reads network stack state and never writes a memory image. It is tempting because it captures volatile network data during live response, which is useful for identifying exfiltration sessions, but RAM acquisition requires a dedicated imaging tool.

Windows Task Manager dump

Why it fails: Task Manager can write a process minidump, capturing only one process's user-mode memory, not the full physical RAM image required for forensic analysis. It is tempting because it is built into Windows and produces a .dmp file, but it omits kernel memory and other processes.

WinPcap capture

Why it fails: WinPcap captures network packets traversing an interface, not the contents of physical memory. It is tempting because it is a well-known forensic-adjacent capture tool and records volatile network traffic, but packet capture and RAM acquisition are entirely different data sources.

Acceptable Use Policy

Why it fails: This defines user behavior, not incident communication rules.

Access Control Policy

Why it fails: This defines who can access systems, not who is informed during an incident.

Data Classification Policy

Why it fails: This defines data sensitivity, not disclosure rights.

Isolating infected hosts from the network

Why it fails: This is part of the containment phase.

Interviewing employees about the incident

Why it fails: Interviewing employees gathers evidence and establishes what occurred, which sits in Analysis, not Recovery. It tempts because post-incident interviews do occur, but in the Lessons Learned or post-incident review stage, and would be correct when the goal is understanding root cause rather than restoring systems.

Notifying the media of the breach

Why it fails: Media notification is a Communications and stakeholder-management activity, not system restoration. It tempts because breach disclosure is a real obligation, and would be correct during Communications planning or when regulatory notification timelines apply, not while returning affected systems to normal production service.

The 'Elasticsearch' index prefix in system settings

Why it fails: This determines storage location, not the structure of incident report fields.

The 'Analyzer' timeout setting in the application.conf file

Why it fails: This setting controls the duration of external analysis tasks, not metadata field definitions.

The 'Cortex' connection string in the GUI settings

Why it fails: Cortex settings manage connections to analyzers, not the internal incident schema.

Reimage the server immediately to restore operations, then reconnect it to the network.

Why it fails: Reimaging the server destroys potential evidence and does not guarantee that the ransomware has been fully eradicated from the environment. Reconnecting it without proper containment measures could lead to reinfection. This approach skips critical incident handling steps such as eradication and recovery validation, and it may violate legal or regulatory requirements for evidence preservation. It is a reactive action that ignores root cause analysis.

Immediately power off the server to stop the encryption process.

Why it fails: Powering off the server abruptly may destroy volatile evidence in memory, such as encryption keys or running processes, and can cause file system corruption. It also does not address the need to maintain business continuity for the revenue application. This action is too disruptive and irreversible, making it a poor containment choice when evidence has already been collected and a graceful approach is possible.

Leave the server connected to monitor the attacker's behavior and gather more intelligence.

Why it fails: Leaving the server connected allows the ransomware to continue encrypting files and potentially spread to other network segments. While monitoring can be valuable, the risk of further damage and lateral movement outweighs the benefits in an active ransomware outbreak. Containment should take priority to limit impact, and intelligence gathering can be done through other means such as network monitoring or endpoint detection tools.

Disable the compromised user accounts and reset their credentials.

Why it fails: Disabling accounts and resetting credentials can be part of containment for credential-based attacks, but ransomware spread often occurs through network shares and exploits, not only compromised accounts. Doing this first without isolating endpoints may not stop the encryption process already in progress. Account actions are useful but not the primary containment step for active ransomware on endpoints.

Reimage all affected endpoints immediately to restore normal operations.

Why it fails: Reimaging destroys volatile and disk-resident evidence, including ransomware binaries, persistence mechanisms, and encryption keys that could help with decryption or attribution. It is a recovery action, not a containment action, and should occur only after evidence is collected and the root cause is understood. Immediate reimaging also risks reintroducing the malware if the initial access vector is not remediated.

Restore affected systems from the most recent backups.

Why it fails: Restoring from backups is a recovery action, not containment, and should only occur after the threat is contained and the environment is verified clean. Restoring too early can reintroduce the ransomware if the initial access vector or persistence remains. It also overwrites evidence and can lead to repeated reinfection, wasting recovery effort and extending downtime.

Technical Investigator

Why it fails: The Technical Investigator performs forensic analysis and evidence collection, not legal or privacy review. It is tempting because investigators handle sensitive data, but their remit is technical fact-finding, not ensuring handling activities meet organisational legal and privacy requirements.

Incident Lead

Why it fails: The Incident Lead coordinates the overall response, triage and resource allocation, not legal or privacy conformance. It is tempting because the lead oversees all activities, yet legal alignment sits with a dedicated advisor rather than the operational coordinator.

Communications Officer

Why it fails: The Communications Officer handles media, stakeholder and public messaging during an incident, not legal or privacy alignment. It is tempting because communications often touch disclosure wording, but the role owns external messaging, not regulatory compliance of handling activities.

Taking photographs of the server location

Why it fails: Photographs document the scene and server condition but do not record who held the evidence, when, or why; an unbroken documented chain of custody is what establishes admissibility. It is tempting because scene documentation is a genuine forensic step, yet it supports the investigation rather than proving custody continuity.

Using an anti-static bag for transport

Why it fails: Anti-static bags protect hardware from electrostatic discharge during transport, not evidential integrity; admissibility hinges on an unbroken, documented chain of custody with signed transfers. It is tempting because proper packaging feels like evidence handling, but packaging addresses physical preservation, not the documented custody trail courts require.

Hashing the drive contents immediately

Why it fails: Hashing verifies integrity but does not itself document possession; admissibility requires a continuous, signed chain-of-custody record tracking every transfer. It is tempting because hashing is a genuine forensic safeguard, yet it proves the data is unchanged, not who controlled the evidence at each stage.

Updating the password policy

Why it fails: A password policy change addresses one credential control, not the review's purpose of capturing what happened and amending procedures, detection rules or training. It is tempting because credential weaknesses often feature in incidents, and policy hardening is the right response when the root cause is genuinely weak authentication requirements.

Archiving all forensic images for ten years

Why it fails: Retention of forensic images preserves evidence for legal or investigative needs but changes no procedure, control or training, so future response capability is untouched. It is tempting because evidence preservation is mandatory in regulated or litigious incidents, where chain-of-custody and long retention periods genuinely are the priority.

Assigning blame to the employee who made the error

Why it fails: Blaming an individual suppresses the honest reporting that lessons-learned depends on, so systemic causes stay hidden and recur. It is tempting because accountability feels like closure after an incident, and disciplinary action is correct when someone acted maliciously or with gross negligence rather than making an error.

To comply with the Acceptable Use Policy

Why it fails: An Acceptable Use Policy governs employee system usage, not incident communications resilience. Out-of-band methods exist because the primary network or email may be compromised or unavailable during an attack. Policy compliance is achieved through standard channels; it does not explain the out-of-band requirement.

To simplify documentation for the final report

Why it fails: Out-of-band communication is chosen for resilience, not documentation convenience. Incident records are compiled afterwards from logs and notes regardless of channel. Simplified reporting suits a structured ticketing system, whereas out-of-band tools are selected because the primary network may be unavailable.

To increase bandwidth for file transfers

Why it fails: Out-of-band channels are typically lower bandwidth, using separate networks or telephony, so they cannot increase transfer capacity. Their purpose is availability when primary infrastructure is compromised. High-bandwidth transfers suit the primary corporate network during normal operations.

Business Continuity Plan

Why it fails: This focuses on overall business survival, not specific technical incident handling steps.

Communication Plan

Why it fails: This outlines who to contact, not technical recovery steps.

Security Policy

Why it fails: This defines organizational requirements, not specific technical procedures.

Change the root password to lock out the attacker

Why it fails: Changing the root password alters system state and can overwrite credential artefacts, while the insider may retain other access paths or already have exfiltrated data. It is tempting as immediate lockout, and credential rotation is correct during later remediation, but evidence capture must precede any modification of the compromised host.

Delete the suspicious user account

Why it fails: Deleting the account destroys authentication logs, mailbox data and file ownership records that constitute evidence, and alerts any accomplice. It is tempting as rapid containment, and disabling an account is valid once evidence is captured; however, volatile and account-linked artefacts must be preserved before any identity change.

Reboot the compromised system to clear malicious memory

Why it fails: Rebooting clears volatile memory, destroying running processes, network connections and injected code that constitute primary evidence. It is tempting because restarting often restores service quickly, and rebooting is acceptable after memory capture; however, live forensic acquisition must happen first to preserve integrity.

Moving the logs to a backup server

Why it fails: Copying logs to a backup server creates a duplicate without documented integrity controls, so the original's authenticity cannot be proven. Backup copies suit disaster recovery, whereas evidence preservation demands write-once storage with hashing and custody records.

Printing the logs to a secure PDF

Why it fails: A PDF printout is a derived copy that alters the original log format and breaks the chain of custody. Printing suits sharing a readable summary, but forensic validity requires preserving the original SIEM data with verified hashes.

Taking a screenshot of the SIEM dashboard

Why it fails: A screenshot captures only rendered pixels, discarding raw log fields and metadata, and is trivially altered. Screenshots suit quick visual reporting, but maintaining evidential validity requires exporting original SIEM records with cryptographic hashes and documented custody.

A list of all employees who were working during the incident

Why it fails: A roster of employees present is context, not a chronological record; the timeline needs timestamped events and actions in sequence. It is tempting because knowing who was on duty aids reconstruction, and such personnel detail would correctly appear in an appendix or participant list rather than the timeline itself.

The cost estimate for all hardware replaced

Why it fails: Hardware replacement costs belong in a cost or impact section, not the chronological sequence of attacker and responder actions. It is tempting because financial loss is a legitimate post-incident metric, and would be the correct entry when documenting the incident's business impact or recovery expenditure.

The personal opinion of the investigators on who was responsible

Why it fails: Investigator opinions on responsibility are subjective attribution, whereas the timeline records timestamped factual events and actions. It is tempting because assigning blame feels like a natural review outcome, and such conclusions belong in a findings or recommendations section supported by evidence, not the chronology.

Block the IP at the firewall immediately

Why it fails: Blocking immediately may terminate an active session before evidence is captured and could be a false positive, disrupting legitimate users. It is tempting as rapid containment, but the identification phase requires gathering data first; blocking belongs to containment once the threat is confirmed.

Notify the local law enforcement

Why it fails: Law enforcement involvement follows internal escalation and evidence preservation, not initial triage of unverified traffic. It is tempting because suspected attacks may become criminal matters, but notification is premature before confirming malicious intent, scope, and impact through investigation.

Shut down the web server

Why it fails: Shutting down the server causes denial of service to legitimate users and destroys volatile evidence such as memory and active connections. It is tempting as decisive containment, but the identification phase demands investigation first; shutdown is a last-resort action after the threat is confirmed.

The number of security tools that flagged the alert

Why it fails: Alert volume reflects detection coverage and tooling overlap, not the actual harm caused. It tempts because multiple corroborating detections can raise confidence in an incident's legitimacy, which supports triage validation rather than the impact-driven severity classification.

The time of day the incident occurred

Why it fails: Timing is contextual metadata; severity derives from business impact, data sensitivity, and scope of compromise. It tempts because off-hours incidents may delay detection and response, which is relevant to staffing and escalation, not to the inherent severity assigned to the event.

The technical complexity of the exploit

Why it fails: Exploit complexity describes attacker technique, not the business impact or data exposure that drives severity ratings. It tempts because intricate exploits can demand urgent specialist response, which matters in containment planning rather than in the impact-based severity classification itself.

Export the data to a public cloud storage service

Why it fails: Exporting to a public cloud service moves potentially sensitive investigative data outside the organisation's controlled, access-restricted environment, breaching preservation and confidentiality duties. Public cloud export suits non-sensitive bulk archival or approved collaboration, not evidence subject to a legal hold.

Follow the standard 90-day retention policy

Why it fails: A legal hold suspends routine destruction, so applying the 90-day retention schedule would purge evidence and risk spoliation sanctions. Standard retention is correct for ordinary records with no litigation, audit or regulatory trigger; here the hold overrides it, requiring preservation until released.

Delete the data and generate an audit log

Why it fails: Deleting the data destroys the very evidence the hold compels you to preserve; an audit log records the deletion but cannot restore content, so spoliation still occurs. Deletion with logging suits routine end-of-life disposal of non-relevant data, not material under an active legal hold.

To identify the attacker

Why it fails: Identifying the attacker is threat attribution, performed during investigation, not containment. Containment isolates affected hosts to halt propagation. It is tempting because attribution shapes later legal and notification steps, and would be correct in the post-incident review or intelligence phase.

To analyze the root cause

Why it fails: Root-cause analysis belongs to the post-incident investigation phase, after systems are stabilised. Containment's goal is limiting scope and stopping spread, so analysis here delays that. It is tempting because understanding cause feels urgent, and would be correct once eradication and recovery are complete.

To recover normal operations

Why it fails: Recovering normal operations is the recovery phase, which follows eradication of the threat. Containment instead prevents further spread while the incident is active. It is tempting because restoring service is the ultimate aim, and would be correct after containment and eradication are verified.

To monitor network traffic for threats

Why it fails: Monitoring network traffic is a detective control performed by IDS or SIEM tooling, not the function of an IR policy, which defines roles, escalation paths and procedures for handling confirmed incidents. It is tempting because monitoring feeds incident detection, but that activity belongs to the detection phase, not the governing policy document.

To define the budget for new security tools

Why it fails: Budgeting sits with security governance and finance planning, not an IR policy, which defines incident classification, roles, escalation and communication. It is tempting because IR programmes do need funding, and this would be correct if the question asked about a security programme charter or business case.

To provide step-by-step instructions for patching servers

Why it fails: An IR policy states objectives, scope, roles and authority for handling incidents; patching procedures belong in change-management or vulnerability-management documentation. It is tempting because patching often remediates the root cause, and would be correct if the question asked about remediation runbooks.

The local news media

Why it fails: Media notification follows a formal disclosure plan and legal review; tipping journalists first risks uncontrolled exposure and regulatory breach. It is tempting because publicity shapes reputation, and media engagement is correct for planned announcements, not for the initial containment and forensic response this confirmed PII breach demands.

The marketing department

Why it fails: Marketing handles messaging and brand positioning, not containment, forensics or regulatory notification. It is tempting because customer trust and communications matter after a breach, and marketing is correct when drafting public statements once legal and incident response have scoped the disclosure, not first.

The software development team

Why it fails: Development staff neither own incident response nor hold authority over breach notification, containment, or regulatory reporting, so notifying them first delays the legally time-bound actions. It is tempting because developers may have written the vulnerable code, and would be the right contact for a defect fix, not a confirmed PII breach.