CISM EXAM PREP - Domain 2B - Risk Response

Welcome, or welcome back, to the CISM Exam Prep Series. So, building on our discussion of risk assessment in our previous installment, here in Domain 2, Part B, we'll focus on information security risk response. We'll talk risk treatment options. We'll unpack the categories and functions of the security controls used to address the risks we identify, before discussing risk ownership versus control ownership. We'll have a look at continuous risk monitoring and reporting, and we'll talk about how changes in the threat landscape of the business sometimes trigger risk response activities, sometimes urgently. So, and finally, we'll look into the essential elements of risk management documentation. And to that end, we'll cover exam topics with anecdotes, where I can, for how these situations play out in the real world. Let's dig in.

[Music]

And in this installment of the CISM Exam Prep Series, we're going through every topic in the official exam syllabus for Domain 2, Part B, Information Security Risk Response. And while you may know me for my exam prep content here on YouTube, in my 9-to-5, I'm a cybersecurity strategist and a VC for a regional bank, where I'm exercising my cybersecurity knowledge every day, like that which you'll find here on the CISM exam. More importantly, last year, I helped thousands achieve cybersecurity certifications like the CISSP, CCSP, and the Security Plus exams, and I'm bringing that proven formula to you here with the CISM exam. As with all my exam prep courses, you'll find a PDF copy of this presentation available for you in the video description to leverage in your exam preparation as you require. You'll also find a clickable table of contents available in the video description, and it should appear automatically on your YouTube video timeline.

Domain 2 is focused on information risk management, and as with all four domains of the CISM exam, the domain is divided into a Part A and a Part B. Today, we're focused on Domain 2, Part B, which is Information Security Risk Response. And Part B is broken into three sections: Risk Treatment and Response Options, Risk and Control Ownership, and finally, Risk Monitoring and Reporting. And this is actually where we'll also unpack the essentials of risk management documentation. But we see a logical flow here from a process perspective, as we do with all the domains. We covered risk assessment in the previous installment, and now we'll move into risk response. Logically, the next step.

Now, there are several supporting tasks that align to Domain 2, Part B, of the 37 total we see listed in the syllabus. So, number nine is: Compile and present reports to key stakeholders on the activities, trends, and overall effectiveness of the information security program. So, really digging into the what, when, who, and why of reporting. Task 22: Participate in or oversee the risk identification, assess, and risk treatment process. So, knowing the core process to identify, assess, and respond to risk. Number 24: Identify, recommend, or implement appropriate risk treatment and response options to manage risk to acceptable levels based on organizational risk appetite. So, this is really about understanding how risk appetite affects risk response. Task 25: Determine whether information security controls are appropriate and effectively manage risk to an acceptable level. So, really balancing cost and security at a level appropriate to the risk. Task 27: Monitor for internal and external factors that may require reassessment of risk. So, here it's really about remembering that risk may be influenced by forces both inside and outside the organization. And finally, 28: Report on information security risk, including non-compliance and changes in information risk, to key stakeholders to facilitate the risk management decision-making process. Basically, right time, and in the right tone and form, and the right people in terms of targeting our communication.

So, here in Part B, we'll start with 2B1, which is Risk Treatment and Response Options. We'll begin with a look at determining risk capacity and acceptable risk. So, we're going to revisit the risk boundaries we looked at in our previous session. We'll talk through risk response options, risk acceptance framework. We're going to revisit inherent and residual risk in the context of our risk response, controls, control objectives, and control effectiveness. I really like the controls discussion; this is an interesting topic, and it's going to set the stage for control selection in Domain 3. Legal and regulatory requirements, and in the vein of legal and regulatory requirements, I want to have a discussion with you about compliance as a business decision. This is an interesting real-world topic. And then finally, cost-benefit analysis, finding that balance between cost and benefit relative to the risk we're addressing. The CISM exam places a lot of emphasis on cost-effective controls, so I'd like to quantify that for you here.

So, as we add security controls, the cost of our controls rises, of course, but at the same time, our cost of losses drop as that level of control is increasing. And what we need to do is keep an eye on our total risk-rated cost and make sure that we keep the cost of our controls beneath the cost of the losses we are attempting to prevent. So, to say it another way, the goal of risk treatment is to find a balance where risk is reduced to an acceptable level without incurring costs that exceed the value of the risk reduction. So, what that cost to level of control diagram is showing is that as you increase the security controls, you generally reduce risk more effectively, but your costs go up. You need more tools, more staffing, more processes, etc. And if you apply too few controls, your cost is going to be lower, but your exposure may be unacceptably high. It may cross that acceptable risk boundary we talked about in our previous session. And if you apply too many controls, you might drive cost to a point where the benefit of further risk reduction is not worth the additional expenses. So, organizations aim for balance, a level of control that brings risk to an acceptable level, aligned with the organization's risk appetite, without overspending. Bottom line: Beyond a certain point, extra controls become disproportionately expensive relative to the added risk reduction. That's your takeaway.

