Operational Risk Management Questions

Direct answer

Tie the path to a residual score band and make each band answer four questions: who is told, who may accept, by when, and with what conditions. Nobody accepts a risk above their delegated limit, and every acceptance expires.

Escalation path (illustrative policy on a 5x5 scale: likelihood 1 to 5 times impact 1 to 5; 20 to 25 Critical, 15 to 19 High, 8 to 14 Medium, 1 to 7 Low). The residual score is the score after existing controls.

A residual of 4 x 4 = 16 lands in High. Here likelihood 4 (likely) means a full-region failure is expected within a year or two, and impact 4 (major) means customer-visible order loss with contractual exposure; the scale words are 1 rare, 2 unlikely, 3 possible, 4 likely, 5 almost certain for likelihood, and 1 minor to 5 severe for impact.

Who owns what across functions

• Service owner: the person accountable for running a given service; Product owns the business outcome and normally signs.
• Sales: states customer commitments and contract exposure.
• Legal: judges regulatory or contractual duties; acceptance cannot waive those.
• Security: assesses and challenges the residual score and must concur.
• Operations: owns the contingency and detection that make acceptance safer.

Cadence and disputes

Critical items reviewed weekly until closed; High monthly in a risk forum (a standing meeting that reviews open risks). The risk committee is the executive group that oversees risk across the company. If the risk owner and security disagree, escalate to their next common manager within 2 business days; if unresolved, the more senior authority decides in writing and the dissent is recorded.

Message to executives (bottom line first)

Decision needed by Friday: accept or fund the fix for checkout data loss risk, still rated High (4 x 4 = 16) after mitigation. Exposure: a full-region failure can lose up to the last 15 minutes of orders. Mitigation done: cross-region replication. Remaining gap: no tested restore. Options: fund 6 engineer-weeks to drill and automate restore (reduces residual to 2 x 4 = 8, Medium), or accept for 90 days with monthly review, the cadence the High band sets. My recommendation: fund. If accepted, owner is the VP of Commerce.

Pitfalls: escalation that only informs, no expiry, and acceptors who lack the authority for the size of loss.

Direct answer. A risk register is a list of identified risks with enough information to decide, act and track. An entry is useful when someone named owns it, it says what you will do and by when, and it is reviewed on a schedule. A register that sits there is usually a long list of vague worries with no owner, no dates and no link to decisions.

Fields I would insist on, and why

Scoring scales and bands used here. Likelihood: 1 rare, 2 unlikely, 3 possible, 4 likely, 5 almost certain. Impact: 1 minor, 2 moderate, 3 significant, 4 major, 5 severe. Score 15 to 25 is High, 8 to 14 is Medium, 1 to 7 is Low. These cut-offs are a choice each organization makes to match its risk tolerance, not a universal standard; here High starts at combinations such as 3 x 5 or 4 x 4. Inherent risk is the score before the planned actions (some teams measure it before any control at all, so state which basis your register uses); here it is the score with today's controls.

Worked entry: vulnerable dependency

• ID R-017. Description: because the payments service uses an open-source library with no automatic update, a newly published critical vulnerability could be exploited before we patch, leading to customer data exposure.
• Inherent: likelihood 4 (likely, because there is no automatic update and the window to exploit is open until we patch), impact 4 (major, because the payments service holds customer data), score 16 (High).
• Controls: dependency scanning in the build pipeline, a rule that critical fixes ship within 7 days.
• Response: reduce. Actions: enable automatic update pull requests (owner: platform lead, due end of next month).
• Residual: likelihood 2 (unlikely, because updates are proposed automatically), impact 4 (unchanged), score 8 (Medium).
• KRI: number of critical vulnerabilities open longer than 7 days. Amber at 1, red at 3.
• Next review: quarterly.

What keeps a register used.

• Review cadence tied to residual score: High monthly, Medium quarterly, Low twice a year.
• High items reach leadership with a decision needed, not just a status.
• Cap the list: merge duplicates, close with evidence, retire what no longer applies.
• Flag any entry that has passed its own next-review date without an update. The threshold follows the cadence: a High entry is stale after about a month, a Medium after about a quarter, a Low after about six months, so a flat 90-day rule would wrongly flag healthy Low entries.

Pitfalls. Entries like "security risk" with no event or consequence. Owners who are teams. Scores never revisited after actions complete.

Direct answer

Rank the ten risks by annual expected loss reduction per dollar of fix, pick the best three that fit the budget, then correct the ranking for overlap (two fixes that remove the same cause) and diminishing returns (the last few percent cost the most). Two terms matter here. Risk appetite is how much risk the organization is willing to pursue overall. Risk tolerance is the limit for a specific risk, above which you must act whatever the ratio says. Tolerance overrides the arithmetic where a single risk sits above it.

Setup (illustrative, $k)

Expected loss = probability x impact, per year. Budget: $250k one-time, so I compare yearly reduction to one-time cost (a first-year view; a multi-year view would favour durable fixes more). Reduction = expected loss x fix effectiveness.

Choosing

• Greedy by ratio (take the best ratio first, then the next, until the budget runs out) gives D, F, A (cost 230, reduction 480 + 360 + 240 = 1,080), and the next best, B, does not fit.
• Overlap: suppose D and F share a root cause. After D, F's gain halves from 240 to 120. Checking every set of three risks costing at most $250k (I ran them all), A + D + F gives 960 and A + D + I gives 945, the next best. Overlap took 120 off the naive 1,080 and made the choice a near tie.
• I pick A, D, F (cost 230, reduction 960) because the 15-point gap is far inside the error of the estimates, and A + D + F only gets better if the overlap is smaller than assumed: with no overlap it is 1,080 and still ahead of every other triple (the best alternative without overlap is B + D + F at 950, which falls to 830 if D and F overlap, and A + D + I gives 945 either way), so it is never worse. Total expected loss is 3,320 a year, so about 2,360 remains.
• Diminishing returns: pushing D from 90% to 99% effectiveness would remove another 400 x 0.09 = $36k a year for about $60k more, a ratio of 0.6. Stop at 90%.

