CISM EXAM PREP - Domain 2A - Risk Assessment

Welcome to domain two of the CISM exam prep series. So, domain 2 is all about risk management, and the CISM exam doesn't expect you to just memorize risk-rated concepts. They expect that you know how to apply them in real scenarios. So, in part A, we'll focus on the concepts and activities related to risk, including the dynamics of risk management, assessment, and analysis. We'll look at the three risk boundaries: appetite, tolerance, and capacity. We'll walk through the mechanics of identifying and assessing risk, and then we'll examine vulnerabilities, threats, and threat intelligence, and how they factor into the risk assessment and analysis processes. And we'll finish with a look at the three methods of risk analysis and the all-important risk formulas you should know how to use on exam day. Let's dig in.

[Music]

Welcome to domain 2A, which is information security risk assessment, and we're going through every topic on the official exam syllabus in the first half of domain 2. 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+ 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.

The focus of domain 2 is information risk management, and as with all four CISM exam domains, we have a part A and a part B for each. Today, we're focused on domain 2, part A, which is risk assessment. So here, we'll be digging into the risk assessment process and all of its components, including emerging risk, threat landscape, vulnerability, and control deficiency analysis, and then the risk assessment and analysis process, including those all-important formulas that you should know how to apply in real scenarios on exam day. When we move into part B of domain 2, we're focused on risk treatment and response, risk and control ownership, and the ongoing risk monitoring and reporting process. But risk assessment, that we're focused on today, is fundamental when it comes to risk management and will come up throughout domain 2 and even in domain 3 when we talk about our control selection.

We have three supporting tasks most closely associated with domain 2, part A: that's number 2.2, "Participate in and/or oversee the risk identification, assessment, and risk treatment processes." We'll look at the impact of budget, culture, risk appetite, legal, and regulatory, and how they apply in our decision-making. 2.3, "Participate in and/or oversee the vulnerability assessment and threat analysis process." Really knowing the difference between a vulnerability and a threat and the collaborative techniques to address both is very important. And number 2.6 on the list of supporting tasks, "Facilitate the integration of information risk management into business and IT processes." So, really, effective risk identification, prioritization, and treatment requires input from business stakeholders. We always talk about the importance of IT security and business alignment, and it's no different here.

And before we even dig into the first section, I want to ground you in some terms and concepts that will pay dividends to know right from the start. So let's talk about GRC: governance, risk management, and compliance. An integrated approach that combines these three disciplines. So, governance, again, is about oversight provided by senior management and the board of directors. It establishes mechanisms to ensure personnel adhere to policies and procedures. Risk management: the process of identifying, assessing, and mitigating potential risks to the organization. It involves identifying potential risks and their impact, prioritizing risk mitigation based on business objectives, and then developing and implementing internal controls to manage risk. And then finally, compliance: the process of documenting, monitoring, and enforcing policies, procedures, and controls to ensure adherence to standards and regulations.

So, let's talk about the three risk boundaries. So, risk appetite is the first: the amount of risk the organization is willing to take on across all assets. We then have risk tolerance, which is the amount the organization will accept for a specific threat-asset pair. So, basically, the amount of drift we can have in our appetite as an upper boundary. And then the outermost boundary is risk capacity. This is the maximum amount of risk the organization can absorb and expect to survive. And risk appetite sets the boundary for risk acceptance. If the risk is down there within our risk appetite, we may simply accept a risk and do nothing. So, if we were to simplify these even further: risk appetite is our organization's willingness to take risk. Tolerance is the acceptable variation in that risk boundary. And then capacity is our maximum bearable risk.

There are two important terms related to risk you should know well before we get started. Two types of risk: there's inherent risk. So, this is the level of risk in the absence of any controls or mitigation effort. So, before we've taken any action. And there's residual risk, which is the level of risk that remains after controls have been applied.

So, let's dive into section 2A1, which is emerging risk and threat landscape. So, we'll talk about risk identification categories, threats, defining a risk management framework, and what a risk management framework can do for us, emerging threats, and risk likelihood and impact.

So, identification: before an enterprise evaluates potential and emerging risks, it has to determine how to identify risk. So, we want to determine all possible threats, whether technical, physical, or operational, that could exploit the enterprise's vulnerabilities. And then we examine the vulnerabilities. We identify the weak points in systems, processes, and personnel that, if targeted by a threat, would result in risk. And we need to recognize assets. And it's not just assets within the company, within the organization. We need to consider assets beyond the organization's direct control, whether that's data or services hosted by vendors or contractors or cloud providers. We need to look at our supply chain, in other words. So, in the area of identification, we are identifying the organization's valuable assets, the assets related to critical business services, the assets that keep the business running. And once we identify these assets, security practitioners and risk managers can then begin to identify potential causes of disruption to the asset.

And risk frameworks give us a template, so to speak, for assessing our risk. We can look at existing frameworks as a starting point. So, there's ISO IEC 31,000, which are risk management guidelines. We can look at NIST 800-37, which is the guide for applying the risk management framework to federal information systems. These are just a starting point. We can tailor these to the organization's specific needs, but they give us a framework, a frame of reference to start with. And the process of identifying risk typically involves a knowledgeable, cross-functional group. So, we have subject matter expertise within this group, both on the technical side of the house and on the business process side of the house. So, we have all the perspectives in identifying where potential risks lie. So, this may take the form of a workshop where we're together determining all possible threats, walking through scenarios to determine what could exploit the enterprise's vulnerabilities, structured techniques like data flow diagrams, mapping out weak points in systems within a business process, looking at personnel to determine that if something is targeted by a threat, what sort of risk it's going to result in, what-if and scenario analysis where we might examine less defined or emerging situations, strategic risks, changes in technology, and project potential outcomes in those scenarios and the impacts that will come with those changes, and threat mapping, so correlating internal and external threats with known or suspected vulnerabilities to see where the organization is at most risk. So, we're trying to identify impactful and likely threats. And all of these should be considered recurring activities.

So, let's dig into the categories of risks, or what we might call types of risks. So, we have strategic risk, which threatens an organization's ability to achieve its strategic objectives. We have operational risk. This relates to day-to-day operations of an organization, and it can result from inadequate or failed internal processes, people problems, or system failures, human error, so employees or third-party error, or external events like disasters or theft. Reputational risk, which can damage an organization's reputation and erode stakeholder trust, and this might arise from data breaches, negative publicity, or even unethical behavior. And compliance risk, which arise from non-compliance with laws, regulations, or industry standards, and these can result in fines, penalties, and significant reputational damage.

So, let's actually dig into the consequences of non-compliance. So, reputational damage, which can result in a loss of customer trust and a loss of revenue, and the effects may last for years. I can think of a fast-food chain out there, for example, and I have a negative impression of them, and it's related to some health failure on their part all the way back in the 1990s. Couldn't even tell you what it was, but their reputation suffers in my mind some 30 years later. Sanctions: so, these are legal repercussions that can be harsher than fines, including restrictions on operations or even criminal charges. Contractual impacts, which would come from failure to comply with regulations that might lead to contractual breaches, resulting in penalties or termination of partnerships. The organization might incur fines. So, for example, failing to report a breach can result in fines that can reach into the millions of dollars. This is definitely true with GDPR, and it may lead to lawsuits, for that matter. Loss of license. So, in some cases, non-compliance can lead to the revocation of a business license or permit to operate.

So, continuing with risk categories, we have technology risks. So, technology risks are associated with the use of technology, as you might imagine. This can include cybersecurity threats, system failures, and data breaches. This can lead to unplanned downtime, which can significantly disrupt operations. It might increase our costs due to emergency repairs, and business impact analysis can really come in handy here in identifying business-critical processes and services and their related technology assets, so we can get ahead of some of these risks. There's data risk, which can relate to the collection, use, and disclosure of data, and it can include data breaches, data loss, and privacy violations. So, data risk can lead to financial loss, including those regulatory fines we talked about, reputational loss with a decline in customer trust and brand value, which can be tough to overcome. It might result in loss of trade, as customers simply move on to competitors with better data security practices. It can result in disruption to business operations with potential downtime and the recovery costs that come of downtime. Identity theft with unauthorized access to personal information, and legal consequences, lawsuits, and regulatory penalties. So, a variety of risks in the data category, and all potentially very impactful.

And finally, we have human resources risks. So, these arise from the actions or inactions of employees, contractors, or other personnel, and they can include issues like employee misconduct, negligence, or lack of training. And these risks can lead to consequences like legal disputes, like wrongful termination lawsuits or discrimination claims, financial losses, like those arising from employee theft or fraud, reputational damage, like negative publicity from employee misconduct, that, as we discussed, can be very hard to get past, and operational disruptions, such as those caused by employee absenteeism or low morale.

So, let's talk about threat actors. We'll start with types of threat actors. So, at a high level, we have white hat hackers, who are authorized security professionals who act with permission to discover and help fix vulnerabilities in systems and networks. So, a threat actor who is on our team, effectively. Black hat hackers, who are malicious actors who exploit vulnerabilities for unauthorized purposes and personal gain. And somewhere in the middle, we have the gray hat hacker, who are unauthorized actors who discover vulnerabilities but report them to the organizations rather than exploiting them maliciously.