So, let's revisit this in the context of the risk boundaries we looked at in our previous session. So, risk appetite is the amount of risk the organization is willing to take on across all assets. Risk tolerance is the amount of risk the organization will accept for a specific threat or asset pair. So, this is the amount of variance the organization is willing to accept for a specific threat-asset pair. And risk capacity is the maximum amount of risk the organization can absorb and still expect to survive. And the risk appetite sets the boundary for the amount of risk the organization can accept in a specific case and in the aggregate. So, remember, risk appetite is the org's willingness to take on risk. Risk tolerance is the acceptable variation. And risk capacity is the maximum bearable risk. To put it simply, and at the end of the day, risk acceptance should not exceed risk appetite, but it must not exceed the organization's risk capacity. And that's where risk analysis methods like quantitative risk analysis, especially, will allow us to find that cost-effective point.

So, risk treatment is the organization's response to risk. And we have four options here. There is risk avoidance, where the organization changes business practices to completely eliminate the potential that a risk will materialize. So, this can negatively impact business opportunities because the organization might avoid certain business opportunities to avoid the risk that that opportunity brings. Risk mitigation, perhaps the activity we think of most often, is the process of applying security controls to reduce the probability or magnitude of a risk. So, when we talk about inherent risk and residual risk, inherent risk is the risk that exists before we apply security controls, and residual risk exists after we apply security controls. Residual risk is that risk that remains after mitigation. There's risk transference, which shifts some of the impact of a risk from the organization experiencing the risk to another entity. Cyber insurance is a top-of-mind example there. Risk acceptance is where the organization deliberately chooses to take no other risk management strategy, in other words, take no action, and to simply continue operations as normal in the face of a risk. So, this is often used when the cost of mitigation is greater than the cost of impact. So, you will be expected to know these concepts and be ready to recognize examples on the exam.

So, it's important that the organization establishes a framework for when risk acceptance should be allowed. It defines when and how a risk can be accepted, including the approval process, documentation requirements, the reporting line, which stakeholders are informed. It ensures that accepting risk is a conscious, well-governed decision rather than an ad hoc or unintentional decision. So, we see risk acceptance in a couple of specific scenarios: when an identified risk is within the organization's tolerance level, so we're keeping acceptance within the risk appetite, and for a specific threat-asset pair within tolerance. And when mitigating is not cost-effective or otherwise justified. So, acceptance must be formally documented, ensuring accountability for any potential consequences of accepting that risk. And without documentation, accountability is difficult, right? It becomes one person's word against another.

So, in terms of reassessment and final acceptance of risk, there are a few factors we need to think about: cost and effectiveness of the potential controls. Are they within the cost-effective boundary? And are they going to be effective in actually reducing the risk? Acceptable levels of impact, organizational culture and maturity, are regulatory and compliance requirements. We may have external requirements that guide our actions, and our risk appetite and stakeholder strategy. So, we should already have guidance in writing from the top at this point as to the organization's risk appetite. And uncertainty in the threat or asset environment. So, thinking through questions like, "What is the worst that could happen?" And acceptable risks have to be monitored to confirm that existing controls remain effective, and that our risk remains within limits, and that no new risk conditions arise that increase the risk. And we need to take a holistic view of this decision. Certainly, we're examining the tangible impacts to our critical assets, but we also need to think about the intangible impacts, our reputational harm, for example, any external obligations that we're subject to, such as GDPR privacy regulations. So, it may be very expensive to secure our users' sensitive data in our application, but at the end of the day, the reputational harm if we fail to do so and we have a data compromise is going to be much greater than the cost of any protections we put in place, any controls we apply. And external obligations like GDPR can open the organization to massive fines that can wipe out any and all profits.

