Building Your First Risk Register That People Actually Use

TL;DR

In Part 1, So, You Own Risk Now, Jess worked out that risk management does not start with a template. In Part 2, How to Assess What You’re Working With, she assessed what the organisation already had and where the real gaps were.

Now she has to build the thing everyone thinks risk management is: the risk register.

This is where a lot of organisations go wrong. They build a register that looks impressive but nobody trusts, updates, or uses. A good first register should be simple, honest, owned by the right people, and connected to real decisions.

Not fifty risks. Not twenty columns. Not a spreadsheet pretending to be a framework.

A working register.

The spreadsheet is open again

By now, Jess has done more work than most people realise.

She has spoken to the CEO, operations, HR, IT, program managers, and a couple of people who do not have fancy titles but know exactly where the organisation bends under pressure. She has looked at the old risk register, the policy folder, Board papers, incident reports, audit actions, and the handful of controls everyone assumes are working because nobody has checked them properly for a while.

She has also done the harder thing.

She has admitted the current system is not terrible, but it is not reliable either.

That is a useful place to be.

So now she is sitting at her desk with the spreadsheet open again. The old risk register is on one screen. Her maturity assessment notes are on another. There is a coffee going cold beside her, because she has just realised the next step is not quite as simple as “refresh the register”.

This is the moment where the register can go one of two ways.

It can become a useful management tool.

Or it can become another governance artefact that looks serious, gets attached to a Board pack twice, and slowly dies in a folder.

I have seen both.

A risk register is not a list of worries

The first mistake people make is thinking a risk register is just a list of bad things that might happen.

Cyber attack. Staff turnover. Funding cuts. Compliance breach. Data loss. Reputation damage. System outage.

All real. All plausible. All too vague to do much with.

That sort of list feels productive because it gets risk out of people’s heads and onto a page. But a list of worries is not a risk register. It is a starting point.

A proper risk register does three jobs:

• It helps the organisation see what could affect its objectives.
• It shows what is already being done about those risks.
• It creates enough ownership and discipline that people can make decisions before something turns into a crisis.

That is the difference.

Jess does not need a register that proves she knows the standard terminology. She needs a register the CEO can use in a management meeting, the Board can understand without translation, and risk owners can update without needing a half-day training session.

That is the test.

If the register only makes sense to the person who built it, it is already failing.

Start with fewer risks than feels comfortable

Jess’ first instinct is to move everything across from the old register and tidy it up. I mean, that’s a good starting point right?

It would be a mistake.

The old register has 43 ‘risks’ in it. Some are risks. Some are issues. Some are overdue tasks. Some are control weaknesses dressed up as risks. One says “Governance” which is not a risk. One says “People” which is not a risk either. A few have not been reviewed in eighteen months.

So Jess does something better.

She starts again, but not from scratch.

She takes what she learned from the maturity assessment in Part 2 and works backwards from the organisation’s objectives. What could stop this organisation from delivering services, meeting funding obligations, keeping people safe, protecting its reputation, and staying financially viable over the next 12 to 24 months?

That question cuts through a lot of noise.

The first version does not need 43 risks. It probably needs 10 to 15.

That number makes some people uncomfortable. They worry something will be missed. But the point of a first register is not to prove you thought of every possible scenario. It is to focus the organisation on the risks that genuinely matter now.

You can always add more later. In fact, you will.

But if the first version is too big, nobody will use it. They will nod politely, say it looks comprehensive, and then go back to managing risk in emails, meetings, and memory.

Write risks like a human being

This is where Jess slows down.

Because the way a risk is written changes the conversation that follows.

A bad risk statement is usually too short, too broad, or too abstract. “Cybersecurity” is not a risk. It is a category. “Compliance failure” is not enough either. Failure of what? Caused by what? With what consequence?

The better structure is simple:

There is a risk that [event] caused by [cause] results in [impact].

You do not need to be religious about the wording, but you do need the thinking.

So instead of writing:

Cyber attack

Jess writes:

There is a risk that a cyber incident caused by weak access controls and limited staff awareness results in service disruption, data loss, and reputational damage.

That is better because people can act on it.

