“We need to improve our cyber risk posture.”

If you’ve sat through security presentations, you’ve heard variations of this statement. It sounds important. It contains buzzwords. And if you’re like most executives, you nodded along while having no idea what it actually meant.

Here’s the thing: risk management is genuinely important. It’s how you make rational decisions about where to spend limited security resources. But the way it’s usually explained—heat maps, risk registers, inherent vs. residual risk matrices—obscures a simple concept behind consultant-speak.

Let me try a different approach.

Risk Management Is Just Decision-Making Under Uncertainty

Every business decision involves uncertainty. When you hire someone, you don’t know if they’ll work out. When you launch a product, you don’t know if customers will buy it. When you enter a market, you don’t know how competitors will respond.

You manage these risks intuitively. You check references before hiring. You do market research before launching. You analyze competitors before entering. You’re not eliminating uncertainty—you’re understanding it well enough to make reasonable decisions.

Cybersecurity risk management is the same thing, applied to “something bad happening to our technology and data.”

That’s it. No matrices required.

The Four Questions That Matter

Every security risk can be analyzed with four questions:

1. What bad thing could happen?

This is your threat scenario. Not “hackers” generically, but a specific sequence: “An attacker compromises an employee’s email account, uses it to reset the password for our admin panel, and exfiltrates our customer database.”

The more specific you get, the more useful the analysis. “Data breach” is too vague. “Customer PII exposed due to credential compromise” is actionable.

2. How likely is it?

This is where traditional risk management introduces complicated probability assessments. In practice, for most organizations, a three-tier model works:

• Likely: This happens regularly in your industry, you have limited controls, or it’s happened to you before
• Possible: This happens occasionally in your industry, you have some controls but gaps exist
• Unlikely: This rarely happens, you have strong controls, and nothing suggests you’re a target

Don’t pretend you can calculate that there’s a “23.7% annual probability of credential compromise.” You can’t. Rough categories are more honest.

3. How bad would it be?

If the bad thing happens, what’s the damage? Think in concrete terms:

• Financial impact (incident response costs, fines, lawsuits, lost revenue)
• Operational impact (can the business function while you recover?)
• Reputational impact (will customers and partners trust you afterward?)
• Regulatory impact (will regulators take action?)

Again, rough categories work. “Minor inconvenience” to “business-ending catastrophe” with a few levels in between.

4. What are we doing about it?

For any risk, you have four basic options:

• Accept it: Decide the risk is tolerable and do nothing. This is a legitimate choice for low-likelihood, low-impact risks.
• Mitigate it: Implement controls to reduce likelihood or impact. This is most security spending.
• Transfer it: Make it someone else’s problem—cyber insurance, contractual liability shifts, or outsourcing.
• Avoid it: Stop doing the thing that creates the risk. Don’t store data you don’t need. Don’t run services you don’t use.

An Example That’s Not Boring

Let’s walk through this with a real-ish scenario.

Scenario: Your company uses a SaaS vendor for customer relationship management. The vendor has admin access to customer data. The vendor’s security practices are unknown.

Question 1: What could happen? The SaaS vendor gets breached, attackers access your customer data through the vendor’s systems, and you suffer a data breach by proxy.

Question 2: How likely? Possible. Supply chain attacks are increasingly common. You don’t know their security posture. They have access to valuable data.

Question 3: How bad? Depends on the data. If it’s just contact info, maybe moderate impact—some customer notification, reputational hit, possible regulatory inquiry. If it’s sensitive personal data or financial information, potentially severe—major fines, lawsuits, customer exodus.

Question 4: What do we do?

Options:

• Accept: Decide the risk is worth the vendor’s benefits and move on
• Mitigate: Conduct security assessment of vendor, require security certifications (SOC 2, etc.), limit data shared to minimum necessary, implement monitoring for anomalous activity
• Transfer: Ensure contract includes liability provisions, verify vendor has adequate insurance
• Avoid: Use a different vendor with better known security, or bring the function in-house

There’s no single right answer. A startup with limited resources might accept risks that an enterprise with regulatory obligations must mitigate. The point of the exercise is making a deliberate choice rather than accidentally accepting risks you didn’t know existed.

Why “Risk Appetite” Isn’t Corporate Nonsense