So, touching again on the two types of risk you want to be familiar with in order to make a competent risk treatment: there's inherent risk, the level of risk in the absence of any controls or mitigation effort, so the risk that exists before we take action. And then the residual risk, the risk that remains after we have applied mitigating controls. The goal is to ensure that the residual risk that remains after application of the appropriate security controls is equal to or less than the organization's threshold for acceptable risk, allowing us to accept the risk that remains safely. So, impact refers to the potential magnitude of harm, be that financial, reputational, operational, the harm that might result of a risk materializes. And it's important to remember that a single risk can impact multiple aspects of the organization. It can touch our finances, our operational processes, the reputation of the business. So, remembering that one risk can touch multiple areas, and not just in a tangible way, also intangible elements like reputation or strategic. So, perhaps the organization goes all-in with a single public cloud provider, and we have cost increases or security issues there. If we build ourselves into a corner where migration is difficult, if we're locked into that vendor, that's a strategic risk we need to think about. And different processes may have different levels and types of risk that they bring. So, we need to scope our efforts here to ensure that the control addresses the right areas, the important areas, the critical areas. And to avoid too much redundancy. Certainly, overlap is going to be a fact of life in a layered approach, but we want to avoid too much overlap because that represents wasted spending. And if we leave gaps unaddressed risks, then we've shifted too far the other direction, attempting to control costs.

So, there are also compliance implications. So, when a process or environment is found to be non-compliant, we have to evaluate the consequences as an organization. And if the cost of compliance is deemed too high, there are some options management can consider: accepting the risk of non-compliance if non-compliance is less expensive and acceptable in terms of its impact, adjusting operations, so adjusting our operations to make sure that we are compliant in a cost-effective way. But if regulations are mandatory and non-negotiable, like the GDPR privacy obligations, and I say mandatory and non-negotiable because they are an element of the GDPR regulation, but the fines that come with non-compliance are massive, and the reputational impact as well, at that point, the organization has to chart a course to compliance. And that may mean going back and adjusting operations, for example. It may mean adjusting the architecture of an application. So, compliance is manageable from a cost perspective.

So, let's talk through the various aspects of impact we should be familiar with. So, impact is the consequence of a threat exploiting a vulnerability successfully. It represents the harm or loss resulting from a security incident. Impacts can be direct, like financial, they can be indirect, like reputational, and we need to quantify that impact. So, we looked at the three methods of risk analysis in our previous session. So, our impact assessment can be qualitative, using terms like minor, major, catastrophic, or they can be quantitative, where we're assigning monetary values. And as we get into more complex risk scenarios, getting down to that dollar figure becomes more important. Direct financial losses are often easier to quantify. Lost revenue, legal costs are a bit easier to put a dollar figure on. The indirect impacts, like reputational damage, loss of customer trust, that can be challenging to quantify, but they're very important to consider. As I mentioned in a previous session, I can think of a fast-food chain that exists here nationally in the United States, and they had some severe reputational damage all the way back in the 1990s that sticks with me to this day, though I can't tell you exactly what happened within that business that caused me to no longer trust their reputation. And many others are in exactly that same stance as I am.

Then there are the types of impacts: so, financial, direct loss of money, criminal or civil liability, reduction in share value. Reputational, that's the loss of reputation, goodwill, image, breach of confidence or privacy with our customers. Or operational, loss of a business opportunity, reduction in operational efficiency, disruption in operational processes. Then legal, non-compliance with laws and regulations that can result in penalties. And when we're going through that acceptance decision process, we need to know what those penalties may be in the end. So, our impact analysis methods, we can look at a business impact analysis, which is a common way to identify and assess potential impacts to the business because the BIA considers factors like the criticality of the assets, sensitivity of information, and potential disruptions to business operations. So, bottom line, a business impact analysis can help set priorities and provide some guidance on where to focus our risk assessment effort. And then we need to prioritize. So, higher impact risks on critical assets require more attention and resources for mitigation. An impact analysis also informs business continuity planning efforts that can tell us where we need to build resilience and redundancy into our infrastructure, into our services. And it helps establish recovery time objectives and recovery point objectives that tell us how long we can stomach being down and how much data we can lose in the recovery process, and other critical parameters for restoring business back to normal operations.

Now, let's dig into controls. So, a control is any procedure, practice, process, policy, standard, or technology that serves to regulate an activity or behavior. The objective of a control is to reduce or eliminate risks. And controls, at their most basic level, can be preventive, detective, or corrective in nature. We'll get to that in a moment. And there are three categories of security controls you should be familiar with and know how to recognize: technical controls, also called logical controls, that involve the hardware or software mechanisms used to manage access; the technology. Administrative controls, these are policies and procedures defined by the organization, security policy, or other regulations and requirements. And then physical controls, items you can physically touch, controls in the physical world. Let's look at examples of both breakdowns I mentioned here.

So, controls are implemented to prevent unauthorized access, ensure confidentiality, integrity, and availability, protecting the CIA triad, detecting and responding to security incidents, meeting compliance requirements. So, I said they can be preventive, detective, or corrective in nature. So, if we just look at this list, preventing unauthorized access is preventive in nature. Ensuring confidentiality, integrity, and availability, that's preventive. Detecting and responding, that would be detective and corrective in nature. And security controls can serve multiple purposes amongst these three. They can have a primary purpose and certainly a secondary purpose. Meeting compliance requirements, that sounds preventive.

