GRC Platforms Need Governance Before Configuration
In our experience, GRC programmes routinely start configuring before anyone has agreed who owns the outcome, or how competing requests will get decided. Workshops run, requirements get captured, screens get built. It is only later, when two stakeholders want different things from the same workflow, that it becomes clear nobody was ever empowered to choose between them.
By then, the decision usually gets made anyway. It just gets made badly: by whoever is most persistent or most senior in the room, rather than by anyone positioned to weigh the trade-off. A first-line risk owner wants a control exception routed straight to their queue; a second-line compliance lead wants the same exception to trigger a review step first. Both requests are reasonable. Without someone whose job it is to decide between them, the workflow gets built to satisfy whoever raised the point most recently, and then rebuilt three months later when the other side notices.
The Governance Gap: Why It Stays Invisible Until It Is Expensive
Both the build and the rebuild were visible work. What was missing in between was not, and that is why the gap survives. Configuration is visible progress: a screen either works or it does not, and a workflow either routes correctly or it does not. Governance is invisible until it is missing. A missing decision-rights model does not announce itself; it shows up later as rework, inconsistency, or a design nobody can quite explain.
Left unmanaged it has a recognisable shape: questions that keep reopening, processes configured differently for reasons nobody recorded, and design choices that turn out, a year later, never to have been decisions at all.
On one implementation, a business area raised a valid requirement during initial setup, but because it was not fully articulated or clearly presented, it never made it into the design. There was no forum whose job it was to catch that, and no point at which an unclear requirement was tested before it was dropped, so the gap was closed with a workaround instead: a template asking people to fill in a single free-text field that needed to be captured in the backend as three separate fields: a date, a text description and a drop-down selection. The workaround was never a decision. Nobody weighed it and nobody owned it, and it took several months to surface as a problem, by which time it had become how the process worked.
What it cost downstream, as free-text entries and structured fields diverged and the correction grew far larger than the original requirement would have been, is told from the delivery-capability side in ‘Right-Sizing the GRC Implementation Team: Minimum Capability or False Economy?’ The governance point is narrower: none of it needed to happen. The requirement was raised, in the room, by the right people, and there was simply nowhere for it to go. Even a year after the underlying design was fixed, some users were still filling in the free-text field out of habit.
Five Governance Foundations Every GRC Programme Needs Before Configuration
Habit outlasting the design is what a missing forum costs a year on. That forum is one of five things that need to exist before configuration starts in earnest, whether the platform is IBM OpenPages, ServiceNow IRM or another enterprise GRC system.
Governance element | What it does | Where this typically sits |
A design or governance forum | Gives design trade-offs, as well as schedule and budget, a place to be surfaced and resolved, with the right people in the room | Chaired by the programme’s risk or compliance lead, or a delegated design authority |
Business architecture ownership | Names who is accountable for how the target operating model, process, and risk taxonomy should work | Typically the COO function, the risk function, or a dedicated design authority; rarely technology |
Solution architecture | Frames how a target process could be implemented in the platform, with what each way of doing it is likely to cost, and says where the process itself would be better adjusted to fit | Typically closer to the business than to pure technology, because the judgement the role turns on is a business one |
A policy and procedure reference point, identified upfront | Gives the design something real to be tested against, rather than only what stakeholders happen to ask for | Owned by the policy owner or the risk/compliance team that holds the framework |
A named trade-off authority | Names who can decide between competing, legitimate asks for the same business process | A named business owner, product owner or design authority. A steering-group member only where they also hold one of those roles. |
Each element answers a question that will be answered one way or another: deliberately with governance, or by default without it.
Business architecture ownership and solution architecture are not the same role, and in larger organisations they are rarely the same person. A business architect settles how the target process should work. A solution architect takes that as given and works out what building it would involve. Where both sit with the same person, the cost of an option ends up weighed by whoever produced it.
A Simple Decision Discipline: Intent, Options, Review
Those roles only matter at the point a design decision gets made, and the alternative to deciding by preference is a discipline applied consistently to every decision:
Test the intent behind a request before accepting it as a requirement. Many requests are a proxy for something else. A control owner asking for a new field is often asking for earlier visibility of an exception, which may be solvable without a schema change. Testing intent this way regularly resolves a request without any build at all. What testing a request involves in practice is the subject of a later article in this series.
Prepare a small number of realistic options, with the trade-offs made visible rather than buried: what each option costs to build, what it costs to maintain, and what it constrains later. Framing those options is a different job from deciding between them, and it is usually the solution architect who does it.
Review those options with the accountable owner or forum, and let them decide with the trade-offs in front of them, not with only the loudest version of the request.
The last step is what the design forum and the named trade-off authority are for: the forum gives the options somewhere to be reviewed, and the trade-off authority is who settles the question when two of them are legitimate. Without both, the sequence collapses back into whichever preference was expressed most recently.
This is also where the balance between configuration and customisation gets decided: by testing what the request is trying to achieve, and letting the accountable owner choose with the full trade-off in front of them. The range between the two only becomes visible once the options are on the table, which is the solution architect’s contribution to the decision rather than the decision itself.
That contribution is easiest to see where a request arrives with the solution already chosen. On one implementation, the request was for a particular value to be added to a drop-down field. Looking at the process rather than the field, the solution architect found that the condition under which the value would be selected was one the user had no reason to be asked about in that scenario, and proposed an earlier question instead, set automatically by the system, which determined whether the later question needed to be asked at all. Both options were technically possible and the first was slightly quicker to build. The second gave the user a better experience and left more room for other scenarios later. Nothing technical spoke against the original request, so without the second option in front of them the business owner would have had nothing to choose between.
Each decision factor has a foundation it belongs with, and the wrong owner produces a defensible-looking decision made by someone without the standing to make it.
Decision factor | Which foundation weighs it |
Cost to build | Framed by solution architecture as implementation options; weighed by business architecture ownership, because it is a target-design question before it is a budget one |
Cost to maintain | Framed by solution architecture; weighed by business architecture ownership, on the advice of whoever will own the platform in BAU |
Regulatory defensibility | The policy and procedure reference point, tested in the design forum |
Time to deliver | The named trade-off authority, against the roadmap |
The trade-off itself (what standard configuration gives up, and what deliberate design costs to build and to keep) is the subject of a later article in this series. The governance question is the narrower one: who is entitled to weigh it.
Why Governance Gaps Are Harder to Defend Under Regulatory Scrutiny
Entitlement to weigh a trade-off is also what someone outside the programme will ask about. In regulated financial services, a design choice that can only be traced back to “the business preferred it in a workshop” leaves nothing to show them. A choice traced to a named forum, a tested intent and a documented set of options reviewed by an accountable owner can be walked through step by step.
In our experience, examiners and internal audit tend to be less interested in whether an outcome looks defensible in isolation than in whether there is a demonstrable chain from a decision to the individual accountable for it.
The same shape appears in Australia’s Financial Accountability Regime, where an accountable person is answerable for a defined part of the business and that part is written down before anything goes wrong. FAR does not reach platform design, and nothing here suggests it does. What it illustrates is the artefact: a named person, a defined area, and a record connecting the two that exists before anyone needs it.
A trade-off authority is the same construct one level down, inside the programme. It answers the question that gets asked whenever a design choice is revisited, whether by internal audit or by whoever inherits the platform: who decided this, on what basis, and can they explain why.
The gap that makes this hard is usually in the business record rather than the technical one. A change gets explained in conversation, elaborated through further conversation, and documented once it is built, so the technical record of what was configured is complete. The business requirement behind it was never written down and never went through an agreement cycle; it went into a release because it was a good idea at the time. The cost of that lands later, when a closure pack on a remediation plan cannot be traced back to the original request, or when the platform is handed to a run team that was not involved and has no way to answer why a particular aspect is in the system at all.
Governance introduced from day one is the easier case. More often, and this is the position programmes we see are in, it needs to be introduced mid-programme, once the cost of not having it has already started to show up in rework or inconsistent builds, in much the same way the free-text workaround described above only became visible once the underlying data had already diverged. That retrofit is harder, because existing decisions have to be re-tested against the new discipline instead of made fresh, but the same five foundations apply, and the earlier they are put in place, the fewer decisions there are left to unwind.
Naming the Five Roles Before the Next Workshop
Those decisions are the cost of arriving late. Skipping governance altogether does not reduce the number of trade-offs the programme has to make. It removes only the person who would have decided them. They are then made by whoever happens to be in the room, and no one is accountable for them.
Whether that is already happening is testable before the next configuration workshop. Each symptom points to one missing foundation.
Observed symptom | What it indicates | Governance element that resolves it |
The same question resurfaces in every workshop | No forum ever closed it | A design or governance forum |
Similar processes are configured differently across business areas | No one owns the target operating model those processes should follow | Business architecture ownership |
Options arrive as a single proposal, or as a build estimate with no alternative | No one is framing what could be done differently | Solution architecture |
Requirements get built that contradict existing policy | Design has nothing real to be tested against | A policy and procedure reference point |
Decisions get reopened, or resolved by seniority rather than merit | No one is empowered to choose between competing asks | A named trade-off authority |
If any of them look familiar, configuration is already ahead of governance, and the gap will surface later as rework rather than as a decision anyone remembers making.
Having the five roles named is not the same as having them resourced; ‘Right-Sizing the GRC Implementation Team: Minimum Capability or False Economy?’ covers what it takes to staff them.
Start by naming five people: the chair of the design forum, the business architecture owner, the solution architect, the holder of the policy reference point, and the trade-off authority. Each of them should know the call is theirs before the next configuration decision is made.
Comments