Risk Assessment, Priorities, and Tolerance

Key Concepts

Risk assessment turns the identified list into a decision aid. Its job is not perfect prediction; it is to rank which risks deserve attention first, which can wait, and which must be formally accepted by an accountable leader. Most CC scenarios resolve to two variables: likelihood (how probable, based on exposure, known attacks, weakness severity, history, and current control strength) and impact (how bad for operations, people, finances, legal duty, customers, and reputation).

Qualitative assessment uses categories (low/medium/high). It is fast, intuitive, and appropriate when hard data is weak — the most common CC default. Quantitative assessment uses numbers and lets you compare a control's cost to expected loss. Know three CC formulas:

• Single Loss Expectancy (SLE) = Asset Value x Exposure Factor (the fraction of value lost per event).
• Annualized Rate of Occurrence (ARO) = how many times per year the event is expected.
• Annualized Loss Expectancy (ALE) = SLE x ARO.

Example: a laptop fleet worth $400,000 with a 25% exposure factor gives an SLE of $100,000. If theft happens twice a year (ARO = 2), ALE = $200,000. A $60,000 control that cuts ARO to 0.5 drops ALE to $50,000 — a $150,000 annual reduction for $60,000, so it is cost-justified. Beware false precision: bad inputs produce confident but wrong numbers, so match the method to the data quality and program maturity in the scenario.

Priority is not pure technical severity. A critical flaw on an isolated test box may matter less than a moderate flaw on an internet-facing customer portal. Priority = technical facts + business context (exposure, exploitability, data sensitivity, legal duty, safety, recovery difficulty).

Risk appetite is the broad level of risk leadership will take to meet objectives — a startup may accept more operational risk to move fast; a hospital or bank tolerates far less for outages or privacy. Risk tolerance is specific and measurable: "no more than 4 hours of downtime for online ordering," "zero public storage buckets holding customer data," "no unencrypted laptops carrying regulated records."

Exam Application

Inherent risk is the risk before controls; residual risk is what remains after controls. Suppose customer records sit in a cloud database. Inherent risk includes unauthorized access and data exposure. Encryption, MFA, least privilege, monitoring, backups, and change review reduce it. Residual risk persists because credentials can be phished, software can fail, and people make mistakes. Decision-makers must understand and sign off on the residual level.

Treatment must match appetite and tolerance:

• Risk above tolerance -> treat or escalate; do not choose "ignore."
• Risk below tolerance -> may be accepted and monitored. Acceptance is a deliberate, documented decision by the right owner, not silence.
• A help-desk analyst cannot accept enterprise legal risk; the business or risk owner must.

Scenario: a retailer finds unsupported point-of-sale systems on the same flat network as office workstations. Likelihood is elevated (no security fixes, plus phishing-exposed office users); impact is high (payment operations, customer trust, possible card-brand penalties). A high-priority response is network segmentation, a replacement plan, enhanced monitoring, and compensating controls until the systems are retired.

CC questions ask for the "best" or "most appropriate" action. If the scenario says the risk exceeds tolerance, never pick "accept and ignore." If it says the business owner has already accepted a documented low risk, do not overrule with a costly control unless a legal, regulatory, or safety duty forces action. Map the facts to likelihood, impact, and tolerance, and the keyed answer follows.

Roles and ownership appear in many CC items. The risk owner (usually the business owner of the asset or process) is accountable for the risk and signs off on acceptance; the security team advises and implements but does not own the business risk. Senior management sets risk appetite and is ultimately accountable for the program; the board or governance body provides oversight. When a scenario asks "who should accept this risk," the answer is the accountable business or risk owner at a level matching the risk magnitude — not the analyst who discovered it.

A frequent distractor is letting an IT technician unilaterally accept a high enterprise risk; reject it.

A risk register is the working record that ties all of this together. Expect to recognize its typical fields:

• A risk identifier and short description (asset, threat, vulnerability).
• Assessed likelihood and impact, and the resulting priority or rating.
• The risk owner and the chosen treatment.
• Current status, target date, and residual-risk level.

The register makes risk decisions traceable and reviewable, which is why auditors and leadership rely on it. Two more vocabulary contrasts worth locking in: threat modeling is forward-looking analysis of how an attacker could act, while risk assessment prices the likelihood and impact of those scenarios; and a key risk indicator (KRI) is a metric that warns when risk is trending toward or past tolerance, such as the count of systems missing critical patches.

On the exam, when data is thin and the scenario stresses speed or judgment, a qualitative answer is usually preferred over a falsely precise quantitative one — choose the method that matches the evidence the scenario actually provides.