Risk Management interview questions

Most frameworks (ISO 31000, ISO/IEC 27005, NIST SP 800-30 / 800-37) follow a similar cycle:

1. Establish context: objectives, scope, criteria for likelihood, impact and risk appetite.
2. Identify risks: assets, threats, vulnerabilities, processes, third parties.
3. Analyse: estimate likelihood and impact, taking existing controls into account.
4. Evaluate: compare against risk criteria and appetite to prioritise.
5. Treat: mitigate, transfer, avoid or accept, with owners and due dates.
6. Monitor and review: track treatment progress, KRIs and changes in the environment.
7. Communicate and consult throughout, and record everything (risk register).

• Mitigate (reduce/modify): implement controls to lower likelihood or impact — e.g. deploy MFA.
• Transfer (share): shift part of the financial impact to another party — e.g. cyber insurance, contractual clauses. Accountability for the risk stays with the organisation.
• Avoid (terminate): stop the activity that creates the risk — e.g. retire a legacy system.
• Accept (tolerate): consciously take the risk because it is within appetite or treatment costs more than the benefit. This must be a documented decision by someone with the right authority.

A risk register is the central record of identified risks and how they are managed. Typical fields:

• Risk ID, title and clear risk statement (cause → event → consequence).
• Category (cyber, privacy, third-party, operational, compliance).
• Risk owner (accountable person, usually a business leader).
• Inherent likelihood, impact and rating.
• Existing controls and their effectiveness.
• Residual rating and comparison with appetite.
• Treatment decision, actions, action owners and due dates.
• Target risk, related KRIs, status and last review date.

A heat map plots risks on a grid of likelihood vs impact, coloured green to red, to show relative priority at a glance.

Limitations:

• Ratings are subjective and can be inconsistent between assessors.
• Ordinal scales cannot be meaningfully multiplied or added (a '4' is not twice a '2').
• Risks in the same cell may differ greatly in real exposure.
• It can hide aggregation — many 'medium' risks may together be significant.

Mitigate this with clear scale definitions, calibration sessions and quantitative analysis for top risks.

A risk statement describes a risk clearly enough that someone can own it, assess it and treat it. A common format is cause, event and consequence:

• 'Because of [cause/vulnerability], [event] may occur, leading to [business impact].'
• It names the business impact, not just the technical problem.
• It is specific enough to assess. 'Cyber attack' is too vague; 'ransomware through unpatched VPN' is assessable.
• One risk per statement. Do not mix several causes and impacts.

• Likelihood: how probable it is that the risk event happens in a given period, considering threats, vulnerabilities and existing controls.
• Impact: how bad the consequences would be: financial loss, patient or customer harm, regulatory action, reputational damage, operational disruption.
• Scoring: usually a 1–5 scale for each, with written definitions (for example, impact 5 = loss over a defined amount or harm to patients; likelihood 5 = expected more than once a year).
• Risk rating = a combination, often via a matrix, of likelihood × impact.
• Use the same definitions across the organisation so scores are comparable.

• Risk appetite: the amount and type of risk an organisation is willing to pursue or accept to achieve its objectives. Usually set by the board, often as qualitative statements per risk category (e.g. 'very low appetite for regulatory non-compliance').
• Risk tolerance: the acceptable variation around objectives — often expressed as measurable thresholds (e.g. 'no more than X hours of downtime for critical systems per quarter').
• Risk capacity: the maximum risk the organisation can absorb before it fails or breaches its obligations.

Appetite should sit well within capacity, and KRIs are often set against tolerance thresholds.

• Qualitative: uses descriptive scales (e.g. Low/Medium/High or 1–5) for likelihood and impact, often plotted on a heat map. Fast, easy to understand, good for broad prioritisation, but subjective and hard to compare with financial decisions.
• Quantitative: expresses risk in numbers, usually money and probability (e.g. expected annual loss, loss ranges). Supports cost-benefit analysis and insurance decisions but needs data and more effort.
• Semi-quantitative: assigns numeric scores to qualitative scales; useful but the numbers are still ordinal, not true measurements.