So, let's talk about threat actors and their motivations. So, every threat actor is going to be motivated by money or their mission, or some combination thereof. So, in the nonprofit area, we will have threat actors who are entirely mission-driven. Anything in the government space is usually going to be a mix of money and mission. There's going to be some economic motive and political motive, typically. And then there are threat actors who are purely profit-driven. It's just a business for them. In that category would be your criminal syndicates. So, nation-states in the government space, there's going to be some combination of economic motive and political motive, gaining advantage for their nation. And then there is the hacktivist, who is focused purely on their mission, on their benevolent cause, or perceived benevolent cause. But understanding a threat actor's motivations can help us to understand the potential threat they pose to us and the risks that come from those threats.

So, I've also charted out for you here a description of specific threat actors, their motivation, skills, and funding, typically. So, we have script kiddies, for example, who are very inexperienced, low skills, typically low funding. We have hacktivists, who are mission-driven and will vary in their skills and funding. But moving up that list, we have criminal syndicates, high skill, high funding, focused on business, financial gain. Advanced Persistent Threats, that's where your state-sponsored actors will fall. These are the folks that are motivated by a combination of money and mission. They're well-funded, highly skilled. Insiders, often overlooked by organizations. These are folks within the organization who already have access, who may be seeking financial gain, or it could be a grievance they're trying to resolve. So, maybe a disgruntled employee, typically self-funded, but dangerous because they've already crossed that access barrier. And then you have competitors, who are looking to steal sensitive information. This is espionage. Bear in mind that espionage begins outside the organization, but that competitor may work in concert with a disgruntled insider. So, it begins outside, but that may shift. So, just understanding the different types of threat actors and their motivations can help the organization to understand the threats and the risks that result from those threats. And we're going to continue to peel back the layer here so you really understand all the facets of the risk assessment and analysis process. I really want it to be something you know on exam day.

So, let's talk about a couple of important terms here: threat vector and attack surface. So, let's start with definitions. Threat vector is a method or combination of methods that attackers use to gain unauthorized access to a computer system, a network, or data. So, think of it as the pathway an attacker takes to exploit a vulnerability. Examples would include phishing emails, malware and attachments, unpatched software vulnerabilities, social engineering tactics. And then we have the attack surface, which is the sum total of all the possible entry points that an attacker can take to exploit a system and gain access. It's the broader landscape of weaknesses an organization or an individual presents. A larger attack surface means there are more potential direct vectors attackers can utilize. So, examples here: unsecured devices, weak passwords, open service ports, outdated software, or even reliance on untrusted sources.

So, let me restate threat vector and attack surface with an analogy that might make this more accessible. So, imagine you have a castle. The threat vector would be a specific way to breach the castle, like scaling a weak wall or bribing a guard. The attack surface would be the entire castle itself, including all its walls, gates, and potential weaknesses. So, the stronger the castle's defenses, the smaller the attack surface will be, and the fewer effective ways attackers will have to breach it.

So, let's touch on just a few examples of threat vectors, those pathways threat actors use. There's email and social media, which are very common entry points for phishing attacks, spam, and social engineering attempts. Email being the most common, and this can result in compromised user credentials, the spread of malware, or even ransomware. Direct access. So, physical access to facilities or systems, often achieved through unauthorized entry or social engineering of building access controls. For example, we see tailgating and piggybacking used by attackers who are socially engineering employees to hold the door open for them. Wireless networks. Networks that can be accessed remotely, potentially allowing attackers to connect from nearby locations without physical access, which is a great reason why we want to make sure that we have the right amount of wireless coverage and we don't have wireless signal transmitted well beyond our necessary boundaries. Removable media. Physical devices like USB drives that can be used to spread malware or exfiltrate data. We've seen threat actors actually drop an infected USB drive in the parking lot of an organization just to get an employee to carry it in and plug it into transmit malware, for example. The cloud. So, cloud services that may have misconfigured access controls or security vulnerabilities that attackers can exploit. And finally, third-party risks. So, vulnerabilities introduced through supply chain vendors or other business partners, perhaps software companies we purchased services from who have access to systems or data. And we see an increased focus on third-party and supply chain in 2025.

Let's shift gears and talk about threat intelligence and threat intelligence feeds. So, threat intelligence broadly can describe any activity an organization undertakes to educate itself about changes in the threat landscape. This often comes in the form of a feed containing information about malicious entities that can be ingested by our tools. A single feed may be comprised of many sources, including open-source intelligence, and it may be factored to be human-readable. It may be machine-readable, which is more often the case these days. And an entity might be an IP address, a website, a threat actor, an AP, a file hash, or any indicator of malicious activity. And the activities and resources that help organizations to learn about these changes are broadly referred to as threat intelligence.

So, you have the open-source community. This can be publicly available information that comes from government agencies like CISA, security blogs, community forums. And you also have what we'd call proprietary or closed-source intelligence. So, these will typically be coming from commercial sources that will provide exclusive information or paid access to threat data, maybe intelligence to their customers. We see this from companies like Mandiant, CrowdStrike, IBM, Microsoft delivers it to their cloud-based security services. There are vulnerability databases. These are centralized repositories of known security weaknesses and flaws in software, hardware, systems. A number of sources that can help organizations prioritize their patching and understand emerging exploit trends. So, there's the National Vulnerability Database. We'll talk about the NVD, CVE, CVSS, the Common Vulnerability Scoring System, MITRE ATT&CK, all a bit later when we're discussing vulnerability management. Indicators of Compromise. So, this is forensic data that indicates a potential security incident has occurred, such as unusual file signatures, suspicious log patterns, or other digital evidence of malicious activity. An indicator, but not a confirmation. So, this could be file hashes of a known malicious file, IP addresses that have been flagged for malicious activity, known malicious domain names. And there's threat indicator management and exchange. These are standardized systems and protocols for sharing threat information between organizations and systems. So, TAXII and STIX come up here most predominantly when we think about machine-readable threat intelligence exchange. I'll unpack STIX and TAXII for you in just a moment. And then there are public and private information sharing centers. These are organized communities and centers, like Information Sharing and Analysis Centers, that facilitate threat information sharing within specific sectors, often using protocols like TAXII and STIX. We can also get information through local meetups, just meeting with other security professionals. That's going to be very much just a human-friendly exchange.

Assessing threat intelligence. Not all threat intelligence is of equal quality and utility. Your mileage may vary, right? Key considerations would include timeliness. So, how current and relevant is the threat information? And information that's more than a few days old is going to be, you know, an indicator in our mind that it may be outdated at this point. Accuracy. What is the reliability and truthfulness of the threat information based on the source we received it from and the evidence behind it? Relevance. How applicable is the threat information to our specific organization, our industry, our systems, which can vary based on the business we are in and the software we are running and the hardware vendors we work with? Confidence scoring. So, a standardized rating system to evaluate trustworthiness and reliability of the threat intelligence. Often times, the confidence level of the entity that is providing us that intelligence, they can tell us, this is high impact, high certainty, and that's going to carry weight with us if we trust that organization.

So, some key practices and activities in terms of remaining abreast: subscribing to and integrating threat intelligence feeds from reputable sources, industry groups, government agencies like CISA, commercial providers that your organization works with. Conducting proactive threat hunting activities to identify and investigate potential threats and vulnerabilities. If you have a SIEM system, Security Information Event Management, this is a common tool organizations use to centralize their logging and to perform those threat hunting activities. Sharing threat intelligence information with relevant stakeholders, our incident response teams, for example, security vendors, our industry peers. We even see industries where multiple entities, like multiple banks, for example, will arrange organized threat intelligence sharing. I'll talk to you more about that when I touch on STIX and TAXII here in a moment. And continuously updating and refining threat intelligence processes and sources to ensure that we have effective, relevant processes in place, we're getting the latest information from the most reputable and relevant sources to our business.

So, when we get into machine-readable intelligence, we have automated indicator sharing. So, the Cybersecurity and Infrastructure Security Agency, CISA, an element of the US government, enables the real-time exchange of machine-readable cyber threat indicators and defensive measures. It's provided free to help participants of that community and ultimately to reduce the prevalence of cyber attacks. You can actually read more about that on the CISA.gov website. So, then there is TAXII, Trusted Automated Exchange of Intelligence Information. So, TAXII defines how real-time cyber threat information can be shared via services and message exchanges. And hand-in-hand with TAXII is STIX, Structured Threat Information Expression. So, this is a common language for expressing cyber threat information. TAXII is designed specifically to support the transfer of STIX-formatted messages. So, STIX defines what is shared, the message, and TAXII is how STIX-formatted messages are securely transferred between systems. So, your SIEM, your firewalls, your IDPS solutions may actually ingest threat intelligence feeds. That is increasingly common in the current age.

So, I want to just give you a diagram of TAXII and STIX and a bit of background about how this works to deliver machine-readable threat intelligence in case you're not familiar already. So, we have a TAXII server, which sends STIX-formatted messages. You have a TAXII client, which will request STIX information. So, for example, when we connect our SIEM to a threat intelligence feed, our SIEM is acting as a TAXII client and is requesting those STIX-formatted messages, which is the cyber threat intelligence being delivered to that SIEM system, to that next-generation firewall in real-time or near real-time to give that tool the most up-to-date threat intelligence we can provide. And the trust groups there are how we control from the TAXII server which entities subscribe to that information. So, for example, trust group one might be a group of banks in a specific country that are getting the latest threat intelligence relevant to their geography, their industry, etc. And a TAXII server can potentially have multiple trust groups, where we're grouping the recipients in that way. And I've seen in the banking industry in particular, I've actually seen banks in a country set up TAXII servers where they are actually, through their TAXII clients, also pushing threat intelligence back up to the server so they can crowdsource the latest threat intelligence information.

