Enterprise Risk Management (ERM) is the comprehensive process of evaluating, measuring, and mitigating the many risks that face an organisation. The goal is to identify all risks, then put controls in place to bring risk down to an acceptable level. The go-to NIST reference is SP 800-39: Managing Information Security Risk.
Why organisations adopt ERM
Confidentiality
Keep customer and corporate data from reaching unauthorised parties. A breach makes this visible, costly, and public.
Avoid financial loss
Attacks damage or destroy resources and cause data leaks — both generate direct and indirect financial cost.
Avoid legal trouble
Breaches can trigger civil lawsuits and regulatory penalties. Proper risk management reduces legal exposure.
Brand protection
It takes decades to build a brand and moments to lose it. A breach permanently damages customer trust in many industries.
Business continuity
Ensure the organisation can survive disasters (natural or man-made) and keep operating — the COOP (Continuity of Operations Plan).
Stakeholder objectives
Shareholders, executives, customers, and employees all have objectives. ERM ensures the organisation can meet them under adversity.
NIST SP 800-39 — Four-component framework
🗺
Frame
Establish a strategic risk management framework supported by senior decision makers. Sets the context for everything else. Senior leadership creates the frame; analysts work within it.
🔍
Assess
Identify and prioritise business processes, workflows, and the risks to each supporting system. Vulnerability scans, asset inventories, threat analysis. Your primary job as a CySA analyst.
🛡
Respond
Deploy managerial, operational, and technical controls to mitigate identified risks. Reduce risk to within the organisation's risk appetite.
📊
Monitor
Evaluate the effectiveness of risk response controls and identify changes that affect risk. Continuous — assess → respond → monitor → reassess as conditions change.
Analyst's role in ERM: You as a cybersecurity analyst work primarily in Assess, Respond, and Monitor. You don't set the Frame — that's a senior leadership function. But you translate technical risk findings into language and recommendations that allow decision makers to Frame the right policies and priorities.
2
Risk Identification — System Assessment & Assets
Risk identification evaluates threats, identifies vulnerabilities, and assesses the probability of an event affecting an asset or process. Before you can assess risk, you must know what you have and what it's worth.
Asset value and liability categories
Business continuity loss
Loss from inability to fulfil contracts or orders due to system breakdown. The system may still exist — it just can't be accessed. Example: video platform offline means students can't learn and contracts can't be fulfilled.
Legal costs
Criminal prosecution (jail time) or civil lawsuits (financial damages/restitution) arising from a breach. Legal costs can far exceed the direct cost of the breach itself.
Reputational harm
Negative publicity leading to loss of market position or consumer trust. For a cybersecurity company, a breach is catastrophically more damaging reputationally than for a company in an unrelated industry.
Four asset categories in a system assessment
People
Employees, visitors, suppliers, users, customers. People both use and protect assets — and are often the initial attack vector (phishing). People are not replaceable in the way hardware is.
Tangible assets
Physical, touchable things — buildings, furniture, computers, equipment, electronic data files, paper documents. These have clear purchase/replacement values.
Intangible assets
Ideas, commercial reputation, brand name. Cannot be touched or easily valued, but are often the most important assets — and the hardest to recover once damaged.
Procedures
Supply chains, standard operating procedures, workflows, ways of doing business that are unique to your organisation. Competitive advantage often lives in how things are done, not just what is done.
Mission Essential Functions (MEF): A business activity so critical it cannot be deferred for more than a few hours, if at all. Identify your MEFs first — they determine your risk prioritisation. Everything that supports a MEF gets more protection, more redundancy, and faster recovery time objectives than everything that doesn't.
3
Quantitative Risk — SLE, ARO, ALE & ROSI Formulas
Quantitative risk calculation assigns numerical (dollar) values to risk using mathematical formulas. The result is a dollar figure that allows direct cost-benefit comparison between risk exposure and the cost of controls. Executives love quantitative analysis because it makes decisions simple: spend less on controls than the ALE to justify the investment.
Quantitative risk formula suite — chained calculation
Single Loss Expectancy
SLE = expected loss per single event
SLE = AV × EF
AV = Asset Value ($). EF = Exposure Factor (% of asset lost in one event).
Example: AV=$100,000 × EF=10% → SLE=$10,000
Annual Rate of Occurrence
ARO = how often per year
ARO = events ÷ years
Count occurrences over a period and divide by the number of years in that period.
Example: 1 event in 3 years → ARO = 0.33/yr
Annual Loss Expectancy
ALE = expected yearly loss
ALE = SLE × ARO
Combines the per-event cost with how often that event occurs each year.
Example: $10,000 × 0.33 → ALE=$3,333/yr
Return on Security Investment (ROSI) — is the control worth buying?
ROSI = (ALE − ALEm − Cost) ÷ Cost
ALE = annual loss expectancy without control. ALEm = ALE after the control is applied. Cost = annual cost of the control. If ROSI is positive, the control saves money. If the ALE is $3,333 and a control costs $25,000/year, don't buy it. If a control costs $1,200/year, buy it immediately.
Exposure factor examples: 10-server cluster with 2 servers taken down by ransomware → EF = 2/10 = 20%. 20-office building with 1 office flooded → EF = 1/20 = 5%. The EF is always the percentage of the asset that would be lost or unusable as a result of the specific threat materialising.
4
Qualitative & Hybrid Risk Analysis
Qualitative risk calculation uses expert judgment rather than mathematical formulas to assign ratings of High, Medium, or Low to likelihood and impact. It's faster, requires less data, and is easier to communicate to non-technical audiences — but less precise than quantitative analysis.
Qualitative stoplight chart — 3×3 matrix
🟢 LOW
Low impact + Low likelihood
🟡 MEDIUM
High impact + Low likelihood — or — Low impact + High likelihood
Historical data is available. The risk can be expressed in dollars. Decision makers are financially minded. You have time for detailed analysis. Result: a dollar figure for direct cost-benefit comparison.
Qualitative — use when
Limited or no historical data (new/emerging threats). The risk involves intangibles (reputation, employee morale). Time or resources are constrained. Result: H/M/L rating for quick prioritisation.
Hybrid — use when
You have some data but not enough for a full quantitative analysis. Combine objective historical data with expert judgment. Handles hard-to-quantify risks like reputation or employee morale that can't be cleanly expressed in dollars.
Exam tip — five reasons qualitative is preferred in cybersecurity: Complexity (threats hard to quantify). Unknowns (zero-days, new threats). Limited data (no historical occurrence record). Resource constraints (faster to perform). Communication (H/M/L is clearer to non-experts than SLE formulas). In practice, most organisations use a hybrid of both methods.
5
Business Impact Analysis — MTD, RTO, WRT & RPO
A Business Impact Analysis (BIA) is a systematic activity that identifies organisational risks and determines their effect on ongoing, mission-critical operations. The BIA produces four key availability metrics that drive continuity planning and recovery investment decisions.
MTD
Maximum Tolerable Downtime
The longest period a business can be inoperable without causing irrevocable failure. Sets the outer limit for all recovery planning — RTO + WRT must always be ≤ MTD.
Q: How long can we be down before going out of business?
RTO
Recovery Time Objective
The target time to resume normal business operations after an incident. Example: power RTO = 0 seconds (instant battery failover). Not the same as fixing everything — just getting the primary function back.
Q: How quickly do we need the function back online?
WRT
Work Recovery Time
Additional time after RTO to reintegrate and test restored or upgraded systems. Example: power comes back in 45 seconds (RTO), but a fried server needs to be rebuilt (WRT). RTO + WRT = total recovery time.
Q: How long to fully restore all dependent systems after the primary is back?
RPO
Recovery Point Objective
The maximum tolerable period of data loss. Example: daily midnight backup + ransomware at 6 AM = 6 hours of data loss. If RPO = 4 hours, this backup frequency violates it. Shorter RPO = more frequent backups = higher cost.
Q: How much data can we afford to lose?
MTD, RTO, WRT, RPO relationship: MTD is the ceiling — the maximum you can tolerate. RTO + WRT must fit within the MTD. RPO determines your backup frequency. If RPO is measured in days, tape backups suffice. If RPO is zero or minutes, you need server clustering and real-time replication — which costs significantly more.
6
Risk Prioritization — Four Responses & Risk Appetite
Risk appetite is how much risk an organisation is willing to accept. A large company may accept a $1M risk as manageable; a small company cannot. Risk appetite drives which of the four risk responses is applied to each identified risk.
Mitigate
Add controls
Reduce the risk using controls to bring it within the organisation's risk appetite. Most common response. Does not eliminate risk — reduces it. Example: patching reduces vulnerability risk; seatbelt reduces injury risk in an accident.
Exam keyword: controls / countermeasures
Avoid
Change plans
Stop doing the activity that creates the risk entirely. Least common option — you can't avoid all risks. Example: refusing to fly on small planes; not collecting certain types of customer data that would create liability.
Exam keyword: change course of action / stop doing
Transfer
Insurance / outsource
Move the financial responsibility of the risk to a third party. Examples: cyber insurance policy covers breach response costs. Outsourcing server hosting transfers maintenance and patching responsibility. Note: reputational damage cannot be transferred.
Exam keyword: insurance policy / third party
Accept
Low risk / monitor
Acknowledge the risk and take no additional action beyond monitoring. Used when the risk is within appetite or the cost of controlling it exceeds its expected cost. Example: accepting the risk that an alien invasion will occur.
Exam keyword: risk within appetite / low priority
Security control prioritisation
Required by framework/regulation
Regulatory requirements = law. Non-compliance means fines or being shut down. Always the highest priority controls. No business case analysis needed — you must comply.
Cost of the control
Both initial cost and ongoing maintenance. A $1M/year control protecting a $50K/year asset makes no sense. A $1K/year control protecting against a $10K/year risk is a clear win.
Amount of risk mitigated (ROSI)
A control that eliminates 90% of your risk exposure has higher priority than one that addresses 5%. Calculate ROSI to compare across controls and invest where the return is greatest.
Operations vs. security tradeoff: Security and usability exist in tension. Maximum security (everything encrypted, everything two-factor, everything logged) slows operations. The only 100% secure system is one that's powered off — and it has 0% operational capability. You will always be making tradeoffs. Know your risk appetite and make deliberate engineering tradeoffs accordingly.
Your job as an analyst is to translate technical risk into plain business language. An executive hearing "SYN flood three-way handshake" learns nothing actionable. An executive hearing "our website could go down for 2 hours and we'd lose $25,000 in sales" can make a resource decision immediately.
Risk register — what to document
Impact and likelihood ratings — the H/M/L from your qualitative analysis
Date identified — when was this risk first documented?
Risk description — plain-language statement of the risk and its potential consequence
Countermeasures and controls — what is currently in place to mitigate this risk?
Risk owner — who is responsible for this risk? (A person, not a department)
Risk response decision — accept, mitigate, transfer, or avoid? Made by the risk owner.
Status and plan of action — current state and next steps to bring the risk under control
Risk register is for management and executives — not just the security team. It must be shared with the stakeholders who own the workflows and business functions at risk. They need to understand what risks they're accepting, because ultimately they own those decisions.
Compensating controls
A compensating control acts as a substitute for a primary control when the primary cannot be implemented. It must provide the same or better level of protection using a different method or technology.
Example 1
Requirement: antivirus on all workstations. Can't install AV on one system. Compensating control: install anti-malware (which includes AV functionality) instead.
Example 2
Requirement: 16-character passwords. ICS/SCADA only supports 8-character passwords. Compensating control: multi-factor authentication (smart card + PIN) — stronger than a long password alone.
Exception management
When a policy cannot be met, document it formally with: affected business processes and assets, personnel involved, reason for the exception, risk assessment (is the residual risk acceptable?), compensating controls in place, exception duration (not indefinite — set a deadline), and steps required to achieve compliance. If a policy generates too many exception requests, the policy itself may need redesign.
8
Training & Exercises — Tabletop, Pen Test, Red/Blue/White
Risk mitigation doesn't end with controls — your people must know how to respond. Training teaches what to do; exercises test whether they actually can do it. Two primary exercise types, three team colours.
Tabletop Exercise
Discussion-based — theoretical
Walk through a simulated incident scenario by discussion around a table. Participants describe what they would do, step by step, as if the incident were real. Quick and inexpensive. Risk: "magic wand" effect — participants skip over difficult steps in discussion (a "30-minute fix" becomes a "12-hour crisis" in real life). Don't train executives to expect things faster than they actually happen.
Penetration Test
Active tools — hands-on reality
Uses real security tools to simulate an attack, bypass controls, and exploit vulnerabilities on a live or lab system. Must be properly scoped (define what is tested), resourced (agree on methodology + rules of engagement), and authorised (never test without written authorisation). Prefer external red team or internal red team separate from system admins — admins are biased toward proving security works rather than finding holes.
Red, blue, and white teams
⚔️
Red Team
The attackers — hostile team simulating adversary TTPs. Third-party pen testers or an internal red team (separate from operations). Goal: find every hole. Approach: assume the attacker's perspective.
🛡️
Blue Team
The defenders — system administrators, network defenders, cybersecurity analysts. Your team. Goal: detect, contain, and eradicate the red team's simulated attack. Approach: monitor, alert, respond.
⚖️
White Team
The referees — administer, evaluate, and supervise the exercise. Build the training environment if using a separate network. Write the after-action report identifying what each team did well and poorly. Control the rules of engagement.
Prefer external red teams: System administrators testing their own systems are biased — they try to prove their work is good rather than find holes. An external team or separate internal red team has no such bias and will find vulnerabilities the admin subconsciously protects from scrutiny.
SLE = AV × EF (single event loss). ARO = events ÷ years (frequency per year). ALE = SLE × ARO (annual expected cost). ROSI = (ALE − ALEm − Cost) ÷ Cost. If ALE < cost of control → accept the risk. If control cost < ALE → buy the control.
Exposure factor examples
2 of 10 servers down = 20% EF. 1 of 20 offices flooded = 5% EF. EF = (units unusable) ÷ (total units). SLE = AV × EF. ALE = SLE × ARO. All three chain together for a full quantitative risk picture.
Qualitative vs. hybrid
Qualitative = H/M/L stoplight chart (likelihood × impact). Use when: no data, new threats, limited time. Hybrid = mix concrete data with expert judgment. Use for hard-to-quantify things (reputation, employee morale). Most orgs use hybrid. Qualitative advantages: complexity, unknowns, limited data, resource constraints, communication.
BIA metrics
MTD = max tolerable downtime (ceiling — going out of business threshold). RTO = how fast to get primary function back. WRT = additional time for full system reintegration. RPO = max data loss tolerable (drives backup frequency). RTO + WRT ≤ MTD always.
Translate technical to business impact: not "SYN flood" but "site goes down for 2 hours = $25K lost sales." Risk register: impact/likelihood, date, description, countermeasures, owner, response decision, status. Share with all stakeholders — they own the business functions at risk.
Compensating controls & exceptions
Compensating control = substitute for primary control, same or better protection. Exception = formal documentation when a policy can't be met. Exception includes: affected systems, reason, risk assessment, compensating controls, duration (not indefinite), compliance path. Too many exceptions = redesign the policy.
Teams & exercises
Tabletop = discussion, cheap, no hands-on (magic wand risk — don't let execs expect tabletop speed in real life). Pen test = real tools, scoped, rules of engagement required. Red = attackers (external/separate internal). Blue = defenders (your team). White = referees + AAR authors. Prefer external red teams — admins are biased.