Many mature programmes use qualitative assessment for the full register and quantitative analysis for top risks.

These are the classic quantitative risk formulas:

• Asset Value (AV): the value of the asset.
• Exposure Factor (EF): the percentage of the asset value lost in one event.
• Single Loss Expectancy: SLE = AV × EF.
• Annualised Rate of Occurrence (ARO): how many times per year the event is expected to happen (e.g. 0.5 = once every two years).
• Annualised Loss Expectancy: ALE = SLE × ARO.

Example: AV = 200,000, EF = 25% → SLE = 50,000. ARO = 0.2 → ALE = 10,000 per year. A control costing much more than the ALE reduction it delivers is hard to justify on cost alone.

1. Understand scope: business purpose, data types (e.g. PHI, personal data, card data), users, integrations, hosting and vendors.
2. Classify data and identify applicable requirements (HIPAA, GDPR, DPDP, PCI DSS, contracts).
3. Identify threats and vulnerabilities — architecture review, questionnaires, threat modelling, scan results.
4. Assess existing and planned controls against a baseline (e.g. ISO 27001 Annex A or NIST 800-53).
5. Rate likelihood and impact using the organisation's methodology.
6. Recommend treatments, agree owners and timelines, and record residual risk.
7. Get sign-off from the risk owner before go-live; schedule reassessment on significant change.

• The risk owner is the person accountable for managing the risk — usually the business or process leader who owns the objective affected, not the security team.
• Security / GRC advises, facilitates and challenges (second line).
• Risk acceptance authority should scale with risk level, e.g. a manager can accept low risks, a senior executive or committee must accept high risks above appetite.
• Acceptance must be documented with rationale, conditions and an expiry/review date.

• Risk: an uncertain future event that may affect objectives.
• Issue: a problem that has already happened or a known condition that needs action now (e.g. a control is not operating).
• Finding: the result of an audit or assessment that identifies a gap against a requirement — it often becomes an issue with a remediation plan, and may increase a related risk.

Keeping them distinct but linked (finding → issue → affected risk) helps reporting stay accurate.

A control self-assessment asks the first line (control owners and process owners) to evaluate their own risks and controls, usually through workshops or structured questionnaires, with GRC facilitating and challenging.

• Useful for broad coverage of many controls between audits, raising risk awareness and building ownership.
• Weakness: people tend to rate their own controls favourably, so results need validation by sampling and review of evidence.
• Results feed the risk register, the audit plan and management reporting.

A risk scenario is a short, concrete story of how a loss could happen: threat actor, method, asset affected and business consequence.

• They make abstract risks tangible for business owners.
• They give structure to quantitative analysis (FAIR needs a clearly defined scenario).
• Build them from threat intelligence, past incidents, industry reports and the asset inventory.
• Keep a library of 10–20 top scenarios and reuse them for assessments, tabletop exercises and board reporting.

• ISO 31000 gives general principles, a framework and a process for managing any type of risk across an organisation.
• ISO/IEC 27005 gives guidance on information security risk management specifically, supporting the requirements of ISO/IEC 27001 clauses 6.1 and 8.2–8.3.
• The 2022 edition of 27005 aligns with ISO 31000 terminology and describes both event-based (scenario) and asset-based approaches to identifying risks.
• Neither is certifiable on its own; both are guidance.

• Clarify the facts quickly: what are the risks, how likely, what is the impact, and are there interim compensating controls?
• Offer options rather than a simple block: delay, go live with reduced scope (for example no real patient data yet), or go live with compensating controls and a fix date.
• If the business chooses to go ahead, the decision must be made by someone with authority for that level of risk and recorded as a formal acceptance with an expiry date.
• Track the remediation actions and report them through governance.

