Operational Procedures practice questions

Disaster recovery plan (DRP)

Why it fails: The Disaster Recovery Plan (DRP) is primarily concerned with the technical recovery of IT systems, infrastructure, and data after a catastrophic event. Its focus is on restoring technological capabilities, such as servers, networks, and applications, to an operational state. While DRPs may briefly mention notification procedures, they do not govern the strategic or tactical communication protocols with internal and external stakeholders during or after a security incident.

Communication management plan

Why it fails: A Communication Management Plan specifically outlines the strategies, protocols, and responsibilities for disseminating information to internal and external stakeholders during and after security incidents. It defines who communicates what, when, through which channels, and to whom, ensuring consistent and timely messaging. Post-incident reviews frequently identify areas for improvement in stakeholder communication, making this the appropriate document to update to enhance future incident handling and transparency.

Business continuity plan (BCP)

Why it fails: The Business Continuity Plan (BCP) is a comprehensive strategy designed to ensure the continued operation of critical business functions during and after a disruptive event. While it encompasses broader organizational resilience, including the recovery of essential processes and resources, its primary objective is maintaining operational viability. The BCP focuses on sustaining core business activities rather than detailing the specific communication strategies or protocols for incident-related information dissemination.

Sharing indicators of compromise with threat intel platforms

Why it fails: Sharing indicators of compromise (IOCs) with external threat intelligence platforms or ISACs is a key component of the Post-Incident Activity phase. During this final phase, organizations compile lessons learned and distribute threat data to improve collective defense. Doing this during preparation is impossible as the specific incident-related IOCs have not yet been generated or identified.

Conducting root cause analysis of past incidents

Why it fails: Conducting a comprehensive root cause analysis (RCA) of past security incidents is performed during the Post-Incident Activity (or Lessons Learned) phase. This retrospective analysis aims to identify the underlying vulnerabilities or process failures that allowed the breach to occur. While the output of this analysis can inform future preparation, the act of conducting the RCA itself belongs to the post-incident phase.

Analyzing malware samples in a sandbox

Why it fails: Analyzing suspicious malware samples within an isolated sandbox environment is an active investigative task that occurs during the Detection and Analysis phase. This technical analysis helps responders understand the capabilities, behavior, and impact of a live threat currently affecting the network. It is a reactive measure taken once an indicator of compromise has already triggered an alert.

Technical intelligence

Why it fails: Technical intelligence reports focus on specific indicators of compromise such as hashes, IP addresses, and malware signatures. These are intended for security engineers and researchers who need to implement detection signatures and blocking rules. They are inappropriate for executive decision-making because they lack business context, convey no strategic risk, and are written at a machine-speed level that a board-level audience cannot act upon.

Tactical intelligence

Why it fails: Tactical intelligence reports concentrate on threat actors' tactics, techniques, and procedures (TTPs) and are used by SOC analysts to guide threat hunting, detection, and response. This level of detail is actionable for hands-on defenders but is not suitable for a high-level audience. The report would require deep security expertise to interpret and does not connect technical activity to enterprise risk, strategic priorities, or investment decisions.

Operational intelligence

Why it fails: Operational intelligence reports provide context about specific campaigns, attacks, or ongoing incidents, often including victimology and attacker infrastructure. They are designed for security operations managers who must orchestrate incident response and allocate defensive resources. While this adds situational awareness, it remains focused on immediate operational effectiveness rather than translating threats into long-term business risk, which is why it does not serve an executive audience making strategic decisions.

Rolling patch deployment

Why it fails: Rolling patch deployment involves gradually updating a subset of systems at a time, often to minimize service disruption and test stability before full rollout. While a valid deployment strategy for non-critical updates, this phased approach is inherently too slow and deliberate for addressing a critical vulnerability that demands immediate, widespread remediation across the affected environment. It prioritizes availability and controlled risk over rapid, comprehensive mitigation of an urgent threat.

Patch compliance tracking

Why it fails: Patch compliance tracking is a post-deployment activity focused on auditing and reporting to ensure that required security updates have been successfully installed across all target systems. This process verifies the effectiveness of a patching initiative and identifies non-compliant assets, but it does not describe the actual procedure or method for deploying the critical patch itself. It's a measurement and verification step, not the immediate operational response to a vulnerability.

