Risk Management practice questions

The vendor's recommended patch cycle

Why it fails: Vendor-defined patch cycles focus on technical maintenance schedules rather than the business-centric evaluation of risk appetite required for qualitative assessments. While these cycles provide essential guidance for operational security and vulnerability management, they represent a prescriptive baseline rather than an organisational risk tolerance metric. This option appears relevant when establishing technical remediation timelines or compliance baselines, but it fails to incorporate the subjective business impact and strategic risk thresholds necessary to align security posture with organisational objectives.

The threat actor's motivation

Why it fails: Analysing a threat actor’s motivation focuses on tactical intent rather than the organisation’s defined risk tolerance levels. While this information assists in refining specific threat modelling exercises or developing defensive countermeasures against targeted campaigns, it does not quantify impact or likelihood against established business thresholds. Organisations require a standardised framework to measure risk appetite, whereas motivation remains a subjective, variable attribute that lacks the necessary alignment with the quantitative or qualitative scales required to govern enterprise-wide risk management decisions.

The technical complexity of the vulnerability

Why it fails: Technical complexity focuses on the difficulty of remediation rather than the strategic alignment required for qualitative risk assessment. While this factor is essential for resource allocation during the implementation of technical controls, it ignores the business impact and risk tolerance defined by stakeholders. This option appears relevant when prioritising the operational workload for security teams, yet it fails to address the organisational risk appetite, which mandates that risk prioritisation be driven by business value and potential loss rather than the effort required to patch a vulnerability.

Asset Value multiplied by Threat Frequency

Why it fails: Calculating risk through asset valuation and threat frequency produces an inherent risk baseline rather than a true residual posture, as it completely omits existing security controls and their operational efficacy within a GRC integration. This deterministic equation is tempting because it forms the foundational arithmetic for quantitative risk assessment, and it *would* be the correct choice when scoping baseline vulnerability exposures before any defensive mitigations are deployed across the corporate infrastructure.

Compliance Score subtracted from 100

Why it fails: Deriving residual risk through simple mathematical inversion of a compliance score fails because adherence to regulatory controls does not measure loss frequency or impact severity. While this metric is tempting for audit reporting because it directly reflects regulatory posture and framework fulfillment, it remains useful strictly for measuring governance adherence rather than quantifying the actual financial or operational exposure facing the organisation.

Total Budget divided by Number of Findings

Why it fails: Dividing a total security budget by the number of findings merely produces an arbitrary financial average per vulnerability, failing to quantify threat likelihood, asset criticality, or control effectiveness within a GRC tool. This metric appears tempting because organisations frequently attempt to translate qualitative risk registers into financial terms to justify expenditures. Such a calculation *would* be appropriate for high-level financial benchmarking or estimating baseline remediation costs per ticket in a helpdesk ticketing system, but it holds zero relevance for calculating operational residual risk for a board.

Review of the CSP's website

Why it fails: Relying on a vendor's public website only provides static, high-level marketing claims and rarely reflects the real-time operational security posture required for continuous assessment. Although this approach is tempting for initial scope reduction and high-level vendor discovery during early-stage procurement, it should instead be reserved for initial market research or preliminary due diligence before formal technical evaluation begins.

One-time penetration test

Why it fails: Conducting a point-in-time penetration test provides a static snapshot of security vulnerabilities at a specific date, failing to deliver the ongoing, real-time monitoring required to track dynamic infrastructure changes and configuration drift in a cloud environment. Security teams are frequently tempted by this method because it offers deep, hands-on validation of exploitable flaws and verifies active defences. Such an assessment is the correct choice when validating the immediate security posture before deploying a major new application release or satisfying a specific annual compliance audit requirement.

Annual SOC 2 Type II review

Why it fails: Annual SOC 2 Type II reviews provide point-in-time assurance regarding historical control effectiveness over a preceding observation period, failing to deliver the real-time telemetry and ongoing metrics required for continuous assessment. Organisations are often tempted to rely on SOC 2 reports because they offer independent third-party validation of security posture, making them the correct choice for periodic compliance auditing and baseline vendor due diligence where point-in-time verification satisfies regulatory or contractual obligations.

Time taken to deploy the agent

Why it fails: Measuring the time taken to deploy an endpoint detection and response agent focuses entirely on operational rollout speed rather than risk reduction or financial return, failing to communicate strategic posture to senior leadership. This metric is frequently tracked during initial project implementation phases to gauge operational efficiency and project velocity, making it valuable for a project manager evaluating contractor performance or software rollout schedules, but it remains irrelevant for demonstrating board-level risk mitigation or financial justification.

