# The Risk Register and the Threat Landscape

> Chapter 3 of the Courseiva ISACA-CRISC curriculum — https://courseiva.com/learn/isaca-crisc/risk-register-and-threat-landscape

**Official objective:** 1.3 — Identify and document internal and external threats, vulnerabilities, and risk scenarios

## Introduction

The risk register is the single source of truth for every danger facing an organisation's technology and data. Without it, a business is effectively driving blind, reacting to fires instead of preventing them. For a CRISC candidate, mastering how to identify threats and vulnerabilities and capture them in a risk register is the foundation of the entire risk management process.

## The Restaurant Kitchen Inspection Analogy

A professional kitchen is a system of interconnected parts, each vulnerable to specific failures. The head chef uses a master inspection checklist, the risk register, to document every potential problem, from a greasy floor (an internal vulnerability) to a supplier delivering spoiled fish (an external threat). The threat landscape is the full menu of dangers: a knife left in a sink (accidental injury), a broken refrigerator (temperature danger), a health inspector visit (compliance risk), or a sudden rush of 200 customers (operational overload). The chef can't prevent every bad thing, but can identify and rank them.

Each day, the chef reviews the register. The greasy floor has a high likelihood of causing a slip, so a 'non-slip mat' control is installed. The spoiled fish has a high impact, so a 'trusted supplier list' control and 'temperature log' detective control are added. The register also notes threats that never happened, like a fire, and the controls that prevent it, such as the overhead extinguisher system.

This is exactly how an IT risk register works. The restaurant's floor, fridge, and suppliers are your IT assets (servers, databases, cloud services). The slipping chef is a human error vulnerability. The health inspector is a regulatory threat. The register doesn't stop bad things; it forces the chef to see them, measure them, and decide what to do before the kitchen burns down.

## Core explanation

To understand the risk register and the threat landscape, you must first understand that risk is not a thing you can touch. It is a calculation: the likelihood that something bad will happen, combined with the severity of the impact if it does. The risk register is a formal document, often a spreadsheet or a specialised database, that lists every identified risk. Think of it as a living to-do list for danger.

The threat landscape is the entire collection of possible dangers that could cause harm. Threats can be internal (coming from inside the organisation, such as a disgruntled employee or a faulty server) or external (coming from outside, like hackers, floods, or a new law). A vulnerability is a weakness that a threat could exploit. For example, a unlocked back door is a vulnerability; a burglar is the threat.

Why does this matter? Because you cannot manage what you do not measure. The risk register forces an organisation to be honest about its exposures. It stops people from saying 'we are secure' without evidence.

Here are the key components of a well-structured risk register:

- Risk ID: A unique number (e.g., R-001) to track the risk.
- Risk Description: A clear, plain-English statement of what could happen. For example, 'A phishing email tricks an employee into revealing their password.'
- Threat Type: Internal or external.
- Vulnerability: The weakness being exploited (e.g., 'lack of security awareness training').
- Likelihood: How probable is this? Often rated low, medium, or high.
- Impact: How bad would it be if it happened? Financial loss, data breach, regulatory fine.
- Risk Owner: The person accountable for managing this risk.
- Controls: Existing measures that reduce likelihood or impact (e.g., 'multi-factor authentication is enabled').
- Risk Treatment: What will you do? Avoid, transfer, mitigate, accept.

A real example: A small online retailer runs a website on an old server. The external threat is a hacker exploiting a known software flaw (a vulnerability). The risk register would list this as R-003: 'Hacker exploits unpatched web server software, leading to customer credit card theft.' The likelihood is high because the flaw is public. The impact is catastrophic (data breach fines, reputation loss). The control is 'auto-patching is disabled' (a bad control, which is actually another vulnerability). The risk treatment is to 'install the security patch immediately'.

The threat landscape is constantly changing. New threats emerge daily: new malware strains, new regulations, new climate events. The risk register must be reviewed and updated regularly—at least quarterly. It is not a one-time homework assignment; it is a continuous process.

A common mistake is to treat the risk register as a tick-box exercise for auditors. That is a waste of time. A good risk register drives real decisions: which projects get funded, which controls get priority, which vendors are dropped.

For the CRISC exam, you must be able to identify the difference between a threat and a vulnerability. Exam questions will describe a scenario and ask you to pick the correct classification. They love to phrase a vulnerability as a threat to trick you. For instance, 'the lack of encryption' is a vulnerability, not a threat. 'A hacker stealing data' is the threat. The register connects these two things.

