# Likelihood

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/likelihood

## Quick definition

Likelihood is a way to measure how likely it is that a bad event will happen in your IT environment. It is used in risk management to decide which problems need attention first. You can think of it as asking, 'What are the chances of this threat actually happening?' This helps you prepare and protect your systems better.

## Simple meaning

Imagine you live in a house and you worry about different things that could go wrong, like a kitchen fire, a burglary, or a leaky roof. Likelihood is your best guess of how probable each event is. For example, if you often cook with the stove on high and leave the kitchen, the likelihood of a kitchen fire might be higher than for someone who always watches their cooking. In IT, likelihood works the same way. It is a judgment call based on past data, known threats, and your specific environment. If your company stores customer credit card information, the likelihood of a data breach might be higher because hackers target such data more often. If your system has weak passwords and no two-factor authentication, the chance of someone breaking in increases. Likelihood is not about how bad the event would be, but about how often it could occur. A very bad event that almost never happens might have a low likelihood, while a minor issue that happens every day has high likelihood. In risk management, you combine likelihood with impact, which is the potential damage, to determine the overall risk rating. For example, a tornado might have a very high impact on your data center, but if you are located in a region with almost no tornadoes, the likelihood is low, so your risk is lower than a company in Tornado Alley. IT professionals use likelihood to prioritize their security efforts. Instead of trying to fix everything at once, they focus on threats that are both likely to happen and could cause significant harm. This way, they use their limited time and budget effectively. Understanding likelihood helps you make smarter decisions about where to invest in security controls, such as firewalls, antivirus software, or employee training, to reduce the chance of a damaging incident.

## Technical definition

In formal risk management frameworks, such as NIST SP 800-30, ISO 31000, or the FAIR (Factor Analysis of Information Risk) model, likelihood is a core component used to calculate risk. Risk is typically expressed as the product of likelihood and impact, or more precisely for IT, risk = probability of a threat event times the magnitude of loss. Likelihood is not a single number but is derived from a combination of factors including threat capability, motivation, and the presence of vulnerabilities. For example, in a quantitative risk assessment, likelihood is often expressed as an annualized rate of occurrence (ARO). If historical data shows that a specific type of ransomware attack occurs once every three years in similar organizations, the ARO is 0.33. This number is then multiplied by the single loss expectancy (SLE) to compute the annualized loss expectancy (ALE). In qualitative assessments, likelihood is described with ordinal labels such as rare, unlikely, possible, likely, or almost certain. IT professionals assign these labels based on expert judgment, threat intelligence feeds, and vulnerability scan results. For instance, a server that is fully patched and behind a well-configured firewall may have a 'rare' likelihood of being compromised by a known exploit. In contrast, a legacy system with known unpatched vulnerabilities accessible from the internet may receive a 'likely' or 'almost certain' rating. When implementing a risk management program, likelihood assessment usually follows a structured process. First, you identify assets, such as databases or application servers. Then, you identify threats, such as malware, insider errors, or natural disasters. Next, you evaluate existing controls, such as encryption or access controls, that reduce the likelihood of a successful attack. Finally, you estimate the residual likelihood after controls are applied. This process is documented in a risk register, which is a living document that tracks identified risks, their likelihood ratings, impact scores, and mitigation plans. A common standard for this is ISO 27001, which requires organizations to assess and treat risks to achieve certification. In the context of IT certifications such as CompTIA Security+, CISSP, and CISA, candidates must understand that likelihood is a probabilistic estimate, not a certainty. It is based on available information and can change over time as new threats emerge or as controls improve. For exam questions, you might be asked to calculate risk based on given likelihood and impact values, or to determine which risk should be prioritized based on a combination of likelihood and impact ratings.

## Real-life example

Think about your daily drive to work. The likelihood of getting into a car accident depends on several factors: how well your car is maintained, the quality of the road, the weather, how many people are on the road at that time, and your own driving habits. If you drive on a clear day on a well-maintained highway with low traffic, the likelihood of an accident is low. But if it is pouring rain, you are on a gravel road with many potholes, and you are distracted by your phone, the likelihood increases significantly. You know this intuitively, and you adjust your behavior accordingly, maybe by driving slower or paying more attention. In the IT world, likelihood works in much the same way. Instead of a road, you have a network. Instead of weather, you have new vulnerabilities discovered daily. Instead of your driving ability, you have the skill level of potential attackers. Consider a company that uses outdated antivirus software on a server that holds employee payroll data. The likelihood of that server being infected by malware is higher compared to a server with up-to-date antivirus and a strict application whitelist. Just as you would check the weather before a long drive, an IT professional reviews threat intelligence and vulnerability reports to gauge the likelihood of an attack. They also look at factors like how often the system is patched, whether employees are trained to avoid phishing emails, and if the organization has proper firewalls and intrusion detection systems. If the likelihood is high, they take action: they patch the server, improve the firewall rules, or enforce multi-factor authentication. The analogy holds up because in both cases, you are making a judgment about the future based on observable conditions. The key difference is that in IT, we formalize this process with scales and documentation to ensure that decisions are consistent and defensible.