Standard patch management

Why it fails: Standard patch management typically involves a structured lifecycle that includes thorough testing in development and staging environments, scheduled deployment windows, and adherence to formal change management procedures. While crucial for maintaining system stability and minimizing operational impact for routine updates, this methodical approach introduces delays that are unacceptable when facing a critical vulnerability requiring immediate remediation. The time-consuming testing and approval phases inherent in standard processes would leave systems exposed for too long.

Implement a compensating control

Why it fails: When direct patching is not immediately possible due to operational constraints or testing requirements, implementing a compensating control is the most appropriate action. This involves deploying alternative security measures, such as network segmentation, intrusion prevention system (IPS) rules, or enhanced monitoring, to reduce the exploitability or impact of the vulnerability. These controls effectively lower the immediate risk, allowing the organization to adhere to the 30-day remediation policy while planning for the permanent patch deployment.

Apply a hotfix without reboot

Why it fails: Applying a hotfix without a system reboot is often insufficient for fully addressing a vulnerability, as many patches require a complete restart to properly load new kernel modules, libraries, or system services. This approach risks leaving the vulnerability partially exploitable or introducing system instability due to mismatched components. Consequently, it fails to reliably remediate the vulnerability within the policy timeframe and may create new operational issues.

Extend the remediation deadline

Why it fails: Simply extending the remediation deadline is an administrative action that does not address the underlying technical vulnerability or reduce the associated risk. This approach constitutes a direct violation of the company's security policy, as it merely postpones compliance without implementing any actual security measure. It demonstrates a failure to prioritize security and can lead to a culture of non-compliance with critical vulnerability management standards.

Current CPU utilization on firewalls

Why it fails: This metric represents a low-level operational performance indicator for network devices. While crucial for network engineers to monitor device health and capacity planning, it provides no strategic insight into the organization's overall security posture or risk landscape for executive decision-making. Executives require aggregated, risk-centric data to understand business impact, not infrastructure performance.

Patch installation status of all endpoints

Why it fails: The granular status of patch installations across all endpoints is an operational detail critical for IT and security teams responsible for vulnerability management and system hygiene. While vital for reducing attack surface, presenting this level of detail to executives would overwhelm them with tactical information rather than providing the strategic overview of risk and compliance they require. Executives need to know the impact of patching, not the individual status of each patch.

Number of IDS alerts per hour

Why it fails: Reporting the raw number of Intrusion Detection System (IDS) alerts per hour provides a tactical, high-volume metric that lacks the necessary context and aggregation for executive-level understanding. Executives are not concerned with the sheer volume of alerts, which can often include false positives, but rather with the actual impact of significant security incidents or the overall effectiveness of threat detection capabilities. They require insights into materialized risks or trends in critical threats, not operational noise.

Individual performance evaluations of team members

Why it fails: A post-incident review, particularly the "lessons learned" phase, is designed to improve organizational processes and procedures, not to conduct individual performance evaluations. Focusing on individual performance can foster a culture of blame, hindering open communication and honest assessment of systemic failures. The objective is to identify systemic weaknesses and enhance future incident response capabilities, not to discipline personnel.

Legal liability of the organization

Why it fails: While legal implications are a significant consequence of a data breach, determining the organization's legal liability is typically handled by legal counsel and is distinct from the technical post-incident review process. The primary goal of the technical review is to understand how the breach occurred and what can be done to prevent recurrence, not to assess legal culpability or prepare for litigation. Mixing these objectives can compromise the objectivity of the technical analysis.

A request to remove the asset from inventory

Why it fails: Requesting to remove an asset from inventory is an inappropriate action within a vulnerability exception request, as it merely obscures the asset and its associated risks rather than addressing them. Such a practice undermines asset management and visibility, creating 'shadow IT' that remains vulnerable but untracked, significantly increasing the organization's overall attack surface. A legitimate exception acknowledges the vulnerability and its host, focusing on risk mitigation rather than concealment.

Implement multi-factor authentication for all accounts

Why it fails: While enforcing multi-factor authentication (MFA) is a critical identity and access management (IAM) control that mitigates credential stuffing and unauthorized access, it does not address the procedural communication failures identified during the post-incident review. Technical controls cannot substitute for well-defined administrative workflows and incident coordination procedures.