Okay, let's talk about the risk formula. Risk is equal to the likelihood times the impact of a potential threat. So, risk is going to be prioritized based on likelihood and impact, as well as the value and criticality of the asset. That's going to be how we prioritize the focus of our risk assessment and analysis efforts. So, there are a number of helpful factors in determining risk likelihood that make sure we have our focus in the right direction. But by considering these factors together with other assessment information, we can gain greater context around the likelihood of risk. It results in a more comprehensive understanding of the likelihood of various risks, and greater understanding in context leads to better prioritization. It means we're focusing on the big, impactful, likely risks.

So, the first element is volatility. So, the probability of a risk can fluctuate based on the stability or lack of stability of the situation. And if conditions are unstable or rapidly changing, the likelihood of certain risks may be higher. There's velocity. So, this refers to the speed with which a risk event could occur and its impact could be felt. So, a high-velocity risk with little warning time would generally have a higher likelihood of causing damage or disruption because we have less time and opportunity to respond to it. There's proximity. So, this is related to velocity. Proximity indicates the time between an event and its impact. A shorter time frame, closer proximity, suggests a higher likelihood of negative consequences. There's interdependency. So, risks don't exist in isolation. The likelihood of one risk materializing can be influenced by other risks or events in the organization. So, for example, in an e-commerce system, maybe we discover that system B can only be compromised from system A. So, it would take multiple compromises, multiple steps in an attack, to recognize that interdependency, that linked risk. We'll talk a bit later about the technique that allows us to best identify those sorts of risks. Motivation. The motives of potential attackers can influence the likelihood of a risk. So, highly motivated attackers are going to be more likely to persist and look for multiple avenues into the resource they're trying to compromise and potentially succeed. Skill, of course, factors. The skill of the potential attacker can impact the likelihood of a successful attack. We know that APTs, for example, have higher skill and better funding than a script kiddie, but those with greater skills can execute more complex or sophisticated threats that are more likely to find a way around or through our security controls. Then there's visibility. So, high-visibility targets are more likely to attract attention and attacks. So, this could include systems with valuable data, critical infrastructure, prominent online presence, those top-of-mind customer-facing systems. And that's a pretty common-sense conclusion to come to. If a system is internet-facing and it's revenue-generating for an organization, it's going to be a more likely target.

And organizations can track risks in a risk register. This is a tool in risk and project management that's sometimes used to fulfill compliance, but really, its core purpose is to track potential issues that can derail our intended outcomes. So, it typically includes a number of details, but it'll include often a risk ID, certainly a description of the risk, probability, impact, severity, or intended response, and owner of that risk. Now, the exact properties will vary, the metrics are going to vary from company to company, but we are tracking everything we need to know about that risk to prioritize it and to track its ultimate outcome because we have an owner in there. Often times, we see the risk register as a simple spreadsheet that has the columns relevant for that organization. And the risk register should be considered a living document. It should be updated periodically, certainly at least annually. During periods of heavy assessment or project activity, we will often see the risk register updated multiple times within a month or even a week. But bottom line, we want to see those risks tracked all the way out to the ultimate response, where we've identified the appropriate response and it is executed, and the owner is then monitoring on an ongoing basis.

Okay, let's apply what we've learned in a practice question. We're at the end of section 2A1. So, our question: Which information assets should be included in a security risk assessment? Is it A) those inside the organization, B) those already classified and labeled, C) those that support business processes, or D) those that have tangible value?

So, there are definitely a couple of answers here that I can cross right off the list. So, they're asking me which assets should be considered when we're assessing risk. Well, we did discuss that we need to expand our scope to look at important assets outside the organization, the cloud assets managed by vendors, whether that's information or systems. So, we know only looking at internal assets is not the answer. And we can immediately just cross off those already classified and labeled. It is perhaps even more important for us to assess risk around assets that have not yet been classified and labeled, particularly if they are of business value. So, we have two plausibly correct answers here. So, the assets that support business processes, that is true, or those assets that have tangible value. So, if I'm picking the better of these two answers, which is going to be a common occurrence on the CISM exam, you're going to be presented with multiple plausible answers, and you need to find your way to the best. So, both of these are true, and one of these is higher priority for a supportable and objective reason. So, the answer here is going to be C) assets that support business processes. So, the assessments should focus on information assets that directly support or interact with critical business processes. That enables the organization to prioritize risk management efforts on assets that are most important to their operations. We may have multiple assets that have value, but they are only secondary in their support of critical business processes. So, that's going to be our top-level filter when we're prioritizing.

Moving into section 2A2, we're going to focus on vulnerability and control deficiency analysis. So, this is really about how to identify vulnerabilities that you should focus your attention on, how to set your priorities. We'll talk about controls, security controls, and what makes an effective security control, control versus an ineffective security control, and how we can automate configuration and make configuration consistent using security control baselines.

Understanding the fundamental nature of vulnerabilities is our first step in determining the likelihood of a risk. We want to focus on likely risks. And a vulnerability is essentially a weakness. The weakness can exist in a system, a process, or even a policy. And it's not always a simple yes or no. Vulnerabilities exist on a spectrum, with some being more severe than others and more easily exploitable than others. The degree of exposure directly influences the probability that a vulnerability will be exploited. A highly exposed, severe vulnerability is a significant risk. If I have a very significant risk in terms of its severity, but it sits behind five layers of defense, making it effectively never exploitable, it's not such a worry. I'm looking for those risks that are exposed and severe. That's where I'm going to focus my attention is closing the door on my high probability risks. And proactive identification is absolutely critical. The goal here is to find and address vulnerabilities before they are exploited by malicious actors. To manage vulnerabilities, first, you have to know how to find them. So, one way are vulnerability scans, which are automated tools that check systems for known weaknesses. They penetration tests that simulate real-world attacks to identify exploitable vulnerabilities. Security reviews, which involve a thorough examination of policies, procedures, and configurations. Audits, which assess compliance with security standards and regulations. So, you notice here we have multiple tools, and these are absolutely complimentary, but we need to consider all aspects. We need to look at process, procedural, physical, and technical vulnerabilities. We're looking across the spectrum. And our estimates can be quantitative or qualitative. So, numbers or descriptions. And they may be used together in a hybrid, semi-quantitative approach. We'll look at all three of those before we're done in this session. And it's important to remember that subject matter experts can provide valuable insights and context. And that subject matter expert may be someone who is technically focused, but it may also be someone from the business process side of the house. A business process owner may have all sorts of context that can help dial our focus in to the most vulnerable aspects of a business service.

But your controls, or security controls as they're sometimes called, are your safeguards. And understanding their weaknesses is also very important. So, controls are designed to mitigate risks and vulnerabilities, and control deficiencies occur when controls are weak, ineffective, or missing. So, we want to evaluate controls in context. The impact of a single weak control depends on the effectiveness of the other controls around it. If we have many layers of effective controls, one weak link isn't the end of the world. And a lack of training and awareness is a critical control deficiency that we need to be aware of because our end users are the first line of defense. And users who are unaware of security best practices are more likely to make mistakes, plain and simple. In fact, think about phishing simulations that we use to train our users on phishing email awareness. There are two things we can do to reduce the risk of ransomware to the business. The first is to reduce the number of malicious emails our users are presented. And the other thing we can do is to train them so they are less likely to click on those malicious emails.

And another aspect of your vulnerability identification is recognizing typical vulnerabilities, vulnerabilities that are commonly exploited. These would include defective software, software bugs or flaws that are known and can be exploited. Misconfigurations, so identifying incorrect settings in hardware or software that create security gaps. Inadequate compliance, so just plain failure to adhere to security standards or regulations. Poor network design, so flat networks or other design flaws that increase the attack surface. This is where network segmentation comes into play. Lack of redundancy, single points of failure that can cause disruptions or data loss, potentially affecting the availability leg of the CIA triad. Poor password choice, avoiding weak or easily guessable passwords is actually pretty easy nowadays. Most of your identity platforms not only have policy controls that allow us to require complex passwords, but we can implement strong multi-factor authentication. Unprotected communications, transmitting sensitive data without encryption, also easily avoidable in 2025. Insufficient staffing, just a lack of qualified personnel to manage security. Lack of proper hygiene and maintenance, it's not keeping systems up to date with patches. One of the best ways to prevent common vulnerabilities is to simply keep your systems up to date on their security patches. And some zero-day vulnerabilities actually come through the door using unpatched systems. So, patching your systems is actually a good way to at least partially insulate yourself from some zero-day threats. But identifying a range of commonly exploited vulnerabilities results in a more effective, proactive risk assessment effort. At the end of the day, you want to avoid focusing on unlikely edge cases where spending a lot of time analyzing and implementing controls doesn't really reduce our overall risk.

Part of staying informed is knowing where to look. And there are many authoritative sources of vulnerabilities out there. So, a few include the NIST National Vulnerability Database, which is a comprehensive source of vulnerability information. You have Common Weakness Enumeration, a list of software and hardware weakness types. Common Vulnerabilities and Exposures, CVE. This is a dictionary of publicly known information security vulnerabilities and exposures. These are commonly included in reports from vulnerability scanners. OWASP, the Open Web Application Security Project, focuses on web application security. They have myriad resources out there that will help you with common vulnerabilities. And ISACA cites a few categories of vulnerabilities, including network, physical access, applications, utilities, supply chain, process equipment, cloud, IoT, bring your own device. So, a lot of areas we can focus. But it's really about understanding the common vulnerabilities.