## Why it matters

Understanding likelihood is fundamental to effective IT risk management because it directly influences how resources are allocated. In a typical organization, the IT department has a limited budget, a finite number of staff hours, and a long list of potential security improvements. Without a clear sense of likelihood, every threat would appear equally urgent, leading to a reactive and inefficient approach. For example, a company might spend thousands of dollars on a specialized anti-drone system to protect its rooftop servers, while ignoring the high likelihood of a ransomware attack targeting its outdated email system. By assessing likelihood, the team can focus on the most probable threats first, reducing the organization's overall exposure. This is especially important for compliance reasons. Many regulatory frameworks, including PCI DSS, HIPAA, and GDPR, require organizations to perform risk assessments that consider likelihood. A documented likelihood assessment can demonstrate due diligence during an audit, potentially reducing fines or penalties if a breach does occur. For IT professionals, likelihood is a common language used to communicate risk to non-technical stakeholders, such as executives or board members. When you say, 'The likelihood of a data breach from phishing is high,' it is more meaningful than saying, 'Phishing is a problem.' It conveys urgency and helps justify investments in security awareness training or email filtering. In incident response planning, likelihood also shapes the scenarios that teams practice. For instance, a tabletop exercise for a likely scenario like a phishing incident is far more beneficial than one for a rare but terrifying scenario like a meteor strike on the data center. Finally, likelihood is not static. As an organization adopts new controls, such as endpoint detection and response (EDR) or zero-trust network access, the likelihood of certain threats decreases. Regularly reassessing likelihood allows the organization to track its security posture over time and adjust its strategy accordingly. This continuous improvement cycle is a core principle of modern IT risk management.

## Why it matters in exams

Likelihood is a key concept tested across multiple major IT certification exams. In CompTIA Security+, it appears under domain 1.0 (General Security Concepts) and domain 5.0 (Governance, Risk, and Compliance). Questions often require you to distinguish between likelihood and impact, or to select the appropriate risk response (avoid, mitigate, transfer, accept) based on a given combination of likelihood and impact. For example, a scenario might describe a system with a very high likelihood of exploitation and a very high impact, and you must choose to mitigate it immediately. In the CISSP exam, likelihood is part of the risk management domain. Candidates are expected to understand quantitative and qualitative risk analysis methods, including how to compute ALE (Annualized Loss Expectancy) from ARO (Annualized Rate of Occurrence) and SLE (Single Loss Expectancy). Exam questions may present data in a table and ask you to calculate the risk for different assets. You must also understand the difference between inherent risk (without controls) and residual risk (with controls), and how likelihood changes after controls are applied. The CISA exam from ISACA focuses heavily on risk assessment as part of the audit process. Questions may ask you to evaluate the effectiveness of controls based on how they reduce likelihood. For instance, you might be told that a firewall reduces the likelihood of external attacks from 'very high' to 'low,' and you need to determine if that is sufficient. In the Project Management Professional (PMP) exam, likelihood is used in the Perform Quantitative Risk Analysis process, where probability and impact are combined to prioritize individual project risks. IT risk management and project risk management share the same fundamental concepts. In the GIAC Security Essentials (GSEC) and Certified Ethical Hacker (CEH) exams, likelihood is less of a standalone topic but appears in the context of threat modeling and vulnerability management. For example, a question might ask you to prioritize which vulnerability to patch based on its likelihood of being exploited, often using CVSS (Common Vulnerability Scoring System) scores where the exploitability metrics directly represent likelihood. Across all these exams, the common thread is that you must be able to apply likelihood in a decision-making context, not just define it. Exam writers often design questions where candidates confuse likelihood with impact, so pay close attention to the wording. If the question asks about 'the chance of occurrence,' that is likelihood. If it asks about 'the severity of damage,' that is impact.

## How it appears in exam questions