So, if we were to look at a few examples, we have preventive controls: access control systems, for example. Firewalls with an access list can be preventive. Physical security measures, such as a badge locking a door, is preventive. Detective controls: log monitoring, where our Security Information and Event Management can identify malicious activity, trend analysis, security audits, video surveillance is detective. Motion detection will detect unwanted activity. And then we have corrective controls: incident response planning, root cause identification, backup and restore processes that are designed to correct an unwanted condition. Patch management, corrective in nature.

And then, if we look at it from another angle, organizing those same controls we just looked at, but this time by category: administrative controls, security and awareness training, change management procedures, incident response planning policies and procedures, right? It's the paperwork, the actions that we design. Technical controls, the hardware and the software, the technology. Access control systems, a SIEM, firewall, antimalware software, all technology that we implement as controls to mitigate risk. And then physical controls, physical security measures like video surveillance, motion detection, bollards to prevent vehicles from crashing into our building, access control vestibules that prevent multiple people from slipping in on a single badge swipe.

So, understanding the nature, the category, and the high-level capabilities of controls will factor in Domain 3 when we talk about control selection. And although the CISM is not going to test you on a bunch of technology directly, there is an assumption that you have some underlying knowledge from your experience when we get to that section where we're talking about control selection. And I'll make sure to supplement your knowledge with some basics so you're ready for exam day. And as part of that continuous adaptive loop of risk management, we need to assess control effectiveness. We need to regularly assess the effectiveness of controls to ensure they're still meeting their intended objectives. And there are several ways we can do this: self-assessments, independent audits, vulnerability scans, penetration tests. We would call these assurance functions. We talked about the concept of assurance functions back in Domain 1. But the strategy here is to select controls that balance cost, complexity, and the level of residual risk that remains after implementation. Over-controlling a risk can be wasteful. Under-controlling can leave the organization vulnerable. And we need to align with business objectives, always, of course. They need to align with the business goals and ensure they don't hinder legitimate business processes unnecessarily.

And in this process of risk management, we need to assess our legal and regulatory obligations. Senior management are the ones who need to determine the necessary level of compliance and to allocate resources for us accordingly. Organizations have to comply with various laws depending on industry: data privacy laws like GDPR, industry-specific regulations like HIPAA in healthcare, Sarbanes-Oxley or SOX for publicly traded companies, cybersecurity frameworks like the NIST Risk Management Framework is mandatory for federal government agencies to which it applies. And we have to evaluate the consequences. Regulations have to be reviewed by legal experts to understand potential penalties for non-compliance. And if the environment is non-compliant, the organization has to decide whether to bear the risk, modify operations, or invest in compliance measures. Mandatory requirements, as we'll see in some industries, are prescriptive. They can't be negotiated or accepted as a risk. And in these cases, compliance is compulsory.

So, ISACA describes evaluation of the consequences of non-compliance as a business decision. That sometimes the business may choose intentionally to be non-compliant. And it is true, there are sometimes circumstances where non-compliance may be warranted, such as scenarios compliance is not routinely enforced. We often see this as a political decision driven by a desire for deregulation, where a new government that comes in will simply not enforce what they see as overreach. Or when compliance is much more expensive than the fines levied for non-compliance. Two obvious exceptions to this logic would be when human safety or user privacy would be at risk due to non-compliance. And in these cases, professional ethics and protecting the reputation of the business would take precedence. We would make sure we're compliant in these cases.

So, moving on to cost-benefit analysis. So, costs, whether they're direct or indirect, of implementing our controls, transferring risks, as through insurance premiums, or halting activities altogether to avoid a risk, have to be weighed against the benefit of risk reduction. This forms the basis of a business case for security investment. Key considerations here are going to include balancing cost and benefits, and the intangible factors like protecting the business reputation, customer trust, for example. Controls have to meet three criteria: they need to be technically effective at reducing the risk, they need to be cost-effective, and they need to support business objectives, not hindering business activity unnecessarily.