Replace the current SIEM tool with a faster one

Why it fails: Upgrading or replacing a Security Information and Event Management (SIEM) system may improve log ingestion rates and correlation speeds, but it does not resolve human-centric communication issues. A faster SIEM will still fail to streamline incident response if the security team lacks clear escalation paths and defined communication channels to report findings.

Conduct more frequent vulnerability scans

Why it fails: Increasing the frequency of vulnerability scanning helps identify unpatched systems and configuration drift earlier in the lifecycle. However, this proactive assessment measure does nothing to resolve the reactive communication and coordination gaps that occur once an active security incident is underway.

Boot the suspect system to check for running processes.

Why it fails: Booting the suspect system, particularly in normal mode, initiates the operating system and writes data to the disk—changing file access times, creating temporary files, and potentially altering user data or logs. This violates the core forensic principle of preserving evidence in its original state, as any modification can destroy or contaminate proof. Even if the system is booted from a live CD, the system's devices may still generate write activity, and performing a live boot is only justified in specific, carefully controlled scenarios where volatile data must be captured before powering down. In a routine forensic acquisition, the correct procedure is to keep the system powered off and use static imaging techniques.

Store original evidence on the same network as the investigation.

Why it fails: Storing original evidence on the same network as the investigation introduces a severe risk of corruption, accidental modification, or unauthorized access. For example, if the network is compromised by malware, the evidence files or the forensic images could be infected or altered, breaking their integrity and making them inadmissible in court. Additionally, network storage may have automated backup or indexing processes that modify file timestamps, and it can be accessible to other users, which creates a chain-of-custody violation. Original evidence should be stored on write-protected media in a physically secured, isolated evidence locker, ensuring that it is never exposed to a network environment that could change or contaminate it.

Reinstall the operating system before imaging to ensure stability.

Why it fails: Reinstalling the operating system before imaging would completely obliterate the original evidence—the process overwrites the disk's contents, destroys user files, deletes logs, and replaces system artifacts—thereby defeating the entire purpose of forensic preservation. The goal of digital forensics is to recover and analyze the evidence exactly as it existed at the time of the incident, not to create a clean or stable environment for the investigator. An unstable system does not justify such a destructive action; if a system is unstable, the investigator should still follow proper procedures for imaging the original media, even if it requires additional care or specialized tools. Reinstalling the OS would be tantamount to destroying evidence and could lead to criminal charges for obstruction of justice or evidence tampering.

Apply the patch within the next 30 days as part of routine maintenance

Why it fails: A standard 30-day patch cycle is inadequate for high-risk vulnerabilities on critical assets, especially when EPSS indicates a high likelihood of exploitation. Delaying remediation leaves the organization exposed to active threat actors who can weaponize the vulnerability long before the routine maintenance window occurs. Vulnerability management policies must dynamically escalate patching timelines based on threat intelligence and asset criticality.

Implement a network-based intrusion prevention system signature to block exploitation attempts

Why it fails: While deploying an IPS signature serves as an effective compensating control, it does not remediate the underlying vulnerability and can be bypassed by encrypted traffic or alternative attack vectors. Relying solely on network-level blocks introduces a false sense of security and delays the necessary host-level remediation. Compensating controls should supplement, not replace, the primary objective of patching the vulnerable software.

Deploy the patch immediately in the production environment without testing

Why it fails: Deploying patches directly to production systems without any validation testing introduces severe operational risk, potentially causing system instability, service outages, or compatibility conflicts on critical assets. Even under emergency conditions, organizations must perform rapid, sandboxed testing to verify basic functionality before deployment. Bypassing testing entirely violates change management best practices and can result in self-inflicted denial-of-service conditions.

Conduct a tabletop exercise for the incident response team.

Why it fails: Tabletop exercises are an evaluation or training mechanism for incident response processes, roles, and communication flows, not a method for modifying detection content. Running a dry-run with the team may surface procedural gaps, such as unclear escalation paths, but it does not add or tune any signature, YARA rule, or SIEM correlation logic. Because the goal is to improve human readiness rather than defensive sensors, it would not have directly detected the actual ransomware on the network.

Increase the frequency of vulnerability scans.