Likelihood appears in several distinct question patterns across IT certification exams. The first and most common is the scenario-based question. You are given a short description of an organization's situation, including a threat and the existing controls. Then you are asked, 'What is the likelihood of this threat occurring?' or 'Given the following factors, which risk should be treated first?' For example: 'A small business uses an unpatched Windows Server 2008 system as a file server. They have no antivirus and no firewall. The server is connected to the internet. A new ransomware variant targets unpatched SMB vulnerabilities. What is the likelihood of a ransomware infection?' The correct answer would be 'high' or 'very high' because multiple vulnerabilities exist and the threat is active. The second pattern is the risk calculation question. You may be given a table with assets, threats, likelihood (as a percentage or label), and impact (as a dollar amount). You must calculate the risk score or ALE. For instance, 'Asset A has a likelihood of 0.2 and an impact of $50,000. What is the expected annual loss?' The answer is $10,000. You must be comfortable converting between qualitative labels and quantitative numbers if the exam provides conversion rules. The third pattern is the control effectiveness question. The question describes a control that was implemented, and you must assess how it changed the likelihood. Example: 'After implementing a Web Application Firewall (WAF), the likelihood of a SQL injection attack decreased from high to low. Which type of risk response is this?' The answer is mitigation, because you are reducing the likelihood. The fourth pattern is the prioritization question. You are given multiple risks with different likelihood and impact combinations, and you must choose the one that should be addressed first. For example, Risk 1: Likelihood high, Impact low. Risk 2: Likelihood low, Impact high. Risk 3: Likelihood medium, Impact medium. Using a risk matrix, Risk 3 might be the priority if it falls in the high-risk quadrant. You must be careful because the specific matrix used may vary by framework. The fifth pattern is the true/false or definition question. These are less common but appear in foundational exams like CompTIA Security+. For instance, 'Likelihood is the same as impact. True or False?' The answer is false. These questions test whether you understand the basic vocabulary. To handle all these patterns, focus on reading the scenario carefully, identifying whether the question is about probability or severity, and applying any given numbers or labels precisely.

## Example scenario

You are the IT security analyst for a medium-sized company called GreenLeaf Books, an online bookstore. The company has a web server that hosts the main e-commerce site, an internal database of customer information including names, addresses, and credit card details, and a small office network for employees. You are performing a risk assessment. One threat you identify is a distributed denial-of-service (DDoS) attack against the web server. You look at the company's controls. The web server is protected by a basic firewall, but there is no DDoS mitigation service like Cloudflare or AWS Shield. The company does not have a redundant hosting provider. The web server runs a popular open-source platform that has had DDoS vulnerabilities in the past. Now, you must assess the likelihood of a successful DDoS attack. First, you consider the threat landscape. The company is in the retail sector, which is a common target for DDoS attacks, especially during holiday seasons. Second, you think about your controls. The basic firewall alone is not enough to stop a large-scale DDoS attack. Third, you know that the server has limited bandwidth and processing power. Based on this, you estimate the likelihood as 'high' because the threat exists, your defenses are weak, and you are an attractive target. Next, you consider the impact. If the web server goes down, the company cannot make sales. For an online bookstore, this means lost revenue. Customer trust may be damaged. You estimate the impact as 'high' as well. Using a standard risk matrix, a risk with high likelihood and high impact is rated as 'critical.' You then present your findings to management, recommending they purchase a DDoS mitigation service as a mitigation measure. If implemented, the likelihood of a successful DDoS attack would drop to 'low' or 'medium,' because the service absorbs the attack traffic. In your exam, a similar scenario might ask you to determine the overall risk level or to choose the best next step. In this case, the correct answer would be to mitigate by deploying DDoS protection, rather than accepting the risk, transferring it via insurance, or avoiding it by taking the site offline permanently.

## Common mistakes

- **Mistake:** Confusing likelihood with impact. For example, thinking that a highly expensive breach automatically means high likelihood.
  - Why it is wrong: Likelihood only measures probability, not the severity of damage. A ransomware attack could cost millions (high impact) but if the organization has strong backups and defenses, the likelihood might be low.
  - Fix: Separate the two concepts in your mind. Ask yourself: 'How often could this happen?' (likelihood) vs. 'How much damage if it does?' (impact).
- **Mistake:** Assuming that because a threat is unlikely, it does not need any attention or control.
  - Why it is wrong: Even low-likelihood threats can have catastrophic impacts. For example, a meteor strike on a data center is extremely unlikely, but if it happens, the loss would be total. Some risk must still be addressed, often through insurance or disaster recovery planning.
  - Fix: Always pair likelihood with impact. A low-likelihood, high-impact risk might still require a mitigation or transfer strategy.
