PT0-002 Practice Question: A penetration tester needs to provide a metric…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Annual Loss Expectancy (ALE).

  Why this is correct

  ALE is the expected monetary loss per year from a specific risk, calculated as Single Loss Expectancy (SLE) multiplied by Annualized Rate of Occurrence (ARO), where SLE equals asset value times exposure factor. Because it expresses risk in tangible financial terms, the CFO can directly compare potential losses across assets and threats, prioritize remediation based on cost-benefit analysis, and justify security spending or risk transfer such as cyber insurance. This metric is the only answer that translates technical vulnerability context into the business language of dollars and cents.

• ✗

  CVSS base score.

  Why it's wrong here

  CVSS base score quantifies vulnerability severity based on exploitability and impact metrics, but it does not incorporate asset value, financial loss probability, or business context. The CFO requires a metric that translates technical risk into monetary terms, which CVSS alone cannot provide. It is tempting because CVSS is a standardised, widely used scoring system for prioritising technical remediation, and would be correct for communicating relative technical severity to a security team.

• ✗

  Number of critical findings.

  Why it's wrong here

  A raw count of critical findings condenses every severity into a single number, but it does not weight each finding by the value of the asset, the likelihood of exploitation, or the potential financial impact. For example, one critical remote code execution vulnerability in a payment processing system could cause a multi-million-dollar breach, while dozens of 'critical' vulnerabilities in a non-internet-facing research lab may pose negligible monetary risk. Thus, a count lacks the financial context needed for a CFO to understand real exposure and make a cost-effective remediation decision.

• ✗

  Technical difficulty of exploitation.

  Why it's wrong here

  Technical difficulty of exploitation is a qualitative, subjective judgment about attacker skill and effort, and it does not incorporate asset criticality, business process impact, or the probability of a loss event. A low-difficulty vulnerability in a low-value auxiliary system might have little financial consequence, while a high-difficulty vulnerability that compromises a core banking ledger could result in catastrophic losses and regulatory penalties. The CFO needs an objective monetary metric such as ALE, not a nontransferable measure of attacker effort that cannot be mapped to budget or insurance decisions.

Go deeper

Related to this question