So, I highlighted business case there because I've heard the question a few times: Does ISACA have a specific definition or framework for business case? And the answer is, I don't believe so. But I'm going to explain a business case and give you a simple example just for context, so you feel better about it if you don't feel confident today. So, a business case is a documented justification for a proposed security project, in this case, or an initiative. It's not just a technical explanation of the security problem. It's a persuasive argument presented in business terms that articulate how a specific investment will provide ROI or align with the organization's strategic goals. The key differences from a purely technical justification are that a business case focuses on business value, it will include financial language, often to articulate what the ROI is, and it targets a business audience. So, it's going to be in business language, but it articulates the business need for security investments. In this case, for example, a technical justification might simply say, "We need a new firewall because the old one is end-of-life." A business case would articulate that investing in a new firewall will reduce the risk of data breach by X%, potentially saving us Y dollars in fines, while also improving compliance with Z regulations. So, articulating why it makes business sense for that security investment.

But a cost-benefit analysis weighs the expenses, financial or otherwise, of controls or compliance against the potential benefits or risk reduction. It helps determine the appropriate level of controls based on the organization's risk appetite and tolerance. The intangible factors may include inconvenience to users, reduced throughput, training in new procedures, compliance monitoring, end-of-life decommissioning. Even if they're not direct costs here, they're going to be indirect costs to the business in terms of human effort and perhaps reduced productivity. For example, benefits can also include reputational protection and avoidance of regulatory fines or legal action. And again, if the cost of a control outweighs its benefit, it may be more appropriate to just accept the risk, provided it remains within acceptable tolerance levels, doesn't cross any of those ethical or legal lines we discussed earlier. CISM questions may actually involve quantitative or qualitative evaluations of cost versus risk reduction to confirm controls are cost-effective. We talked about risk analysis methodologies in the previous installment, and in the quantitative section, single loss expectancy and annual loss expectancy are going to be the two most important figures you should know how to calculate given a scenario.

So, let's try a practice question to exercise our knowledge here from section one. So, Koso Corp is implementing additional security controls to address the risks of a new process. This is an example of which of the following: accepting the risk, transferring the risk, avoiding the risk, or mitigating the risk? So, we're implementing additional security controls, so we're definitely not transferring the risk because we're keeping it within the organization. We're implementing controls, and we're definitely not avoiding the risk because we're addressing it. Remember that avoidance would be to simply avoid a business activity altogether. So, is this an example of acceptance or mitigation? I hope after our discussion here today that the answer to this question is very simple. The answer is mitigating the risk. So, transferring the risk hands it to another entity, like buying insurance, so the insurance company can take the risk. Implementing additional controls is an example of mitigating the risk. We address the inherent risk, which leaves us with a lower residual risk after the control has been implemented. Doing nothing at all would be an example of acceptance.

Moving on to section 2B2, we're talking about Risk and Control Ownership. We'll look at risk ownership and accountability between the risk owner and control owner roles. Fairly short section, important information though. So, we have the risk, and we have the control. So, when we identify the risk, that informs us through estimates of probability and impact, for example, the necessity of a control. And when we implement a control, it's going to reduce risk if effective in its intent. And of course, the value of the asset will influence the max cost of control as we aim for that balance between security and cost-effectiveness. But both the risk and the control need to have an owner. So, after a risk is identified, analyzed, and evaluated, a manager or senior official is named the risk owner. This individual must have the authority to decide how the risk will be handled, whether it's mitigation, acceptance, transfer, avoidance. The risk owner is accountable for the outcomes of those decisions, and they must ensure the risk is managed within the organization's risk appetite. And they need adequate knowledge, authority, and resources for the risk owner to effectively manage and communicate about that risk. Responsibility can be delegated, but bear in mind, accountability cannot. The risk owner is accountable. So, the risk owner is the person ultimately responsible for ensuring a specific risk is managed appropriately. Typically, this role is held by a senior executive, manager, or director whose area of responsibility is most affected by the risk. Key responsibilities here will include making key decisions about risk responses, allocating resources to manage the risk, accepting residual risk if it aligns with the organization's risk appetite, and ongoing monitoring of that risk and reporting changes or updates as needed to key stakeholders.

So, let's talk about the control owner. Who has authority and accountability for decisions about a control designed to address a particular risk? Usually, the control owner and the risk owner are the same person, especially for critical controls. Technical staff may implement or maintain a control, acting as a custodian or a steward of the control. The control owner remains ultimately accountable for its effectiveness, and the risk owner is accountable for the risk outcome, while the control owner is responsible for operating or overseeing the specific control. So, you can imagine why, if the risk owner is accountable for the risk outcome, even if the control is poorly implemented, it would make sense to ensure that the risk owner and the control owner are the same person. Otherwise, you're going to have to make some very careful decisions here around how you manage this relationship between those two, because the buck stops with the risk owner ultimately. So, the key responsibilities of the control owner: ensuring the control is properly designed, documented, and tested, and aligned with the organization's risk appetite. Monitoring the control's performance and taking corrective action when needed. Coordinating with other stakeholders, that could be IT, compliance, audit, to maintain a strong control environment. So, this ensures better performance and cost efficiency in a layered defense when we see collaborative behavior and continuous monitoring. But again, the risk owner is ultimately accountable for the risk outcome. So, they have a lot of skin in the game when it comes to the control itself.