Now, I want to unpack just a couple of items in the list we see here. So, the Common Vulnerabilities and Exposures and the Common Vulnerability Scoring System, and how they tie into the National Vulnerability Database. So, the CVSS is the overall score assigned to a vulnerability. It indicates severity, and it's used mainly by many vulnerability scanning tools. That's where I see it popping up in my day-to-day. The CVE is simply a list of all publicly disclosed vulnerabilities that includes a CVE ID, a description, date, and comment. The CVSS score is typically not reported in the CVE listing. You usually have to use some connection to the National Vulnerability Database to find the assigned CVSS score. So, your vulnerability scanners can typically help you with that. And the CVE list feeds into that National Vulnerability Database from NIST. And that database is actually synchronized with the MITRE CVE list behind the scenes. So, to look at it from another perspective, vulnerability management is the overall process. That's the discipline, which includes routine vulnerability scans and periodic vulnerability assessments. So, vulnerability scanners can detect known security vulnerabilities, weaknesses, absence of patches, or weak passwords, and surface to us a list of vulnerabilities and their severity, and typically an accompanying CVE ID. And we use those scanners to create the scans that we can then use as part of our vulnerability assessment, where we go beyond the technical scans, and we not only review those reports, we prioritize, we may go out and audit other aspects of our services. But it's a process where we're really analyzing, typically with human input. So, if we look at it visually, we've got vulnerability management is your overarching discipline. The vulnerability assessment would include a vulnerability scan, and then we analyze the vulnerabilities within that report. We can take inputs from the CVSS and CVE to come to some conclusions and priorities about how we're going to address those vulnerabilities. The CVEs can help with tracking, prioritization, and remediation, but at the end of the day, you still need that smart person in the chair that can look at that vulnerability and assess the exploitability, the severity, in the context of the other layers of security that are in place. The vulnerability scanner identifies the vulnerability. It doesn't have that extra layer of context to help determine what the exploitability is in your environment.

So, let's talk about vulnerability scans and scanners and how they factor into the process. So, the role of vulnerability scans in monitoring and maintenance. So, the idea with a scan is to identify weaknesses in your IT infrastructure. We're using automated tools to scan systems for known vulnerabilities. Common tools would include Tenable, Qualys makes a very common scanner, many out there, and they're going to vary a bit in their capabilities. There are some common themes, though. And the reports of the identified weaknesses will typically categorize their severity. Often, they're going to have that CVE and potentially the CVSS. They may also even suggest potential remediation steps, depends on the tool. At the end of the day, regular vulnerability scans can verify the efficacy of your configuration management and identify new issues and regressions. It's pretty common that when we find a vulnerability that it's due to some regression somewhere that perhaps we've addressed in years past and somehow we've got a piece of technology that's, you know, managed to step around a policy, or a policy was unintentionally modified, and now some configuration is no longer being enforced. And so, what we see very common is a monthly vulnerability scan can establish a pattern in which the team can quickly spot negative changes month to month. And in environments I work with, we do this, and occasionally we do find something that has regressed, and we'll go back and address it as quickly as we can. People are not perfect, accidents happen. And a recurring vulnerability scan can help us identify where perhaps we have a regression in a policy-based configuration or a security control baseline.

And the scan, though, is assessing possible vulnerabilities in our computers, our network, and really any equipment that can be exploited. We can point a vulnerability scanner at a range of addresses and make a number of checks, but the capabilities, the types of scans we can do, will vary. For example, a credentialed scan, where we give the vulnerability scanner a login, a credential scan is a much more powerful version because it has higher privileges than a non-credentialed scan. It can spot vulnerabilities that require privilege, like non-expiring passwords. A non-credentialed scan has lower privileges than the credential scan, obviously. It will find vulnerabilities that any attacker would easily find. These kinds of scans can find missing patches and some protocol vulnerabilities. So, each of these have their place, and you'll want to use them both. Non-intrusive scans, these are passive, and they merely report vulnerabilities. They don't cause damage to your system or probe in any way. That's normally what we're working with. Intrusive scans can cause damage as they try to exploit the vulnerability and should be used in a sandbox and not your live production system. I don't see these used as often, of course. And configuration review. So, configuration compliance scanners, and for example, the Desired State Configuration in PowerShell can ensure that no deviations are made to the security configuration of a system. But the combination of techniques can reveal which vulnerabilities are most easily exploitable in a live environment. Network scans can look at computers and devices on the network and help identify weaknesses in their security. So, this is where we can often find services that are listening on our network that we don't expect should be there. We can find potential protocol vulnerabilities. Application scans. So, you'll have scanners that are specialized to look at applications and perform regression testing to make sure that our code doesn't have any exploitable deficiencies. Web application scans may crawl through a website as if they're a search engine, looking for vulnerabilities, perform an automated check for application vulnerabilities like cross-site scripting or SQL injection, the types of vulnerabilities that would show up in the OWASP Top 10 list. But there are many sophisticated web application scanners available, due in part to mass adoption of cloud computing. So, you have many options that you can employ today.

And another technique we can use to identify and assess vulnerabilities is the penetration test. An authorized simulated cyber attack on a system, network, or web application, whatever our scope may be, to evaluate its security. Effectively, an ethical hacker using the same tools, techniques, and processes as real attackers to find and demonstrate vulnerabilities. And there are a few different approaches we can take to penetration testing. There's the known environment test, where the tester is given a map of target systems and networks, and they go into the test with substantial or full information of the target systems and the networks. Typically, we'll tell them quite a bit about the network and what types of systems perhaps reside on those networks. This is also called a white box test. Then there's the unknown environment, where the penetration tester knows nothing about the target systems and networks. They go in completely blind, and they build out a database of everything they find as they go. That's a black box test. And then there's some middle ground, a partially known environment, where limited information is shared with the tester, sometimes in the form of logon credentials. It's intended to simulate the level of knowledge that a hacker with long-term access to a system would achieve through research and system footprinting. We call that a gray box test. And we find these are effective when used together. For example, if we have a couple of black box, you know, unknown environment tests come back clean, that's where we move into a partially or known environment test, where we give the penetration tester more information so they can dig deeper to find vulnerabilities in the inner layers of our environment. So, we can continue to strengthen the security posture.

And with the penetration test, it's important we have rules of engagement that define the purpose of the test and what the scope will be for the people who are performing the test on the network. And this really ensures everyone will be aware of the scope, what systems will be considered, the date, time, any constraints that everyone should be aware of. A penetration test should never happen without a signed contract and rules of engagement. And a couple of techniques worth mentioning: there's lateral movement. So, this is where the pen tester gains access to an initial system and then they try to move to other devices on the inside of the network. So, if our pen tester can compromise a system, lateral movement is something we would like them to attempt so we can understand the strength of our security once an attacker has breached that trusted network. Privilege escalation. This is a security hole created when code is executed with higher privileges than those of the user running it. Something we'd also typically ask a penetration tester to attempt. If they can compromise a system, try to elevate your privilege and execute commands with higher privileges. Generally, it's a higher-level account, but in some cases, they may manage horizontal privileged escalation, where a user gains access to another user's resources. And then there's persistence. So, in the context of penetration testing, this refers to the tester's ability to achieve a persistent presence on the exploited system long enough for a bad actor to gain in-depth access. So, they would have a presence that survives across reboots and is not wiped out by anti-malware software, but effectively enabling the ability to reconnect to the compromised host and to use it as a remote access tool over time.

In some organizations, particularly larger organizations, will carry out different exercise types in the context of penetration testing to exercise their capabilities. There's the

Red team, which are internal or external professionals dedicated to testing the effectiveness of a security program by emulating the tools and techniques of likely attackers. This is offense in the context of the exercise.

The blue team is your internal security team that defends against both real attackers and the red teams. They are defense.

And you'll typically see purple team, which exists to ensure and maximize the effectiveness of the red and blue teams. It's process improvement. It's not actually a separate team; it is the red team and blue team together working to improve the process. Red plus blue mixed together equals purple, thus the reference.

And you may assign a white team. These are the folks responsible for overseeing an engagement or a competition between a red team of mock attackers and a blue team of actual defenders. They are effectively the judge or referee.

So let's talk about the difference between penetration testing and a vulnerability scan because the two seem different in some respects, but there are some key differences here and some key differences in their capabilities. So the vulnerability scan and the penetration test.

A vulnerability scan will identify weaknesses in your infrastructure. And a penetration tester may perform a vulnerability scan, but they're going to go further than that. It's a more in-depth exam, similar to a simulated cyber attack. So your vulnerability scanner is using an automated tool to scan systems for known vulnerabilities. On the penetration test side, it's going to be a combination of automated tools and manual techniques, which involves the expertise of the penetration tester.

A vulnerability scan reports the identified weaknesses and categorizes their severity, often that CVE ID. On the penetration test side, they're attempting to exploit vulnerabilities and assess their potential impact. A vulnerability scan may also suggest potential remediation steps. The penetration test is going to help you understand how vulnerable you are to real-world attacks and how much damage could be done.

