Why does your risk program exist?

If the honest answer is "because SOC 2 requires it" or "because the auditor asked for it," you don't have a risk program.

You have a compliance control that happens to be called risk management.

And you're not alone. Most GRC programs I speak to have the same problem. The risk register exists because a framework said it should. The risk appetite statement says "low" for everything because nobody wants to sign their name next to "we accept this." The risk scenarios describe control gaps instead of business outcomes.

The whole thing is an ouroboros.

"Why do we have a risk program?" Because compliance requires one.

"What does the risk program cover?" Compliance risks.

"How do we know it's working?" The auditor accepted it.

The snake eats its own tail. Actual business risk happens outside the circle entirely.

IN PARTNERSHIP WITH

Finding GRC gaps is the easy part. Getting them closed without creating more operational drag is the real challenge.

Join Scrut’s live webinar to see how GRC and security teams are moving beyond passive tracking to agent-assisted execution, where routine compliance work gets pushed forward, approvals stay human, and every action remains auditable and accountable.

How This Happens?

It starts innocently. You're building a SOC 2 programme. The framework requires risk management. You stand up a risk register, write a risk appetite statement, run a risk assessment.

Checkbox done.

But the programme was born to satisfy a control. So it behaves like a control:

- It activates before audits, not after incidents

- It speaks framework language, not business language

- It measures compliance status, not exposure

Nobody planned this. It's the natural consequence of building risk management inside a compliance programme instead of the other way around. I covered a version of this dynamic in Compliance as Cope: we automated the wrong layer.

The same pattern applies to risk.

Five Signs Your Risk Programme Is Actually a Compliance Control

1. Your risk register updates happen before audits, not after incidents.

Compliance-driven: The register gets refreshed in Q3 because the SOC 2 observation period starts in Q4. Risks are reviewed to make sure nothing looks embarrassing.

Risk-driven: The register updates when something changes. A new product launch, a vendor incident, a market shift, an architectural decision. The trigger is the business, not the calendar.

The question: When was your register last updated? If it was before the last audit and not since, you know what's driving updates.

2. Your risk appetite statement says "low" for everything.

Compliance-driven: The board approved a risk appetite statement that says the organisation has "low appetite" for every category. Nobody pushed back because nobody read it. It exists to satisfy the control.

Risk-driven: The statement has real thresholds:

- "We accept up to 4 hours of downtime per quarter for non-critical services."

- "We accept residual risk on legacy systems scheduled for decommission within 6 months."

Specific. Measurable. Actually used in decisions.

3. Your risk scenarios describe control gaps, not business outcomes.

Here's what this looks like in practice:

# Compliance-driven risk entry

- risk_id: R-041

  description: "Lack of multi-factor authentication"

  likelihood: High

  impact: High

  owner: "IT Security Manager"

  review_date: "2026-Q3"

# Risk-driven risk entry

- risk_id: R-041

  scenario: "Credential compromise → unauthorised PII access"

  business_impact: "Regulatory notification + $2M remediation + enterprise pipeline damage"

  annualised_loss_expectation: "$840,000"

  owner: "VP Engineering (can authorise MFA rollout)"

  trigger: "Any auth-related incident or architecture change"

The first describes a missing safeguard. The second describes what actually happens to the business. I wrote about transforming static registers into action engines in Risk Registers Reimagined.

4. Your risk reporting uses traffic lights instead of currency.

Compliance-driven: The board sees a 5x5 heatmap with red, amber, green dots. Nobody knows what "high likelihood, high impact" actually means in business terms. But it looks like risk management is happening.

Risk-driven: The board sees estimated loss exposure in dollars. Instead of:

> "IAM risk: Critical (30/30)"

You present:

> "Token leaks via public repositories will cost between $210K and $4.2M annually, with a most likely outcome around $1.15M. There is a 63% probability annual losses exceed $1M."

Finance understands this. The board can make actual decisions.

One gets a slide. The other gets a budget.

