6.2.3. Risk Register and Tolerance

💡 First Principle: A risk register is the living document that tracks all identified risks, their assessment, and the response decision for each. Risk tolerance defines how much risk the organization is willing to accept — it's the threshold that determines whether a risk requires action or can be accepted.

Risk register contains for each risk: description, likelihood, impact, risk score, owner, response strategy, status, and review date. It's a management tool that ensures no identified risk is forgotten or ignored. A well-maintained register is a living document — reviewed regularly, updated when risk conditions change, and used to drive resource allocation decisions. Typical fields include: risk ID, date identified, risk description, category (operational, technical, compliance), likelihood rating, impact rating, inherent risk score, current controls, residual risk score, risk owner, response strategy, action items, and next review date.

Risk heat map — a visual representation of the register, plotting risks on a likelihood × impact matrix. The heat map quickly communicates to leadership which risks are in the "red zone" (high likelihood + high impact) and require immediate attention versus those in the "green zone" that can be monitored passively.

Risk tolerance (also called risk appetite) — the organization's willingness to accept risk. A startup might accept high risk for rapid growth; a hospital might accept very low risk for patient safety systems. Risk tolerance should be set by senior leadership and documented.

Key Risk Indicators (KRIs) — metrics that signal when risk levels are approaching tolerance thresholds. A KRI might be "percentage of systems unpatched beyond 30 days." When the KRI exceeds the threshold, management is alerted.

Risk owner — the individual accountable for managing a specific risk. Usually a manager or executive who has authority to allocate resources for mitigation.

⚠️ Exam Trap: Risk tolerance is set by management, not by IT. If a question asks who determines acceptable risk levels, it's senior leadership or the board — not the security team. The security team advises; management decides.