So think of a vulnerability scan as like a fire alarm. It warns of a fire, but it doesn't say exactly where or how severe it is. That's why in a vulnerability assessment, we really have to assess how severe and exploitable that vulnerability is. A penetration test is going quite a bit further. It's like a firefighter testing the fire alarm and the sprinkler system and telling you if you're in working order or not.

Really, almost anyone could perform a vulnerability scan. In the organizations I work with, the vulnerability scans that happen month-to-month, it's often a tier one sock analyst doing that scan. It's not one of the senior personnel. There's somebody churning out that report every month for us to look at. The penetration tester is someone with special skills. So we're going to be able to identify more complex vulnerabilities on the penetration test side when we talked about vulnerabilities earlier, where there's interdependencies, there's linkages, where perhaps we can only compromise system B or component B after we've compromised component A. A penetration test is going to be able to help us to identify vulnerabilities that are potentially layers deep, where a vulnerability scan is not going to be so helpful in that respect.

Vulnerability scans are generally not intrusive. As I mentioned, your penetration test is intrusive. It may be disruptive if you don't do it right.

Let's talk about security control baselines. So a security control baseline is a predefined set of security controls aligned with the organization's risk tolerance and compliance requirements. So it represents a minimum security requirement configuration that the organization has to maintain to manage risk at an acceptable level. So the baselines are often developed using guidance from frameworks like NIST 800-53 or ISO 27001 and the accompanying ISO 27002, which has the control guidance, or it may come from something as simple as an organizational policy.

But the baseline can help compare where you should be versus where you actually are in terms of security control maturity. They provide the essential building blocks for an effective risk management program, ensuring that we have consistency in our security configurations. They give us structure, measurability, and that consistency. So if a setting that should be in place is no longer in place, we can spot the regression and potentially automate the repair of that regression.

But different baselines may be required for different data classifications. So the security configuration for a system with confidential data is going to vary from a system that hosts public data, for example.

And a few key considerations in developing your security control baselines: Context really matters. So the baselines have to be tailored to the organization's specific needs, their risk appetite, culture, structure, available resources, budget. Generic standards like NIST, ISO, and COBIT are going to offer guidance, but they're going to require customization. Typically, we want to consider people and processes in addition to technology when we're defining our baselines. We can have baselines that define more than just technical controls. So think of procedural and physical security baselines, for example, how we secure our physical locations.

And a classification scheme. So a clear data classification scheme is important for establishing appropriate baselines because the higher classification levels with our data will require more stringent controls. In terms of effectiveness and efficiency, the baselines are not based on a single test but on the overall capacity of controls to mitigate risk. So regular testing and evaluation are necessary to ensure that the baseline remains effective in mitigating risks over time.

And from a collaboration perspective, developing and implementing baselines generally requires collaboration across departments. It should be approved by someone in leadership or a steering committee. And internal audits and reviews can identify efficiencies that lead to the security control baselines being modified to ensure continuing compliance.

And your baselines provide several tangible benefits to the risk management program and security operations, including standardization. So ensuring consistent security measures across the enterprise because all of the entities of a specific type will be configured in the same fashion, for example, having a security control baseline for your Windows Enterprise desktops. Risk management: This provides a structured and measurable foundation for effective risk management. It's operationally efficient because baselines can simplify security operations and management and ensure we have a consistent configuration at scale.

And to that end, application of security control baselines is often, almost always in fact, automated and monitored for configuration drift and automatically corrected as needed through policy-based controls. And they're also measurable. It facilitates the measurement and evaluation of security effectiveness, which can be helpful in security assessments and audits. It's a great way to provide proof to an auditor without having to go to a great deal of additional effort in the context of that audit.

So there are a few key considerations to ensure that your baselines meet business needs and continue to do so over time. So risk appetite and tolerance are key, right? Your baselines have to align with the organization's risk appetite and tolerance. It's security aligning with the business. And baselines have to be regularly reviewed and updated to address changing threats, vulnerabilities, business needs. So it's a continuous process. It's not a one-time activity or an occasional activity. And you want to use relevant metrics to measure the effectiveness and efficiency of the controls and baselines. The metrics should be specific, measurable, attainable, relevant, and timely. So the SMART metric paradigm we talked about earlier in the series.

And our security control baselines need to be dynamic in that they need to adapt and flex to changes in the environment. And there are several factors or events that can trigger the need to modify existing baselines, sometimes urgently. So an incident, for example, any security incident, whether it's due to a control failure or a lack of control, can necessitate a reassessment of risk and may require adjustments to the baseline. A root cause analysis is going to be important in that case to make sure we're addressing the cause of the incident.

Or the change is effective. Organizational changes like mergers and acquisitions or a decision to migrate to public cloud could definitely trigger a change in baseline. Continuous monitoring and assessment of controls can certainly reveal degradation over time or identify areas where controls are no longer effective. And this can be as simple as changes to an operating system over time as patches roll through, maybe a control isn't as effective now as it was before. A minor change, but this triggers the need to update the baselines. And we always have to be watching for those triggers.

And we could encounter external events outside the organization: protests, civil unrest, natural disasters that could necessitate temporary or permanent adjustments to our physical security baselines. Legal and regulatory changes. So new or updated laws and regulations might mandate changes to security controls, and that is going to flow down to our baselines for sure. Changing risk appetite. So if the organization's risk appetite shifts, if our leadership has a change in strategy, it may cause us to adjust our security baselines to match the organization's change in their appetite for risk. New threats and vulnerabilities. Of course, the emergence of new threats or vulnerabilities is going to require a reassessment of risk. It might lead to changes in the baselines to ensure continued efficacy.

System changes could be another source of a need to update our security control baseline. So any change to a system, an app, or infrastructure can introduce new vulnerabilities that require a baseline adjustment. And we have to review our baselines on a regular basis just to ensure they remain effective as threats evolve, vulnerabilities may crop up in the environment, or business requirements change. But maintaining an appropriate level of security should really be viewed as a continuous process.

And it's not just internal changes. Again, remember that just as we identify assets outside the organization, changes outside the organization that affect our internal organization, such as vendor updates where we might identify new vulnerabilities or changes in their products, for example, just a normal side effect of software version updates may necessitate modifications to the related security baselines.

Okay, let's put what you've learned in section 2.8.2 to the test, or the practice question. And our question is: Which is the best way to assess and prioritize the overall risk deriving from a series of vulnerabilities in related systems? So we're looking for the best way to assess risk in the aggregate across a series of vulnerabilities in linked systems. Our options are A) Security audits, B) Risk assessments, C) Penetration tests, or D) Vulnerability scans.

So we need to assess and prioritize aggregate risk across a series of vulnerabilities and linked systems. So the fact that the systems are linked, that means we're talking about interdependencies here. So that means that one vulnerability might not be exploitable without first exploiting a vulnerability somewhere upstream in the linkage. So that means I can take two answers right off the table here. Security audits and risk assessments, which aren't going to actively test the systems in a way that will be meaningful in this sort of assessment and prioritization.

And vulnerability scans and penetration tests are both active technical exercises of our security. So they are assessing in an active technical way. But one of these is going to be better suited than the other to assessing the vulnerabilities in linked systems where we might have to compromise one in order to detect another. And in that case, there's only one clear answer here, and that is C) Penetration test. In fact, penetration tests are about the only type of security assessment that attempts to exploit vulnerabilities sequentially, linking them together and providing a measurement and prioritization of risks. We're not going to get that with a simple vulnerability scan, which is going to basically scan individual vulnerabilities. It's not going to compile those with any additional context that allows us to get to that answer.

Moving on to section 2.A.3, which is risk assessment and analysis. So our important takeaways here are going to be fully understanding the relationship and differences between risk management, risk assessment, and risk analysis. And you'll notice that qualitative, semi-quantitative, and quantitative risk analysis are mentioned here. We're going to dig into those quantitative formulas that you won't be tested on directly in terms of memorization, but you will be expected to know how to use when confronted with a scenario on the exam.

So risk assessment and analysis sound pretty similar, maybe even interchangeable. But what's the difference here? Well, risk assessment is the broader process of identifying, analyzing, evaluating, and prioritizing potential risks. It encompasses the entire lifecycle from initial identification to developing mitigation strategies. Risk analysis is the specific step within risk assessment focused on analyzing identified risks, like evaluating likelihood and impact of identified risks and detailed examination of the characteristics of particular risks. So in essence, risk assessment provides the strategic overview, while risk analysis delivers the tactical insights needed to make informed decisions about risk management.

So essentially, risk management is the overarching strategy for dealing with risks to ensure the organization meets their goals. And then we have risk assessment. And ISACA lays out a three-phase risk assessment process: risk identification, risk analysis, and risk evaluation. So risk assessment is that broader process of identifying, analyzing, evaluating, and prioritizing potential risks. And risk analysis is that subset of risk assessment that dives deeper into the specifics of identified risks.

So let's look at the three phases of risk assessment because the exam will test your understanding of these phases. So we have risk identification, risk analysis, and risk evaluation. So identification: This is where we're asking ourselves, "What could go wrong?" We're identifying potential risks. This involves identifying assets, identifying threats (whether they're intentional, accidental, or natural), and identifying vulnerabilities (the weaknesses). And then identifying any existing controls. There certainly may be protections in place, but we'll need to at some point decide if those existing controls are adequate. And then determining potential consequences or impacts.