Do now, defer, accept

• Do now (ratio view): A, D, F. The tolerance check below can change this verdict.
• Defer with a trigger (ratio at or above 2.0): B, I, H. B is first in line next budget cycle.
• Accept and monitor (ratio below 2.0): C, E, G, J, with a KRI (key risk indicator, an early-warning metric) each. G and J are below 1.0.

Risk appetite weighting

Suppose leadership sets the tolerance for any single risk at $450k a year. A (600) and B (500) are above it and must be treated whatever the ratio. A is already in the set; B is not. A + B + D costs 120 + 100 + 60 = $280k, $30k over budget, and removes 480 + 350 + 360 = 1,190. I would ask for the extra $30k instead of leaving an above-tolerance risk open. If that tolerance applies, the final verdict is A, B, D now and F moves to defer; if leadership has set no such limit, A, D, F stands.

Pitfalls: treating point estimates as certain (use ranges, or Monte Carlo simulation, which samples many plausible values, if the decision is large), ignoring dependencies between fixes, and funding by ratio alone.

Direct answer. Expected annual loss (EAL) is probability per year x loss per occurrence. R1 = 10,000, R2 = 2,000, R3 = 500, total 12,500. R1 ranks first. But the ranking alone should not decide the order of mitigation, and the estimate I trust least is R1's 2%.

Calculations

R1: 0.02 x 500,000 = 10,000
R2: 0.10 x  20,000 =  2,000
R3: 0.50 x   1,000 =    500
Total               = 12,500

R1 is 80% of the total (10,000 / 12,500), R2 16%, R3 4%. Ranking: R1, R2, R3. Intuition: an average, and the rare large loss dominates it.

Why the ranking is not the decision

1. Mitigation cost and effect. EAL is what you could save, not what it costs. If removing R3 costs $200 and R1 costs $400,000, R3 may come first. Rank by loss removed per dollar.
2. Shape of the loss. R1 is a once-in-fifty-years style event that arrives as a $500k hit; the chance of at least one in ten years is 1 - 0.98^10, about 18%. If the company cannot absorb $500k, that is a survival question an average does not show. R3 is a small, frequent cost (even odds in any given year): a cost of doing business to automate or accept.
3. Non-financial impact. Safety, legal or reputational harm does not fit the dollar figure.
4. Correlation. If R1 and R2 share a cause, fixing it removes both.

Which estimate I trust least: R1's probability. A 2% rate is rarely backed by history, so it is a judgement. The sensitivity is large: at 1% R1 is 5,000, at 4% it is 20,000. R3 is the most trustworthy because a 50% annual event happens often enough to count. R2's $20,000 loss may be biased too, but its probability has data behind it. Break-even check: R1 stays above R2 unless its probability falls below 0.4% (2,000 / 500,000), so R1's rank is fairly stable, but its size is not.

Spreadsheet sensitivity. Put the three rows in a sheet with low/likely/high for probability and loss, and recompute the ranking. If the order holds across the range, act on it; if it flips, estimate more carefully only where it flips.

Pitfall. Presenting 12,500 as a precise forecast. It is a planning figure.

Direct answer

Technical debt means shortcuts in design or code that save time now and cost more to maintain or fix later. Treat it as a decision that belongs to the person who owns the outcome, and make that decision informed, explicit and written down. I do not try to win the argument or block the milestone. I make the risk concrete in the stakeholder's own terms, offer options that protect the milestone, and if they still accept, I record who accepted what, until when, and what triggers the fix.

Negotiation, in order

1. Understand the milestone. What does hitting it buy (a contract, a launch, funding)? If I cannot say what they gain, I will not be heard on what they risk.
2. Quantify the risk in their language. Example (illustrative): a 25% chance in the next two quarters that the debt causes an outage costing $800k is an expected loss of 0.25 x 800 = $200k, plus the customer trust cost I cannot price. Show a range rather than false precision.
3. Offer options, not a veto: a reduced-scope mitigation that fits before the milestone, a time-boxed acceptance with a funded remediation slot next quarter, or a tripwire (a key risk indicator, KRI: a metric that warns the risk is getting worse) that automatically reopens the decision.
4. Ask for an explicit decision from someone with the authority to accept it, not a vague nod in a meeting.

Documenting the decision (risk acceptance record)

Accountability if it manifests

The signer owns the business consequence and engineering owns executing the contingency. The incident review uses the record as the starting fact pattern (what was known, what was accepted, were the conditions kept), blameless in tone (it asks what in the system and process allowed the outcome, not whom to punish) but not blind to who decided. Remediation was pre-scheduled, so it starts immediately rather than being renegotiated.

Escalating to leadership and legal

If the stakeholder lacks authority for this size of risk, or the debt touches a legal duty (data protection, contractual uptime commitments), escalate. If an interviewer asks for a real example, tell it in STAR form (Situation, Task, Action, Result, a standard format for behavioural answers). Situation: state the architectural risk and the deadline pressure. Task: get a decision from the right authority. Action: send a written one-page summary with evidence (incident history, load data, assessment), the options, and the decision requested by a date, copied to legal where an obligation is involved. Result: report what was decided and what changed. If you have no direct experience, say so honestly and describe a smaller comparable case (for example, a time you documented a disagreement over a release) plus exactly the steps above you would take. Do not invent an outcome.

Pitfalls: becoming the "no" person, accepting verbally with nothing in writing, and acceptance without an expiry.