Finally, remember the acronym STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) — a popular model from Microsoft to help identify threat categories. You do not need to memorise it for CRISC, but understanding it helps you think systematically about threats.

## Real-world context

An IT risk manager at a mid-sized logistics company is preparing for a quarterly risk review. They open the risk register, a cloud-based tool called 'LogicGate'. The register currently lists 47 risks. The manager is focusing on a new risk identified last month: 'Delivery routing service outage due to a DDoS attack on the cloud provider'.

Here is what the manager does step by step:

- Step 1: Verify the risk description. The manager calls the cloud provider's support team to confirm the service-level agreement (SLA) and whether there have been any recent Distributed Denial of Service (DDoS) attacks (an external threat that floods a system with traffic, causing it to crash).
- Step 2: Analyse the vulnerability. The vulnerability is the company's reliance on a single cloud provider for routing without a manual backup process. The manager notes this in the register as 'single point of failure, no failover plan'.
- Step 3: Update likelihood and impact. Based on industry data, DDoS attacks are increasing. The manager raises the likelihood from 'low' to 'medium'. The impact remains 'high' because a routing outage would stop deliveries for hours, costing £50,000 per hour.
- Step 4: Evaluate current controls. A web application firewall (WAF) is in place but is not tuned for DDoS. The manager adds a new control: 'contact cloud provider to enable DDoS protection service'. Also, a detective control: 'configure alerting for traffic spikes'.
- Step 5: Assign risk treatment. The company cannot avoid this risk (they must use the cloud). They decide to mitigate by implementing a secondary routing provider as backup. The cost is £2,000 per month. They accept a residual risk of 15% that the backup might also go down.
- Step 6: Update the owner. A new risk owner, the VP of operations, is assigned. The manager sets a review date for 30 days to check if the backup has been configured.
- Step 7: Report to management. The manager extracts a summary report from the register showing the top 10 risks by exposure (likelihood × impact). This report goes to the board to inform insurance renewals and budget requests.

In a real meeting, the CEO sees the DDoS risk and asks: 'Why didn't we catch this months ago?' The manager points to the register: the risk was added after an industry news alert. This shows how the register is not just a document; it is a communication tool that drives accountability.

Another key activity is threat intelligence gathering. Every week, the manager scans threat feeds (automated services like AlienVault OTX) and news for new vulnerabilities relevant to their industry. When a new vulnerability, like 'Log4Shell' (a critical flaw in a widely used logging library), is disclosed, the manager immediately searches the register for any asset that uses that software and adds a new risk entry. This rapid updating is what keeps a risk register useful rather than stale.

## Exam focus

The CRISC exam tests 'The Risk Register and the Threat Landscape' in several distinct ways. You will not be asked to build a register from scratch, but you must understand its components and purpose.

Key exam topics:

- Distinguishing between a threat, a vulnerability, and a risk. This is the most tested distinction. A threat is the potential cause of an unwanted event (e.g., a hurricane). A vulnerability is a weakness (e.g., a data centre in a flood zone). Risk is the combination (e.g., high risk of flood damage to servers).
- Identifying whether a risk is internal or external. This maps to exam objective 1.3. A phishing email from an employee's compromised account is internal. A nation-state attack is external.
- Knowing what a risk register must contain. You must remember at least: risk description, likelihood, impact, risk owner, and controls. The exam may present a scenario and ask what is missing from a register.
- Understanding the difference between inherent risk (risk without controls) and residual risk (risk after controls). They love to hide the word 'residual' in questions.

Trap patterns to watch for:

- The question describes a vulnerability but asks 'what is the threat?'. Example: 'An organisation lacks encryption on its data in transit.' The threat is 'data interception'. The vulnerability is 'lack of encryption'. Many beginners pick the vulnerability as the answer because it is more concrete.
- The question presents a risk that is actually a compliance issue. The exam likes to test if you recognise that a risk can be avoided by simply ceasing an activity. If the activity is non-essential, 'avoidance' is the correct treatment, not mitigation.
- They test 'risk scenario' as a distinct concept. A risk scenario is a narrative description of a specific risk, including the threat, vulnerability, and impact. They might give you a scenario and ask which risk register entry is best written.

Correct answer patterns:

- If a question asks for the 'best' initial action after identifying a new threat, the correct answer is always 'document it in the risk register' (before analysing or remediating).
- If a question asks for the difference between a threat and a vulnerability, look for descriptive words: 'lack of', 'absence of', 'outdated' indicate a vulnerability. Words like 'attack', 'fire', 'flood', 'theft' indicate a threat.
- Any question about 'risk owner' — the correct answer is the person who best understands the risk and has authority to manage it, not necessarily the most senior person or the IT manager.