Analysis: So that's where we're asking, "How likely is it to go wrong, and how bad would it be? What is the worst that can happen?" So this involves assessing the probability of the threat exploiting the vulnerability, assessing the impact in terms of financial, reputational, operational, legal, etc., if that threat were realized. And this often involves qualitative or quantitative risk analysis.

And then we have risk evaluation, where we ask ourselves, "Is the risk acceptable?" So this involves comparing the analyzed risk level to the organization's risk appetite, determining if the risk is within acceptable tolerance levels, and then making a decision: Do we accept, mitigate, transfer, or avoid this risk? That's what we call risk treatment. We're going to dive into the details of risk treatment and our options a bit later in the series. But a good chunk of the technical knowledge and experience that ISACA assumes you've come into this exam with will come into play in the risk treatment process, where we are selecting appropriate controls.

So let's talk about the risk management context. The risk management context refers to the overarching environment in which an organization's risk management program operates. It sets the stage for how risks are identified, analyzed, and addressed by defining strategic goals and objectives (so what the organization is trying to achieve and how risk management can support those business aims), regulatory environment (the laws, regulations, and standards the organization has to follow, which help determine acceptable actions and constraints), risk appetite and tolerance (so how much risk is the organization willing to accept while still pursuing its objectives), and the scope and boundaries (which parts of the business are covered by the risk program, the regions, the business unit, who the stakeholders are, and how those responsibilities are assigned).

By laying out these factors, the risk management context ensures any security measures or risk controls align with the organization's broader mission, legal and regulatory requirements, and within acceptable risk thresholds. So this will be influenced by internal and external factors. So from inside the business, the internal environment: mission, goals, objectives, business strategies, financial health, current risk practices, our organizational maturity. And from outside the environment: market conditions, economic conditions, applicable laws and regulations, social and political environment, external stakeholders, external threats and threat actors, our supply chain, regulators, partners, suppliers.

All right, and that brings us to alignment. So a well-defined risk context ensures that business goals and risk mitigation efforts reinforce each other. In global organizations, the context may actually differ by region due to legal, cultural, and market factors. So it's not going to be the same in every region and every country. And tailoring the risk management program to these nuances helps maintain compliance and supports the organization's strategic objectives.

So the key considerations for the exam: Regulatory constraints. So the CISM questions will often test understanding of how laws shape risk context and influence priorities. But remember, since compliance with these elements is mandatory, these will often take priority over other considerations. Now, there is certainly a business decision involved in compliance. We'll unpack that a bit later, but unless there's a good reason not to be compliant, we're going to assume compliance is mandatory. But it is certainly a business decision.

Risk appetite statement. So the leadership's definition of acceptable risk is essential. It's central to all of our decision-making here. So do expect questions on balancing risk-taking with risk avoidance through the lens of the business's risk appetite and tolerance.

And then documentation and communication. So be prepared for questions on the importance of clearly documenting the risk context so stakeholders understand its boundaries and rationale. This means distilling technical concepts into non-technical language for business leaders. An important part of communication on the whole, right? We always need to be tailoring communication to our audience, appropriate language, and appropriate communication channels, and appropriate schedule or cadence.

So bottom line: Determining the risk management context is about understanding both the internal and external conditions that shape an organization's threat landscape. And by establishing clear boundaries aligned with strategic objectives, regulatory requirements, defined risk appetites, information security leaders can design risk processes that effectively support the business.

So just to walk through the core risk management processes then from an ISACA perspective: risk identification, we assess those risks; risk response and mitigation; and then ongoing risk and control monitoring and reporting. We make sure those controls remain effective. And remember, risk analysis is that subset where we're looking at individual risks and analyzing the conditions there. Response and mitigation, that's more or less where treatment is happening. And right here in monitoring and reporting, we're identifying changes, driving improvements there based on the continued effectiveness of those controls.

So because risk is ongoing, the CISM perspective is that risk management should be viewed as a continuous, adaptive loop. And you should appreciate the importance of change management in the risk management process. So any change to hardware, software, facilities, or processes can introduce new vulnerabilities. So those changes must go through the change management process. And the role of the security manager here is to participate in that change management committee to ensure all changes receive appropriate security review, to document and analyze any deviation from security policies and standards before final approval.

And the enterprise impact here is that we're really extending beyond IT owners to facilitate management, business continuity, and outsourced services. So we're looking at the business picture. And this aligns security requirements with normal operational changes, system upgrades, data center blueprint changes, essentially ensuring security alignment with the business. Are you tired of hearing that yet? It's a big focus. But formalized change management processes can reduce unintended security gaps.

Bottom line: So if we think about risk in the context of physical security and facilities management, physical security systems increasingly with IT networks, which introduces new vulnerabilities, new potential attack vectors. And a lack of standardized hardware and software across dispersed sites can make implementation of consistent security roles difficult. So our facilities concerns include making sure we have contracts for facility services that include adequate SLAs and emergency response clauses. Undocumented or unreviewed changes in facilities infrastructure can impact our business continuity, and we always need to bear that in mind.

Human factors represent a critical source of risk because that change management process involves people, incorporating those changes, submitting those changes into change management. Bottom line here is inadequate oversight of facility changes or outsourced management can undermine security posture and business continuity. So if we're outsourcing some of our facility operations or business functions, not just IT, but any function really, that expands the risk management scope to third-party compliance and performance. We have to exercise due diligence in selecting suppliers, drafting contracts, monitoring their performance. And this includes periodically confirming that third parties adhere to your organization's security standards. This means that we're assessing vendor compliance typically at least once a year. And in fact, in the real world, the way we often see that play out is with a vendor survey where they can at least self-report their compliance. But always remember, risk assessment and tolerance thresholds must not be exceeded by any vendor or third-party partner. They factor in our adherence to the organization's risk appetite statement.

Okay, to recap, our best practices here: Risk management should be treated as a continuous process, that continuous loop. And our best practices include integrating with change management, so incorporating risk assessments and mitigation steps at each stage where changes occur, and we run those changes through change management. Maintain updated documentation, keep records of changes, both IT and facilities, and communicate them across the enterprise so everyone's aware. Assess human factors, include background screenings, contractual terms, role-based access for internal and external personnel, employees, and vendors. Conduct incremental updates. So rather than waiting for periodic major assessments, update risk analyses continuously or whenever a significant change is proposed. And align with business goals. We always want to keep security controls and risk decisions in sync with the organization's objectives and regulatory landscape.

And ISACA does highlight frequently that cost savings come when we identify security risks in early project stages rather than catching them after they happen. And let's touch on the role of the information security manager in all of this. That's essentially the role we're assuming here. The information security manager is a strategic leader who ensures that the risk management processes are interwoven into every phase of the system lifecycle. And by guiding policy compliance, evaluating the security implications of changes, and collaborating with both internal stakeholders and external service providers, the information security manager helps maintain a robust security posture throughout the enterprise.

So let's talk about key issues and focus areas for risk scenario analysis. In other words, what do we need to focus on when developing our risk scenarios? So we have credible risk scenarios for analysis, so we're not focused on irrelevant edge cases. So we have to involve stakeholders. So scenario analysis shouldn't be confined to just risk analysts and senior management. We want to include staff from all levels, particularly those in the first line of defense who are directly involved in daily operations. They're going to have valuable insights into what they see frequently and how we deal with it today. But bring in those frontline people.

Focus on a range of scenarios. So over-focusing on extreme low-probability events can lead to neglecting the more frequent but less severe incidents that can still have a significant impact. So consider a range of scenarios with varying severity levels. Analyze how less severe incidents can cascade or combine with other events to create a more complex and impactful negative outcome. Remember we talked about cascading risk.

Build complexity gradually. So walk, then run. Complex scenarios can definitely be challenging to analyze and visualize. When you're developing your organization's process to tackle these risk scenarios, start with simple scenarios and gradually increase complexity by showing how cascading events and dependencies, for example, can lead to more severe consequences.

Account for systemic and contagious risks. So systemic and contagious risk can have a significant impact on the enterprise, and you want to pay attention to scenarios where a single event affects a large group of enterprises, an entire system. We'd call that a systemic risk, or a more localized but still impactful risk that affects multiple business partners within a short time frame, contagious risk. Uh, so one of these is a localized scale, the other is a more global scale. Let me give you a couple of examples. So for systemic, we have Stuxnet, which was back in 2010, that infected Iran's nuclear systems. But Stuxnet spread around the globe. Or if we saw a global supply chain attack that impacted every bank, for example, that would be systemic. Contagious would be something more localized, like a phishing scam or a ransomware attack that spread amongst business partners who were communicating frequently.

Leverage scenario building for risk detection. Enterprises may not be aware of all potential risks, and scenario building can help identify risks that the enterprise might not have otherwise recognized. This is going to improve risk detection capabilities. And building these scenarios is going to involve multiple personas. You'll need the business process folks in the room with the security team.

Focus on detectability. Can the enterprise observe and recognize something has gone wrong? And ensure currency and relevance. So risk factors and enterprise environment change over time, affecting the validity of our existing risk scenarios. We want to make sure that these scenarios are still relevant through changes over time. Regularly review and update risk scenarios to reflect changes in the business environment and landscape. Frequency depends on the risk profile, but at least annual reviews are typically recommended. But we want to make sure that our risk scenarios remain relevant.