All right, let's test what we saw here in section 2B2 with a practice question. Who should be the owner of customer data stored in a CRM database used by the organization's sales department? Would it be the sales department manager, the Chief Information Officer, the IT security manager, or the database administrator? So, we have a customer relationship management database where we have customer data. So, I know right away the IT security manager and the database administrator could conceivably be involved from a control owner perspective. They're not going to be the risk owner. Again, the risk owner should be someone who is in management, and senior or executive management, it said, and who is directly related and benefiting from this data. So, that makes this a more black and white decision. And the answer here should be the sales department manager. The owner of the asset should be the person with the decision-making power, which means they're going to be the owner of the risk. And the sales department manager is the department deriving the most benefit from the asset. So, in this case, they would be the owner of the asset and ultimately the owner of risk with that asset.

Let's move on to section 2 B3, which is Risk Monitoring and Reporting. So, here we'll touch on monitoring key risk indicators, KRI selection criteria, reporting changes in risk, risk communication, awareness, and consulting, and documentation. So, there are several elements that are essential to how you track, measure, communicate, and document risk over time. And mastery of these is going to be a key part of the information security manager's role in ensuring risk remains within the limits of the organization's risk appetite. So, this really lands directly on that persona we are assuming when we walk into this exam.

So, risk monitoring involves continuous or periodic review of risks, controls, and the external environment, threat intelligence and regulatory changes, for example. This ensures that new risks are identified promptly, and existing risks are evaluated in light of any changes. We're ensuring those existing controls remain effective, right? So, charts or visualizations can be helpful. Samples of risk reports are available in frameworks like COSO. Key risk indicators are forward-looking metrics used to signal increasing or decreasing levels of risk exposure. They act as early warning systems that signal when an enterprise is subject to risk that exceeds a tolerable level. So, there are several benefits of implementing effective KRIs: they enable organizations to proactively identify and address emerging threats rather than reacting to incidents after they occur. They provide information for risk assessments, allowing organizations to make informed decisions about risk mitigation strategies and resource allocation. And they facilitate continuous risk monitoring, enabling organizations to track changes in risk level over time and adjust their risk management approach accordingly.

So, the right KRIs are going to vary widely by organization. A few examples would include phishing emails blocked. If we were tracking the number of emails blocked, patch latency, system downtime frequency. So, number of phishing emails blocked, if we see that number going up or going down, if we take a look at our security controls there, we can identify, do we see an increase in phishing emails, or do we see a decrease in the efficacy of our controls? So, the KRI is forward-looking, but it should be, at the end of the day, relevant and measurable. So, the criteria for effective KRI selection include: prioritizing indicators associated with risks that have a high potential impact to the organization. This ensures that resources are focused on mitigating the most critical threats. Effort to implement and measure and report. We need to select indicators that are relatively easy to measure and report. If it takes a lot of manual effort to get that report together, it's going to be less valuable to us. This ensures KRIs are practical and they don't consume excessive resources for our monitoring and analysis cycles. In reliability, we need to make sure that we choose indicators that have a strong correlation with the actual risk they represent. Reliable indicators accurately predict or indicate changes in risk levels. If that fact is in question, we need to go back to the drawing board and reselect KRIs. We need to select indicators that are sensitive to changes in risk level. This allows for early detection of emerging risks. If we don't see an indicator that tells us there's a change, it's not very useful. Needs to be relevant to our stakeholders. So, we want to involve relevant stakeholders in the selection of KRIs to ensure that the indicators we choose are relevant to their needs, that it's going to inform their decision-making. And we want to find a balance between different types of indicators: leading indicators that are purely predictive, lagging indicators which are forward-looking but they're reactive, they tell us something after an event occurs, but before a security incident, of course, and trend-based indicators. But for the exam, remember, KRIs should align with business goals. They should have thresholds that trigger escalation or additional controls, and they reveal trends in our exposure to risk.

So, risk reporting involves communicating updates in risk status, including new threats, control effectiveness, or incidents to stakeholders at the right level of detail. Some key considerations in reporting: the process. We need a well-defined process that should be in place for reporting and communicating changes. And this needs to include clear reporting channels and procedures, defining the format and frequency of risk reports. So, folks know what it's going to look like, the format is useful, and they know when it's coming. And using appropriate communication methods for your audience, whether that's meetings, reports, dashboards, the level of the language, making sure we're dialing in our level of technical and business language to the audience that's consuming these reports. It's important to remember that monitoring is continuous. Risk is a dynamic factor, and changes in the internal or external environment, in business operations, can significantly impact the risk landscape. So, continued monitoring and reporting of risk changes are essential in effective risk management.

