Building Sustainable GRC Platforms Requires More Than Configuration
Updated: Sep 26
The first in a series on what determines whether a GRC platform is still trusted two years after go-live, and why none of them appear on a delivery plan.
In our experience, most GRC platform implementations are reported as successful. The closure pack records the milestones met, notes some variance on time or budget, thanks the delivery partner and moves on. That account is rarely dishonest. It is just describing the part of the work that was visible from where the reporting was done.
The version further down looks different. The configuration was harder than expected, and some of it was resolved by decisions nobody quite recorded. The implementation partner built the platform and then left, and the internal people who were meant to take it on were either never clearly identified or were only ever partly available. The administrators and business support staff who will run it day to day saw the design late, if at all, and are learning its implications after the fact rather than shaping them. The change and training effort was scoped as a workstream and funded as whatever remained. And a few months in, users who cannot make the platform do what they need have started doing it their own way, producing data nobody fully trusts.
We have watched this pattern repeat across enough regulated financial-services implementations that it no longer surprises us. What is striking is how little of it shows up as a problem at the time. Almost none of it is logged as an issue, because none of it is a failure of delivery in the sense a delivery plan measures. These are decisions that were made, or not made, in places the status report was never looking.
That matters more in this domain than in most. Risk and compliance already carries a reputation in many organisations as an overhead that slows the business down. A platform that earns a poor name on top of that starting position is very difficult to recover, because the people who might have championed it were never especially enthusiastic to begin with.
For most regulated financial-services organisations, a GRC platform becomes part of the risk and compliance operating model rather than a system sitting alongside it. It shapes how risks are assessed, how controls are documented, how obligations are managed, how incidents are escalated, how issues are resolved, how assurance is evidenced and how senior management receives information. That is why the success of the platform depends on more than whether it can be configured. The size of that effort scales with the programme: a single-jurisdiction compliance rollout and a multi-entity enterprise GRC platform demand very different levels of work. But the six conditions below don't disappear for smaller implementations; they just show up at a smaller scale.
Key Takeaways
Sustainable GRC platforms depend on design, governance and ownership decisions, not on configuration alone.
Long-term success rests on six conditions: a clear risk and control operating model, a selection process led by someone who can map business need to platform capability, requirements tested against intent and policy, conscious configuration trade-offs, adequately resourced change and training, and a business-as-usual (BAU) capability that is funded, governed and staffed with people who understand the platform.
Skipping any one of these doesn't remove the work. It moves the cost downstream: into rework, inconsistent data, or a platform the business works around. That single idea is the thread running through everything below.
Conditions five and six are summarised here and treated in full later in the series.
Condition 1: Start with the Risk and Control Operating Model, Not the Platform
One of the reasons GRC projects become difficult is that the platform forces questions the organisation may not have fully resolved, before configuration even begins. It shows up in a familiar pattern: three business units each maintaining their own version of a control library, none quite compatible with the others, until the platform is asked to report across all three as if they were one.
For many regulated organisations this now also includes operational resilience obligations, such as CPS 230 in Australia (APRA's operational risk management standard) or DORA in the EU, which require critical operations to be visible in day-to-day risk and compliance processes rather than managed as a separate exercise.
A capable platform can support many different answers to these questions. The challenge is deciding which answers are right for the organisation. If the underlying operating model is unclear, the implementation team can still configure screens, workflows and reports; the result will simply embed the inconsistency in a more structured form. Take the three-business-units example: without a resolved taxonomy decision, the platform doesn't remove the inconsistency between the three control libraries. It gives each business unit a more convincing-looking place to keep disagreeing with the other two.
The cost of leaving that question open does not stay constant. It rises with each phase, because each phase builds more on top of the unresolved answer.
These figures reflect the pattern we consistently see across regulated implementations, not a formal cost model. They are indicative and specific to the risk-and-controls workstream, not a share of total programme cost. The pattern matters more than the multipliers: the cost of resolving a taxonomy question rises the longer it is left, and the rise is steepest after go-live, once data has already been loaded against the wrong answer.
This is why GRC implementation is often less a platform exercise than a test of whether the organisation's taxonomies, ownership model and governance expectations are clear enough to be translated into a sustainable solution. The next condition follows directly from this one: even a well-resolved operating model only helps if the platform selected can actually support it.
Foundation area | Question to resolve | Typical symptom if unresolved |
Risk taxonomy | Is it complete, current, and clearly owned? | Business units maintain their own informal variants, and platform reporting can't roll them up consistently. |
Control taxonomy | Does the same ownership and governance discipline exist as for the risk taxonomy? | Controls get documented inconsistently across business areas, and control effectiveness can't be compared or aggregated. |
Obligations & policy links | Are obligations clearly linked to policies, controls, and business owners? | Obligation applicability becomes a manual, spreadsheet-driven exercise each reporting cycle. |
Process & subprocess mapping | Is there a shared view of how processes connect to risks, controls, obligations, and issues? | Assessments and issues get raised against the wrong process, and root cause analysis becomes guesswork. |
Resilience & related domains | Are BCM (business continuity management), TPRM (third-party risk management), audit, model risk, or AI governance integrated with the core GRC data model, or given a defined interaction point? | Critical operations, third-party risk, or AI risk sit in disconnected spreadsheets that never reconcile with the core risk view. |
Condition 2: Test the Demo Against Your Operating Model, Not the Vendor's
Everything that follows assumes the organisation is working with a platform capable of supporting what it needs. That assumption is worth examining, because a great deal of downstream difficulty originates in a selection process that was never equipped to test it.
Many people will run a platform selection process, but not everyone doing the assessment has the necessary combination of skills: deep working knowledge of GRC technology, a clear understanding of what the business actually needs, and the ability to map one onto the other while sitting in front of a vendor presentation. That combination is rarely available inside an organisation, least of all one implementing a GRC platform for the first time. Where the selection runs without it, led by procurement against a requirements matrix, by a steering group weighing vendor references, or by whoever was available, the criteria tend to be drafted at a level of generality that every serious vendor can satisfy. Once the matrix is ticked by everyone, the conversation moves quickly to the two things still visibly differentiated: price and implementation speed.
That is where out-of-the-box enters the discussion. Most vendors, including IBM OpenPages and ServiceNow IRM, will offer some version of “if you stay out-of-the-box, this can be live in two to three months,” and presales teams are good at their job: the demonstration is built to show the platform meeting the requirement as stated, using the vendor's data and a configured process to match it. In our experience, that assumption rarely survives contact with an actual implementation. Most regulated organisations carry approved policies, established processes and their own variations on methodology that a generic baseline doesn't cover, and the distinction that matters most, what is genuinely out-of-the-box, what requires additional configuration, and what is customisation, is the hardest thing to judge from a demonstration alone. A later article in this series looks at why out-of-the-box should be treated as a starting point to test, not a delivery strategy in itself.
Second-time buyers are not automatically better placed. Their framing is usually shaped by the pain points of the system being replaced, and left unchecked, this produces a selection aimed at fixing the last implementation rather than at the uplift this one could deliver: people try to replicate the old system's workflow almost step for step, in areas like incident management, issue management, or risk assessment, carrying its inefficiencies across rather than asking what the new platform's capabilities now make possible. This is exactly where it's worth pausing to question the assumption and propose a better way: address the underlying intent within real business constraints and using what the new system can actually do, rather than simply recreating how the process was done before.
The consequences show up later and are rarely traced back. Requirements that seemed straightforward turn out to need customisation. Reporting that was assumed to be standard needs building. The delivery estimate moves, and the variance is attributed to scope rather than to a selection that was never tested against the operating model.
By defining the operating model before going to market the selection improves immediately: there is a clear picture of what is actually required from a platform, and a defensible split between the non-negotiables and the nice-to-haves. An organisation that has not resolved its taxonomy and ownership questions cannot describe what it is selecting for, and will default to criteria every vendor can meet.
What the selection lead has to be able to do | What typically happens instead |
Read a vendor demonstration against the organisation's own operating model | The demonstration is judged on whether it looked capable, using the provided data and a configured process to match the customer ask. Whether that would actually be how it is implemented stays open. |
Distinguish native capability from configuration, and configuration from customisation | All three are recorded as “supported” in the requirements matrix, and the distinction surfaces during build |
Test roadmap claims: what is committed, to which release, and when | Roadmap items are treated as available because the demo already shows it. |
Set criteria specific enough to separate one vendor from another | Criteria are general enough that every vendor ticks the box, and the decision defaults to price and quoted implementation speed |
If the Platform Is Already Selected: What Can Still Be Corrected Most readers will be past this point, which does not make the condition irrelevant. It changes what to do about it: re-baseline scope against native capability before build, design an interim approach with a defined switchover point for anything depending on a roadmap item, and reset the delivery narrative with the steering committee early, while there is still contingency in the schedule to act on it. Some things will already be fixed, a capability that doesn't exist, a release date that isn't yours to move, a commercial arrangement already signed, and raising that early is still considerably cheaper than raising it late. |
Condition 3: Test Every Request Against Intent and Policy, Not Just What Was Asked
A well-selected platform still needs the right things asked of it. Many GRC projects start by asking stakeholders what they want from the system. That is necessary, but not sufficient. There are two separate tests to apply before a request becomes configuration, and most programmes apply neither consistently.
The Intent Test: What Is This Actually Solving?
The more important question is what the requirement is intended to achieve, not just what has been asked for. Deliver the requested field, workflow or report without understanding that, and it is possible to hit the brief and still miss the actual business need.
Requirements describe symptoms. Intent identifies the design problem.
A new GRC platform is also a chance to improve the underlying process: to clarify ownership, simplify workflows, improve data quality, strengthen control points and align reporting to how management actually needs to oversee risk and compliance. That is not always easy: there will be legitimate constraints, limited appetite for change, and some existing processes that exist for good reasons. But the platform should work for the business and its operating model, not the reverse.
The Policy Test: Who Has the Authority to Decide This?
Understanding intent tells you what the business is trying to achieve. It does not tell you whether the answer is consistent with what the organisation has already committed to in policy. A GRC platform should not be designed by whoever holds the strongest opinion in a workshop.
Requests need to be assessed against approved policies, frameworks, methodologies, control standards, regulatory obligations and management reporting needs. These define how the organisation says it manages risk and compliance, and platform design should translate that intent into process, data, workflow, evidence and reporting.
That does not mean every current policy is complete or fit for the future state. New requests often reveal that policy and methodology need to be clarified: a request may fail to align because it is unnecessary or inconsistent, or because the policy has not kept pace with regulatory expectations, operating model changes, or lessons learned.
If a request doesn't align to policy, the project shouldn't configure around the gap. It should surface the issue, identify the right owner, and decide whether the requirement should be rejected, adjusted, deferred, or used as a trigger to update the underlying policy. Good GRC design requires this two-way relationship: policy guides platform design, but implementation also exposes where policy needs to evolve.
In practice this test is only as good as the organisation's ability to name a policy owner who can actually adjudicate, a role that is often less clearly assigned than the policy documents themselves suggest. A later article in this series covers how to build that decision-rights structure in full.
Both tests depend on reading past the form a request arrives in. The most common requests, and what each one may actually indicate:
Request | May actually indicate |
A new field | A data quality issue, or a genuine gap in the platform's data model |
An approval step | Unclear ownership, or a necessary control in a regulated process |
A custom report | A data model misaligned to management needs, or a genuine reporting gap the standard reports don't cover |
Automating a process | Real efficiency to be gained, or a process that should be simplified or redesigned first |
Condition 4: Every Configuration Choice Is a Design Decision, Not a Technical One
Testing intent and policy answers whether a request should proceed. It doesn't answer how it should be built. That is where the fourth condition sits: that something can technically be done does not make it a good idea.
A configuration choice that looks convenient in a workshop may create complexity later in reporting, assurance, administration, upgrades, integrations or user adoption. The same unresolved taxonomy question from the three-business-units example in Condition 1 resurfaces here: a workshop request for a fourth, unit-specific control rating field is the configuration-level symptom of an operating-model question that was never settled.
A useful test before agreeing to any configuration change: who else will read this data, what happens at the next platform upgrade, and who owns the exception a year from now.
Those questions are considerably easier to answer when the people who will live with the answer are in the room. Administrators and business support staff are frequently brought in only at the end, to be trained on a design they had no part in shaping, which converts their frontline knowledge from design input into complaint.
Not every configuration change should be refused. Some are justified by legitimate business, regulatory, control or reporting need. The point is that each should be assessed consciously, not accepted because the platform can support it.
Looks easy today | Long-term cost |
Adding a field for one team | Becomes a data quality problem for every other team reading that field |
A local workflow exception | Becomes a permanent branch in the operating model that has to be maintained |
A workflow shortcut on an approval step | Weakens accountability and makes evidence harder to interpret under audit |
A custom object built for one report | Becomes another object every future upgrade and integration has to account for |
Condition 5: Resource Change and Training as Delivery, Not Overhead
Getting the design right doesn't guarantee anyone can use it. Of the six conditions, this is the one most readily agreed to in principle and least reliably funded in practice. Change and training are typically scoped as a workstream and sized against whatever budget remains, rather than against what adoption actually requires, and the shortfall stays invisible until the platform is technically complete and the organisation is expected to start using it, which is the point the programme's real outcome gets decided.
A common pattern: a training plan built around two generic sessions per user group, timed for the week before go-live, covering navigation and screen layout rather than the judgement calls users will actually need to make: how to interpret an ambiguous risk rating, when to escalate rather than resolve, what to do when the workflow doesn't quite match how the team actually works. The sessions get delivered, attendance gets logged as complete, and the programme closes out the workstream on schedule. The gap only becomes visible weeks later, in the support queue and in the workarounds users build to cope with situations the training never addressed.
Treating change and training as delivery rather than overhead means funding it against the adoption outcome and continuing the effort past go-live rather than closing it out with the project. A later article in this series covers this in full operational detail: role design, cadence, and how to size the effort.
Area | What under-resourced looks like | What adequately resourced looks like |
Role design | Generic sessions for all users regardless of role or judgement required | Training scoped to the decisions each role actually has to make, not just the screens they use |
Cadence | A single push before go-live, closed out with the project | Ongoing support that continues past go-live, tied to the adoption curve rather than the delivery timeline |
Sizing | Budgeted from whatever remains after configuration and build | Sized against the adoption outcome required, before the remaining budget is known |
Condition 6: Fund, Govern and Staff BAU Before Go-Live, Not After
Even a well-adopted platform still needs someone to own it afterwards. Go-live is the beginning of platform ownership, not the end of implementation. A GRC platform doesn't stop evolving once it's live. New regulatory requirements, maturing methodologies, audit findings and emerging data quality issues each turn a finished implementation into an ongoing BAU capability, whether or not anyone planned for that.
A funded BAU capability needs four things in place before go-live: a named platform owner sitting in risk or compliance, not technology; at least one internal administrator involved during design rather than trained at the end; a standing backlog with a regular release cadence; and a budget line that survives the first round of cost-cutting after go-live.
A common pattern where this isn't in place: six months after go-live, a growing list of enhancement requests sits in an inbox with no owner empowered to prioritise it, technology fields ad hoc requests because there is no business owner to route them to, and the platform's reputation begins to rest on whichever request happened to get actioned rather than on a deliberate roadmap.
Money and governance are only part of the problem: the knowledge of why the platform was built the way it was sits with the people who leave at the end of the engagement, and it transfers through involvement across the implementation, not through a design document handed over at go-live.
Without this in place, enhancements become difficult to prioritise and the platform's value erodes rather than fails outright. A later article in this series covers the BAU operating model in full: funding models, governance structure, and how to staff it without over-building.
What Good Looks Like at Six Months
The six conditions above are all expressed as failure modes, which is how they are usually encountered. It is worth turning the picture around and stating the target directly.
In a mature implementation, the business, not technology, is the primary point of contact for questions and changes to the platform. The majority of requests are resolved directly by the business administrator function; technology becomes involved only where there's a genuine technical requirement, typically something needing backend access, that the business admin isn't able to action themselves. That split, more than any single metric, is the clearest early indicator that ownership has genuinely transferred rather than just been assigned on paper.
Data quality on its own is not a reliable early signal, and it's worth being explicit about why: a new implementation rarely has perfect data at six months, and migrated data tends to carry forward exactly the taxonomy and ownership questions discussed in Condition 1, so early imperfection is not itself a warning sign. What matters is direction and accountability: in a healthy implementation, data quality issues are identified and either being addressed or deliberately worked around and ring-fenced. Where quality is declining and nobody has noticed, or nobody is doing anything about it, that is a sign the system has not been sufficiently accepted or understood.
The backlog, similarly, sits with the business team that owns the platform. Where backlog management has drifted to technology or to whoever is available, that is usually the same underlying problem showing up in a different place. The same test applies further upstream: a mature operating model, a well-tested selection, and requests that were checked against intent and policy all show up the same way six months in. They show up as decisions the business can explain, not ones technology is still fielding on their behalf.
A Six-Question Health Check for Your Current GRC Implementation
None of these will appear on a delivery plan as a risk, which is why they are worth checking deliberately.
Score each yes, partly, or no. The number matters less than which ones are which: a “no” on the operating model is a different order of problem from a “no” on BAU funding, because one is expensive to revisit and the other is not yet decided.
The configuration work is rarely where sustainable GRC platforms succeed or fail. Skip any of these conditions and the work does not disappear; it moves downstream, where it costs more and is harder to attribute.
Four of the six conditions are covered here in overview and treated in full elsewhere in the series:
Condition | Covered here | Covered in full in |
Condition 2: Selection | Why testing the demo against your own operating model matters | Why out-of-the-box should be treated as a starting point to test, not a delivery strategy |
Condition 3: Intent & Policy | The intent test and the policy test | How to build the decision-rights structure that makes the policy test work |
Condition 5: Change & Training | Why change and training must be resourced as delivery, not overhead | Role design, cadence, and how to size the effort in full operational detail |
Condition 6: BAU | What a funded BAU capability needs before go-live | The BAU operating model in full: funding models, governance structure, and staffing |
If two or more of the six answers above are “no,” that is a decision about how much of the platform's value the organisation is prepared to keep, not a delivery problem to raise at the next status update. The cheapest time to have that conversation is now, with a steering committee or risk committee that can still act on it, not at the next audit finding or the next budget cycle, when the same conversation costs considerably more and carries less choice. Run the check this quarter, attach a named owner and a decision to whichever answers come back “no,” and revisit it in six months.
In our experience, the organisations that treat these six conditions as design decisions rather than configuration afterthoughts are the ones still pointing to their GRC platform as a source of truth three years after go-live, rather than running it alongside a spreadsheet nobody quite admits to using.
This series continues with how to structure a GRC delivery team without either overbuilding it or hollowing it out through false economy, and moves through governance, requirements and design roles, platform design choices, the change and training effort that determines whether any of it gets used, and the BAU operating model that determines whether the investment holds its value.
Comments