The techniques exist. Calibrated estimation, Monte Carlo simulation, Bayesian updating. They're not new and they're not hard. The problem is that compliance-driven risk programs never needed them. A heatmap was enough to pass the audit.

If you want to go deeper on this shift, Tony Martin-Vegue's podcast with me on why cyber risk quantification is the mindset shift your GRC programme needs is worth your time.

5. Your risk owner is whoever was in the room when the risk was identified.

Compliance-driven: The risk register assigns ownership to whoever attended the risk workshop. Usually a manager who didn't know they'd be volunteered. They've never looked at the register since.

Risk-driven: The risk owner is the person who can actually change the outcome:

- The VP Engineering who decides whether to prioritise the fix

- The Head of Product who chooses whether to accept the delay

- Someone with authority, budget, and accountability

IN PARTNERSHIP WITH

Why FedRAMP Is About to Matter to Every GRC Team (Even If You Don’t Sell to the Government)

Compliance doesn't have to suck.

Stop drowning in "soul-crushing" spreadsheets. Whether you’re tackling FedRAMP 20x, Rev 5, or CMMC, Paramify automates the heavy lifting. Generate instant, machine-readable SSPs and POA&Ms that are actually audit-ready.

Get compliant 90% faster at 1/4 the cost - and like your job at the same time.

Why This Matters More Than Ever

In an agentic world, the gap between performative risk management and real risk management becomes existential.

AI agents don't care about your heatmap. Automated attackers scan, identify, and exploit at machine speed. The risks that matter are moving faster than your quarterly risk review cycle can capture them.

If your risk program is still oriented around what the auditor needs to see, you're building for auditors instead of attackers. Security teams, product teams, engineering teams: they're all operating in real-time.

GRC is the only function still running on audit-cycle time.

That disconnect is itself a risk. And it's not on your register.

What Risk-Driven Actually Looks Like

The fix isn't complicated. It's directional.

Compliance-driven risk management starts with the framework and asks: "What does the auditor need to see?"

Risk-driven risk management starts with the business and asks: "What could actually hurt us, and what are we doing about it?"

The risk programme should generate requirements for compliance. Not the other way around.

When risk management leads, you get:

- A risk register that actually informs decisions

- A risk appetite that means something

- Scenarios that the business recognises

- Reporting that finance can act on

- Owners who own

# Compliance-driven: runs before audit season

def quarterly_risk_review():

    risks = get_risk_register()

    for risk in risks:

        risk.status = "Reviewed"

        risk.review_date = next_audit_date()

    generate_board_heatmap(risks)  # red/amber/green

# Risk-driven: runs when the business changes

def on_change(event: BusinessEvent):

    affected = identify_affected_risks(event)

    for risk in affected:

        risk.exposure = recalculate_ale(risk, event)

        if risk.exposure > risk.threshold:

            notify_risk_owner(risk)

            escalate_to_leadership(risk)

    update_dashboard(currency=True)  # dollars, not colours

When compliance leads, you get a checkbox. A well-formatted, auditor-approved, framework-aligned checkbox. But a checkbox.

The GRC Graduation from Compliance Theatre to Risk-Driven Insights covers the full maturity journey if you want to go deeper.

What to Do This Week

If any of the five signs hit close to home, here's where to start:

1. Rewrite one risk scenario in business language. Pick your highest-rated risk. Rewrite it as a business outcome with a dollar estimate. See if the conversation changes.

2. Ask your risk owners if they know they're risk owners. If the answer is no, your programme is performative.

3. Check when the register was last updated. If it was before the last audit and not since, you know what's driving updates.

4. Replace one traffic light with a number. Even a rough annualised loss expectation forces a different conversation than red/amber/green. "This risk costs us approximately $1.2M per year" changes the room. "This risk is red" does not.

5. Ask yourself the ouroboros question. "Why does this program exist?" If the honest answer loops back to compliance, you've found the root cause.

Risk management that exists to satisfy compliance will always behave like compliance.

If you want it to behave like risk management, it needs to start from the business, not from the framework.

The ouroboros only breaks when you change the direction.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!