Version number of the security software

Why it fails: Tracking the version number of an Endpoint Detection and Response deployment only indicates software currency and patch status rather than operational risk reduction or financial return on investment. Board members require metrics demonstrating loss avoidance, threat mitigation rates, or financial exposure reduction to justify capital expenditure. However, this metric appears tempting during technical audits or compliance reporting where asset inventories and baseline configuration compliance must be verified to satisfy regulatory frameworks and baseline hardening mandates.

Number of detected malware incidents

Why it fails: Raw detection volume measures the sheer activity level of threats rather than financial mitigation or operational risk reduction, failing to translate technical telemetry into the business language the Board requires for capital expenditure justification. However, this metric appears tempting because it directly quantifies the operational output of an Endpoint Detection and Response tool, making it the correct choice for an operational dashboard evaluating daily signature updates, analyst workloads, and the frequency of attempted endpoint compromises.

Avoid the risk

Why it fails: Eliminating the legacy system entirely would remove the unencrypted PII exposure, but the stem explicitly states that the business cannot replace it due to operational dependency. Risk avoidance is tempting because completely halting the vulnerable activity guarantees zero residual exposure to data breach liabilities. This approach is the correct choice only when a proposed system or process can be entirely decommissioned or cancelled without violating core business functions, which directly contradicts the strict operational constraints detailed in the scenario.

Transfer the risk

Why it fails: Transferring risk involves shifting the financial impact of a breach to a third party, typically through cyber insurance or service-level agreements. This approach is tempting because organisations naturally seek external financial protection against regulatory fines and liabilities stemming from unpatched legacy vulnerabilities. Such a strategy would be correct when dealing with third-party cloud hosting providers or outsourced managed services where contractual liability can be legally negotiated. However, it fails here because contractual risk-shifting does not remediate the underlying technical vulnerability or satisfy regulatory mandates requiring direct protection of personally identifiable information.

Accept the risk

Why it fails: Accepting the risk leaves the unencrypted Personally Identifiable Information entirely exposed to regulatory penalties and data breaches, failing to satisfy the mandatory due care required to protect sensitive data. This approach is tempting when remediation costs outweigh potential asset losses or when no technical controls exist, making it the correct choice only after a formal cost-benefit analysis demonstrates that the financial impact of mitigation exceeds the total expected loss from a security incident.

Total number of employees

Why it fails: Counting total employees measures headcount rather than tracking the likelihood of future security failures, rendering it useless for predicting email-borne threats like phishing campaigns. This metric is tempting because workforce size directly dictates the total volume of potential attack surfaces and phishing targets, making it a standard baseline for assessing organizational exposure or licensing requirements. It would be the correct choice when calculating baseline enterprise capacity, resource allocation, or user-license provisioning within Microsoft Entra ID rather than evaluating the ongoing performance and predictive risk profile of an email security control.

Cost of the email license

Why it fails: Licensing expenditure tracks financial overhead rather than operational vulnerability or threat exposure, meaning it fails to measure the likelihood or impact of security failures within the messaging infrastructure. This metric appears deceptively relevant because budgeting directly influences resource allocation for security controls, making financial tracking essential for procurement planning and cost-benefit analysis when organisations evaluate security tool investments rather than operational risk posture.

Number of emails received

Why it fails: Counting the total volume of incoming messages merely quantifies baseline operational traffic rather than measuring security posture, as it fails to reflect malicious intent, threat density, or control failures. This metric appears plausible because organizations frequently track email flow to gauge server load, capacity requirements, or network throughput. It would serve as a valid Key Performance Indicator (KPI) for capacity planning or sizing mail server infrastructure, but it provides zero insight into the efficacy of anti-malware filters or user susceptibility to phishing.

$200,000

Why it fails: This is the original ALE before any risk treatment. Purchasing insurance transfers a portion of that risk, so the residual risk is lower than the original ALE. Stating the full ALE ignores the effect of the insurance policy. Residual risk must reflect the remaining exposure after the risk response has been applied.

$50,000

Why it fails: This is the annual insurance premium, not the residual risk. Residual risk is the portion of loss the organization retains after controls, which here is the deductible amount. The premium is a cost of the risk treatment, not the expected retained loss itself. Confusing premium with residual risk understates the true exposure because the organization still bears the deductible.

$150,000

