Risk Optimization practice questions

Require a formal risk assessment for every sprint cycle.

Why it fails: This will impede development velocity and is often impractical.

Remove risk governance requirements until the project reaches the production phase.

Why it fails: This creates a significant risk gap in the development lifecycle.

Replace the risk register with a daily stand-up meeting for risk tracking.

Why it fails: A register is required for audit and governance accountability, regardless of meeting cadence.

Draft a press release.

Why it fails: Communication is important, but containment comes first.

Identify the person responsible for the incident.

Why it fails: Blame is secondary to business continuity.

Perform a root cause analysis.

Why it fails: This happens after containment.

The specific brand of coffee in the breakroom.

Why it fails: Irrelevant.

The number of printers in the office.

Why it fails: Irrelevant.

Number of open high-severity security patches.

Why it fails: This is a tactical operational metric, not a strategic governance metric.

Average response time for IT service desk tickets.

Why it fails: This is a performance indicator, not a risk-governance metric.

Historical count of phishing emails blocked by the email gateway.

Why it fails: This is a measure of operational threat volume, not strategic risk posture.

A list of all open vulnerabilities categorized by severity.

Why it fails: A vulnerability list by severity is a technical inventory; it omits business impact, likelihood and treatment status, so the board cannot judge residual risk or align spending. It tempts because severity ratings feel objective and actionable. Such lists are the correct artefact for remediation tracking by security teams, not for board risk oversight.

The total number of security incidents reported in the last quarter.

Why it fails: Incident counts are lagging operational metrics that show past events, not forward-looking risk exposure or business impact, so the board cannot prioritise investment from them. They tempt because they are easy to collect and quantify. Incident trends are the correct input for security operations reviews, not board-level risk reporting.

A detailed technical audit report of the firewall configurations.

Why it fails: Firewall configuration detail is operational assurance evidence, not risk information expressed in business terms; the board cannot weigh it against strategic objectives. It tempts because technical audits feel rigorous and concrete. Detailed configuration audits are the correct deliverable for IT assurance and change control, not board risk reporting.

To ensure that all employees have completed security awareness training.

Why it fails: Training completion is a compliance or performance metric, not a risk indicator; it measures activity rather than changes in risk exposure. KRIs track forward-looking risk drivers such as control failures or incident trends. Training metrics suit assurance reporting, not risk monitoring.

To provide a detailed log of all security threats blocked by the firewall.

Why it fails: A KRI is a forward-looking metric tracking risk exposure against thresholds to signal rising likelihood, not a record of past events. A firewall log is retrospective operational data, describing threats already blocked. Logging suits incident investigation and audit trails, but cannot indicate whether a risk is approaching tolerance.

To measure the success of past risk mitigation strategies.

Why it fails: A KRI provides early warning of changing risk exposure, indicating whether risk is rising or falling. Measuring mitigation success is retrospective, which is the role of key performance indicators or post-implementation reviews. KRIs would be chosen when forward-looking risk monitoring is required.

Total Cost of Ownership (TCO) analysis.

Why it fails: TCO analysis totals acquisition and operating costs of an asset over its life, so it captures mitigation cost but excludes the business benefit side of the trade-off. It would be correct for comparing the lifetime cost of competing solutions, not for weighing risk-reduction spend against expected benefit.

Key Risk Indicator (KRI) dashboarding.

Why it fails: KRI dashboards track risk exposure trends against thresholds; they report whether risk is rising or breaching tolerance, not whether mitigation spend is justified by benefit. They would suit ongoing risk monitoring. The stem requires comparing mitigation cost with business benefit, which KRIs cannot quantify.

Business Impact Analysis (BIA).

Why it fails: A BIA identifies critical business processes and the impact of their disruption, typically to set recovery objectives. It quantifies downtime consequences, not the cost of mitigation against benefit. It would be the right choice when determining RTOs and RPOs for continuity planning.

Moving the IT risk management function under the responsibility of the Chief Financial Officer.

Why it fails: Placing IT risk under the CFO subordinates it to financial reporting priorities, leaving technology risk outside the enterprise risk function's governance. It is tempting because CFO ownership can raise funding and board visibility, and would fit an organisation where IT risk is purely a financial-control and audit concern.

Requiring IT to report risks directly to the Chief Risk Officer on a weekly basis.

Why it fails: Weekly reporting to the Chief Risk Officer creates a communication channel, not integration; IT still assesses and manages risk using its own criteria and scales. It is tempting because direct CRO escalation genuinely improves oversight, and would suit an organisation needing faster visibility of critical IT exposures.

Mandating that IT uses the same risk assessment software as the finance department.

Why it fails: Sharing finance's risk assessment software imposes a common tool, not a common risk taxonomy, appetite or reporting line, so IT risks stay siloed from ERM. It is tempting because standardising tooling genuinely helps consolidate registers, and would suit an organisation whose only integration gap is fragmented data storage.

Implement excessive controls regardless of project cost.

Why it fails: Applying controls without regard to cost ignores the risk-based, cost-justified treatment the framework expects; residual risk should be reduced to within appetite at proportionate expense. This approach would fit only where regulation mandates fixed controls irrespective of financial impact.

