By Head of Client Solution Design, Lionel Matsuya
I’ve spent over a decade working in risk and control: first as an advisor at PWC, and now supporting GRC strategy through GRC technology that works for our clients at CoreStream GRC.
One thing that’s become clear to me is this: a GRC initiative does not succeed or fail on just the strategy, the framework, the technology, the people or the methodology. It needs all of them working together, in a planned, designed outcome.
The difference between a GRC solution that truly works for you and one that doesn’t, is often decided at the very beginning, before a single workflow is mapped, or a dashboard is built. That’s the part I want to talk about in this series.
To make it easier, I’m going to use an analogy. We’re going to build a house. Not literally (although building my own one day is a personal dream), but to explore the layers of GRC design in a structured, relatable way. Over this series , I’ll share what I’ve learned about the “architecture” of GRC systems, and how to get them right.
This isn’t about strategy (where to locate the house) or operations (how to maintain them). It’s about design: the decisions that determine whether a solution stands strong and serves its occupants, or whether it starts to crack under pressure.
We’ll start, as all good projects do, with the foundation.
The foundation of a successful GRC ecosystem
If a house were really being designed and built from a blank slate, the best place to start is to think: what is the house going to be used for? Are the future occupants a family? Perhaps a group of housemates? Is space the key priority, or is accessibility more important?
The more you can picture the future lives of the users of the house, and understand them and what drives them, the more likely you are to end up with a home that is loved and lived in well. (For me, the non-negotiables would be a separate study and a covered BBQ shed – ideally an outdoor kitchen.)
It’s the same in GRC. The foundation rests on two critical elements:
- Understanding the why: the needs and pain points of your future users.
- Engaging the right stakeholders early and understanding how they will work together.
(These aren’t the only elements, of course – plenty more to think about in future parts.)
1. Understanding the why of your governance, risk and compliance project
Too often, GRC design projects start from the “what”: what system are we implementing, what processes will we embed, what reports will leadership get. But the more important question (the one that dictates success or failure) is why; and the why can be unpacked as:
- Positives (achieving business objectives)
- Negatives (avoiding pain points like risks, manual admin and confusion).
Skipping this step is like building a house with no sense of whether the occupants need three bedrooms or five, a garage or a garden. It will look complete from the outside, but it won’t be fit for purpose and the team won’t be happy with it.
Two examples which highlight the differences in answering this question
- A large, regulated bank might feel acutely the pain point of scrutiny and compliance
- A government body may have the business objective of better transparency and integration across the houses.
Both are “houses.” But their occupants want very different things.
The way to uncover this is structured discovery. Workshops are useful, but only if they are focused. Interviews and short surveys can complement them. And above all, don’t just ask stakeholders what they want: ask them what’s frustrating them today. The answers to that second question are often where the real value lies.
2. Engaging your different stakeholders early in their GRC wants and needs for design
A GRC system without stakeholder buy-in is like a beautifully designed house that only one person lives in.
If senior leadership doesn’t see the benefit, reports won’t get used. If operational teams see controls as a burden, they’ll work around them. The foundation crumbles, and when that one advocate moves to a different company, the home is no longer accessible!
The most successful designs I’ve been involved in are the ones where stakeholders don’t just feel “consulted” but genuinely “heard.” That means:
- Mapping stakeholders properly. Not just executives, but process owners, first-line teams, compliance, audit, IT: the whole ecosystem.
- Asking the right questions. “What do you need to do your job better?” “What frustrates you today?” “What would make this system successful in your eyes?”
- Feeding back. Let them see their input reflected in the design. Even if compromises are needed, show the trade-offs transparently.
This isn’t just about good manners; it’s practical risk management. A solution that fits the needs of one group but alienates another is a fragile foundation.
Side note: integrating activities means integrating teams
One of the most common “whys” of GRC initiatives is to integrate the different ways that functions manage their GRC activities, to standardize, reduce duplication and benefit from sharing. We have risks and controls in finance, compliance and legal – why not integrate them?
We’ll cover integration a bit more in a future post, but the points made in this article apply to multiple teams too. If you want integration of GRC activities, you need the teams to be integrated in purpose and (to a certain extent) language.
The pitfall comes when everyone is keen on integration but only if they don’t have to give anything up and everyone aligns to them. This is clearly not going to work if everyone comes with this attitude, but it’s a bit of an elephant in the room for many GRC projects.
Bringing the GRC requirements together for a clear blueprint and plan
So, by the time the foundations are laid, you should have three things in hand:
- A clear map of who the “occupants” are (your stakeholders).
- A grounded understanding of their needs and pain points.
- An agreed definition of what “success” looks like.
Only then should you start sketching walls, wiring, or fixtures – the subject of the next parts of this series.
Because in GRC, as in housebuilding, the temptation to rush to the visible elements is strong. But it’s the foundations (invisible though they are) that determine whether the structure stands strong for years, or starts to crack under the first bit of pressure.
In Part 2, I’ll talk about Integrating the experience, and why corridors aren’t enough.
About Lionel Matsuya
Lionel is the Head of Client Solution Design at CoreStream GRC, where he’s disrupting the traditional approach to Governance, Risk, and Compliance. With 12 years of experience from a Big Four consulting firm, Lionel is all about designing bold, customized solutions that make clients rethink what’s possible with the CoreStream GRC platform. Lionel’s experience spans organizations of all sizes and across various levels of GRC maturity, both locally and globally. A chartered accountant with the ICAEW and a Certified Information Systems Auditor, Lionel is passionate about using technology to make people’s lives easier.
Connect with Lionel on LinkedIn here.
Frequently asked questions
The foundation of a successful Governance, Risk, and Compliance (GRC) design lies in two key elements: understanding the “why” behind the initiative (user needs and pain points), and engaging the right stakeholders early in the process. Without these, even the best technology or frameworks can fail.
Start by uncovering both the positive goals (like achieving business objectives) and the pain points (such as manual processes or compliance risks). Use focused workshops, interviews, and surveys to ask not just what users want, but what frustrates them today.
A common mistake is starting with the “what” (tools, reports, workflows) instead of the “why” (user needs and business drivers). Another is failing to involve a diverse group of stakeholders, which can lead to poor adoption and siloed systems.
Just like building a house, GRC design requires a strong foundation. You must understand who will “live” in the system (stakeholders), what they need, and how they’ll use it. Skipping this step can result in a system that looks good but doesn’t function well.
