By Head of Client Solution Design, Lionel Matsuya
Over the years advising organizations on risk and control design, I have seen a consistent pattern. GRC frameworks and solutions are implemented thoughtfully and with real commitment. For a time, they work well: reporting is clear, ownership is understood, and assurance has structure.
Then the organization changes, and the GRC platform can’t keep up.
Growth introduces new markets, regulatory expectations shift, leadership priorities change, acquisitions reshape the operating model. None of this change is unusual. What is striking is how often the GRC environment begins to feel out of step; not because it was poorly built, but because it was designed for a moment rather than for a journey.
We wouldn’t expect to demolish a house every few years simply because the occupants’ needs have changed. We design with longevity in mind. Rooms can be repurposed. Extensions can be added. Infrastructure can be upgraded. The structure itself remains sound.
Yet in GRC, significant change often triggers a search for replacement: a new tool, a redesigned framework, a fresh start. The implicit assumption is that systems cannot adapt; they must be rebuilt.
Behind this, the key point is that the vision and objectives should be clear, and remain the driving force behind the GRC framework and supporting processes. The vision and objectives of a living space are clear, so you don’t usually compromise on them – and the same principle should apply to your approach to GRC strategy.
When growth exposes structural limitations of your GRC platform
Organizations rarely grow in neat, predictable increments. Expansion may involve entering new jurisdictions, acquiring businesses with different practices, or responding unevenly to emerging regulatory pressures. If the structure underlying the GRC platforms and processes were too tightly bound to the original requirements, then they can’t grow with.
The impact is usually gradual. Additional fields are added to capture new requirements. Workflows become more complex to accommodate exceptions. Reporting structures are adjusted to reflect revised hierarchies. Individually, these changes appear manageable. Collectively, they introduce friction and make the environment harder to navigate and explain.
Growth itself is not the problem. The issue arises when the original design lacks the structural flexibility to absorb change without constant reconfiguration.
Start with strong, simple core processes for your risk & compliance programs
The fundamentals of risk management do not change with scale.
Whether supporting a fast-growing start-up or a multinational group, the essential questions remain consistent:
- What is the risk?
- Why does it matter?
- How is it controlled?
- Who is accountable?
- How do we know it is working?
As organizations grow, volume and complexity increase, but these core principles endure. Scalability depends on keeping them clean and consistent.
Difficulty often arises when systems are over-engineered to meet the needs of edge cases. Bespoke classifications, highly specific workflows and additional data requirements accumulate over time. While each addition may be justified, the overall effect is a design that becomes increasingly difficult to extend.
A GRC house built to endure is anchored in simple, timeless processes. Edge cases are managed as extensions of the structure, not as drivers of it.
Design your GRC platform for direction, not just today’s structure
Operating models will change. That is inevitable. What should guide GRC design is the organization’s longer-term direction -whether that involves international expansion, acquisition-led growth, digital transformation or increased regulatory scrutiny.
Hierarchy, taxonomy, and reporting structures should support future direction without requiring reversal. This does not mean building an elaborate, fully mature framework prematurely. If things get too complicated too soon, people might not use the system – and it just makes more work for everyone.
It does mean selecting architectural principles that will still make sense in 5 or 10 years’ time.
In a house, this is probably a painfully familiar story: choosing a shortcut can save time and money now, but will come back to bite someone at some point.
Invest in shared architecture and language
Scalability is ultimately about coherence.
Organizational hierarchies, risk taxonomies and control libraries form the structural framework of a GRC environment. If they are too tailored to one function, integration becomes harder as the organization grows.
To build something that really scales, you need to think about what each part needs – whether it’s risk, controls, assurance, or compliance – while still keeping everything under one roof. If these pieces are set up clearly and consistently from the start, it’s much easier to handle new rules or changes in the organization without having to go back and redo your main data.
Avoid building around a single function
Another common source of long-term strain is designing primarily for one stakeholder group. Optimizing early for the needs of risk, compliance or internal audit may create short-term efficiency, but bring structural bias.
As the organization grows and new audiences engage with GRC information, translation layers multiply. The system becomes harder to understand outside its original context.
A durable GRC environment is enterprise-first. It supports multiple perspectives without being structurally dependent on any one of them. That balance is easier to achieve at the design stage than to correct later.
Design for intuitiveness
As organizations expand, new leaders and teams engage with the GRC framework. They will not share the institutional history of why certain choices were made.
For a system to scale, its logic should be understandable without extensive explanation. It should be clear how risks are defined, how controls are linked, how assurance is performed and how information flows upward.
Sophistication that cannot be explained simply will struggle to endure.
Building for decades, not for redesign cycles
We would not demolish a well-built house just because regulations evolve or a company grows. We would reinforce it where necessary, extend it carefully and ensure that additions respect the original structure – the original vision, which shouldn’t change.
GRC should be approached in the same way.
Strong foundations define purpose. Connectivity enables flow. Security protects without obstructing. Usability drives adoption. But adaptability determines whether the entire structure continues to serve the organization as it changes.
The most effective GRC environments are not those that promise perfection at launch. They are those designed with simplicity and integrity to remain relevant over time, accommodating growth, acquisition and regulatory change without needing to be torn down and built again every time something changes.
A well-designed GRC house evolves with its occupants, supporting them for decades rather than forcing them to start again every few years.
Check out Lionel’s previous blogs here
Designing your dream GRC home, part 1: the foundations of good GRC design
Designing your dream GRC home, part 2: connectivity and why corridors need to be planned
Designing your dream GRC home part 3: security and access
Designing your dream GRC home part 4: wiring the house – making automation helpful, not burdensome
Designing your dream GRC home part 5: how thoughtful experience turns good design into real adoption
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 about GRC user experiences
Most organizations first notice symptoms rather than root causes: increasing numbers of exceptions, complex workarounds, heavier admin, reporting inconsistencies, or difficulty onboarding new stakeholders. These are signs that core structures, taxonomy, workflows, data models, were not designed with flexibility in mind.
It means aligning the GRC architecture to the organization’s strategic direction, not to today’s shape. Instead of building tightly around one team or one temporary structure, you design for scenarios like international expansion, acquisitions, or increasing regulatory demands, so the framework still makes sense 5–10 years later.
Simple enough that the fundamentals never change:
What is the risk?
Why does it matter?
How is it controlled?
Who owns it?
How do we know it works?
If these are clean and consistent, complexity can grow around them without distorting the whole system.
By designing with an enterprise lens. Risk, compliance, audit, and assurance should all be able to use the framework without translation layers or special versions. A shared taxonomy and architecture ensure that as more teams engage, the system remains intuitive and scalable.