Direct the IT team to lower the risk by reducing project scope.

Why it fails: Reducing scope alters the project's deliverables rather than treating the risk itself, and may forfeit the competitive advantage the project exists to deliver. It is tempting because scope reduction genuinely lowers exposure, and would be right where the risk is acceptable once trimmed and the business outcome survives intact.

Cancel the project immediately to maintain compliance.

Why it fails: Cancelling forfeits the competitive advantage the project delivers, and risk appetite permits accepting or mitigating risk rather than mandating termination. Immediate cancellation is correct only when residual risk cannot be reduced to within appetite and the business benefit does not justify acceptance.

Performing an annual penetration test on the provider's infrastructure.

Why it fails: An annual penetration test assesses technical vulnerabilities at a point in time; it does not evaluate whether the provider's risk management processes align with the enterprise's risk appetite. It is tempting because it provides assurance evidence, making it suitable for validating specific controls rather than ongoing governance alignment.

Mandating a SOC 2 Type II report review on an annual basis.

Why it fails: A SOC 2 Type II report covers the provider's controls over a period, but it attests to the provider's own criteria, not alignment with the enterprise's stated risk appetite. It is tempting because it offers independent assurance, making it suitable for vendor due diligence rather than continuous risk-appetite governance.

Establishing clear service level agreements (SLAs) with penalty clauses for downtime.

Why it fails: SLAs with penalty clauses govern availability and performance commitments, not the provider's internal risk management alignment with enterprise risk appetite. They are tempting because they enforce measurable outcomes, making them suitable for service continuity guarantees rather than governance of risk practices.

Update the enterprise risk management policy to include the new risks.

Why it fails: Rewriting the enterprise risk management policy addresses documentation, not the live deviation from approved risk appetite; the board must first evaluate and direct a response to the current exposure. Policy revision is tempting because governance work often produces documents, and would be correct once a response decision has been agreed and needs codifying.

Instruct the IT department to stop all new projects until the risk is lowered.

Why it fails: Halting all new projects is a blanket operational freeze that exceeds the board's remit and ignores the risk response options available; the deviation must first be escalated and assessed against tolerance. Freezes are tempting as decisive-sounding action, and would be correct only after a formally declared risk event requiring immediate containment.

Adjust the risk appetite levels to match the current risk profile.

Why it fails: Raising the risk appetite to match the observed profile reverses the control relationship, legitimising exposure rather than bringing it back within tolerance; appetite is set by the board and drives decisions, not the reverse. Realignment is tempting when appetite looks unrealistic, and would be correct only through a deliberate, documented board reappraisal.

Draft the IT risk register for department heads.

Why it fails: A risk register documents identified risks and owners; it does not establish the appetite that should drive those entries. Drafting it first inverts the sequence, capturing departmental risks before strategic objectives define acceptable tolerance. It would be correct once appetite is agreed and risk identification begins.

Conduct a technical vulnerability scan of all production servers.

Why it fails: A vulnerability scan enumerates technical weaknesses on hosts; it produces findings, not a statement of how much risk the enterprise will accept in pursuit of strategy. Scanning is correct during operational risk assessment, after appetite and scope are set, not as the alignment starting point.

Implement an automated GRC risk dashboard.

Why it fails: A GRC dashboard visualises risk data already defined and collected; automating reporting cannot create the appetite thresholds it displays. It is correct later, once appetite, metrics and data sources exist, to monitor alignment continuously rather than establish it.

The cost of the hardware that needs to be replaced.

Why it fails: Hardware replacement cost captures only one asset class, ignoring business-process disruption, revenue loss, regulatory penalties and reputational damage that define true impact. It is tempting because tangible asset valuation is easy to quantify, and would suit a narrow asset-replacement budget exercise rather than enterprise risk impact assessment.

The percentage of the IT budget consumed by the incident.

Why it fails: Budget consumption measures financial cost, not the business consequence of a risk event, so it ignores operational, regulatory and reputational impact. It would be correct when prioritising IT spend, but risk impact assessment requires evaluating effect on business objectives and stakeholders.

The number of hours required to restore the system.

Why it fails: Restoration hours measure downtime duration, not the business consequence of that downtime; an hour of outage in payroll differs vastly from one in trading. It is tempting because recovery time is measurable and feeds RTO planning, and would be the right metric for setting recovery objectives, not for assessing impact severity.

To automatically reduce the cost of IT security.

Why it fails: Maturity models assess and improve risk processes; they do not automatically lower security spend, which depends on controls chosen and risk appetite. Cost reduction is a possible outcome of better-targeted controls, but the model's purpose is capability assessment, not guaranteed savings.

To force all departments to use the same IT tools.

Why it fails: Standardising tools across departments is a technology governance decision, not an output of assessing risk maturity. A maturity model evaluates process capability and identifies gaps; tool consolidation would be the correct approach when the goal is reducing platform sprawl.

To determine exactly how many employees are needed in the risk department.

Why it fails: A risk maturity model benchmarks capability against defined levels and guides improvement priorities; it says nothing about headcount numbers for a risk department. Staffing models derived from workload would be the correct tool when the objective is sizing the team.

