Risk Optimization practice questions

Number of open high-severity security patches.

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

Average response time for IT service desk tickets.

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

Historical count of phishing emails blocked by the email gateway.

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

A list of all open vulnerabilities categorized by severity.

Why wrong: This is too technical and lacks business context.

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

Why wrong: This is a lagging indicator and does not represent risk exposure.

A detailed technical audit report of the firewall configurations.

Why wrong: This is an operational detail irrelevant to board-level governance.

To ensure that all employees have completed security awareness training.

Why wrong: This is a compliance metric.

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

Why wrong: This is a log management function.

To measure the success of past risk mitigation strategies.

Why wrong: This describes a Key Performance Indicator (KPI) or audit metric.

Total Cost of Ownership (TCO) analysis.

Why wrong: TCO focuses on cost, not risk-adjusted value.

Key Risk Indicator (KRI) dashboarding.

Why wrong: KRIs monitor risk levels, they do not calculate investment trade-offs.

Business Impact Analysis (BIA).

Why wrong: BIA identifies criticality, not the economic trade-off of mitigation.

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

Why wrong: Organizational structure does not guarantee process integration.

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

Why wrong: Frequency of reporting does not equate to effective integration.

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

Why wrong: Software is secondary to the process and communication framework.

Implement excessive controls regardless of project cost.

Why wrong: This would likely destroy the project's return on investment.

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

Why wrong: Changing scope without board input risks failing to meet the original business objective.

Cancel the project immediately to maintain compliance.

Why wrong: Canceling ignores the potential strategic value; governance is about balanced decision-making.

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

Why wrong: Testing the provider's infrastructure often violates cloud provider terms of service.

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

Why wrong: While important, this is a point-in-time check, not continuous alignment.

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

Why wrong: SLAs address availability, not broader enterprise risk alignment.

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

Why wrong: Updating policy does not address the active variance from the approved threshold.

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

Why wrong: This is a reactionary measure that lacks a formal governance process.

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

Why wrong: Changing appetite to fit the status quo is poor governance; the risk must be mitigated or accepted formally.

Draft the IT risk register for department heads.

Why wrong: The risk register is an output of the risk management process, not the starting point.

Conduct a technical vulnerability scan of all production servers.

Why wrong: This is a tactical operational task, not a strategic governance one.

Implement an automated GRC risk dashboard.

Why wrong: Tooling is secondary to defining the governing parameters.

The cost of the hardware that needs to be replaced.

Why wrong: Hardware cost is usually a minor part of the overall business impact.

The percentage of the IT budget consumed by the incident.

Why wrong: Budget consumption is an operational metric.

The number of hours required to restore the system.

Why wrong: Recovery time is a metric, but the impact is measured in business consequences.

To automatically reduce the cost of IT security.

Why wrong: Maturity may increase costs initially, but it improves effectiveness.

To force all departments to use the same IT tools.

Why wrong: Standardization is a benefit, but the primary goal is improving risk management capability.

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

Why wrong: Staffing levels are not the goal of maturity assessment.

The Network Engineer.

Why wrong: This is a technical role with no governance authority.

The external auditor.

Why wrong: Auditors review the risk, they do not accept it.

The IT Security Manager.

Why wrong: They manage the risk, but do not own the enterprise risk.

Require a formal risk assessment for every sprint cycle.

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

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

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

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

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

The location of the software vendor's headquarters.

Why wrong: Location is secondary to the control environment and data sensitivity.

The number of employees working for the software vendor.

Why wrong: Company size does not necessarily indicate risk level.

The brand reputation of the software vendor.

Why wrong: Reputation is subjective and does not measure operational risk.

Accept the risk because the project is strategically important.

Why wrong: Risk acceptance requires formal board approval if it exceeds appetite.

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

Why wrong: Changing appetite to match project risk is not a valid governance practice.

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

Why wrong: Ignoring a risk that exceeds appetite is a failure of governance.

The system administrator's patch management reports.

Why wrong: These are technical performance reports, not risk posture documents.

The IT department's operational incident logs.

Why wrong: These are too granular for the board.

The annual budget allocation for IT security.

Why wrong: Budget is an input, not a risk output.

Moving all data to a public cloud provider.

Why wrong: Cloud providers generally have limited liability for data breaches.

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

Why wrong: This transfers operational activity but often retains the residual risk/liability.

Signing an indemnity clause in a software license agreement.

Why wrong: Indemnity clauses are rarely enforceable against major software vendors.

To simplify the budget process for IT.

Why wrong: Budgeting is a secondary activity to risk response.

To automatically approve all low-impact risks.

Why wrong: Risk management requires monitoring, even for low-impact risks.

Because the government requires it by law.

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

The risk remaining after all security patches are installed.

Why wrong: This is residual risk.

The risk that is accepted by the board of directors.

Why wrong: This is accepted risk.

The risk that has been mitigated by insurance.

Why wrong: This is transferred risk.

The specific model of routers used in the network.

Why wrong: Technical specifications belong in procedures, not policy.

The salary structure for IT staff.

Why wrong: HR policies are separate from IT risk policy.

A detailed list of all system passwords.

Why wrong: This is a security violation, not a policy component.