Risk management questions on the Security+ exam cover risk calculation, risk response strategies, and risk terminology. These questions have definitive answers based on CompTIA's definitions. Understanding the core concepts eliminates most wrong answers immediately.
Risk Formula
The fundamental risk equation:
Risk = Likelihood (Probability) × Impact
- Likelihood — How probable is it that a threat will materialise? Often expressed as a percentage or on a scale (low/medium/high).
- Impact — What is the consequence if it does? Financial loss, operational disruption, reputational damage.
Exam questions sometimes ask you to rank risks by overall risk level when given likelihood and impact scores. Multiply them and compare.
Example: Threat A has likelihood 0.2, impact 100. Risk = 20. Threat B has likelihood 0.8, impact 10. Risk = 8. Threat A has higher overall risk despite lower likelihood.
Annual Loss Expectancy
For quantitative risk analysis:
- SLE (Single Loss Expectancy) — The cost of a single occurrence of a risk: Asset Value × Exposure Factor
- ARO (Annualised Rate of Occurrence) — How many times per year the risk is expected to occur
- ALE (Annualised Loss Expectancy) — SLE × ARO; the expected annual cost of the risk
The exam uses ALE to evaluate whether a control is cost-effective. If a control costs more per year than the ALE it prevents, it is not cost-effective.
Risk Response Strategies
There are four ways to respond to a risk:
Avoid — Eliminate the activity that creates the risk. If a company stops using a risky software product, it avoids that risk entirely. Avoidance is not always practical.
Transfer — Move the financial impact of the risk to a third party. Purchasing cyber insurance transfers the financial risk. Outsourcing a function can transfer operational risk.
Mitigate (Reduce) — Implement controls to reduce likelihood or impact. Installing a firewall, enabling MFA, and patching vulnerabilities are all mitigation.
Accept — Acknowledge the risk and choose not to act. Appropriate when the cost of mitigation exceeds the potential loss, or when risk falls below the organisation's risk threshold.
Exam trap: candidates confuse transfer with avoidance. Transfer does not eliminate the risk — the event can still happen; the financial burden is just shifted. Avoidance eliminates the risk by removing the activity entirely.
Inherent vs Residual Risk
Inherent risk — The level of risk before any controls are applied. The raw risk of a threat exploiting a vulnerability.
Residual risk — The risk that remains after controls have been applied. No control eliminates risk entirely; residual risk is what the organisation accepts.
Risk appetite — The amount of risk an organisation is willing to accept in pursuit of its goals.
Risk tolerance — The acceptable variation around the risk appetite.
Exam question: "After implementing a new firewall, what type of risk remains?" — Residual risk.
"Before controls are applied, what type of risk exists?" — Inherent risk.
The Risk Register
A risk register documents all identified risks for an organisation:
- Risk description
- Likelihood and impact ratings
- Current controls
- Risk owner (person responsible)
- Response strategy
- Residual risk after controls
The exam asks about the risk register as the document used to track and manage organisational risks over time.
Qualitative vs Quantitative Risk Analysis
Qualitative — Uses descriptive scales (low/medium/high) and subjective judgement. Faster and cheaper; used when precise data is unavailable.
Quantitative — Uses numerical values (ALE, SLE, ARO) for objective measurement. More accurate but requires detailed financial data.
Exam questions distinguish between these: a question describing a risk assessment that uses dollar amounts and probability percentages is quantitative. One that uses a risk matrix with colour coding is qualitative.
Practice Security+ risk management questions to build familiarity with these calculations and term definitions.
Risk Register — What It Is and Why the Exam Tests It
A risk register is the living document that tracks every identified risk to an organisation. It is the central artefact of a risk management programme.
A complete risk register entry contains:
- Risk ID — A unique identifier for tracking
- Risk description — What the risk is, what causes it, what it affects
- Likelihood rating — How probable the risk is (often on a 1–5 or low/medium/high scale)
- Impact rating — How severe the consequences would be
- Risk score — Likelihood × Impact
- Current controls — What is already in place to address this risk
- Risk owner — The specific person accountable for managing this risk
- Response strategy — Avoid, transfer, mitigate, or accept
- Residual risk — The risk level remaining after controls are applied
- Review date — When this entry will be reassessed
Exam scenarios: "Which document tracks all identified risks, their likelihood and impact, and the current controls in place?" Risk register. "A security manager is updating documentation to reflect that a new firewall has reduced the likelihood of an external breach. Which document is being updated?" Risk register — specifically the residual risk for that entry.
The risk register is not the same as an asset inventory, which tracks what you have. The risk register tracks what could go wrong.
Business Impact Analysis — RTO, RPO, MTTR, MTBF
The BIA is conducted before a disaster occurs to determine how badly each business function would be impacted by various disruptions. It produces the metrics that drive recovery planning.
RTO — Recovery Time Objective. The maximum acceptable time for a system or function to be down before the business impact becomes unacceptable. If payroll processing must be restored within 4 hours, the RTO is 4 hours. This drives how much redundancy and automated failover is needed.
RPO — Recovery Point Objective. The maximum acceptable amount of data loss measured in time. If the RPO for a customer database is 1 hour, you cannot afford to lose more than 1 hour of transactions. This drives backup frequency — if your RPO is 1 hour, you need at minimum hourly backups (preferably continuous replication).
MTTR — Mean Time to Repair. The average time it takes to repair a failed component after it fails. A measure of your maintenance efficiency. Lower MTTR means faster recovery from individual failures.
MTBF — Mean Time Between Failures. The average time a component operates before it fails. A measure of reliability. Higher MTBF means more reliable components. MTBF is used to estimate when hardware is likely to need replacement.
How to tell which metric a question is testing:
- "How long can the system be down?" → RTO
- "How much data can we afford to lose?" → RPO
- "How reliable is this device?" → MTBF
- "How quickly can we fix a broken component?" → MTTR
Exam trap: Candidates confuse RTO with RPO because both involve time. Remember: RTO is about system availability (downtime), RPO is about data (data loss). A question saying "the organisation can tolerate losing at most 2 hours of transactions" is testing RPO, not RTO.
Qualitative vs Quantitative Risk Analysis
Qualitative risk analysis assigns descriptive ratings — High/Medium/Low likelihood, High/Medium/Low impact — and plots them on a risk matrix. It does not require financial data. It is subjective, faster, and used when precise numbers are not available.
Qualitative output: "This risk is High likelihood / High impact — it is a priority risk." A risk heat map is a visual qualitative tool.
Quantitative risk analysis uses actual numbers: dollar values for assets, probability expressed as a percentage, annual loss expectancy calculated numerically. It requires more data and more time to conduct, but produces defensible financial justifications for security investments.
Quantitative output: "This risk has an ALE of $240,000 per year. The control to mitigate it costs $45,000 per year. Implementing the control saves $195,000 annually."
The exam question pattern: "A security team is using a colour-coded risk matrix with high, medium, and low ratings." = qualitative. "A security team calculated that a specific threat has a 30% annual probability and would cost $500,000 per occurrence." = quantitative.
Real-world note: most organisations use a hybrid approach — qualitative for initial triage, quantitative for high-priority risks where the financial justification is needed for executive sign-off.
Risk Appetite vs Risk Tolerance vs Risk Threshold
These three terms appear in the same exam question options. They are related but distinct.
Risk appetite is the broad amount of risk an organisation is willing to accept in pursuit of its objectives. It is a strategic statement: "We are a high-growth company willing to accept above-average risk to move fast." Or: "We are a healthcare provider with near-zero tolerance for patient data exposure." Risk appetite is set by the board and executives.
Risk tolerance is the acceptable variation around the risk appetite. If the risk appetite says "medium risk is acceptable," the risk tolerance defines exactly how much variation from "medium" is acceptable before action is required. It is the operationalised version of risk appetite.
Risk threshold is the specific point at which a risk level triggers a defined response or escalation. When risk exceeds the threshold, something must be done. The threshold is the actionable line.
Memory trick: Appetite = "how much risk can we stomach overall?" → Tolerance = "how much can we deviate from our appetite?" → Threshold = "at what exact number do we stop and act?"
Exam scenario: "The organisation's board has determined that a 5% chance of a data breach per year is acceptable. However, when the probability of a breach exceeds 8%, it must be escalated for executive review." The 5% is the risk appetite/tolerance. The 8% trigger is the risk threshold.
Third-Party Risk Management
Vendors and partners introduce risk that your own controls cannot fully address. Third-party risk management (TPRM) is specifically on the SY0-701 exam objectives.
Vendor risk assessments: Before engaging a vendor who will handle sensitive data or have access to your systems, assess their security posture. This includes reviewing their SOC 2 Type II report, completing a security questionnaire, or performing your own audit.
Right-to-audit clauses: Contract language that gives you the right to audit the vendor's security controls. This matters when a vendor handles your data — you need the ability to verify their controls are what they claim, especially for regulated data (PCI DSS, HIPAA).
Supply chain risk: The SolarWinds attack made this concrete — attackers compromised a trusted software vendor and used legitimate software updates to distribute malware to thousands of organisations. Supply chain risk means that even trusted software from legitimate vendors can be compromised. Controls include: software bill of materials (SBOM), vendor security assessments, code signing verification, and network segmentation to limit what third-party software can reach.
Minimum security requirements: Contracts should specify the minimum security standards a vendor must meet, the right to be notified of breaches that affect your data, and consequences for non-compliance. These are not optional — many regulatory frameworks (GDPR, HIPAA) require them.