- **Mistake:** Using the same likelihood rating for all threats without considering specific controls or environment.
  - Why it is wrong: Likelihood is not a static value. It depends on the context: the same ransomware attack is far more likely against a system without patches than one fully updated. A one-size-fits-all approach leads to inaccurate risk assessments.
  - Fix: Tailor likelihood for each asset-threat pair based on current controls, vulnerability status, and threat intelligence.
- **Mistake:** Mixing up qualitative labels (like 'unlikely') with quantitative numbers without a clear conversion rule.
  - Why it is wrong: If an exam or framework does not provide a mapping, your subjective interpretation may differ from the intended answer. For example, 'possible' might mean 30% to one person and 10% to another.
  - Fix: In exams, always use the definitions provided in the question or the framework being tested. For your own assessments, document the conversion scale you use.
- **Mistake:** Thinking that implementing a single control completely eliminates likelihood to zero.
  - Why it is wrong: No control is perfect. Even the best firewall can be bypassed, and even the best training program cannot prevent every human error. Likelihood can be reduced, but rarely to zero.
  - Fix: Recognize that residual likelihood always exists. Risk management is about reducing likelihood to an acceptable level, not eliminating it entirely.

## Exam trap

{"trap":"The question describes a scenario where the threat event is extremely rare, but the impact is catastrophic. It then asks for the overall risk level, and some answer choices use high impact as the primary driver.","why_learners_choose_it":"Learners focus on the dramatic high impact and forget that risk is a combination of likelihood and impact. They see 'catastrophic' and automatically select 'high risk' without considering the low probability.","how_to_avoid_it":"Always remind yourself to check both factors. If the likelihood is 'rare' or 'very low,' the overall risk may be medium or low, even if the impact is severe. Use the risk matrix if provided, or logically combine the two dimensions."}

## Commonly confused with

- **Likelihood vs Impact:** Impact is the magnitude of harm or loss if the threat event occurs, while likelihood is the probability of that event happening. For example, a data breach might have a high impact (costly fines, reputational damage) but a low likelihood if strong security controls are in place. (Example: A fire in a data center could cause millions in damage (high impact), but if the data center has excellent fire suppression and is located in a low-risk area, the likelihood is low.)
- **Likelihood vs Vulnerability:** A vulnerability is a weakness in a system that can be exploited, while likelihood is the probability that an exploit will actually occur. A vulnerability does not automatically mean high likelihood; other factors like threat existence and attacker motivation also matter. (Example: A server has an unpatched vulnerability (weakness), but if that vulnerability is only exploitable locally by someone physically present, and the server is in a locked room with access controls, the likelihood of exploitation remains low.)
- **Likelihood vs Risk:** Risk is the combination of likelihood and impact. Likelihood is just one component of risk. Without considering impact, likelihood alone does not provide a complete picture of the danger. (Example: A phishing attack might have a high likelihood (many employees receive phishing emails daily), but if the organization has strong email security and employee training, the impact might be low, resulting in a moderate overall risk.)

## Step-by-step breakdown

1. **Identify the asset and the threat** — First, determine exactly what you are protecting (e.g., a database of customer credit cards) and what could harm it (e.g., a SQL injection attack). Without a clear pairing, you cannot estimate likelihood accurately.
2. **Evaluate existing controls** — List all the security measures already in place that could prevent or reduce the threat. For SQL injection, these include input validation, parameterized queries, a web application firewall, and regular vulnerability scanning. The more effective the controls, the lower the likelihood.
3. **Consider the threat capability and motivation** — Ask whether the attackers have the skill and resources to exploit the vulnerability. A nation-state actor targeting a defense contractor has high capability. Also assess motivation: is your data valuable, or is your organization a high-profile target? High motivation increases likelihood.
4. **Review historical data and threat intelligence** — Look at past incidents within your organization or similar ones. If ransomware has hit three similar companies in your industry in the past year, the likelihood is higher. Threat feeds from services like US-CERT or industry groups provide real-time data on active threats.
5. **Assign a likelihood rating using a consistent scale** — Choose a scale such as 1-5 or qualitative labels (rare, unlikely, possible, likely, almost certain). Apply it based on all the information gathered. Document the reasoning. For example, 'Likely (4/5) because the vulnerability is known, the exploit is publicly available, and no patch exists yet.'
6. **Combine with impact to determine risk** — Once likelihood is estimated, pair it with the impact rating in a risk matrix. The intersection gives the overall risk level (e.g., low, medium, high, critical). This final rating guides decisions on whether to mitigate, transfer, accept, or avoid the risk.

## Practical mini-lesson