The IT manager can talk about access controls. HR can talk about staff training. The CEO can understand the service and reputation impact. The Board can see why it matters.

Same with funding.

Not:

Funding cuts

Better:

There is a risk that the organisation loses a major funding stream due to contract non-renewal or changing funder priorities, resulting in reduced service capacity and financial pressure.

Now the conversation has shape.

Which funding stream? How concentrated are we? What early warning signs would we see? What relationships matter? What reserves do we have? What services would be affected first?

That is what good risk language does. It turns anxiety into a useful conversation.

If you’d like more guidance refer to our blog post on writing clear risk statements.

Do not add twenty columns because the template had them

The next temptation is structure.

Jess has found three templates. One has 12 columns. One has 19. One has so many fields that the spreadsheet feels like it was designed by someone who has not had to convince a busy operations manager to update anything since 2009.

Risk ID. Category. Cause. Consequence. Inherent likelihood. Inherent consequence. Inherent rating. Existing controls. Control effectiveness. Residual likelihood. Residual consequence. Residual rating. Risk appetite. Treatment plan. Action owner. Due date. Review date. Assurance activity. Status. Comments.

There is nothing wrong with those fields in the right environment.

But this is a 40-person NFP at the start of its risk maturity journey. Jess is not building a bank-grade operational risk system. She is building a first working register.

So she keeps it tight.

For the first version, she needs:

Risk title. Risk statement. Owner. Category. Existing controls. Current rating. Further actions. Action owner. Due date. Review date.

That is enough.

Not perfect. Enough.

The important thing is that every field earns its place. If nobody understands it, uses it, or makes a decision from it, it probably does not belong in the first version.

This is one of the most practical disciplines in early risk management: make the system light enough that people will actually touch it.

Because the register is not useful because it exists.

It is useful because people use it.

Ownership is where the register becomes real

Jess then hits the uncomfortable part.

Risk ownership.

Everyone likes the idea of a register until names start appearing next to risks. Then the mood changes.

The CEO owns strategic funding risk. The Operations Manager owns service delivery continuity. The IT lead owns cyber resilience, although Jess makes a note that the CEO still has accountability for organisational exposure. HR owns workforce capability and key-person dependency. Finance owns liquidity and financial controls.

This is where people start negotiating.

“Shouldn’t that sit with the executive team?”

“Isn’t that more of a shared risk?”

“I’m not sure we can say I own that.”

That’s normal.

But if everyone owns a risk, nobody owns it.

Risk ownership does not mean the owner does all the work. It means they are responsible for knowing the risk, understanding the controls, monitoring movement, and making sure the right conversations happen when the exposure changes.

That distinction matters.

Jess explains it in plain English: “You are not personally responsible for stopping every bad thing from happening. You are responsible for making sure we are not asleep at the wheel.”

That lands better.

Controls are not hopes

The old register has a column called “Controls”. Some of the entries are useful. Some are not.

“Staff are experienced.”

“Managers monitor this.”

“Policy in place.”

“Regular communication.”

These may be true, but they are not always controls. Sometimes they are assumptions. Sometimes they are hopes. Sometimes they are just words people put in a spreadsheet because the cell could not be left blank.

Jess needs to be more disciplined.

A control is something the organisation actually does to reduce the likelihood or consequence of a risk. It should be observable. It should be owned. Ideally, you should be able to tell whether it is working.

For the cyber risk, controls might include multi-factor authentication, regular access reviews, phishing awareness training, backups, patching, and an incident response plan.

For funding concentration, controls might include active funder relationship management, pipeline reporting, reserves monitoring, diversification planning, and Board review of major contract dependencies.

For key-person dependency, controls might include documented procedures, cross-training, delegated authority limits, succession planning, and shared access to critical systems.

The wording does not need to be fancy. It needs to be real.

Jess starts asking a simple question against each control:

If this control disappeared tomorrow, would the risk get worse?

If the answer is no, it probably is not a control.

Ratings should create prioritisation, not arguments

Eventually Jess has to rate the risks.

This is where workshops can go sideways.