Why it fails: This figure incorrectly combines the premium and the deductible. The premium is a separate operational cost, not part of the retained loss. Residual risk focuses on the expected loss the organization must still absorb after the control. Adding the premium overstates the residual risk because it double-counts a cost that is already accounted for in the risk treatment budget.

Security Policy

Why it fails: A security policy is a tactical governance instrument used to dictate mandatory technical and administrative controls, such as password complexity rules or access control restrictions, rather than defining an organisation's high-level willingness to accept risk. It appears tempting because it serves as the foundational documentation for enterprise security governance and operational compliance. A security policy would be the correct answer if the question asked to identify the primary mechanism for enforcing baseline security requirements and standard operating procedures across an IT infrastructure.

Business Impact Analysis

Why it fails: A Business Impact Analysis evaluates operational disruption and financial loss resulting from asset failure to determine recovery time and point objectives, rather than defining organizational risk tolerance. It becomes the correct choice when an organisation needs to prioritise IT recovery procedures and quantify downtime thresholds during disaster recovery planning, but it focuses on operational recovery capabilities rather than the strategic governance thresholds that dictate acceptable risk exposure.

Incident Response Plan

Why it fails: An Incident Response Plan focuses purely on operational containment, eradication, and recovery procedures following a confirmed security breach, rendering it useless for establishing overarching organizational risk tolerances. It is tempting because practitioners frequently consult historical incident data when evaluating how much disruption an enterprise can endure. Such a document becomes the correct choice when defining tactical runbooks, communication chains, and technical workflows required to mitigate active cyber attacks and restore normal operations after a compromise.

Protect

Why it fails: Focusing on safeguarding assets through identity management, access control, and data security, this function addresses technical defenses rather than overarching enterprise risk management structures. It appears tempting because robust security controls are foundational to enterprise risk strategies and are frequently audited alongside governance frameworks. This choice would be correct if the assessment target were shifted toward evaluating the implementation of technical safeguards, such as encryption standards or multi-factor authentication policies, rather than the institutional oversight, policies, and legal compliance defined by the Governance component.

Respond

Why it fails: Focusing on the Respond function addresses post-incident activities such as containment, mitigation, and communications rather than structural oversight and risk management policies. This choice is tempting because enterprise risk management often surfaces during crisis management when existing frameworks fail, and it would be the correct choice if the assessment target were incident response planning, containment execution, or post-incident coordination rather than the foundational Governance component of the NIST CSF 2.0.

Recover

Why it fails: Restoration activities and resilience planning following a cybersecurity incident fall under this function, rather than the strategic oversight and policy framework of enterprise risk management. It would be tempting if the question specifically targeted post-incident service restoration and recovery planning metrics. In such a scenario, evaluating restoration capabilities and supply chain resilience during disruptions would make this function the correct choice, but it does not address the foundational policies required for enterprise risk governance.

Identify

Why it fails: While the Identify function addresses asset management and supply chain risks, it focuses on physical and software inventories rather than the overarching policies, legal frameworks, and enterprise risk management structures defined within the NIST CSF 2.0 Governance component. This option remains tempting because practitioners frequently confuse asset identification with strategic oversight, yet Identify would be the correct choice if the question specifically targeted discovering unmanaged hardware, software, and data flows across the enterprise architecture.

Primary Loss Magnitude and Secondary Loss Magnitude

Why it fails: Primary Loss Magnitude and Secondary Loss Magnitude belong entirely to the Loss Magnitude side of the Factor Analysis of Information Risk model, quantifying financial impact rather than frequency. This choice is tempting because these metrics represent the primary outputs of a risk assessment, making them central to the calculation of overall risk exposure. They would be the correct choice if the question asked for inputs required to calculate Loss Magnitude, which encompasses direct losses alongside secondary legal, regulatory, and reputational costs.

Inherent Risk and Residual Risk

Why it fails: Inherent and residual risk measure the total potential exposure before and after controls are applied, rather than evaluating the frequency of threat events. They represent risk magnitude states rather than the specific causal components required by quantitative risk models. This choice is tempting because these terms are foundational metrics for general enterprise risk management and audit reporting, where they are routinely used to evaluate control effectiveness and prioritise governance initiatives across the broader organisation.

Control Strength and Asset Valuation

Why it fails: Control Strength and Asset Valuation belong to traditional qualitative risk assessment methodologies rather than the FAIR model's specific mechanics, making them useless for computing Loss Event Frequency. This choice remains tempting because these metrics are standard components of legacy risk matrices used to prioritise vulnerabilities and determine overall risk magnitude. Asset valuation and control strength would be appropriate inputs when calculating Loss Magnitude or evaluating residual risk in a conventional compliance-driven framework that relies on subjective high, medium, or low categorisations.