1. Confirm exposure: which assets run the affected version, are they internet-facing, and is exploitation happening in the wild (for example, is it listed in CISA's Known Exploited Vulnerabilities catalogue)?
2. Assess impact: what data and business processes those assets support.
3. Apply interim mitigations if no patch exists: vendor workarounds, blocking at the WAF, disabling the feature, extra monitoring.
4. Communicate a short, factual update to leadership: exposure, actions taken, residual risk and next update time.
5. Track patching to closure, and record the event in the risk register and lessons learned.

• Check the scales first. Different results usually come from vague definitions or different interpretations of impact.
• Publish a single scoring guide with concrete examples for each level of likelihood and each impact type (financial, patient safety, regulatory, reputation, operations).
• Run a calibration workshop: score 3–5 reference risks together and discuss the differences.
• Make GRC the second-line challenger for high ratings, so outliers are reviewed before they reach the register.
• Review consistency each cycle and refine the examples.

FAIR (Factor Analysis of Information Risk) is a model for quantifying cyber and operational risk in financial terms, maintained by the FAIR Institute and adopted as an Open Group standard.

• Risk is decomposed into Loss Event Frequency (how often a loss happens) and Loss Magnitude (how much it costs).
• Loss Event Frequency comes from Threat Event Frequency and Vulnerability (probability a threat event becomes a loss).
• Loss Magnitude includes primary losses (response, replacement, productivity) and secondary losses (fines, legal, reputation).
• Inputs are ranges (min / most likely / max) and Monte Carlo simulation produces a distribution of possible annual losses.

Benefits: comparable risks, cost-benefit analysis of controls, clearer board conversations.

• Make sure the risk is clearly articulated in business terms (impact on revenue, patients/customers, regulation, operations).
• Understand their constraints — budget, timelines, competing priorities — and explore alternatives or compensating controls.
• If they still choose not to treat it, follow the formal acceptance process: the decision must be made by someone with authority for that level of risk.
• If the risk exceeds appetite, escalate through governance (risk committee, CISO, executive) — escalation is a process, not a confrontation.
• Document the decision, rationale and review date, and monitor with KRIs.

• Use a risk taxonomy (for example, Level 1 'Cyber', Level 2 'Data breach', 'Service disruption', 'Third-party') so detailed risks roll up under common headings.
• Avoid simply averaging scores. Several medium risks with a shared cause can add up to a high enterprise exposure.
• Look for common causes and dependencies (the same identity provider or the same unsupported platform).
• Where possible, quantify and sum loss ranges, or at least report the worst credible scenarios per category.
• Report at enterprise level by category, with drill-down available.

• Avoid benchmarks alone ('X% of IT budget'). They say nothing about your specific risks.
• Start from the top risk scenarios and estimate their annual loss exposure, even as ranges.
• For each proposed investment, estimate how much it reduces likelihood or impact, and compare that with its cost (return on risk reduction).
• Show what is needed to bring risk within appetite, and what the remaining risk is if a project is not funded.
• Include regulatory and contractual must-haves separately: some spending is a licence to operate.

1. Triage: close duplicates and risks that no longer exist, merge similar risks and convert issues or findings into the issues log.
2. Re-baseline the top 20–30 risks with their owners using current scoring definitions.
3. Introduce a taxonomy so the remaining risks roll up into categories leadership understands.
4. Set review cadences by rating (for example, high risks monthly, medium quarterly).
5. Make it useful: link risks to KRIs, treatment plans, incidents and audit findings, and use it in actual committee decisions.
6. Report trend and movement, not just a static list.

• Treat insurance as a risk transfer option that only works alongside strong controls. It does not replace them.
• Collect evidence for the controls insurers usually focus on, such as MFA (especially remote and privileged access), EDR, offline or immutable backups with restore tests, patching and incident response plans.
• Answer the questionnaire accurately. Misrepresentation can undermine a claim.
• Use your risk scenarios (and any quantification) to decide on limits, retentions and exclusions with the broker and finance.
• Feed the insurer's requirements back into the roadmap as a business case.