How to Plan a GRC Implementation

The contract is signed and the kick-off call is in the diary. The vendor's implementation lead shares a slide with the phases on it, then asks a simple question: who on your side owns the risk register? There is a pause. Compliance assumes risk owns it. Risk assumes each business head owns their own tab. Internal audit has a copy from last year that nobody has reconciled.

Then your chief operating officer asks the question you hoped to avoid on day one. When will this be live, and who is doing the work? You give a date because you have to. Most heads of risk do.

That moment is where a GRC implementation is won or lost. Not in the software, but in whether you can name why you are doing it, name the phases, put a person against each one and say what has to be true before any data moves.

A GRC implementation is the work of moving your risks, controls, policies and evidence out of whatever holds them today and into a risk and compliance platform that people use day to day. This article covers:

• why you are doing it, and how to keep that pain point in view as the project grows
• the five phases and who should own each one
• how to set a go-live test before any data moves
• what drives the timings, and what stretches them
• phased roll-out against a single go-live
• a worked example, and the pitfall that costs most firms the most time

Why are you doing this?

Before you name a phase or agree a date, write down why the firm is doing this at all.

The reasons are rarely one thing. Manual processes that eat the week before committee: chasing owners, copying between tabs, reconciling versions. Reporting that is rebuilt from the register rather than produced by it, which is where the numbers drift. A regulatory requirement the current files cannot evidence cleanly, whether that is SM&CR, Consumer Duty, DORA or Provision 29. Often all of those, plus a board that has asked for one view of risk.

That list will grow. Someone will want policies in the first release. Someone else will want incidents, or regulatory mapping, because the vendor's slide shows them. Each request is reasonable on its own. The project drifts when nobody can say which of them was the original problem.

You will come back to that sentence more than once. Cleaning takes longer than anyone expects. A team asks to wait until after year-end. A new regulatory piece lands and wants the same people. The sentence is what lets you steer. It is also what you use when someone asks, six months in, whether the project is still the one they signed off.

Be honest about where the pain actually sits:

• Manual processes. If the week before committee is mostly administration, that is the pain. The platform has to take the chasing and the copying away, or it has not done its job.
• Reporting. If the pack is a rebuild, the test of go-live is that the same pack comes out of the new register and says the same thing.
• Regulatory requirements. The obligation is real. It is a reason to be clear about evidence and ownership, not a reason to load every module on day one.

There may be several. Pick the one that hurts most and let the others wait their phase. Scope, which comes next, is much easier to hold if that choice is already made.

What are the phases, and who should own each one?

Each phase needs one named owner. Not a committee, not "the project team". One person who can be asked on a Monday morning whether it is done.

1. Scope. Decide which registers, entities and obligations are in, and which are out for now. Hold the line against anything that does not serve the pain point you named. Owner: you, as head of risk, with an executive sponsor who can settle arguments.
2. Clean. Remove duplicates, rewrite vague risk descriptions, give every risk and control a named owner and link controls to the risks they mitigate. Owner: each register owner in the first line, working to a standard the second line sets.
3. Load. Map your existing fields to the new structure, load the cleaned data and reconcile the counts. Owner: a named data lead in the second line.
4. Parallel run. Operate the old process and the new platform side by side for at least one full reporting cycle and compare the outputs. Owner: you, with internal audit invited to observe.
5. Roll out. Move each team across, train them on their own risks and controls, and switch off the old spreadsheet for that team. Owner: each business head for their team, supported by the second line.

If your firm is under SM&CR, the owners in your register should line up with your statements of responsibilities. The cleaning phase is the cheapest point to fix any mismatch.

How do you set a go-live test before any data moves?

Write the acceptance criteria before the load, not after. Once data is in a new system, there is a strong pull to call it done. A test agreed in advance takes that pressure off you. Tie at least one criterion back to the pain point, so go-live proves the original problem is smaller, not only that the data moved.

A practical go-live test usually includes:

• every risk and control in scope has a named owner who has logged in and confirmed it
• the number of risks, controls and open actions matches the old register, with any differences explained
• the next committee pack can be produced from the new platform and says the same thing as the old one
• first-line owners have completed at least one round of control attestations in the new platform
• the audit trail shows who changed what, and when, during the parallel run

Get your executive sponsor to sign the test off. When someone later asks why go-live moved, you can point to the criterion that was not met.

How long should each phase take, and what stretches it?

The honest answer is that the software is rarely the slow part. Cleaning is.

Scoping is typically a handful of working sessions if your sponsor is engaged. Loading is short when the data is clean and painful when it is not. The parallel run is set by your reporting calendar: if your risk committee meets quarterly, you need a quarter of side-by-side running to see one full cycle. Roll-out depends on how many teams you have and how often their heads are available.

What stretches timelines in practice:

• Underestimating the clean-up. Registers that have grown in spreadsheets over years carry duplicates, orphaned controls and owners who have left.
• Unavailable owners. First-line staff fit this around their day jobs. If nobody protects their time, cleaning drifts.
• Scope creep. Someone asks to add policies, incidents and regulatory mapping mid-way. Each is worthwhile. Adding them all at once usually delays all of them. This is where the pain point earns its keep: if the request does not reduce it, it waits.
• The committee calendar. Miss a reporting cycle and the parallel run waits for the next one.
• Competing regulatory work. Consumer Duty reviews, or DORA work if your group has EU entities in scope, often call on the same people.

For a phase-by-phase timeline you can adapt, see the migration plan in our toolkit.

Phased roll-out or single go-live: which is better?

For most mid-sized firms, a phased roll-out carries less risk. A single go-live can work when the scope is small and the data is already clean. Phasing also keeps the first release aimed at the pain point, with everything else queued behind a register that is already live.

The cost of phasing is that you run two processes for longer. That is manageable if you are clear, team by team, which one is the record.

Worked example: one risk register through a parallel run

Take a payments firm with 40 staff. Its operational risk register lives in a spreadsheet with one tab per team, and its controls sit in a separate workbook. Before anyone talks about modules, the head of risk writes the reason down: the committee pack takes the best part of a week, and nobody can name a single owner for the register. That is the pain. Policies can wait.

Scope. The head of risk writes a one-page scope. The pain point is at the top. Below it, what is in: operational risks and their controls for the UK entity only. Incidents stay where they are for now. The chief operating officer signs it off as sponsor.

Clean. Each team lead works through their tab against a short standard from the second line: one risk per line, a description that says what could go wrong and why, one named owner, and every control linked to at least one risk. Several risks turn out to appear twice under different names. A few controls link to nothing at all. One owner left the firm months ago. All of this is fixed in the spreadsheet, before anything is loaded.

Load. The second-line data lead maps the spreadsheet columns to the platform's fields, loads the data and checks that the counts match.

Parallel run. For one quarter, the team updates both the spreadsheet and the platform. Control owners complete their attestations in the platform. At quarter end, the head of risk produces the committee pack from both and compares them line by line. The differences are small and traceable, mostly late updates made in one place but not the other. The pack that used to take a week comes out of the new register.

Decision. Every item in the go-live test is met, including the one tied to the original pain. The sponsor signs off, the spreadsheet is archived as read-only and the next team starts its clean-up.

Common pitfall: loading the registers before anyone has cleaned them

This is the most common mistake, and the most expensive. The reasoning sounds sensible: get the data in, then tidy it up in the new tool. In practice, the tidying rarely happens. Users meet duplicated risks, controls with no owner and descriptions nobody understands, and they conclude the new platform is no better than the spreadsheet.

It also breaks your parallel run. If the old register was messy, a faithful copy of it will match perfectly and prove nothing. The comparison only tells you something when the data going in is data you trust.

Set a simple rule: nothing loads until its first-line owner has confirmed it is clean against the agreed standard.

What should you tell your executive committee?

Keep it to one page. Open with the pain point in one sentence, then the five phases, the owner for each and the go-live test. Give a target date tied to a named committee meeting rather than a calendar date, because the parallel run depends on that cycle.

Be explicit about what you need from them: protected time for first-line owners during cleaning, and a sponsor who can make scope decisions quickly. Those two things often matter more to the timeline than anything the vendor does. Ask the sponsor to use the pain point when new scope arrives. If a request does not reduce that pain, it waits.

How Initia Risk handles this

We build Initia Risk around a single register that replaces the spreadsheets your risks and controls live in today. That gives your cleaning phase a clear target: the structure you clean towards is the structure your teams will work in.

Ownership is built in. Risks and controls sit with named first-line owners, and the second line has oversight of everything, so the owner you assign during cleaning is the owner who receives attestation requests after go-live. Control testing and attestation, with evidence attached, give you the material for the parallel run, and the audit trail records who changed what during it.

Board and committee reporting comes from the same register, which is what lets you compare your old committee pack with the new one during the parallel run. Once the first register is live, you can add policy management, risk events and incidents, key risk indicators with appetite monitoring, and regulatory mapping as later phases, rather than loading everything at once. That is how the pain point stays in charge of the sequence: the first release fixes it, and the rest follows a register people are already using.

Key takeaways

• Start by naming the core pain point. Manual work, reporting and regulatory requirements may all apply. Steer by the one that hurts most, especially as the project grows.
• Plan in five phases: scope, clean, load, parallel run, roll out.
• Give each phase one named owner, not a group.
• Write the go-live test before any data moves, and have your sponsor sign it off.
• Cleaning usually takes longest. Protect first-line time for it.
• Run in parallel for at least one full reporting cycle, and treat that run as your acceptance test.
• For most mid-sized firms, a phased roll-out carries less risk than a single go-live.
• Tie your go-live date to a committee meeting, not a calendar date.