Risk assessment: quantitative, qualitative, and the third party you cannot audit

Why this matters

This is the largest single objective in domain 1 by the amount of ground it covers, and it is the one whose vocabulary the rest of the exam assumes. Every scenario that asks what you should do first, or which finding matters most, is a risk question wearing technical clothes.

It is also where the level difference between Security+ and SecurityX shows most clearly. Security+ asks you to recognise the terms. CAS-005 asks you to use them: to compute an annualised loss, to choose between quantitative and qualitative methods for a stated purpose, to identify what a third-party questionnaire does and does not establish, and to express a technical defect in terms a risk committee can act on.

The professional stake is that risk assessment is the mechanism by which security gets funded. A finding described as "TLS 1.0 is enabled" competes poorly for money. The same finding described as an annualised exposure against a stated appetite, with a treatment cost and a residual, is a decision somebody can take.

The lesson

SLE, ARO and ALE, worked end to end, and what the numbers are honestly worth

The quantitative model is small and it is worth being able to run it in both directions.

• Asset Value (AV) — what the asset is worth.
• Exposure Factor (EF) — the proportion of that value lost in one occurrence, as a decimal.
• Single Loss Expectancy (SLE) = AV × EF. The cost of one occurrence.
• Annualised Rate of Occurrence (ARO) — how many times per year, which is frequently a fraction.
• Annualised Loss Expectancy (ALE) = SLE × ARO. The expected cost per year.

Worked through: a customer database valued at £2,000,000. A credential-stuffing compromise is assessed to expose 15% of that value in one occurrence through notification costs, remediation, regulatory penalty and churn. SLE = £300,000. The event is judged to occur once every four years, so ARO = 0.25 and ALE = £75,000 per year.

Now run it the other way, which is the part that makes it useful. Multi-factor authentication on customer accounts is assessed to reduce the ARO to 0.05. The new ALE is £15,000, so the annual benefit is £60,000. If the control costs £20,000 a year to run, the cost–benefit is positive by £40,000. That comparison — ALE before minus ALE after minus annual cost of control — is the calculation CAS-005 expects you to be able to perform and is the one that converts a security preference into a funding case.

Two honesty notes that are themselves examinable. The arithmetic is exact and the inputs are estimates, so precision in the output is false: £75,000 is really "tens of thousands per year". And ALE is an expectation, which says nothing about the tail — a risk with a low ALE made of a rare catastrophic event needs different treatment from one with the same ALE made of frequent small losses. Scenarios describing a rare, existential event and a comfortable ALE are asking you to notice exactly that.

Qualitative scoring, its subjectivity, and why it still outperforms no assessment

Qualitative assessment rates likelihood and impact on ordinal scales — typically one to five — and combines them into a rating, often on a matrix.

Its weaknesses are real and you should be able to name them. The scales are subjective and vary between assessors. The labels invite arithmetic they do not support: a likelihood of 4 is not twice a likelihood of 2, so multiplying ordinals produces a number with no defensible meaning. Ratings cluster in the middle because assessors avoid extremes. And "high" carries no information about whether the exposure is thousands or millions, which makes prioritisation between two "high" risks impossible.

It is nevertheless the right method most of the time, for reasons worth understanding:

• It works where no credible frequency data exists, which is the normal case for novel or rare threats.
• It is fast enough to cover a whole estate, and coverage usually matters more than precision — a complete qualitative register beats a rigorous quantitative assessment of three risks.
• It is comprehensible to the business people who must accept the risk.

Three practices repair most of the weaknesses, and a scenario will often be describing the absence of one: define each scale point concretely ("impact 4 = regulatory notification required"), so two assessors reach the same score; calibrate periodically by re-scoring old risks against what actually happened; and quantify the top of the register, using qualitative methods to triage and quantitative methods on the handful that will attract real spending.

That hybrid — qualitative breadth, quantitative depth on the few that matter — is the professional norm and the answer a scenario about method selection is usually seeking.

Business impact analysis and how it differs from a risk assessment

These are routinely confused and the difference is clean.

A risk assessment asks: what could go wrong, how likely is it, how bad would it be, and what should we do about it? It is threat-led and it produces treatment decisions.