Definitions to memorise:

- Risk Register: a central repository of identified risks and their attributes.
- Threat Landscape: the broad set of external and internal threats an organisation faces.
- Vulnerability: a flaw or weakness in system security procedures, design, implementation, or internal controls.
- Threat: any circumstance or event with the potential to cause harm.
- Risk Scenario: a detailed description of a risk event, including cause, vulnerability, and consequence.

Study tip: create flashcards of 20 different scenarios and practise classifying each element as threat, vulnerability, or risk. This will train your brain for the exam's pattern.

## Step by step

1. **Identify Assets and Processes** — List every critical asset (servers, databases, cloud accounts, intellectual property) and business process (payroll, customer support, manufacturing). You cannot manage risk to things you do not know exist.
2. **Identify Threats and Vulnerabilities per Asset** — For each asset, brainstorm what could go wrong (threats) and what weaknesses exist (vulnerabilities). Use frameworks like STRIDE or threat intelligence feeds to be systematic. Write them in plain English.
3. **Analyse Likelihood and Impact** — Assign a rating (e.g., 1-5) for how likely the risk is to occur and how severe the impact would be if it does. This quantifies the risk so you can prioritise. Use historical data and expert judgement.
4. **Identify Existing Controls** — Document what is already in place to reduce the likelihood or impact of each risk. For example, a firewall is a preventive control; a backup is a corrective control. Be honest about whether controls are effective.
5. **Determine Risk Treatment** — Decide what to do: avoid (stop the activity), transfer (buy insurance), mitigate (add controls), or accept (acknowledge and monitor). Document this decision and the residual risk level.
6. **Assign Risk Owner and Review Date** — Name one person accountable for monitoring the risk and implementing the treatment. Set a future review date. The register is not complete until someone is responsible and a next action is scheduled.

## Comparisons

### Threat vs Vulnerability

**Threat:**
- A potential cause of harm (e.g., a hacker, a fire)
- External or internal source (e.g., natural disaster, disgruntled employee)
- Without a vulnerability, a threat cannot cause damage

**Vulnerability:**
- A weakness or gap in protection (e.g., unpatched software, unlocked door)
- Exists within the system, process, or people
- Without a threat, a vulnerability is just a weakness with no consequence

### Inherent Risk vs Residual Risk

**Inherent Risk:**
- Risk level before any controls are applied
- Often high by definition because no protections are assumed
- Used to measure the baseline exposure of an activity

**Residual Risk:**
- Risk level after all controls are implemented
- Should be lower than inherent risk if controls are effective
- The level that the organisation decides to accept or further treat

### Risk Register vs Threat Landscape

**Risk Register:**
- A documented list of specific identified risks
- Structured, maintained, and owned by a team
- Provides detailed information per risk (owner, controls, treatment)

**Threat Landscape:**
- The broad, dynamic set of all potential threats facing the organisation
- Not a document, but a concept representing the environment
- Used to scan for new risks and update the register

### Risk Avoidance vs Risk Acceptance

**Risk Avoidance:**
- Choosing not to engage in the risky activity at all
- Eliminates the risk entirely (e.g., abandoning a project)
- Often used when the risk is too high and cannot be reduced

**Risk Acceptance:**
- Acknowledging the risk and taking no further action
- Residual risk remains and is officially approved
- Used when the cost of controls exceeds the potential impact

## Diagram

_This diagram shows the structure of a risk register, linking each risk entry to its components and treatment options._

```mermaid
flowchart TD
    A[Risk Register] --> B[Risk ID & Description]
    A --> C[Threat (Internal / External)]
    A --> D[Vulnerability]
    A --> E[Likelihood & Impact]
    A --> F[Existing Controls]
    A --> G[Risk Owner]
    A --> H[Risk Treatment]
    H --> I[Avoid]
    H --> J[Transfer]
    H --> K[Mitigate]
    H --> L[Accept]
    E --> M[Residual Risk after Controls]
```

## Common misconceptions