Static Application Security Testing (SAST)

Why it fails: Static Application Security Testing analyses compiled source code or binaries for syntax vulnerabilities, meaning it requires written code to function and cannot evaluate abstract architectural patterns, threat models, or logic flaws at the design stage. Although often viewed as an early development phase control, it is tempting because it operates much earlier than dynamic testing or runtime monitoring, making it the correct choice for automating vulnerability detection within code repositories during the implementation phase of the software development lifecycle.

Dynamic Application Security Testing (DAST)

Why it fails: Dynamic Application Security Testing (DAST) evaluates running applications in test or production environments, which means it relies on compiled binaries or active endpoints and cannot inspect pre-implementation architectural blueprints. It is tempting because it is the industry standard for uncovering runtime vulnerabilities and logic flaws exposed only during execution; therefore, it WOULD be the correct choice during the verification phase of the software development lifecycle after the code has been built and deployed to a staging environment.

Penetration Testing

Why it fails: Penetration testing fails to address design-level risk because it is a dynamic assessment technique requiring a functional, compiled application or deployed infrastructure to identify runtime vulnerabilities and exploitable logic flaws, meaning it cannot evaluate abstract architectural blueprints. Security professionals often gravitate towards it because it is the definitive method for validating real-world defensive postures against active threat actors. It becomes the correct choice later in the system development lifecycle during the verification and release phases, once code has been written and deployed into pre-production or production environments.

Acceptance

Why it fails: Purchasing cyber insurance represents a proactive transfer of financial liability to a third party rather than the retention of risk inherent in acceptance. Acceptance involves acknowledging the potential impact of a threat and choosing to absorb any resulting losses without external intervention. This strategy remains the valid choice only when the cost of implementing other controls exceeds the anticipated financial loss, or when the organisation deliberately decides to live with the residual risk after exhausting all other mitigation efforts.

Avoidance

Why it fails: Avoidance requires the complete elimination of the risk by ceasing the specific activity or business process that introduces the threat. Purchasing insurance does not remove the underlying vulnerability or the potential for a cyber incident to occur; it merely transfers the financial impact to a third party. This option appears attractive because it involves proactive risk management, yet it is only the correct strategy when an organisation chooses to discontinue a high-risk project entirely to prevent any exposure to the threat.

Mitigation

Why it fails: Purchasing cyber insurance represents risk transference rather than mitigation, as it shifts the financial burden of a potential incident to a third party instead of reducing the likelihood or impact of the threat itself. Mitigation involves implementing technical controls, such as deploying Microsoft Entra ID conditional access policies, to actively lower the probability of a breach. This option appears attractive because organisations frequently combine insurance with security controls, yet the specific act of buying a policy functions solely to transfer residual risk.

Authorize the system

Why it fails: Authorising the system actually corresponds to the final 'Authorize' step of the Risk Management Framework, where an official grants operational permission after reviewing residual risk, rather than the preceding 'Assess' step dedicated to evaluating control implementation and effectiveness. This option appears attractive because authorisation relies directly upon the assessment results to make its final risk determination, and it would represent the correct choice if the question specifically targeted the formal acceptance and sign-off phase of system deployment.

Define the boundary

Why it fails: Defining the boundary belongs to the 'Categorise' step, where the scope of the information system is established to determine the security categorisation. This option fails because it precedes the 'Assess' phase, which focuses on determining the effectiveness of security controls rather than setting the system's operational perimeter. Candidates often confuse these steps because both activities occur early in the lifecycle, but 'Categorise' is the specific phase where organisational boundaries and system interconnections are formally documented.

Select controls

Why it fails: Selecting controls occurs during the 'Select' step of the RMF, not the 'Assess' step. This option is tempting because practitioners often conflate the two phases when determining the effectiveness of security measures. It represents the stage where organisations identify and choose the specific security controls necessary to mitigate identified risks based on the system's categorisation. While this is a foundational activity for establishing a security baseline, it precedes the 'Assess' phase, which focuses on verifying that those selected controls are implemented correctly and operating as intended.

To notify the public of breaches

Why it fails: Notifying the public of breaches falls under incident response and regulatory disclosure obligations rather than the iterative, stakeholder-focused framework of ISO 31000. This option appears attractive because organisations must indeed communicate during security crises, such as when managing data loss via Microsoft Entra ID logs. However, ISO 31000 risk communication aims to build consensus and inform decision-making throughout the entire risk management process, whereas breach notification is a reactive, legal requirement triggered only after a specific security failure has occurred.