In real-world IT practice, assessing likelihood is not a one-time academic exercise. It is an ongoing process integrated into vulnerability management, change control, and incident response. As a professional, you might use a Common Vulnerability Scoring System (CVSS) score from a vulnerability scanner to get a baseline idea of exploitability. The CVSS base score includes metrics like Attack Vector (network, adjacent, local) and Attack Complexity (low or high) which directly indicate likelihood. For example, a vulnerability with Attack Vector: Network and Attack Complexity: Low has a higher likelihood of being exploited than one that requires local access and high complexity. You would then adjust this score based on your environment. If the vulnerable service is not exposed to the internet, the likelihood drops. If it is exposed and there is known exploit code in the wild, the likelihood rises. In practice, you would also consider compensating controls. For instance, if the vulnerable service is running on a host with endpoint detection and response (EDR) that blocks the exploit behavior, the effective likelihood may be lower than the CVSS suggests. Another practical scenario is during a risk assessment for a new cloud deployment. You might be asked by management, 'How likely is it that our data in AWS S3 buckets will be leaked?' You would need to assess factors like: whether the buckets are properly configured (public access blocked), whether encryption is enabled, whether access keys are rotated, and whether there are any known AWS vulnerabilities. You would also check the shared responsibility model: is the misconfiguration on your side or AWS's? If the configuration is strong, likelihood is low. If you have no controls like S3 Block Public Access enabled, the likelihood increases significantly. A key professional nuance is that likelihood assessments must be defensible. If you rate a risk as 'high likelihood,' you must be able to justify it with evidence, such as a recent penetration test finding, a threat intelligence report, or an audit finding. This documentation is critical for audits under frameworks like SOC 2 or ISO 27001. When you implement a control, you must reassess the likelihood and update the risk register. This is part of the continuous improvement cycle. For example, after deploying multi-factor authentication for all remote access, the likelihood of a credential-based attack drops from high to medium or low. You should document this change and recalculate the risk score. Likelihood in practice is a dynamic, evidence-based judgment that directly influences security spending and operational priorities.

## Memory tip

Think of 'Likelihood' as 'Likely-hood', how likely is the hood (threat) to drop (exploit)?

## FAQ

**Is likelihood the same as probability?**

Yes, in risk management, likelihood and probability are often used interchangeably. Both refer to the chance that a specific threat will exploit a vulnerability.

**How do I assign a likelihood rating if I have no historical data?**

You can use qualitative methods, such as expert judgment, analogy with similar systems, or threat intelligence from industry reports. Even without hard data, you can categorize likelihood as low, medium, or high based on known factors like the presence of vulnerabilities and attacker motivations.

**What is the difference between likelihood and frequency?**

Likelihood is a general estimate of probability over a period, while frequency usually refers to actual historical occurrence counts. In practice, frequency can inform likelihood estimation.

**Can likelihood ever be zero?**

Theoretically, no. There is always some residual uncertainty. Even if controls are perfect today, new vulnerabilities or errors could emerge. In risk management, likelihood is rarely zero; it is reduced to an acceptable level.

**How does likelihood relate to residual risk?**

Residual risk is the risk that remains after controls are applied. It is assessed by considering the likelihood of a threat event given the controls in place. If controls are strong, residual likelihood is low.

**Do I need to reassess likelihood after every security update?**

Yes, ideally. Whenever a significant control is added, removed, or changed, the likelihood should be reassessed. In practice, many organizations do this on a regular cycle (quarterly or annually) or when a major threat emerges.

## Summary

Likelihood is a fundamental concept in IT risk management that represents the estimated probability of a threat exploiting a vulnerability. It is not the same as impact, vulnerability, or risk, but rather a key component used alongside impact to calculate overall risk. Understanding likelihood helps IT professionals prioritize security efforts, allocate resources efficiently, and communicate risk to non-technical stakeholders. In certification exams, likelihood appears in scenario-based questions, risk calculation exercises, and control evaluation tasks. The most common mistake is confusing likelihood with impact, but this can be avoided by remembering that likelihood is about 'chance' and impact is about 'damage.' To master likelihood, practice applying it in realistic scenarios, use the step-by-step breakdown provided, and always justify your rating. Whether you are studying for CompTIA Security+, CISSP, CISA, or PMP, a solid grasp of likelihood will help you answer exam questions correctly and perform effective risk assessments in your career. Remember: high impact does not automatically mean high risk if the likelihood is low, and low likelihood does not mean you can ignore a threat entirely. Use likelihood as a guide, but always pair it with impact for a complete risk picture.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/likelihood