The Network Engineer.

Why it fails: A network engineer implements and maintains connectivity, holding no enterprise-level risk ownership or mandate to accept risk on the organisation's behalf. The role is tempting because engineers identify and remediate technical vulnerabilities daily, but that operational mitigation differs from formally accepting residual IT risk, which accountable executives or the board must do.

The external auditor.

Why it fails: External auditors provide independent assurance over controls and reporting; they examine and report, but hold no delegated authority to accept enterprise IT risk. The temptation arises because auditors assess risk and issue findings, yet acceptance rests with accountable executive management or the board, who own the risk on the organisation's behalf.

The IT Security Manager.

Why it fails: An IT security manager identifies, assesses and mitigates IT risk, but acceptance at enterprise level requires business accountability beyond the security function. It is tempting because security managers own the risk register and recommend treatments, yet final acceptance belongs to executive management or the board, who bear the consequence of residual risk.

The location of the software vendor's headquarters.

Why it fails: Headquarters location alone does not determine the legal, regulatory or data-residency obligations that apply to the engagement. It is tempting because jurisdiction affects compliance, and would be relevant when assessing which laws govern the vendor's operations or where data may lawfully be stored and processed.

The number of employees working for the software vendor.

Why it fails: Headcount says nothing about the vendor's security controls, data handling or resilience, which drive third-party risk exposure. It is tempting because a large workforce suggests stability and capacity, and would be relevant when assessing the vendor's ability to scale delivery or provide ongoing support.

The brand reputation of the software vendor.

Why it fails: Brand reputation is a perception, not evidence of control effectiveness, contractual obligations or data protection posture. It is tempting because a strong public image implies trustworthiness, and would carry weight when selecting a vendor for marketing credibility or customer confidence rather than for governance risk assessment.

Accept the risk because the project is strategically important.

Why it fails: Accepting a moderate breach risk contradicts the stated low appetite, so governance must direct treatment rather than tolerate it. Acceptance suits risks already inside appetite. Strategic importance does not override a board-set appetite; the correct action escalates for mitigation, transfer or rejection.

Lower the 'low' appetite threshold to 'moderate'.

Why it fails: Altering the appetite threshold to legitimise the project inverts governance: appetite is set by leadership and drives decisions, not the reverse. Thresholds change through formal risk-appetite review, not per-project convenience. Lowering appetite is correct only when strategy genuinely shifts, not to accommodate one initiative.

Document the risk in the risk register and ignore it for now.

Why it fails: Recording and deferring leaves a moderate breach risk unaddressed against a low appetite, breaching governance obligations. The register tracks risks; it does not authorise inaction. Documentation alone suits risks already within appetite or formally accepted after treatment decisions.

The system administrator's patch management reports.

Why it fails: Patch management reports cover only technical vulnerabilities on managed endpoints, omitting governance, compliance, financial and strategic risk dimensions the board requires. They are tempting because they evidence operational control effectiveness, and would suit an IT operations or vulnerability review, but not an enterprise-wide risk posture summary.

The IT department's operational incident logs.

Why it fails: Operational incident logs record individual events and their resolution, not aggregated risk exposure against business objectives, so they cannot evidence enterprise risk posture to a board. They are tempting because incident data feeds risk registers and would suit an operational review of recurring failures, but board-level posture requires the enterprise risk register.

The annual budget allocation for IT security.

Why it fails: Budget allocation shows intended security spending, not actual risk exposure or control effectiveness, so it cannot summarise posture. It is the right source for financial planning and investment justification discussions, not for risk posture reporting.

Moving all data to a public cloud provider.

Why it fails: Public cloud migration relocates infrastructure and operational responsibility but leaves the enterprise accountable for data, compliance and residual risk under shared responsibility. It is tempting because providers carry availability risk, yet no contractual liability shifts to them, so this is not risk transfer.

Outsourcing the entire IT department to a third-party managed service provider.

Why it fails: Outsourcing transfers operational activity to a provider while accountability, governance and residual risk stay with the enterprise under the contract. It is tempting because managed services shift day-to-day responsibility, yet the board retains ownership of the risk, so this is not true transfer.

Signing an indemnity clause in a software license agreement.

Why it fails: An indemnity clause allocates liability for specified losses to the vendor, but it does not transfer the underlying risk itself, which remains with the enterprise. It is tempting because indemnities are contractual risk-allocation tools, yet they address financial consequence rather than the risk event.

To simplify the budget process for IT.

Why it fails: Risk appetite expresses how much risk the organisation will accept in pursuit of objectives, which sets the threshold for selecting responses; it does not streamline IT budgeting. Budget simplification is a financial planning concern, so this option would fit a question about aligning IT spend with funding cycles.

To automatically approve all low-impact risks.

Why it fails: Risk appetite sets tolerance thresholds that inform response selection; it does not automatically approve low-impact risks, which still require assessment and treatment decisions. Automatic approval would be the outcome of defined acceptance criteria or a risk register rule, not of appetite itself.

Because the government requires it by law.

Why it fails: It is a governance best practice, not always a law.