So, triggering events. There are certain events that can trigger a more immediate need for risk reporting and reassessment. These would include significant security breaches or incidents, that's going to send us back to really thinking about the controls we have in place. Changes in internal or external environments, changes that we might reveal through effective KRIs. Changes in business operations or strategic direction. Newer, updated regulations or industry standards. So, security incidents, for example, require a thorough investigation, and they may necessitate a special report to senior management to inform them of the incident, its impact, and the steps being taken to mitigate the risk, and certainly to prevent its recurrence in the future.

So, what's the responsibility of the information security manager? Our role in the big picture here. The information security manager plays a role in monitoring and reporting, including regular risk assessments, so conducting periodic assessments to identify or evaluate new or changing risks. Stakeholder communication, so regularly communicating risk information to our relevant stakeholders, our risk owners, our control owners, and senior management. And status reporting, so providing periodic reports on the overall risk status of the enterprise, including changes in risk level and the status of any open or untreated risks. And effective risk management hinges on clear and consistent communication. This is so important, and I want to explain what I mean at some depth here. So, communicating and creating awareness of risk management issues across the enterprise is the key objective here. And this means more than just communication. It means the right type of communication. It means the appropriate cadence and medium. So, whether that's a meeting, that's a dashboard, that's an email report, that's stopping by the boss's office and having a discussion about that report. But the level of detail and audience engagement is so important. So, for example, I remember delivering daily reports to an executive at a large organization, and he was a brilliant businessman, not a technology person. And over a period of months, we had dialed the dashboard to a format he was comfortable with. And as our environment evolved, one day we went back and touched that dashboard and changed things around to improve the metrics. And suddenly, the frequent communications we'd hear from him, which would be, you know, sometimes two to five times a week, where he would reach out and make a comment, suddenly it was crickets. It was nothing. And it was because the change had adjusted the type of communication to a point that he was no longer comfortable. And so he was no longer engaged. He just shut it off. And we have to be so careful about that. And that's why this has to be a collaborative effort. And any type of communication that appears on the exam should be tailored to its audience, its medium, detail, and cadence. And that includes, and is very important for, security awareness training. I find with security awareness training, I always want it to be entertaining. But if I'm dealing with a business audience that's maybe a little less technically aware, I'm going to be a little bit simpler and prescriptive in my language. And if my audience is younger and tech-savvy, I'm not going to bore them with mundane details they're already familiar with. I might engage them through interesting stories from current events to really make the session relevant and help them understand how the threats really do affect them personally.

So, a few effective techniques: stakeholder engagement. So, communication should involve consultation with all of our relevant stakeholders. And the collaborative approach fosters a shared understanding of objectives and requirements of the risk management program. It leads to better alignment and support because we're all on the same page. But that shared understanding is the key. And I want to address variations because everyone will have at least slightly different needs. And by involving stakeholders, the risk management program can better address those variations in stakeholder needs and perceptions. So, we can come to a happy medium that works for everyone. This ensures that the program is tailored to the specific requirements of the organization. But the tailoring is always important. Risk awareness programs. These are going to be crucial for building a security-conscious culture. They should aim to increase employee understanding of organizational risks, enhancing the ability of employees to identify and report security threats, for example, phishing emails, and fostering a sense of ownership and responsibility for security amongst employees. They need to understand that we're all on the same team, and everyone can contribute. Consulting involves working with different departments or stakeholders to guide them in managing risk effectively. As well, we're going to have leadership who are at varying levels of their risk awareness, and we want to make sure that we consult with the folks who need a little extra support. So, on the exam, the culture of security is something that I believe you'll see more than once. CISM places emphasis on building a culture where risk management is recognized as everyone's responsibility, which means we're going to catch problems earlier, it's going to be less expensive, and the organization will suffer fewer negative security events as a result. Tailored messaging. Communication strategies might differ for technical, non-technical, executive, and operational audiences. So, tailoring the message in whatever endeavor. And bidirectional communication. So, the exam might reference the importance of two-way communication. Going back to that story I talked about with that leader for whom we created a dashboard, making sure we have a dialogue there. So, as the situation evolves, we know that we're still all on the same page, and we're meeting the needs. Two-way communication with leadership, providing updates, and employees reporting observed risks or incidents.

