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.
Jump to a section
A simple way to picture The Risk Register and the Threat Landscape
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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
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
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
Mistake
A risk register is only needed for audits and compliance. Once the audit passes, it can be ignored.
Correct
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.
Mistake
If a vulnerability is patched, the associated risk is completely eliminated.
Correct
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.
Mistake
The threat landscape only includes cyber attacks like viruses and hackers.
Correct
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.
Mistake
All threats and vulnerabilities must be documented in the risk register regardless of size.
Correct
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.
Mistake
The risk owner must be the chief information security officer (CISO) or the IT manager.
Correct
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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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).
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.
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.
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.
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.
You've finished The Risk Register and the Threat Landscape. Continue through the CRISC study guide to build a complete picture of the exam.
Done with this chapter?