Building an ERM Program From Scratch Without It Becoming a Checkbox Exercise

Category: Enterprise Risk Management Author: Cody Swidler Tags: ERM, risk management, program design, risk taxonomy, operating model, GRC

When you're handed the mandate to build an enterprise risk management program from the ground up, the first instinct is usually to reach for a framework. COSO. ISO 31000. OCEG's GRC Capability Model. Pick one, map the requirements, start building.

The framework isn't wrong — but leading with it almost guarantees you'll build something that looks like a compliance program instead of a risk management program. And those are very different things.

A compliance program asks: are we meeting the requirements?

A risk management program asks: what could go wrong, how bad would it be, and what are we doing about it?

The distinction sounds obvious. In practice, most programs that call themselves ERM are really just compliance with more acronyms.

Start With the Risk Taxonomy, Not the Risk Register

The most common mistake I see in ERM builds is jumping straight to populating a risk register before establishing a shared vocabulary. If you ask ten different teams to submit their top risks without a taxonomy, you'll get ten completely different things — some operational, some strategic, some basically just project issues with "risk" in the title.

A risk taxonomy defines the categories your organization uses to classify risk. It creates a common language across functions and makes it possible to aggregate, compare, and report on risks in a way that's meaningful to leadership.

Building a taxonomy takes time, and it requires input from across the business — Legal, Finance, Engineering, HR, Compliance, Operations. But it's the foundation everything else sits on. Skip it, and your risk register becomes an unmanageable list of concerns with no coherent structure.

Design the Scoring Model Early

Before you collect a single risk, decide how you're going to measure them. That means defining:

- Likelihood — how probable is this risk materializing in a given timeframe? Build a scale that's specific enough to use consistently. "Medium" means different things to different people. "One or more occurrences expected in the next 12 months" is a definition people can apply. - Impact — across what dimensions? Financial loss is the obvious one, but for most organizations you also care about reputational impact, regulatory exposure, operational disruption, and customer impact. Define each one with dollar thresholds or other quantifiable anchors. - Expected loss — the product of likelihood and impact. This is where ERM starts to look like a real management tool rather than a survey. When you can show leadership a prioritized list of risks sorted by expected loss, you're having a different conversation than when you're showing them a heat map with everything in the yellow.

The model doesn't need to be complex. It needs to be consistent and defensible.

Governance Structure Before Tooling

One of the most reliable ways to fail at ERM is to buy a platform before you've established governance. I've seen organizations spend six figures on a GRC tool, spend a year implementing it, and end up with an expensive system nobody uses because the underlying ownership model was never resolved.

Before you pick a tool, answer these questions:

- Who owns enterprise risk? Is there a Chief Risk Officer, or does this live under the CFO, CISO, or COO? The reporting line matters. - What is the escalation model? At what threshold does a risk go from a business-unit concern to an executive concern to a board concern? - What is the review cadence? Risk registers that aren't reviewed regularly become outdated and irrelevant within two quarters. - Who is accountable for treatment? Identifying a risk and assigning it to a "working group" is not risk management. Named owners with defined timelines are risk management.

Get those answers first. The tool is just a mechanism to run the process you've already designed.

The Role of Qualitative Judgment

One thing I want to push back on: the idea that quantitative ERM replaces qualitative judgment. It doesn't — and programs that try to automate their way out of hard conversations about risk tend to produce risk reporting that leadership doesn't trust.

Numbers give you structure and comparability. They let you prioritize a list of thirty risks without having an argument every time. But the numbers are only as good as the assumptions behind them, and those assumptions require human judgment — about the business, about the environment, about what "impact" actually means for your organization in context.

The best ERM programs I've worked with treat the scoring model as a starting point for the conversation, not the conclusion of it. The risk committee looks at the numbers, challenges the assumptions, and makes informed decisions. That's what risk management actually looks like.

What "Done" Looks Like

ERM is never really done, but you know you've built something real when:

- Risk owners can describe their top risks and their treatment status without referring to a spreadsheet - Leadership meetings regularly include risk-informed discussion, not just status updates - When something goes wrong — an incident, a control failure, an audit finding — you can trace it back to a risk that was already on your radar, or it triggers a new one that gets managed - The board receives risk reporting that reflects the actual risk appetite discussion they've had, not a list of everything that could theoretically go wrong

That last one matters more than people realize. Board-level risk reporting that isn't tied to an explicit risk appetite statement is just noise. The point isn't to inform the board that risks exist. It's to show them which risks are inside or outside the tolerance the organization has explicitly agreed to accept.

Building that connection — from appetite to registry to reporting — is what separates an ERM program that drives decisions from one that produces documents.

Cody Swidler is the founder of PivotRisk. He built Miro's enterprise Risk Management Program from the ground up, establishing the risk taxonomy, expected-loss scoring model, and ORC governance structure for a global SaaS platform serving 70M+ users.