Enterprise Risk Management

Your Risk Process Does Not Need Software Yet

Enterprise risk management software earns its place when it removes operating friction from a process that already works. Here is how to choose among a spreadsheet, focused workflow tool, and full GRC platform.

By Eric Kennedy · Tue Sep 08 2026 · 11 min read

Most mid-market companies shopping for enterprise risk management software are one step early. If your process cannot yet produce a short list of material risks, one accountable owner for each, a recorded response, a threshold that forces escalation, and a decision at a known point in the calendar, software will not create those things. It will document their absence more neatly, on an annual invoice.

Software earns its place when the process already works and the administrative work of running it starts to choke it. That is a narrower test than most buying committees apply, and it is the one that predicts whether the tool gets used in year two.

TL;DR: Technology removes operating friction. It cannot settle disputed ownership, define risk appetite, choose escalation thresholds, or decide what deserves executive attention. Choose the smallest system the work requires: a spreadsheet for one coordinator and one reporting cycle, a focused workflow tool for multiple owners and recurring executive reporting, a full GRC platform for multiple entities and integrated controls. Evaluate software only when cadence, named ownership, defined escalation, and measurable friction are all true.

What ERM software can fix, and what it cannot

Illustrative example: software can route a quarterly update request to fourteen risk owners, remind the three who ignored it, hold one authoritative version of each record, restrict who sees the litigation entry, aggregate scores into a portfolio view, keep an audit trail of who changed what and when, and generate the same board exhibit each quarter without anyone rebuilding it by hand.

Software is bad at judgment. It cannot decide whether the supply concentration risk belongs to the COO or the Chief Procurement Officer. It cannot tell you the loss the board is willing to accept, or the point at which a deteriorating indicator stops being management's problem and becomes the audit committee's. In an illustrative register, it cannot decide that eleven of twenty-six entries are operational noise that does not belong in front of the board.

The two failure types look identical from the outside. Both produce a stale register and a thin board packet. One is administrative, and technology helps. The other is an operating-model problem, and technology makes it worse by adding a system of record to a disagreement no one has resolved.

Illustrative example. Administrative friction: your risk coordinator spends two days a quarter emailing owners, merging four returned spreadsheet versions, resolving conflicting edits, and rekeying the result into slides. Operating-model failure: two of those owners do not believe the risk is theirs, and nobody with authority has said otherwise. The first is a workflow purchase. The second is a decision the CEO or CFO has to make, and no license fixes it.

The three system choices

Nearly every mid-market program lands in one of three places. The right answer is the smallest system the work requires.

A spreadsheet is a legitimate system of record for a single coordinator running one cycle for one business unit. It is fast to change, which matters more in year one than anyone expects. It breaks when owners stop updating it, because a spreadsheet has no way to ask them.

A focused workflow tool is the right answer when several executives own risks, updates recur on a cycle, and someone has to produce executive or board reporting from the result. Its strength is accountability without a heavy rollout. It breaks when the requirement spreads into internal audit, compliance obligations, control testing, and incident management, because a focused tool is not trying to be all of those.

A full GRC platform is the right answer for multiple legal entities, regulated workflows, and controls integrated with risk. Its strength is one governed system with consistent taxonomy. It breaks when the operating model is not settled, because implementation forces you to encode decisions about ownership, taxonomy, scoring, and escalation that you have not yet made. Configuration then becomes a proxy war for governance, and it is an expensive way to hold that argument.

Comparison in detail

Use the table as a reference when the choice is close or different stakeholders are arguing for different levels of tooling.

Software should remove operating friction. It cannot define the operating model.

Four gates before buying

Run these four gates before you take a demo. They are not maturity theater. They are the conditions under which a tool has something to automate.

1. Cadence exists. Leaders know when risk updates and decisions happen. There is a date, it repeats, and people plan around it.
2. Ownership is named. Every material risk has one accountable executive. Not a department, not two co-owners, not "Finance."
3. Escalation is defined. Thresholds say what moves upward and when, so escalation is a rule rather than a judgment call made under pressure.
4. Friction is measurable. Chasing updates, reconciling versions, or rebuilding reports is consuming a quantity of time you can state out loud.

Four yes answers means evaluate software. Any no answer means fix the operating model first. Technology scales discipline. It does not create it.

The gates also protect the budget conversation. A CFO can defend a purchase that removes a quantified amount of finance and audit time each year. It is harder to defend a platform bought in the hope that it produces a cadence nobody has agreed to run. If you are still deciding what belongs in the register at all, the register is not the program is the better place to start.

Buying signals that are evidence, not annoyance

There is a real difference between a symptom software fixes and a symptom software hides. Five signals that are evidence, each paired with the adjacent problem a license will not touch.