To assign blame for security failures

Why it fails: ISO 31000 focuses on collaborative risk management and stakeholder engagement rather than punitive measures. Assigning blame undermines the transparent culture necessary for effective risk identification and mitigation. This option appears attractive because organisations often conduct post-incident reviews to determine accountability, which is a legitimate activity within incident response frameworks or forensic investigations. However, such activities serve a distinct administrative purpose separate from the consultative communication processes mandated by ISO 31000 to foster shared understanding and risk ownership.

To archive risk records for auditing

Why it fails: Archiving risk records focuses on the retention and storage phase of the risk management lifecycle rather than the interactive, two-way exchange of information required by the ISO 31000 communication framework. While maintaining an audit trail is a critical component of regulatory compliance and historical analysis, it serves a passive documentation purpose. This option represents the 'Recording and Reporting' component of the standard, which would be the correct focus if the question asked about maintaining accountability and historical evidence for external auditors.

Inherent risk before controls

Why it fails: Inherent risk represents the exposure level present before the implementation of any mitigating controls, meaning it reflects raw vulnerability rather than an intentional governance threshold. This option appears tempting because leadership frequently assesses baseline exposure during early risk identification phases, making it the appropriate definition when calculating initial threat impact prior to designing a security architecture.

Zero risk tolerance

Why it fails: Zero risk tolerance implies an absolute posture where no residual threat is permissible, whereas executive leadership explicitly acknowledges that complete eradication of risk is economically and operationally impossible. Zero risk tolerance is tempting because it aligns with a theoretical security-first mindset, making it the correct choice exclusively in ultra-high-consequence scenarios—such as life-critical medical devices or nuclear command systems—where any deviation results in immediate catastrophic failure, rather than standard business governance.

The total budget for security

Why it fails: Confusing risk tolerance with financial resourcing stems from the fact that security funding directly enables mitigation strategies, making budget allocation a primary executive responsibility during annual resource planning. While determining the total budget for security defines the financial envelope available to protect organisational assets, it represents a monetary resource pool rather than a qualitative measure of threat exposure. Acceptable risk specifically denotes the residual threat level management is willing to endure after controls are applied, making financial planning a downstream enabler of risk management rather than the definition of risk appetite itself.

Name of the auditor

Why it fails: Identifying who performed an audit has no bearing on calculating risk severity or urgency, failing to provide the numerical metrics or qualitative impact levels required to sort vulnerabilities by priority. The auditor's identity is designed for accountability, traceability, and compliance tracking, functioning as the correct choice when an organisation needs to establish a clear chain of custody or assign responsibility for past security assessments within governance documentation.

Asset owner's email address

Why it fails: Contact metadata such as an email address facilitates communication and accountability during remediation workflows, making it superficially tempting when mapping responsibilities for action plans. However, this administrative detail provides no metric regarding asset valuation, threat likelihood, or impact magnitude. Consequently, it fails to establish the analytical axis required for risk prioritisation, which relies strictly on quantitative or qualitative evaluation criteria rather than stakeholder contact particulars.

Last modified date

Why it fails: Tracking when a risk entry was last updated helps maintain audit trails and ensure timely reviews, making it a tempting administrative metric for compliance officers seeking to verify governance hygiene. However, a modification timestamp merely records database activity rather than quantifying the business impact, threat likelihood, or residual exposure required for operational risk prioritisation. While this metadata is critical during an internal audit or when investigating stale register entries, it lacks the analytical dimensions needed to rank risks by criticality.

The physical location of their headquarters

Why it fails: Geographical headquarters location is irrelevant for a software vendor because digital supply chain risk depends on operational security, software integrity, and code provenance rather than corporate real estate. This factor is tempting because physical jurisdiction frequently determines compliance obligations and data sovereignty mandates. Therefore, evaluating headquarters location would be the correct choice when assessing compliance with regional data residency regulations or physical site access controls for on-premises infrastructure hosting.

The number of employees at the vendor

Why it fails: Vendor headcount provides no insight into the security posture, software development lifecycle integrity, or supply chain resilience of a critical provider. While an organisation might track employee numbers during procurement to assess financial stability or vendor capacity for scaling support services, this metric fails to identify technical vulnerabilities or malicious code injection risks. Evaluating a critical software vendor requires deep analysis of their security controls and incident response capabilities, rather than simple firmographic data regarding their total workforce size.