You’ll hear security people talk about “risk appetite”—how much risk the organization is willing to tolerate. This sounds like consultant-speak, but it’s actually the crucial variable.

Different organizations have legitimately different risk tolerances:

A consumer tech startup might accept significant security risk to move fast. Getting hacked would be embarrassing but probably not fatal. Moving slowly and losing to competitors definitely is fatal.

A healthcare company has different calculus. HIPAA violations can result in massive fines and criminal liability. The cost of security failure far exceeds the cost of security investment.

A defense contractor operates differently still. Security clearance revocation ends the business. There’s no acceptable level of compromise.

Your security team can’t decide your risk appetite—that’s a business decision. But they can’t do their job without knowing it. The conversation executives need to have is: “Given who we are, our regulatory environment, our customers’ expectations, and our resources, how much security risk is acceptable?”

If you’ve never had that conversation explicitly, your organization is accepting risks by accident rather than by choice.

The Risk Register Is Just a List (With Accountability)

A “risk register” sounds formal. It’s just a list of identified risks with:

• Description of the risk
• Current likelihood and impact assessment
• What you’re doing about it (accept/mitigate/transfer/avoid)
• Who’s responsible
• When you’ll review it again

The value isn’t the document—it’s the discipline of writing things down and assigning ownership. Unwritten risks are unmanaged risks. Risks without owners are everyone’s problem and therefore no one’s problem.

You probably have informal risk registers for other parts of the business. “We’re watching competitor X closely, and if they do Y, we’ll respond with Z” is an unwritten risk register entry. Making cyber risks similarly explicit is the goal.

What Executives Actually Need to Do

If you’re an executive who doesn’t live in security, here’s your practical checklist:

Understand your critical assets. What data and systems would be catastrophic to lose? If you can’t list them, neither can your security team.

Define your risk appetite. Have the explicit conversation about what level of security risk is acceptable. Document it. Don’t make your security team guess.

Demand plain English. If your CISO can’t explain a risk in terms you understand, either they don’t understand it, or they’re hiding behind jargon. Both are problems.

Make decisions, don’t delegate them. Risk acceptance should be conscious and documented. “We’ve decided to accept the risk of X because the mitigation cost exceeds the potential impact” is fine. Accidentally accepting risks because nobody thought about them is not fine.

Review regularly. Business conditions change. The risk assessment from last year doesn’t reflect your current reality. Quarterly reviews for major risks, annual reviews for the full portfolio.

The Dirty Secret About Risk Quantification

There’s a whole industry around quantifying cyber risk in dollar terms. “You have a 15% annual probability of a breach that would cost $10 million, so your annualized risk exposure is $1.5 million.”

This is seductive because it translates security into financial language. Executives love financial language.

Here’s the problem: the inputs are mostly made up. We don’t have reliable actuarial data for cyber risk the way we do for car accidents or house fires. Industry-wide breach statistics don’t predict your specific likelihood. Impact estimates vary by orders of magnitude depending on assumptions.

Precise-looking numbers create false confidence. “The model says our risk is $2.3 million” sounds scientific but often reflects arbitrary assumptions encoded in a spreadsheet.

I’m not saying quantification is useless—rough estimates beat no estimates. Just be honest about uncertainty. “We think this risk is in the $1-5 million range if it materializes, and similar companies get hit every few years, so we should probably budget proportionally for controls” is more honest than false precision.

Risk Management vs. Compliance

These are related but different things.

Compliance means meeting external requirements—regulations, contractual obligations, certification standards. You’re compliant or you’re not. It’s pass/fail against someone else’s criteria.

Risk management means making good decisions about uncertainty. You might accept risks that regulations require you to mitigate (and accept the compliance consequences). You might mitigate risks that no regulation requires (because they’re still risks).

Good security programs do both. They meet compliance requirements (because failing audits has real consequences) while also managing risks that compliance doesn’t cover (because auditors don’t identify every threat).

The danger is treating compliance as synonymous with security. “We passed our SOC 2 audit” doesn’t mean you’ve managed your risks. It means you’ve met the SOC 2 criteria. Those criteria might not address your specific threat landscape.

Use compliance as a floor, not a ceiling. Meet the requirements, then do the additional risk management that your business actually needs.