CompTIA Security+ Risk Management Process

Risk management process

Risk management is the process of identifying risk, deciding how much risk is acceptable, and choosing what to do with risk that an organisation is not willing to carry.

In cyber security, risk usually comes from the relationship between assets, threats, vulnerabilities, likelihood, impact, and controls. A technical weakness is not automatically the highest priority just because it exists. It has to be understood in context: what could exploit it, what could be affected, how likely the event is, and what the result would cost operationally, financially, legally, or reputationally.

The basic process starts with identifying threats and vulnerabilities in the environment. From there, the risk can be assessed, prioritised, and treated through acceptance, avoidance, transference, or mitigation.

Risk terminology

Threats are possible events or actors that could have an adverse impact on the confidentiality, integrity, or availability of information or information systems.

Vulnerabilities are weaknesses in systems, processes, configurations, or controls that could be exploited by a threat.

Risk occurs where a threat can act on a vulnerability and cause impact.

Likelihood describes how probable the event is. Impact describes the effect if it occurs. Those two factors help decide priority. A low-impact issue that is likely to occur may need a different response from a high-impact event that is unlikely but still plausible.

Threats, vulnerabilities, and risk

Threats, vulnerabilities, and risk are related, but they are not the same thing. A vulnerability is a weakness. A threat is something that could use that weakness or cause harm. Risk is the exposure created when those two meet.

Risk identification includes looking for the threats and vulnerabilities that exist in the environment. Common categories include:

• External risks: risks that originate outside the organisation.
• Internal risks: risks that come from inside the organisation, including mistakes or malicious decisions by authorised users.
• Multiparty risks: risks that affect more than one organisation.
• Legacy systems: outdated systems with known or likely vulnerabilities.
• Intellectual property theft: disclosure or theft of information that could harm the organisation.
• Software compliance: software usage that breaks vendor terms or licensing rules and exposes the organisation to financial or legal risk.

These categories help separate technical issues from the wider business exposure. An old operating system, a careless insider, a supplier problem, and a licensing issue are different kinds of risk even if they all appear inside a security review.

Risk assessment

Risk assessments can be qualitative or quantitative.

Qualitative risk analysis is situational and ranked. Threats are assessed on a scale to compare risk, cost, and effect. This is useful when exact figures are unavailable or when the assessment depends on judgement, interviews, workshops, or expert input.

Quantitative risk analysis assigns figures to asset value, expected loss, and probability. It is more concrete, but it depends on reliable data. That can be difficult in technology environments where systems, threats, and controls change quickly.

Qualitative assessment techniques include:

• Brainstorming: collecting spontaneous ideas from a group or individual.
• Delphi technique: reaching anonymous group consensus through blind voting.
• Storyboarding: using diagrams or timelines to represent concepts and events.
• Focus groups: discussing a topic with a selected group.
• Surveys: collecting relevant information from a wider set of people.
• Questionnaires: asking structured questions of people who use or manage the technology.
• Checklists: comparing a system, process, task, or storage location against an inventory of expected items.
• One-to-one meetings: direct discussion between peers or stakeholders.
• Interviews: face-to-face discussion with subject matter experts or people with experience in the situation.

For quantitative risk assessment, these terms are commonly used:

• Asset Value (AV): the value or cost of the asset.
• Exposure Factor (EF): the percentage of damage or loss expected from one event.
• Single Loss Expectancy (SLE): the expected cost of one occurrence.
• Annual Rate of Occurrence (ARO): how often the event is expected to happen in one year.
• Annual Loss Expectancy (ALE): the expected loss over a year.

The simple calculations were:

SLE = EF x AV
ALE = SLE x ARO

If the annual loss expectancy is lower than the cost of a countermeasure, the countermeasure may not make financial sense. That does not mean the risk should be ignored, but it does show why cost, likelihood, and impact have to be considered together.

ARO can be hard to estimate because technology changes quickly and there may not be enough historic data for a new system, service, or threat.

Risk response options

Risk treatment commonly falls into four options: acceptance, avoidance, transference, and mitigation. Rejecting or ignoring risk is sometimes listed as a bad response, but it is not a valid risk-management strategy.

Risk acceptance

Risk acceptance, or risk tolerance, is not the same as ignoring risk. It means management has decided to accept the consequences because the cost or effort of reducing the risk further is not justified.

For example, an organisation might accept some residual social-engineering risk while focusing limited resources on endpoint protection, monitoring, and intrusion-detection capability. That decision should be documented and owned, not left as an assumption.

Risk avoidance

Risk avoidance means changing the activity or design so the risk is not taken in the same way. Deterrence can also support avoidance, where security features are used to discourage activity through fear of consequences, such as visible security cameras.

Examples of avoidance included:

• air-gapped networks;
• analogue processes such as pen and paper;
• sneaker-net, where information is moved physically rather than across a network;
• choosing a different software platform.

Risk transference

Risk transference means moving some of the cost or responsibility for loss to another organisation or service. Examples include purchasing insurance or outsourcing part of a protection function, such as using a provider for DDoS protection.

Transference does not remove all responsibility. The organisation still owns the business outcome and must understand what is being transferred, what remains, and what evidence is needed if the risk occurs.

Risk mitigation

Risk mitigation reduces risk by applying safeguards or controls that reduce likelihood, reduce impact, remove vulnerabilities, or make threats harder to act on.

Mitigation is usually where technical security controls appear. Examples include:

• proactive threat hunting;
• firewalls and endpoint security;
• web application firewalls;
• Group Policy;
• access control;
• user awareness and cyber hygiene for social-engineering risk;
• policies and procedures, including password and backup policies;
• vulnerability assessment and auditing, including penetration testing.

Windows Core Isolation is one example of a mitigation control: isolating core processes in memory can reduce the effectiveness of some malware and kernel-level attack paths. That example should be read as historical study context, not as a complete description of modern Windows hardening.

Security controls and mitigation

Security controls should be tied back to the risk they reduce. A firewall can reduce exposure. Endpoint protection can detect or block malicious behaviour. Access control limits who can reach sensitive systems or data. Monitoring improves visibility. Awareness training reduces some human-led risks. Vulnerability assessment finds weaknesses before they are exploited.

Good mitigation is not just adding a tool. It means choosing a safeguard that fits the asset, threat, vulnerability, likelihood, impact, and business context. The most cost-effective control is not always the most expensive one; it is the one that reduces the right risk to an acceptable level.

Risk management also requires a decision trail. Accepted risks, transferred risks, avoided risks, and mitigated risks should be visible to the people responsible for the system or process.

Currentness note

This is a historical Security+ study/archive post from 2021, not current exam guidance. CompTIA objectives, terminology, and examples change over time, so current certification preparation should use the latest official exam objectives and study material.