The risk register, appetite, response strategies and business impact

Objective 5.2 in this course covers the risk management process. The previous lesson took identification through analysis; this one takes the register, tolerance and appetite, the response strategies, reporting and business impact analysis from CompTIA's scope note. It is the applied lab for 5.2.

Why this matters

The four response strategies — transfer, accept, avoid, mitigate — are close to guaranteed exam content, and the questions give you a scenario and want the strategy named. They are easy marks and they are also easy to lose, because "transfer" and "accept" are more often confused than people expect.

The BIA metrics at the end are the same RPO and RTO from Domain 3, arriving from the business side. Seeing them as one idea, derived in Domain 5 and implemented in Domain 3, is worth doing.

The lesson

Key risk indicators, risk owners and risk threshold

The risk register is the record of identified risks and what is being done about them. It is the central artefact of the whole domain, and an exam scenario about tracking, reviewing or accepting risk usually resolves to it.

What each entry holds:

• a risk description — the cause-and-consequence sentence from the previous lesson;
• the inherent assessment (likelihood and impact before controls);
• the existing controls;
• the residual assessment, after those controls;
• the risk owner — a named person, not a team, who is accountable for the risk and authorised to decide about it;
• the chosen response strategy, and the actions with dates;
• the status and the review date.

Two supporting ideas:

Key risk indicators (KRIs) are measurable signals that a risk is becoming more likely or more severe: the number of unpatched critical vulnerabilities, the age of the oldest open finding, the count of privileged accounts, the proportion of staff failing phishing simulations. Their value is being leading rather than lagging — a KRI moves before the incident, where an incident count only tells you afterwards.

Risk threshold is the level at which something must happen — escalation, additional approval, or mandatory treatment. It is what makes the register operational rather than decorative: crossing the threshold triggers a defined response rather than a judgement call.

The risk owner deserves emphasis because it is examined. The owner is a business person accountable for the area, not the security analyst who found the risk. Security identifies, assesses and advises; the business owns and decides. An analyst accepting a risk on the organisation's behalf is acting without authority, which is the governance point from 5.1.

Risk tolerance and risk appetite: expansionary, conservative, neutral

These two are used interchangeably in speech and are distinguished on the exam.

• Risk appetite is the amount and type of risk an organisation is willing to pursue in order to meet its objectives. It is a strategic statement, set by the board, and it is forward-looking — it is about what you will take on.
• Risk tolerance is the acceptable variation around that: how much deviation from the appetite can be borne before action is required. It is narrower and more operational.

An analogy that holds: appetite is the speed you intend to drive; tolerance is how far over that you will go before slowing down.

CompTIA names three appetite postures:

• Expansionary — willing to accept higher risk to pursue growth, innovation or speed to market. A startup, or a business entering a new market.
• Conservative — prioritising protection and stability over opportunity. Regulated industries, critical infrastructure, organisations with a lot to lose.
• Neutral — balanced, taking moderate risk for moderate return.

Why it matters practically: appetite determines what "acceptable" means, and therefore which residual risks can simply be accepted and which must be treated. The same residual risk is a reasonable acceptance at an expansionary organisation and a mandatory remediation at a conservative one. There is no universally correct level of risk, and an exam option asserting that a risk must always be eliminated is wrong.

Transfer, accept, avoid and mitigate, and exemption versus exception

The four risk management strategies. Learn the distinctions exactly.

• Mitigate — reduce the likelihood or the impact by implementing controls. Patch it, segment it, back it up, train people. The most common response and the one most of this course has been about.
• Transfer — move the financial consequence to someone else. Insurance is the classic; outsourcing and contractual liability clauses are others. What transfers is money, never the obligation: a regulator still holds you responsible, and your customers still blame you. That is the single most tested nuance in this list.
• Avoid — eliminate the risk by not doing the activity. Decommission the system, decline the market, do not collect the data. It is the only strategy that removes the risk entirely, and its cost is the opportunity given up.
• Accept — take no action, knowingly. Legitimate when the cost of treatment exceeds the expected loss, or when the residual risk is within appetite. It must be documented, owned and time-bounded; undocumented acceptance is not a strategy, it is neglect.

Matching them to scenarios:

Exemption and exception are the formal instruments for acceptance:

• An exception is a time-limited, approved departure from a policy or standard for a specific case — usually with compensating controls and an expiry date.
• An exemption is a broader, longer-lived release from a requirement, for a category that genuinely cannot meet it.

Both need an owner, a justification, compensating controls where possible, an approval at the right level, and a review date. The failure the exam describes is the exception with no expiry, which is how a temporary decision becomes a permanent vulnerability nobody revisits.

Risk reporting, and what a board is actually shown

Risk reporting communicates the risk position to those who decide. Different audiences need different things, and getting this wrong is why security reporting is often ignored.

A board does not want a vulnerability count. It wants:

• the top risks in business terms — what could stop us trading, what could cost us the licence, what could end up in the press;
• whether the position is improving or worsening, with a trend;
• what is outside appetite and what is being done about it;
• what decisions are being asked of them — funding, acceptance, or a strategic change;
• and the risks that have been accepted on their behalf, which is the item most often omitted and the one with the sharpest governance edge.

Practical guidance the exam supports: report in money and in business impact, not in technical severity; separate the handful of things that matter from the long tail; and be explicit about confidence and about what you do not know.

Reporting cadence is part of governance: routine periodic reporting, plus event-driven reporting when a risk crosses a threshold. A risk that materially worsens should not wait for the quarterly slide.

Business impact analysis: RTO, RPO, MTTR and MTBF

A business impact analysis (BIA) determines the consequence of losing each business function over time. It is a business exercise, not a technical one, and it is the input to everything in Domain 3's resilience work.

What it produces:

• the essential functions, ranked by how long the organisation can survive without each;
• the impact over time — an hour, a day, a week — because impact is rarely linear and there is often a cliff, such as a regulatory reporting deadline or a payroll date;
• the dependencies each function has: systems, data, people, suppliers, premises;
• and from all of that, the recovery objectives.

The metrics, which are the same four as Domain 3 arriving from the other direction:

• RTO (recovery time objective) — the maximum tolerable downtime for the function. Drives site strategy and recovery capability.
• RPO (recovery point objective) — the maximum tolerable data loss, expressed as time. Drives backup frequency and replication.
• MTTR (mean time to repair) — the measured average time to restore. The reality against which RTO is a target; if MTTR exceeds RTO, the objective is not being met, and that gap is the BIA's most actionable output.
• MTBF (mean time between failures) — the average interval between failures. A reliability figure for capacity and replacement planning.

The relationship to hold: the business sets RTO and RPO in the BIA; technology is then designed and costed to meet them. Doing it the other way round — declaring the RPO to be whatever the current backup schedule produces — is working backwards from capability to requirement, and it means nobody has decided whether that loss is acceptable. When an exam scenario has a stated RPO that the backup frequency cannot deliver, the finding is exactly that mismatch.

The BIA also feeds the continuity planning from Domain 3: essential functions, their dependencies, and the manual workarounds that keep them running while the systems are being restored.

What to take into the exam

• Transfer moves the money, never the obligation or the reputational damage.
• Avoid is the only strategy that removes the risk, and its price is the opportunity.
• Acceptance must be documented, owned and time-bounded; an exception with no expiry is the classic finding.
• Appetite is what you are willing to pursue; tolerance is the acceptable variation around it. Expansionary, conservative, neutral.
• The risk owner is a business person, not the analyst who found it.
• The BIA sets RTO and RPO; technology is designed to meet them. If MTTR exceeds RTO, the objective is not being met.