So we're focusing on addressing risk that can actually happen in our environment. Manage the number of scenarios. A large number of detailed risk scenarios can be overwhelming and basically take resources away from more impactful activities. Aim for a manageable number of scenarios that accurately represent the business environment and its complexity. Use generic risk scenarios as a starting point and create more specific ones when they're necessary.

And utilize methodologies and tools and frameworks. So structured approaches can enhance the effectiveness of risk scenario analysis. So we could use methodologies for risk analysis like FAIR and HARM. We'll talk about FAIR and HARM here shortly. And brainstorming workshops to generate a wider range of scenarios and ensure buy-in from our stakeholders, that everyone agrees we have relevant scenarios.

And focus on response and recovery. Scenario building shouldn't just identify risks, but should also inform response and recovery strategies. So we want to analyze how the enterprise would respond in different scenarios and identify areas for improvement in its resilience capabilities.

Now, I'd like to give you a list that provides a framework for characterizing and analyzing risks that aligns with ISACA guidance. So, exam relevant. Key characteristics of a risk from the ISACA perspective: The asset or the resource. So what is at stake? This could be tangible, like equipment or data, or intangible, like the organization's reputation or brand value. Threat actor. Who or what poses the threat? This could be internal, like employees or systems, or external, competitors, natural disasters, or actual threat actors. The threat type. What is the nature of the threat? Is it intentional? Is it malicious or is it accidental? What is the motivation behind the threat? Exposure. Where and how is the asset vulnerable? Are there weaknesses in security controls, physical locations, or operational processes? Frequency. How likely is the threat to occur? So this involves estimating probability and potential timing of the event. The resulting event. What specific event could occur due to the threat? This could be data breaches, system failures, or business disruptions. And the consequences. What are the potential impacts of the event? This could include financial losses, reputational damages, or operational inefficiencies. Protective mechanisms. What measures, what controls are in place already to mitigate the risk? This could include security controls, policies, or procedures. But by understanding these components, you can better identify, assess, and mitigate potential threats.

So for that risk scenario, the scenario that describes a potential threat to a specific asset or a resource, details what might occur, how it happens, potential impact. Let me give you a list of characteristics here that will get you started on developing your own risk scenarios and appreciating what we're talking about there. The threat type could be malicious, accidental, system air failure, a natural disaster like a flood, some sort of external requirement. The actor: Is it internal? Is it a staff or a contractor? Is it external? Is it a competitor, a hacker, a regulator, a vendor, natural source? What's the event? Data disclosure, process interruption, theft, external business driver, inappropriate use. The asset or resource. So these could be people in skills, organizational structures, processes, facilities, IT infrastructures that drive business processes, our sensitive information, our business critical applications. The frequency: That one's simple, right? How often an event might occur in a given environment? What's the frequency? The loss magnitude: The potential financial impact or disruption to business process. So the combination of these components helps us estimate the frequency and the impact, which are the two key factors in determining overall risk.

So the risk assessment process from an ISACA perspective has four phases. And more important than memorizing the phases is understanding the assessment process and considerations in security control selection. And in security control selection, that's where your past knowledge of the more technical aspects of security are going to come into play. You're not going to be tested on them directly, but it's that foundational knowledge you're more or less expected to walk into this exam with already in your head. But risk assessment is foundational for determining how to protect business assets effectively. So it starts with risk identification. The purpose here: Identify and document all potential risks the enterprise could face. The focus is to uncover assets, vulnerabilities, threats, and relevant business processes or regulations.

And then risk analysis, where we're drilling down on the specific risks, estimating the frequency and magnitude, the impact of identified IT risk scenarios. Our activities here: we're going to evaluate asset value, identify threats and vulnerabilities, assess probability of an event, determine the potential consequences, the impact. And our outcome here is a quantifiable or qualitative understanding of the organization's risk posture. So qualitative, we're talking about relative terms like low, medium, high. Quantitative, as where we're using formulaic calculations to come to a number.

Risk evaluation. So our purpose here: Compare the result of the risk analysis against the organization's defined risk appetite or tolerance criteria. Here we're looking at the risk types, right? Operational, technical, financial, regulatory, legal, legal, social, environmental. Our focus is to decide on appropriate risk response: Do we avoid the risk, mitigate it, transfer it through something like insurance, or do we simply accept the risk because it's within limits? But it's going to be aligned with enterprise goals, internal policies and procedures, our risk appetite as an organization, to be sure.

And then risk treatment. The purpose here: To formulate recommended actions based on the outcomes of risk analysis and evaluation. The focus here is a plan or a strategy detailing which controls, countermeasures, or activities to implement to manage risks within acceptable levels. So to look at it another way: We identify, determine what sensitive data exists, where it resides, how it's processed, stored, and accessed. Then we assess the situation for each area where data exists. Are there vulnerabilities, and are those vulnerabilities exploitable, putting our sensitive data at risk? And then how does it relate to our limits? So if the vulnerability, if the risk is ultimately within our limits, we're simply going to monitor residual risk for changes. If not, we'll evaluate potential responses. What controls might we put in place? And that's really the driver for accepting the risk. If the risk is within our appetite thresholds, yes, we can accept. If it's not, if it's outside our tolerance level, no, we're going to respond.

We discussed systemic and contagious risk earlier. I want to describe cascading risk to you as well. So cascading risk occurs when one failure triggers a chain reaction of failures that amplifies the overall impact of those smaller failures. So how this can happen: U minor vulnerabilities, each seemingly acceptable alone, can compound when chained together. And this can be from multiple sources, not just technical sources, but non-technical dependencies like our supply chain or financial processes, where we have smaller failures that when combined push the organization over their risk thresholds where it's no longer acceptable.

So let's look at an example: A fraudulent accounts payable process allowed invoices below a certain threshold to be paid without a corresponding purchase order. So technical controls only flagged larger invoices. The result is multiple smaller fraudulent invoices exceeding a quarter of a million dollars went undetected because they came through in small amounts. The lesson here is that even well-designed individual controls can be exploited in combination if they're not reviewed holistically in the big picture.

And we talked about risk assessment approaches. I wanted to touch on those frameworks that were mentioned earlier. So there is Factor Analysis of Information Risk, or FAIR, which is a very widely recognized framework that helps break down information risk into its core components. It provides a structured approach to analyzing risk, acting as a valuable complement to other risk assessment methods. FAIR is the method that I prefer and use most often myself. I feel it's most accessible, it's best documented, they provide some tools to help. There is also the Holistic Approach to Risk Management, or HARM, which actually builds upon FAIR, offering a methodology to standardize and refine an organization's approach to risk analysis. It's not a FAIR replacement, it actually enhances FAIR.

And then there is Probabilistic Risk Analysis, or PRA. This framework is useful in analyzing complex systems. It's especially good for understanding risks across the entire lifecycle of a technological asset. The approach is based on probability, statistical theory, reliability engineering, and decision theory. So it's used in high criticality, high complexity scenarios. It was actually originally developed for the U.S. National Aeronautics and Space Administration, or NASA, here in the U.S., and the nuclear power industry. So not a framework you're going to encounter as frequently.

Now, we're going to dive into risk analysis methods. And ISACA recognizes three ways to evaluate risk to assets. They are quantitative, qualitative, and hybrid risk analysis. So quantitative risk analysis assigns a dollar value to evaluate effectiveness of countermeasures. It's objective. It uses formulas to come to that dollar figure to prioritize. We may often initially calculate using an impact and probability score, but we're ultimately going to get to those formulas.

Qualitative, on the other hand, uses a scoring system to rank threats and effectiveness of countermeasures on a relative scale. It's subjective in that respect. So it typically uses a relative low, medium, high scale. So we might see qualitative represented as a heat map, where we have a visual representation of risks affecting the organization, and it shows the severity with the most severe risks in red. But you see we're working in low, medium, high in terms of likelihood, we're working in low, medium, high in terms of impact, and using the relative severity in the color scale there to represent the impact.

And the third method is hybrid, which blends the quantitative and the qualitative, combining qualitative descriptions with a numerical range. Basically, qualitative terms are mapped to quantitative values. Hybrid is also called semi-quantitative, so the two are interchangeable terms. So in semi-quantitative, in hybrid, the method assigns ranged values used to qualitative descriptions, aiming to provide more consistency to the estimation process, better prioritization as a result. But by combining qualitative descriptions with numerical ranges, we improve accuracy while still maintaining some of that user-friendliness that we see with qualitative assessment. It provides more consistent estimations, though it gives us more accurate risk prioritization on the whole because we are quantifying, in a sense. So we can still then ultimately calculate that risk formula: risk equals impact times likelihood. If I have quantitative values mapped to those relative estimates, I can do the math.

So let me just show you. Example values for likelihood in a semi-quantitative system would include, for example, rare equaling one, and then going up the range here. Unlikely is two, moderate is three, likely is four, frequent is five. You see we also have a description of what each level means so we can be consistent in our application. For example, moderate with a value of three has been seen within the last five years. Likely, a value of four has been seen within the last year. Frequent occurs on a regular basis, multiple times a year. Makes sense. And then we can begin to do the math. That's our likelihood. Now let's look at the impact. So insignificant is one, minor is two, major is three, material impact four, catastrophic five. And you see we have a description there by that numeric value to ensure we are applying it consistently.