A business impact analysis asks: if this business process stopped, how quickly would the harm become unacceptable, and what does the process depend on? It is impact-led and deliberately threat-agnostic — it does not care whether the process stopped because of ransomware, a flood or a supplier failure.

BIA produces the recovery parameters the rest of the organisation plans against:

• Maximum Tolerable Downtime (MTD) — the longest the process can be down before the harm is unacceptable.
• Recovery Time Objective (RTO) — the target restoration time, which must be shorter than MTD.
• Recovery Point Objective (RPO) — the maximum acceptable data loss, expressed as time, which drives backup and replication frequency.
• Dependency mapping — the systems, suppliers, people and facilities the process requires, which is where BIA and the CMDB relationships meet.

The reason both exist is that they answer different questions and either alone misleads. A risk assessment without a BIA cannot say which assets matter, because asset value comes from the process it supports. A BIA without a risk assessment produces recovery targets with no view of what is likely to cause the outage.

The examinable relationship: BIA determines the requirement, risk assessment determines the priority. A scenario asking why an RTO was set at four hours is a BIA question; a scenario asking whether to spend on preventing the outage or on recovering from it faster is a risk question.

Third-party and supply-chain risk: questionnaires, attestations, and right-to-audit clauses

The defining constraint here is that you cannot inspect a supplier's estate. You can only obtain assertions about it, at varying strength, and the objective is largely about knowing which is which.

In increasing order of assurance:

• Self-assessment questionnaire. The supplier answers questions about itself. Cheapest, weakest, and unverified. Its genuine value is that it establishes a written statement you can hold them to, and that refusal or evasion is itself informative.
• Third-party certification — an ISO-style certificate. An accredited body assessed a management system against a standard. Check two things: the scope statement, because certification often covers one site or one service and not the one you are buying; and the date.
• Attestation report — an independent auditor's report on controls, of the kind produced for service organisations. Stronger, because it describes controls and tests. The examinable distinction is between a report on design at a point in time and a report on operating effectiveness over a period; only the latter tells you the controls actually ran.
• Right-to-audit clause. A contractual right for you or your agent to examine directly. Strongest, most expensive, and frequently never exercised — a right nobody uses provides leverage, not assurance.
• Continuous monitoring. External attack-surface data, breach notifications, and contractual obligations to report material changes.

Two structural points recur in scenarios. Fourth-party risk — your supplier's suppliers — is real and usually unmapped; a concentration of different vendors on one underlying platform is a single point of failure that none of the individual assessments reveals. And assurance must be proportionate to the dependency, assessed by what the supplier can reach and how quickly their failure hurts, not by how much you spend with them; the low-cost supplier with privileged access to your estate is the one that is routinely under-assessed.

Contractual controls do the rest of the work: security requirements written into the agreement, breach notification with a stated clock, subcontractor approval, data location and return, and defined exit. Exit provisions are the most commonly missing, and their absence turns a supplier problem into a hostage situation.

Expressing a finding as a risk to confidentiality, integrity or availability rather than a defect

CompTIA's bullet ends by naming the three properties, and the reason is practical: it is how a technical finding becomes a governable risk.

A defect statement — "the reporting server runs an unsupported operating system" — invites the question "so what", and the answer lives in someone's head. A risk statement carries the consequence explicitly:

Threat — an attacker with network access exploits an unpatched vulnerability in the unsupported operating system on the reporting server. Vulnerability — the platform is beyond vendor support and no longer receives fixes. Impact — loss of confidentiality of the customer data it holds, and loss of availability of month-end reporting. Likelihood — high; working exploits are public and the host is reachable from the user network. Existing controls — network segmentation, daily backup. Treatment — migrate by Q3; interim compensating control is restriction to a jump host.

Everything a decision-maker needs is present, and the CIA property is what lets it be compared against risks from completely different technologies. It also frequently changes the priority: integrity risks are routinely under-rated because they are quiet — corrupted data propagates into backups and decisions for months, where an availability failure announces itself in minutes.

Two habits finish the job. Name the affected property explicitly rather than saying "security impact", because the property determines the control class: confidentiality is addressed by access control and encryption, integrity by validation, signing and monitoring, availability by redundancy and recovery. And state the residual risk after treatment, because a treatment that reduces a risk to a level still outside appetite is not a completed action — which is the defect a scenario is describing when a remediated finding is followed by an incident of exactly the anticipated kind.