And big finish here with documentation. So, documentation to support risk management, specifically. So, effective risk management requires thorough, readily available documentation. It should cover policies, standards, procedures, anything related to how the organization deals with risk. It ensures consistency, accountability, and clarity for all stakeholders involved. Every step in the risk management process, along with the rationale behind each decision, should be recorded. It should be captured in a written record. Key elements to include are going to be covered throughout this section. So, in terms of objectives and audience, we want to clearly define what the organization aims to achieve with risk management. Identify who needs this information, be it executive leadership, IT staff, auditors, etc. Information resources, so documenting systems, applications, and infrastructure involved in risk management, maintaining references for relevant standards or guidelines. Assumptions and decision criteria, so recording any underlying assumptions, resource availability, regulatory constraints, etc. So, if those assumptions change, if the resource availability or regulatory constraints change, we can go back and update any assumptions. Clarify how decisions are made, including the metrics or thresholds used to determine risk responses. Risk management policy and processes, so this is a formal document that should describe policy objectives and rationale, so why the organization manages risk and the expected outcomes. The scope and charter, which areas of the organization or types of risk are covered. And roles and responsibilities, who is responsible for risk identification, assessment, and mitigation. And the key process steps, how risks are identified, analyzed, and treated within this organization. And risk response guidance, so it acceptable response options for avoidance, mitigation, transference, and acceptance. And documentation requirements, what records must be kept and how should they be maintained. Communication and training, how staff will be informed and trained on risk management practices. Timelines and frequency, so when and how often risk assessments occur, and any triggers for reassessment that might trigger immediate reassessment, for example. Are you seeing the natural progression from a process perspective here? We're now documenting areas that we developed in collaboration with stakeholders in the minutes prior. But reporting and escalation, so how risk information is reported to management and escalated when necessary. So, we have to have all of this documented so there is clear accountability. Otherwise, it just comes down to one person's word versus another, and we don't have clear responsibilities, clear accountability, or any means of real enforcement.

So, typical supporting documentation: a risk register, a living document that lists each identified risk, the risk owner, status, and planned actions. That's going to be a living document that's updated over time, at least periodically, more frequently during projects. A risk management framework, this outlines overall governance, definitions, and the organization's risk appetite. Assessment reports, logs, and forms, so detailed findings from risk analyses, including methods and results. Communication plan and training material, so this would ensure consistent messaging and education across the organization. Risk treatment plans, this describes the chosen mitigation strategies, cost-benefit considerations, and acceptance criteria. And finally, reviews and audits. So, the risk management process should periodically be reviewed or audited, whether internally or externally, to confirm that it remains effective. Proper documentation of risk acceptance decisions is crucial to demonstrate due diligence. When we accept a risk, we need to document who made that decision, and when, and why. And leadership should drive a strong risk management culture, ensuring everyone understands their role and the importance of adhering to established processes and their role in improving security within the organization. The culture and effective version control and handling of documentation are very important. This includes labeling and classification level, revision date, and some number so we know we're working from the latest version of the documentation and how fresh it is. But ensuring that the risk management policy is approved by the board of directors is key to facilitate gaining support from all stakeholders in the enterprise.

Okay, my friends, let's put our knowledge gained in section 2 B3 to the test with a question. The most important objective of monitoring key risk indicators related to information security is which of the following? So, what is the most important objective of monitoring KRIs? Is it a) reducing risk management costs, b) meeting regulatory compliance requirements, c) identifying change in security exposures, or d) minimizing the loss from security incidents? So, we remember that KRIs are forward-looking indicators that signal a change in our exposure to risk. So, I can say right away, cost is not the primary driver here. And while KRIs can help us potentially in meeting regulatory compliance requirements, that's also not a primary function. So, that leaves us with identifying change in security exposures and to minimize the loss from security incident. So, one of these is the primary function, the primary objective of KRIs. The other is a nice benefit of KRIs. If you didn't know if it was C or D, that should tell you the answer right there. One of these is the primary objective, the other is a nice benefit. So, the answer is C, identify change in security exposures. So, by monitoring KRIs, the organization can proactively detect and respond to changes in security exposures. This allows for timely mitigation actions and ensures that emerging risks are addressed before they escalate into significant incidents or breaches. And D, minimizing losses from security incidents, is a great benefit of effective KRI monitoring.

All right, my friends, that's what I have for you in Domain 2, Part B. We should be on to Domain 3 here in just the next few days. Really big section, the largest domain in terms of content, and where your past technical experience, your knowledge of security from a technical perspective, will be most relevant. So, I hope you're getting value from the series. As always, if you have questions, reach out in the comments, ping me on LinkedIn, happy to help with wherever I can. And until next time, take care and stay safe.