Certified: The CISM Prepcast

Welcome to The Bare Metal Cyber CISM Prepcast. This series helps you prepare for the exam with focused explanations and practical context.
Selecting a response to identified risk is a critical step in the risk management lifecycle. Risk response is the process of deciding how to treat risks once they’ve been assessed. There are four standard options: mitigate, accept, transfer, or avoid. While each response category has its place, this episode will focus specifically on the first two—mitigation and acceptance. The decision to apply either must align with the organization’s overall risk appetite, impact thresholds, and strategic objectives.
Risk response decisions should never be arbitrary. They must be documented clearly, with a rationale that explains why a particular action was chosen. This documentation supports accountability and ensures readiness for audits or reviews. Risk decisions reflect the maturity of an organization’s governance processes. If decisions are undocumented or inconsistent, it becomes difficult to demonstrate that risks are being managed effectively.
Mitigation is the most commonly used risk response. It involves reducing either the likelihood or the impact of a given threat through the implementation of controls. These controls may be technical—such as encryption, firewalls, or monitoring systems. They may also be administrative, such as training programs, access policies, or segregation of duties. Physical controls—such as locks, cameras, and environmental protections—may also play a role.
Effective mitigation strategies must be tailored to the specific risk. A control that works in one context may not be suitable in another. Controls must also be proportionate. Over-investing in low-risk areas diverts resources from higher-priority concerns. Prioritization often depends on cost-benefit analysis and resource availability. Timely execution and consistent enforcement are key to successful mitigation. Controls that are poorly implemented or not followed are ineffective, even if they exist on paper.
Designing strong mitigation controls requires attention to detail. Controls should be linked directly to the root cause of the risk. For example, if a risk stems from unauthorized access, then authentication or access monitoring should be considered. Each control should be mapped to a specific risk scenario or threat vector. This mapping helps track whether the control addresses the actual cause rather than just a symptom.
In many cases, layered controls—also known as defense in depth—are appropriate. This means applying multiple, overlapping safeguards that reduce the chance of failure. Before implementing controls, feasibility must be confirmed. A solution that cannot be integrated without disrupting business operations may not be viable. Every control should include a plan for ongoing monitoring and performance measurement. This ensures that the control continues to operate as intended over time.
While mitigation reduces risk, it does not eliminate it. That brings us to acceptance. Risk acceptance means formally deciding to tolerate a known level of residual risk. This decision is typically made when the cost of mitigation exceeds the potential benefit, or when the risk falls within the organization's defined tolerance. Acceptance is also common for low-impact or low-likelihood risks, especially when resources are limited.
However, acceptance is not an excuse for inaction. It must be documented and justified. Leaders must understand the implications of tolerating the risk and agree that doing so is appropriate. Risk acceptance requires formal sign-off—typically from risk owners or executive leadership, depending on the severity. Accepted risks must also be revisited periodically. A risk that was acceptable last year may no longer be tolerable due to changes in the threat landscape or business priorities.
Selecting between mitigation and acceptance requires careful evaluation. Likelihood and impact scores should be consulted, ideally using the organization’s standardized risk matrix. Regulatory and legal requirements must also be considered. Some risks cannot be accepted due to mandatory compliance obligations. Available resources—including funding, personnel, and time—play a role. If mitigation cannot be implemented effectively, acceptance may become a temporary decision while longer-term solutions are explored.
It’s also important to determine whether current controls already bring the risk within acceptable levels. If so, additional mitigation may not be necessary. Involving business owners in these decisions is critical. They are often best positioned to assess operational consequences, reputational impact, and service disruptions. Their perspective helps ensure that the decision reflects both technical and business realities.
Governance bodies play a central role in overseeing risk decisions. Risk owners are responsible for recommending how each risk should be treated. However, decisions involving high-impact or strategic risks may require review and approval by security steering committees or enterprise risk councils. Executive-level endorsement is often necessary for risks that affect financial performance, customer trust, or regulatory standing.
All decisions must be recorded in the organization’s risk register. This includes the treatment strategy selected, the rationale, the approving authority, and any conditions attached. The register serves as a historical record and supports internal or external audits. Audit trails must also reflect how the decision was made, who was involved, and what information was considered. Transparency in risk decision-making supports accountability and maturity.
Once a risk treatment decision has been made, it must be communicated. Stakeholders need to understand not just what action will be taken, but why. For mitigation efforts, timelines, required resources, and anticipated outcomes should be provided. If a risk is accepted, that status should be clearly disclosed. The level of residual risk—what remains after mitigation—should also be made visible.
Updates should be communicated using structured reports. Dashboards, scorecards, and executive summaries help ensure that leadership remains informed. Stakeholders must also understand the trade-offs involved. Choosing not to mitigate may free resources for other priorities, but it also carries consequences. Clear, consistent communication helps build trust in the security program and fosters better alignment across departments.
Monitoring the effectiveness of implemented controls is just as important as designing them. Every mitigation effort should have defined performance metrics and thresholds. These may include indicators such as failed login attempts, system uptime, or data leakage detection rates. Regular control testing ensures that the safeguards are operating as intended. Internal audits may also be used to validate documentation, evidence, and implementation quality.
Incidents and near misses provide real-world feedback. If a control fails to prevent or detect an event, that information must be used to improve future controls. Threat evolution and business changes can also affect control relevance. What worked last year may not be effective today. Non-performing controls should be escalated for reevaluation. In some cases, redesign or replacement is necessary to maintain a secure posture.
Accepted risks must also be revisited. Set a regular schedule to review all risks marked for acceptance. Risk conditions change—new threats may arise, impact levels may shift, or new controls may become available. Technological innovation may also reduce mitigation costs, making previously accepted risks easier to treat. Business priorities evolve, and strategic relevance must be reconsidered.
Revalidating accepted risks helps ensure that tolerances remain aligned with current governance expectations. Document all reassessment outcomes. Even if the risk remains accepted, the rationale must be updated. This practice reinforces accountability and demonstrates that risk ownership is active—not passive. Continuous review is a sign of program maturity and responsiveness.
Risk response must be integrated into the broader security program. This includes embedding risk treatment workflows into the organization’s project management, budgeting, and compliance systems. Treatment status—whether mitigation is complete, in progress, or deferred—should be reflected in dashboards and governance reports. This visibility ensures that leadership can track progress and allocate support where needed.
Security, compliance, and business teams must coordinate efforts. For example, a project that introduces a new vendor may require risk treatment decisions that span across departments. Controls selected for mitigation must be built into project plans and verified upon completion. Risk response is not an isolated event. It is a dynamic, ongoing discipline that reflects how the organization interprets, engages with, and acts on risk information.
Thanks for joining us for this episode of The Bare Metal Cyber CISM Prepcast. For more episodes, tools, and study support, visit us at Bare Metal Cyber dot com.