Parallel versions cause reconciliation. Owners return edited copies and someone merges them by hand, with the risk that the merge itself introduces errors. Software fixes this with one record and controlled edits. It does not fix a register where two owners disagree about the same risk's rating and no one arbitrates.

Risk owners miss updates because there is no workflow. Requests live in email and depend on the coordinator's persistence. Software fixes this with assignment, due dates, and reminders. It does not fix an executive who has been told by their own manager that this is optional.

Board reporting requires repeated manual re-entry. The same numbers are retyped from register to deck every quarter, and the deck version quietly becomes the real one. Software fixes this with generated reporting from the source record. It does not fix a report that shows twenty-six risks because nobody will decide which eight matter. Getting that right is a board-ready reporting problem, not a rendering problem.

Access controls are inadequate for sensitive records. Litigation exposure, key-person risk, or an unannounced restructuring sits in a shared file with the wrong audience. Software fixes this with permissions and field-level restriction. It does not fix the decision about who is allowed to know.

There is no reliable history of changes or decisions. You cannot show when a rating moved, who moved it, or what response was approved in response to what. Software fixes this with an audit trail. It does not fix a program where decisions are never recorded because none are actually made.

The data structure behind all five is not exotic. NIST IR 8286B Update 1, published February 2025, treats priorities, response information, and projected response costs as fields recorded in risk registers so that an enterprise view can be formed and strategy adjusted accordingly. NIST IR 8286C describes how register information is integrated into an enterprise risk register and an enterprise risk profile in support of objectives. Read them for the data architecture, and note the limitation honestly: the 8286 series is cybersecurity-focused and written for a broad audience that includes federal contexts. It is a useful model for how risk data aggregates. It is not an ERM software procurement standard, and it does not tell you what to buy.

COSO's ERM guidance and its 2017 update connect enterprise risk management to strategy and performance, and respond in part to demand for improved risk reporting. COSO does not prescribe software. It describes what the reporting has to accomplish, which is the specification your system should satisfy.

How to evaluate vendors without buying the demo

Vendor demonstrations run on clean sample data, which is exactly the condition your program is not in. Change the input. Give each vendor one sanitized real risk record from your own register, and ask them to run the full lifecycle in front of you: intake, owner challenge, scoring or quantification, response, threshold breach, escalation, executive report, permissions, change history, and export. Watch the friction, not the interface. Which steps required an administrator, a services engagement, or a workaround.

A practical acceptance test list, run against your record:

• Reassign the risk to a different executive owner and confirm the history preserves the prior owner.
• Trigger a threshold breach and show the escalation path it produces without manual intervention.
• Restrict one sensitive field to two named people and prove a third cannot see it.
• Generate the quarterly executive exhibit with no manual editing after export.
• Show every change to the record over a period, with user, timestamp, and prior value.
• Export the complete register, including history and attachments, in a format you can read without the vendor.

Then price the whole thing, not the license line. The cost categories are licenses, implementation, configuration, integrations, training, ongoing administration, support, and exit or data migration. Ask who does the configuration work in year two when your taxonomy changes, and whether it is billable. On portability, ask one question and get the answer in writing: if we terminate, what can we take with us, in what format, and at what cost.

Where Risk Command Center fits

For transparency, we build software in this category. Risk Command Center is designed for the middle option: a focused workflow for risk ownership, exposure, mitigation tracking, and executive reporting for mid-market programs that have outgrown a shared spreadsheet. It is not an integrated GRC suite and does not pretend to be one. If your requirement genuinely spans multiple entities, regulated workflows, and integrated control testing, a full platform is the honest recommendation, and we will say so.

The honest counterpoint

A well-controlled spreadsheet can be the right system for a small, disciplined program, and plenty of credible programs run that way for years. Version control, a named coordinator, locked scoring logic, and a real cadence beat an underused platform every time.

The reverse is worth saying plainly. Software can make a weak process more consistent and more expensive at the same time. You get tidier evidence of the same unresolved ownership, produced on schedule. The case to buy is operating friction plus a stable operating model. It is not embarrassment about spreadsheets, and it is not a board member who mentioned a vendor name.

If you are unsure which side of the line you are on, look at your indicators before your tooling. Programs with working risk indicators usually have the cadence and ownership that make software worth buying. Programs without them usually do not.

Where to start

Decide the operating model first, then buy the smallest system that supports it. Write down your cadence, name one owner per material risk, set the thresholds that force escalation, and quantify the administrative time you spend today. If all four hold, run the vendor evaluation above with your own record. If any one does not, spend the next quarter fixing that instead, and you will buy better software later for less money.

The ERM Program Diagnostic is built for exactly that sequencing question: what your process needs to do before a system locks it in.

Review the ERM Program Diagnostic