Now let's circle back to quantitative risk analysis and talk about those formulas. So here we're assigning a dollar value to evaluate effectiveness of countermeasures. It's objective. It uses formulas to calculate impact to ensure controls are cost-effective, to ensure we're not doing something silly like spending $110,000 a year to mitigate a risk that would only cost us $5,000 a year. That wouldn't be cost-effective. I'm going to walk you through the formulas in an example, bearing in mind that you're not going to be tested on your memorization of formulas. It's really about practical application. There are two figures in particular you need to be able to get to to assess, to analyze, and quantify risk. I'll point those out as we go. But let's step in and get started here.

So we're analyzing identified risks with that conversation that where we begin with what could go wrong, right? We're seeking to answer, "What will the impact be if it goes wrong?" That's our single loss expectancy in quantitative terms. How likely is it to happen? That's our annualized rate of occurrence. So how many times within a year is the event likely to happen? And that's typically going to be expressed as a decimal. Greater than one if it's more than once a year, less than one if it's less than once a year. So for example, if an impact happens twice a year, it has an annualized rate of occurrence of two, basically two times the year. An impact that happens once every two years has an annualized rate of occurrence or an annual rate of occurrence of 0.5. It happens once every other year. So an impact that happens once every five years has an annual rate of occurrence of 0.2. So I could take that one occurrence divided and divide it by five by the five years, and that gives me 0.2. So effectively, I am dividing the number of occurrences by the number of years. So two occurrences divided by one year is two. Uh, one occurrence every two years is 0.5. And then if we divide one occurrence by five years, the result is 0.2.

With these two figures, with single loss expectancy and the annualized rate of occurrence, we can calculate our annualized loss expectancy. So this is the possible yearly cost of all instances of a specific realized threat against a specific asset. So the formula here: Annualized Loss Expectancy = Single Loss Expectancy * Annualized Rate of Occurrence.

So we have a scenario here: It's estimated a tornado may strike a branch office once every five years, causing a 30% loss to a million-dollar building. So let's calculate our single occurrence or single loss expectancy. How significant will it be? Well, the exposure factor, or exposure factor, is 30% in this case. So the formula for single loss expectancy is the asset value times the exposure factor. We saw here that we have a million-dollar building. Our expected loss, our exposure factor is 30%. That's 0.3 when represented as a decimal. That means our single loss expectancy is $300,000. So that's the SLE. That's one of the figures you should be able to get to quickly for the exam. You should be able to do that math. They're not going to test you on the formula, they want to know that you use the formula if it comes up, bearing in mind you have a limited number of questions, right? So you're not going to see any topic all that much. But this formula, I would count as important in your ability to use it. All right, so that's our single loss.

Now let's go the next step. Let's calculate our annualized cost. So we said single loss expectancy on the million-dollar building at a 30% exposure factor is $300,000. The annualized rate of occurrence: this is going to happen once every five years. That means our annual rate of occurrence is 0.2. So let's do the math: $300,000 single loss expectancy times a 0.2 annualized rate of occurrence equals an annualized loss expectancy of $60,000. So when we are evaluating how effective, how efficient our control is, we want to make sure that we have a control that doesn't cost us more than $60,000 a year. So for example, if I were paying $70,000 a year for insurance to cover a $60,000 risk, I might want to go back and think about that strategy more carefully because I'm throwing $10,000 out the window every year in that scenario. So hopefully this gives you some perspective. I will give you a link to a longer video where I talk about quantitative risk analysis over in another exam, but this should get you over the line for exam day with the CISM.

Analyzing cloud service provider risks. So a CSP, or a cloud solution, and the associated risks will involve potentially many departments and focus areas. There'll be business units involved, vendor management, potentially privacy concerns because we're potentially storing sensitive data in the cloud. It is definitely going to be involved our security team. And CSP operations should also be considered. But we can't audit those directly. We can't even really contractually do much. But your major CSPs, your Microsoft Azure, Amazon's AWS, Google Cloud Platform, they are audited for ISO 27001 compliance. They will produce a SOC 2 Type 2 audit, and you can typically download those on demand. So you can check those. You can do your due diligence by simply downloading the audit reports they will provide to you by simply asking, by going to their website and downloading.

Now, there are other risk analysis methods out there that you can use, other techniques that tend to be more complex and less frequently used. They're called out by ISACA, so I wanted to share them with you here so you're familiar. There's Bayesian analysis, which uses prior knowledge or beliefs to inform the analysis of new data. It's basically using historical information. It updates the initial beliefs based on new evidence, resulting in a posterior probability. So it's leveraging prior experience heavily. There's Bow Tie analysis, which is a visual technique that represents risks in a bow tie shape. The knot of the bow tie represents the undesired event. The left side shows potential causes and threats, and the right side shows potential consequences. Controls and mitigation strategies are depicted as the lines connecting the causes and consequences to the knot. I don't expect you're going to get hands-on with any of these on the exam. This is really just to give you the high-level visibility and understanding that ISACA provides in their material.

And then there's the Delphi method. I see this one every now and again. It's an iterative process that involves a group of experts who provide anonymous opinions on a specific topic. This basically leaves everybody free to express their true opinions. They're doing it in isolation, so we avoid groupthink. And the facilitator summarizes the responses, brings them together, and then shares them with the group. But because they're anonymous, there's no fear of judgment, and there's no risk of groupthink. And the experts then revise their opinions based on the feedback, and the process is repeated until a consensus is reached. So a pretty effective strategy, I think.

Event Tree Analysis is a forward-looking technique that starts with an initiating event and analyzes the possible outcomes and their probabilities. It follows the branches of the tree, the possible outcomes. It's a useful tool for predicting the consequences of different scenarios. There's Fault Tree Analysis, which is a top-down approach that begins with an undesired event, the top event, and it works backward to identify the underlying causes. It helps them understand the root causes of failures and then to identify potential ways to prevent them. There's Markov analysis, which is a method used to model systems that transition between different states over time. It assumes that the probability of transitioning to a particular state depends only on the current state and not on past history. There's Monte Carlo analysis. This technique involves running simulations with random variables to estimate the distribution of possible outcomes. It can be used to assess the impact of uncertainty and risk in complex systems. And these Monte Carlo analysis techniques will basically run hundreds or thousands of simulations, even, and look at the distribution of outcomes.

The choice of method depends on the specific context and the goals of the assessment. These are all going to be a bit less likely. So I've mentioned risk treatment a few times. Let's dig in here. This is the practice of modifying risks, generally to lower the risk, of course. It typically begins with identifying and assessing risks by measuring the likelihood and impact, and the risks that are most likely to occur and most impactful would be prioritized for treatment. So our risk treatment is the organization's response to risk. And there are four primary treatments: There's risk avoidance, where the organization changes business practices to completely eliminate the potential that a risk will materialize. It may mean they completely avoid a business activity. It can negatively impact business opportunities because the business chooses simply not to undertake some activity that may generate revenue because they want to avoid that risk.

Risk mitigation: This is the process of applying security controls to reduce the probability and or the magnitude of a risk. There's risk transference, which shifts some of the impact of a risk from the organization experiencing the risk to another entity. Insurance is our most common example there. So if I simply mitigate a risk, what I'm doing there is reducing the amount of risk, and what's left over is the residual risk. Right? With risk transference, I'm handing that risk off to someone else, the insurance company. Now, as an organization, I am still accountable for that risk, but I'm transferring the responsibility over to the insurance company. Cyber insurance is a great example in this context.

And then there is risk acceptance. Deliberately choose to take no other risk management strategy and to simply continue operations as normal in the face of the risk. Of course, we

would continue to monitor that risk to ensure that it remains within the organization's boundaries, within their risk appetite. We'll use this when the cost of mitigation is less than the cost of impact. Do make sure you know these concepts and be ready to recognize examples on the exam. Definitely going to come up.

Now let's apply what we've learned in section 2A3 with a practice question. What is the primary reason for performing risk assessment on a continuous basis? Is it A) continual justification of the security budget, B) the risk environment is constantly changing, C) new vulnerabilities appear daily, D) to keep management up to date on risks?

So they're asking us what is the primary reason, the number one reason for performing risk assessment on a continuous basis. So there are a couple of answers I can cross off the list right away. I always want to try to eliminate obviously wrong answers as a first step. So even if I don't 100% know the final answer, I have a better chance of guessing the right answer. So I'm going to cross out A) continual justification of the security budget. We justify our budget once a year, more or less, so it's not going to be a daily activity. And I'm going to take D) keeping management up to date on risks. Our management perspective is tactical or strategic, depending on the manager we're working with. So they're looking more mid to long range. They're not there with us day-to-day in lockstep. We've talked a few times about making sure that our communication is tailored to our audience in the right format and at the right cadence. So day-to-day on this would be too much.

So is it B) the risk environment is constantly changing or C) new vulnerabilities appear daily that would cause us to perform risk assessment continually? Well, the answer here is B) the risk environment is constantly changing. It's not something that happens on a daily schedule, it happens when it happens, which is potentially all the time. It's impacted by factors like changes in technology, shifts in our business strategy, and these changes introduce new threats and vulnerabilities to the organization. So as a result, risk assessment should be performed continuously. Remember, it is an adaptive, continuous loop in the ISACA perspective.

And my friends, that's what I have for you for domain 2A. I hope you're getting value from the series. As always, if you have questions, reach out here in the comments or ping me on LinkedIn or Discord. Happy to help wherever I can. Expect that I'll drop domain 2B here in the next three days or so, and I'll look forward to seeing you in the next installment. Until next time, take care and stay safe. [Music]