Why it fails: Vulnerability scanning is a proactive posture activity that identifies missing patches, weak configurations, or known CVEs, but it is not a detection-rule update. Even if the ransomware exploited a known vulnerability, the scanner does not write indicators or behavioral patterns into the SIEM, EDR, or endpoint protection. Increasing scan frequency might reveal the attack surface before exploitation, but it provides no mechanism to detect the specific ransomware's files, hashes, or attacker TTPs during an active intrusion.

Share IOCs with external threat intelligence platforms.

Why it fails: Sharing IOCs with external threat intelligence platforms (e.g., MISP, ITX) is a community-based defense action that benefits other organizations by publishing indicators like IPs, domains, and hashes, but it does not alter the incident team's own detection infrastructure. The action is outward-bound; until an external feed is imported back into the SIEM or EDR and configured as a detection source, it has no effect on internal monitoring. Moreover, relying solely on blocklists after an incident is often insufficient because the same TTPs may be reused with new IOCs, so this step alone is not a direct detection-rule update.

Ship the image and document nothing

Why it fails: Shipping without documentation leaves no evidence that the binary is unreachable, so the critical finding cannot be closed or downgraded. Silent deployment suits low-risk changes, not unresolved critical CVEs requiring documented compensating controls or reachability proof.

Only rename the image tag

Why it fails: Renaming the tag changes no layer content, so the vulnerable OpenSSL binary remains in the image and the finding stands. Tag changes are legitimate for release or rollback management, not for remediating or evidencing a CVE.

Ignore all base-image vulnerabilities

Why it fails: Ignoring base-image findings removes the only evidence needed to justify downgrading the CVE. The stem requires validation that the vulnerable OpenSSL binary is unreachable, which demands inspection of the image layer and runtime dependencies. Ignoring suits environments where base layers are rebuilt nightly and findings are tracked centrally, not a pipeline actively blocking the build.

Run another scan on the test group in a week to confirm persistence.

Why it fails: Waiting an entire week to perform a follow-up scan introduces an unacceptable window of vulnerability and unnecessarily stalls the remediation lifecycle. Patch verification on the test group should be executed immediately using authenticated vulnerability scans or local configuration audits to confirm successful installation, allowing the deployment process to advance without artificial delays.

Immediately deploy the patch to all systems without further testing.

Why it fails: Deploying patches directly to production systems without validating them in a test environment bypasses critical change management controls and risks widespread operational disruption. Standard enterprise security frameworks dictate that patches must first be verified for stability and compatibility on representative test systems to prevent unexpected system crashes or software regressions across the enterprise.

Skip full deployment and rely on the test group results.

Why it fails: Limiting the patch application to the test group leaves the rest of the organization's production infrastructure fully exposed to active exploits. The primary purpose of a test group is to validate patch stability and efficacy, but actual risk reduction is only achieved when the verified patch is systematically deployed to all remaining vulnerable assets in the environment.

Apply the firmware patch immediately without rebooting

Why it fails: Attempting to apply a firmware patch immediately without rebooting is technically unfeasible because firmware resides in non-volatile memory and requires a system initialization cycle to load the new code. Furthermore, applying patches immediately to production systems without testing or scheduled downtime violates change management protocols and risks causing unplanned outages.

Implement a virtual patch via the IDS/IPS until a full patch is possible

Why it fails: While implementing a virtual patch via an intrusion detection or prevention system (IDS/IPS) can mitigate risk, it is a temporary compensating control rather than a true remediation. Virtual patching only inspects network traffic for known exploit signatures and does not fix the underlying vulnerability in the firmware itself, leaving the system exposed to alternative attack vectors or local exploits.

Request a hotfix from the vendor that does not require a reboot

Why it fails: Requesting a rebootless hotfix from a vendor is impractical because custom hotfixes are rarely available on demand and still typically require a system restart to apply low-level code changes. Relying on this approach introduces unnecessary administrative delays and leaves the system vulnerable while waiting for a custom software package that may never be delivered.

A presentation with graphs and trends

Why it fails: While visual aids like graphs and trend lines are highly effective for briefing executive leadership on high-level incident impact, they lack the granular technical data required by operations personnel. Security operations teams need actionable, low-level details rather than aggregated metrics to implement defensive changes.

An informal email with bullet points and no specific actions

Why it fails: Informal communications lack the structured, authoritative, and reproducible format required for official incident documentation. Without explicit, actionable remediation steps and verified indicators, the operations team cannot systematically validate that the threat has been fully eradicated from the environment.