One person thinks the risk is high because they experienced it at a prior workplace. Another thinks it is medium because “we’ve always managed it”. Someone else wants to lower the rating because the Board might overreact. Then everyone spends twenty minutes debating whether something is “possible” or “likely” as though the future will reward the most precise adjective.

Jess needs the ratings to be useful, not perfect.

So she keeps the scale simple and makes the discussion practical.

How likely is this to happen? Could it happen in the next 12 to 24 months, given what we know? If it did happen, how bad would the consequence be for service delivery, finances, compliance, people, or reputation? Are the current controls strong enough to reduce that exposure?

That last question matters most.

A lot of registers are optimistic because people rate the world they hope they have, not the control environment they actually have.

Jess has already done the maturity assessment, so she has evidence. She knows where documentation is patchy. She knows where escalation relies on judgement. She knows where one person carries too much organisational memory. She knows where the Board wants better visibility.

That evidence keeps the rating conversation honest.

Not comfortable.

Honest.

The first review is where trust is built

After a week of drafting, testing, and annoying people with follow-up questions, Jess has a first version.

Twelve risks.

Clear statements. Named owners. Existing controls. Current ratings. A short list of practical actions. Review dates that do not assume everyone has suddenly become a full-time risk team.

She sends it to the executive team before the meeting with a short note:

“This is a first working draft. The goal is not perfection. The goal is to check whether this reflects our real exposure and whether the actions are sensible.”

That framing helps.

The meeting is still a bit messy. It should be.

The Operations Manager says two risks overlap. They do. The CEO says one risk is too soft and should be rated higher. She is probably right. HR points out that a workforce risk is really two different risks: retention and capability. Finance pushes back on an action because the due date is unrealistic. Good. Better to find that out now than pretend.

By the end of the meeting, the register is better.

Because people have started to recognise themselves in it.

That is the point at which a register starts becoming useful. Not when it is formatted. Not when the colours are right. When the people who own the risks can see their reality in the document and are prepared to update it because it helps them manage.

The Board does not need every detail yet

Jess is tempted to put the whole register in the next Board pack.

I would not.

At least not as the main event.

Boards need visibility, not a data dump. They need to understand the top risks, what has changed, where exposure sits outside comfort, what management is doing, and what decisions or support are needed.

So Jess prepares a short Board-facing summary.

The full register can sit behind it if needed. But the paper itself focuses on the top five risks, material changes, actions underway, and possibly a couple of points where management wants Board input.

That is a very different conversation from asking directors to review a spreadsheet line by line.

The Board’s job is not to become the risk team. The Board’s job is to govern.

Jess’ job is to give them something they can govern from.

What good enough looks like at this stage

By the end of this step, Jess does not have a perfect risk register.

What she has is a working register that reflects the organisation’s actual context. It has enough structure to create consistency, but not so much that people avoid it. It has named owners. It has real controls, not vague assurances. It has ratings that support prioritisation. It has actions that someone can actually complete. And it has a review rhythm that fits the organisation’s maturity.

That is what good looks like at this stage.

Not enterprise-grade. But usable.

And this is where the register starts doing something more useful than documentation. It starts creating a shared language.

The CEO can talk to the Board about risk without reinventing the story each quarter. Managers can see which exposures matter most. Jess can track whether actions are moving. The Board can ask better questions.

That is the shift.

Risk management stops being a spreadsheet and starts becoming a management habit.

Where StartRisk fits

This is exactly the kind of work we help organisations with at StartRisk.

Sometimes that means sitting with the executive team and turning a messy set of concerns into a clean first register. Sometimes it means helping the Board understand what it should be seeing and what belongs with management. Sometimes it means using the StartRisk platform to quickly generate a strong first draft, standardise the language, keep owners accountable, and stop simplify reporting to keep peoples attention on the risks that matter.

The technology helps a lot here. But the real value is still in the thinking.

What are the risks that matter? Who owns them? What controls are real? What needs attention first? What does the Board actually need to see?

If your organisation is trying to build its first usable risk register, reach out.
A conversation is usually the best place to start.

Book now

Next week, we get to the question that makes the register much more useful and much more uncomfortable: how much risk are we actually prepared to accept?