The vendor's marketing budget

Why it fails: A vendor's marketing budget measures commercial reach and promotional spending rather than operational resilience, software integrity, or secure coding practices required during a supply chain risk assessment. This metric becomes tempting when evaluating a vendor's market stability, brand recognition, or financial health to determine their long-term viability and commercial longevity as a stable business partner.

Ignore the methodologies and rely on external audits

Why it fails: Outsourcing risk evaluation to external auditors sidesteps the immediate governance requirement to harmonise internal merge processes and maintain operational continuity. Relying solely on external assessments is tempting because independent parties provide unbiased, high-level assurance for regulatory compliance and board-level reporting. In scenarios requiring objective third-party validation—such as certifying compliance against external frameworks like ISO 27001 or preparing for a formal statutory audit—external validation is entirely appropriate, yet it fails here because internal security teams must actively manage and integrate day-to-day risk profiles during corporate restructuring.

Force the smaller entity to adopt the larger one's tool

Why it fails: Mandating a single methodology ignores the necessity of mapping disparate risk appetites and asset valuations across distinct business units, which prevents an accurate unified risk profile. This approach appeals to organisations seeking to minimise operational overhead and standardise compliance reporting during straightforward internal consolidations. It functions effectively when the entities share identical threat landscapes and regulatory requirements, allowing for the immediate centralisation of risk management processes without the need for complex cross-mapping or reconciliation of risk registers.

Keep both and report separately

Why it fails: Maintaining two separate methodologies fragments the organisational risk posture, violating governance mandates for a unified enterprise-wide metric during a merger. This approach is tempting because retaining legacy risk models preserves continuity for existing business units and avoids the immediate political friction of forcing business units to adopt unfamiliar criteria. This strategy WOULD be appropriate when two distinct subsidiaries operate in entirely different regulatory jurisdictions with legally mandated compliance frameworks that preclude a consolidated risk metric.

To calculate the cost of a data breach

Why it fails: Calculating the direct financial losses and remediation expenses of a data breach falls under quantitative risk assessment and forensic accounting, which are separate governance functions focused on post-incident liabilities rather than operational resilience. This choice often appears attractive because organisations frequently conflate financial risk management with continuity planning, and such a calculation would indeed be the correct objective when determining cyber insurance coverage limits, legal liability thresholds, or justifying budget allocations for specific perimeter security controls.

To identify all system vulnerabilities

Why it fails: Identifying system vulnerabilities is the domain of a technical risk assessment or vulnerability scan, which examines software flaws, missing patches, and misconfigurations rather than evaluating operational disruption. This option is tempting because both vulnerabilities and business impacts are vital components of a comprehensive risk management framework. A vulnerability assessment would be the correct choice when attempting to discover entry points that attackers could exploit before those technical weaknesses are mapped to specific business processes.

To configure firewalls for recovery

Why it fails: Configuring firewalls is a network engineering task focused on implementing perimeter security rules and access control lists, whereas a Business Impact Analysis is a strategic management process designed to identify critical organizational functions and the financial losses associated with operational downtime. This option appears tempting because firewall rules must indeed be adapted during a disaster recovery scenario to permit secondary routing paths and secure backup data centres, making firewall re-configuration the correct technical choice when executing network failover procedures rather than assessing business criticality.

Encryption

Why it fails: Encryption functions as a preventative control by ensuring data confidentiality and integrity at rest or in transit, rather than identifying security incidents after they occur. It is often confused with detective measures because it protects sensitive information from unauthorised access, making it the correct choice for scenarios requiring data protection or regulatory compliance. However, it lacks the monitoring or alerting capabilities necessary to detect an active breach or anomalous system behaviour, which is the primary requirement for a detective control.

Firewall rules

Why it fails: Firewall rules function as preventative controls by blocking unauthorised traffic based on predefined access policies before it reaches the internal network. They are tempting because they represent a core security mechanism; however, they actively stop threats rather than identifying them after the fact. This option would be the correct choice if the question asked for a preventative control designed to enforce network segmentation or restrict communication paths between distinct security zones.

Disaster recovery plan

Why it fails: Disaster recovery plans function as corrective controls because they restore operations after a disruption has already occurred, rather than identifying security incidents in real-time. This option appears attractive because it represents a critical component of a comprehensive risk management framework. It would be the correct choice if the question asked for a control designed to facilitate business continuity or restore system availability following a catastrophic failure, as its primary purpose is recovery rather than detection.