A one-page executive summary with risk ratings

Why it fails: An executive summary is designed to provide a rapid, high-level overview of business risk and financial impact for non-technical stakeholders. It deliberately omits the deep technical configurations, code snippets, and log analyses that system administrators require to patch vulnerabilities and rebuild compromised assets.

OWASP Top 10

Why it fails: The OWASP Top 10 is a critical awareness document representing the most common security risks for web applications, such as injection and broken access control. It does not provide system-level configuration baselines or operating system hardening guidelines. Implementing configuration management for operating systems requires OS-specific benchmarks rather than application-layer vulnerability frameworks.

CIS Level 2 Benchmark

Why it fails: CIS Level 2 Benchmarks are intended for highly secure environments where data protection is paramount and some reduction in system utility or performance is acceptable. These profiles introduce defense-in-depth measures that can cause operational friction or compatibility issues if applied to standard enterprise systems without extensive testing. Consequently, they are too restrictive for a baseline configuration management rollout.

STIG for Linux

Why it fails: Security Technical Implementation Guides (STIGs) are highly stringent configuration standards created by the Defense Information Systems Agency (DISA) for United States Department of Defense systems. While highly secure, STIGs are notoriously restrictive, complex to implement, and can easily break commercial off-the-shelf software. They are generally inappropriate and overly burdensome for standard, non-military enterprise environments.

Wait until the incident is fully resolved

Why it fails: Postponing communication until complete eradication and recovery are achieved can severely expose third-party partners to active threats stemming from the breach. Many compliance frameworks and service level agreements (SLAs) mandate timely disclosure of active incidents to mitigate downstream supply chain risks and allow partners to defend their own networks.

Post the IoCs on a public threat sharing platform

Why it fails: Publishing indicators of compromise (IoCs) to public repositories without explicit authorization can tip off the threat actors that they have been detected, prompting them to alter their tactics and clean their tracks. Furthermore, leaking sensitive operational data prematurely can damage the organization's reputation and violate non-disclosure agreements with partners.

Directly notify all affected partners

Why it fails: Bypassing the established chain of command to directly contact partners can lead to inconsistent messaging, legal liabilities, and unnecessary panic. Communication must be vetted by legal, public relations, and executive leadership to ensure that the information shared is accurate, authorized, and aligned with contractual obligations.

No action because the incident is closed

Why it fails: Ignoring identified failures simply because an incident is officially closed undermines the entire purpose of post-incident analysis and continuous improvement. Incident closure signifies the immediate threat is contained and eradicated, but it should never preclude the implementation of long-term corrective actions or process enhancements. Failing to address underlying systemic issues guarantees future incidents of a similar nature, hindering an organization's security maturity and resilience.

Deletion of the integration record

Why it fails: Deleting integration records or any other evidence related to a failed alert is a severe breach of forensic best practices, audit requirements, and transparency. Such actions obscure the true root cause of the failure, prevent thorough analysis of the incident's scope and impact, and eliminate crucial data needed for future incident prevention and compliance verification. This practice actively hides security weaknesses and impedes learning, rather than addressing them transparently and effectively.

A vague recommendation to improve security

Why it fails: A vague recommendation, such as 'improve security,' lacks the specificity required for effective implementation, accountability, or measurable progress. Without clear objectives, defined metrics, and an assigned owner, such a recommendation is practically impossible to execute, track, or audit for effectiveness. Post-incident actions must be SMART: Specific, Measurable, Achievable, Relevant, and Time-bound to drive tangible improvements and demonstrate due diligence.

Amount of storage used by desktop screenshots

Why it fails: While desktop screenshots might be captured during forensic investigations or endpoint monitoring, tracking their storage consumption is a capacity planning metric rather than a security operations KPI. This metric does not provide any insight into the quality, speed, or effectiveness of the alert enrichment pipeline within a SIEM or SOAR platform.

Number of unused browser bookmarks

Why it fails: Browser bookmarks are localized user-interface shortcuts managed individually by analysts and do not correlate with security telemetry or automated enrichment workflows. Monitoring unused bookmarks fails to yield any actionable data regarding SOC performance, detection engineering, or the operational value of ingested threat intelligence.