- **Misconception:** A risk register is only needed for audits and compliance. Once the audit passes, it can be ignored. **Reality:** A risk register is a living management tool that must be continuously updated to reflect new threats and changes. Ignoring it leaves the organisation blind to emerging risks. (Many beginners come from environments where compliance checklists are done once and filed away. They confuse a risk register with a static policy document.)
- **Misconception:** If a vulnerability is patched, the associated risk is completely eliminated. **Reality:** Patching a vulnerability reduces the risk, but residual risk often remains (e.g., the patch could be incomplete, or a new vulnerability emerges). Risk acceptance is needed. (People think in binary terms: something is either broken or fixed. In risk management, most fixes only reduce probability, not remove it entirely.)
- **Misconception:** The threat landscape only includes cyber attacks like viruses and hackers. **Reality:** The threat landscape also includes natural disasters, human errors, supply chain failures, regulatory changes, and physical security incidents (e.g., a server being stolen). (Media coverage focuses on cyber attacks, so beginners mistakenly think that is the only threat. CRISC tests a broad view.)
- **Misconception:** All threats and vulnerabilities must be documented in the risk register regardless of size. **Reality:** A risk register should focus on material risks that could significantly harm the organisation. Minor, low-likelihood, low-impact risks are often accepted without formal documentation. (Beginners think thoroughness means documenting everything. In reality, risk registers become unusable if they contain every tiny possibility.)
- **Misconception:** The risk owner must be the chief information security officer (CISO) or the IT manager. **Reality:** The risk owner is the person most able to manage the risk, which could be a department head, a project manager, or a business unit leader. The IT team often implements controls but does not own the risk. (People assume IT owns all technology risks. But risk ownership is about accountability for the business outcome, not technical implementation.)

## Key takeaways

- A risk register is a living document that lists every significant risk, its likelihood, impact, and controls — not a static compliance artifact.
- A threat is a potential source of harm (e.g., hacker, storm); a vulnerability is a weakness that a threat could exploit (e.g., unpatched software).
- The threat landscape includes internal and external risks: from fire and flood to ransomware and regulatory fines.
- Inherent risk is the risk level before any controls are applied; residual risk is what remains after controls are in place.
- A risk scenario is a narrative that combines a specific threat, vulnerability, and business impact — it is how you communicate risk to non-technical stakeholders.
- The risk owner is accountable for managing the risk and must have the authority to implement changes — this is often a business leader, not an IT person.

## FAQ

**What is the difference between a threat and a vulnerability in a risk register?**

A threat is a potential harmful event (like a hacker or a fire). A vulnerability is a weakness that a threat can exploit (like an open network port). In the register, you document both: the threat and the vulnerability it targets.

**How often should a risk register be updated?**

At minimum, the register should be reviewed quarterly, and updated immediately when a significant new threat or vulnerability is discovered (e.g., after a news report of a new vulnerability, or after a security incident).

**What is an acceptable risk in a risk register?**

An acceptable risk is one where the organisation consciously decides not to add more controls because the combination of low likelihood and low impact is deemed tolerable. This must be formally documented and approved by the risk owner.

**Who should be the risk owner for a risk in the register?**

The person who has the authority and expertise to manage the risk and implement controls. This is often a business unit manager, not the IT team, because they own the process that the risk affects.

**What is a residual risk?**

Residual risk is the amount of risk that remains after all controls have been applied. It is what the organisation decides to accept or further mitigate. It is always higher than zero because controls can never be 100% effective.

**Can the same risk appear in multiple registers across different departments?**

Yes, if a risk affects multiple departments (e.g., a data breach affects both IT and HR), each department may have its own register entry, but a centralised enterprise risk register should consolidate them to avoid duplication and ensure consistent management.

## Check your understanding

1. **What is the primary purpose of a risk register?**

   Answer: The primary purpose is to centrally document and track all identified risks, including their likelihood, impact, controls, and treatment, enabling informed decision-making and accountability.

2. **Classify this scenario: 'An outdated firewall is a weakness that a hacker could exploit.' What is the vulnerability?**

   Answer: The vulnerability is 'outdated firewall'. The threat is 'hacker', and the risk is 'hacker exploits outdated firewall to breach the network'.

3. **What is the difference between inherent risk and residual risk?**

   Answer: Inherent risk is the level of risk before any controls are applied. Residual risk is the level remaining after controls are implemented.

4. **Name three mandatory fields that a risk register must contain for each risk entry.**

   Answer: Risk description, likelihood rating, impact rating, risk owner, and controls. (List any three of these.)

5. **When should a risk owner be assigned in the risk register process?**

   Answer: The risk owner should be assigned as soon as the risk is identified and analysed, because without an owner, the risk will not be managed or monitored.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isaca-crisc/risk-register-and-threat-landscape