Building GRC from scratch in a €20 billion retailer
Most large retailers already have the components of a GRC function. Policies exist. Risk registers are maintained. Committees meet. Audit findings are tracked. Security standards are documented somewhere.
The problem is rarely absence of effort. It is absence of coherence.
Policies were written at different times for different reasons. Risk registers are not used for decisions. Audit findings recur because ownership was never properly fixed. Security standards exist in some areas and not others. Procurement manages one layer of supplier controls, technology manages another, and business functions assume someone else has the gap covered.
That fragmentation is common. It is also expensive — in ways that only become visible when the business is placed under pressure.
What fragmented GRC actually costs
The cost of weak GRC is not primarily the cost of the function itself. It is the cost of what the function fails to prevent, absorb, or accelerate.
In a transaction context — acquisition, divestiture, or significant investment — weak governance creates friction. Due diligence surfaces the gaps. Audit readiness takes longer. Integration planning becomes harder because no one can clearly articulate who owns what, where the material risks sit, or how control is evidenced. That friction has a direct commercial cost: it extends timelines, consumes management attention, and in some cases affects valuation.
Outside of transactions, the cost is quieter but persistent. Recurring audit findings that never fully close absorb management time without improving control. Regulatory requests require ad hoc assembly of evidence because no standing process exists. Incidents take longer to contain because responsibilities are split across several teams and no one owns the end-to-end outcome. Board reporting covers activity, not accountability.
The common thread is that leadership — whether a board, an operating partner, or an executive team — cannot get a clear, fast answer to basic questions: what are our material risks, who owns them, and how confident are we that they are controlled?
When that confidence is missing, the management overhead rises. Not because the function is under-resourced, but because it is under-structured.
What the problem looks like in practice
In a €20 billion retailer, the risk landscape is shaped by margin pressure, distributed operations, seasonal peaks, legacy systems, supplier dependency, constant technology change, and large numbers of teams making decisions at speed. That is a demanding operating environment for any governance model.
Most weak GRC builds in this environment share recognisable patterns. The function has been assembled incrementally: a policy here, a forum there, a vendor brought in to solve a specific problem, a role created to close a gap. Each addition made sense at the time. Over time, the accumulation creates something that looks extensive but is difficult to operate.
Governance forums meet, but review rather than decide. Risk registers are maintained, but are not connected to how the business allocates resources or prioritises remediation. Control activity is layered across multiple teams without a clear view of duplication or gaps. Ownership is assumed rather than assigned — and when it is tested by an incident, a regulatory request, or a board question, the ambiguity becomes immediately visible.
That is the pattern. It is not a failure of competence or intent. It is a failure of operating design.
Why framework debates are the wrong starting point
A common instinct when confronting this fragmentation is to select a framework and impose it. That instinct is understandable, but it usually leads the programme in the wrong direction.
At a strategic level, most major GRC frameworks are doing broadly the same job: organising risk, defining expectations, assigning control logic, and supporting assurance. Their emphasis differs. Their terminology drifts. Their implementation patterns vary. But the underlying mechanics are not radically different.
The question for a board or operating partner is not which framework has been selected. It is whether the function has started from the risk shape of the business — and whether the control environment maps to the risks that actually matter commercially.
In a retailer, those material risks typically include some combination of customer-facing resilience (stores, e-commerce, payments, fulfilment), supply chain continuity, pricing and merchandising integrity, identity and data protection, and the platforms that underpin them. If the GRC function cannot explain clearly how control maps to those specific exposures, the framework underneath is largely irrelevant.
Effective GRC builds start with that macro risk picture, then narrow into a minimum viable control baseline: specific control objectives, clear ownership, and repeatable routines tied to the risks that matter most. The priority is adoption and disciplined rollout — not comprehensive design.
Fewer usable controls, credibly adopted, will always outperform an elegant model that the business routes around.
GRC is a change programme disguised as a control programme
This is the point that most framework-led approaches miss.
The hard part of building GRC in a large retailer is not writing policies. It is changing behaviour. It is moving a complex, fast-moving organisation toward clearer ownership, more visible decision-making, tighter control adoption, and more consistent evidence where it is actually required.
That is why GRC is, in practice, a disciplining exercise. It disciplines how risk is discussed. It disciplines how exceptions are handled. It disciplines how issues are tracked and how ownership is assigned. In a large enterprise, these shifts matter more than the elegance of the framework behind them.
A board or operating partner assessing the maturity of a GRC function should look for this: not whether the documentation is comprehensive, but whether the organisation is operating with fewer unmanaged gaps and greater consistency in how control is applied. That requires meaningful adoption — and adoption is a change management outcome, not a compliance outcome.
Where organisations go wrong
Most weak GRC builds are not failures of intent. They are failures of sequence.
They start with the target state before establishing the baseline. They import governance patterns — and often people — from more regulated sectors without adapting them. They create committees that review information but do not make decisions. They mistake document volume for maturity. They design for assurance before they have built ownership. They invest in tooling before clarifying the operating model.
The result is predictable: a GRC function that looks serious but is weak in practice, slows the business, and frustrates the executives who are supposed to rely on it.
A better sequence is simpler. Understand the material risks. Define the minimum viable control baseline. Assign ownership. Establish decision paths. Embed the routines. Then mature selectively where the evidence shows it is needed.
That tends to look less sophisticated in presentation form and much stronger in operation.
What good looks like
Good does not mean finished. It means the business has a clear view of its material risks and a baseline control environment that maps to them. Ownership is visible. Governance forums decide rather than observe. Exceptions are explicit. Issues are tracked. Core controls are being applied with reasonable consistency.
Critically, the organisation is better able to absorb the events that test governance under pressure: audit, regulatory scrutiny, incident response, acquisition activity, or a direct board challenge — without improvising each time.
That is what boards, operating partners, and leadership teams need from GRC. Not an ideal framework. Not borrowed complexity from a bank. Not a function obsessed with methodology at the expense of adoption.
Done well, GRC is not a bureaucratic layer. It is an operating discipline that improves resilience, accelerates readiness for transactions and scale, and delivers measurable cost efficiency by eliminating the hidden overhead of fragmented control.
Next in this series: why operational drift in cyber and technology functions shows up as a performance problem first — and a cost problem second.