By Head of Client Solution Design, Lionel Matsuya
In the first two articles of this series, I explored 2 foundational aspects of Governance, Risk & Compliance (GRC) solution design: understanding organizational needs and stakeholder expectations, and designing effective connectivity between risk, control and assurance functions.
In this 3rd blog, I focus on security and access: not in the narrow sense of cyber or technical controls, but as a core architectural consideration in GRC solution design. Specifically, how access, authority and protection should be designed in a way that safeguards the organization while enabling effective governance, risk management and assurance.
Security, like foundations and connectivity, is not something that can be successfully added at the end. It must be designed in from the outset. In fact, I’d suggest that security is an enabling feature, not a simple administrative requirement.
Security in the context of GRC platforms
In a house, security is expressed through locks, doors and defined boundaries. These protect occupants and their property, while still allowing the house to be used comfortably and effectively.
A well-designed house does not treat every room in the same way. Private spaces are separated from shared areas, valuable items are protected appropriately, and access is intuitive rather than obstructive.
The same principle applies in GRC platforms.
Security in this context is about:
- Defining who can create, modify, review and approve information
- Ensuring appropriate segregation of duties
- Protecting sensitive data while supporting transparency and oversight
- Providing auditability without unnecessary administrative burden
A common pitfall: security as an afterthought in GRC platforms
One of the most common challenges I see in GRC solution delivery is that security is addressed late in the design process.
The focus is often placed first on data structures, workflows and functionality, with access considered much later – or considered as a feature separate from the other functioning of the solution.
An example of security and design working together
I once worked for a community charitable organization. They had a big building which was used by multiple groups of people, at potentially the same time:
- Employees of the charity, who were allowed access to everywhere
- People involved in a weekly provision of food, who needed access to the kitchen
- A parent and toddler group, who needed access to the main hall
- Other groups who sometimes met in other rooms upstairs
The experience outcome was a brilliant building which could be used by multiple groups, controlled through keys. Every key got into the front door and the WC block, but side doors allowed access to the kitchen, stairs, hall and so on in different combinations.
But this good design didn’t happen by accident. Some people sat down and asked:
- Why is this building being built? Who are the key stakeholders? (Blog 1: the foundations)
- How do we design the building so that it works for everyone? (Blog 2: connectivity is key)
- How do we organize the building so that access works? (this blog)
If you didn’t think carefully about the rooms, either your access model just wouldn’t work (“Sorry, your keys don’t allow access to toilets”) or would be unnecessarily complicated (“you need to use this key to get out of the building, walk around, and then use a different key to get back in”).
No, the layout was carefully planned to ensure the access would work seamlessly, always thinking about the user experience as well as privacy and security.
Security depends on the integration of risk and compliance solutions
The example above brings us back to the previous article where I advocated for an integrated approach, connecting the rooms together properly so that the solution has a common language and feel to it.
Where risk, control and assurance data are fragmented across silos, security becomes complex and fragile. Duplicate objects, inconsistent ownership models and conflicting definitions make it difficult to apply coherent access rules.
Conversely, when GRC information is structured around shared data objects and clear relationships, security becomes easier to design and maintain:
- Ownership is unambiguous
- Access rights are consistent
- Oversight and assurance are strengthened
In this sense, strong security is an outcome of good overall architecture.
Designing security into the blueprint of your GRC platform
In well-designed houses, security is embedded into the blueprint rather than retrofitted. The same should be true for GRC platforms and the various solutions within them.
Early design discussions should include questions such as:
- Who is accountable for each type of information?
- Where is independence required?
- What information should be broadly visible, and what should be restricted?
- How do we evidence oversight without creating bottlenecks?
Addressing these questions early leads to security models that support, rather than obstruct, the organization’s governance objectives.
Please note – Effective GRC security does not aim to restrict activity unnecessarily. Its purpose is to enable confident decision-making, clear accountability and reliable assurance. Here at CoreStream GRC, we believe technology should be an enabler, not a barrier, and that security should make sense for your business and the way you work.
Bringing security and the user experience together as the optimal GRC platform
Security is not about adding more locks. It is about placing the right locks, in the right places, for the right reasons.
In GRC solution design, security should be treated as a fundamental architectural element, considered alongside foundations and connectivity, not after them.
In the next blog, I will explore the internal wiring of the GRC house: data quality, reporting and insight, and why strong governance outcomes depend on what sits behind the dashboards as much as the dashboards themselves. See you then!
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
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
Security is not something that can be added at the end of a GRC implementation. Like the structural foundations of a house, access and authority must be designed early to ensure the platform remains usable, scalable and safe. Treating security as a late-stage configuration typically results in conflicts, workaround-heavy workflows and fragile governance. When designed early, security becomes an enabler, supporting confident decision-making, clear accountability and effective assurance.
Security in GRC systems goes beyond cyber protections. It includes:
– Who can create, modify, review or approve data
– How segregation of duties is upheld
– What information is visible or restricted
– How oversight and auditability are ensured
– How sensitive or high-risk data is protected
It’s about designing intuitive, appropriate access, much like having the right keys for the right rooms in a well-planned building.
When security is an afterthought, issues quickly arise:
– Overly complex role models
– Confusing or contradictory access rights
– Data silos and duplicated objects
– Increased administrative overhead
– Gaps in oversight and assurance
Late-stage security design often forces compromises that undermine both user experience and governance integrity.
Security becomes significantly easier when the GRC platform is built on shared data objects and consistent relationships. With integrated design:
– Ownership is clear
– Access rules can be applied consistently
– Oversight becomes reliable
– Assurance activities are easier to manage
Strong security is largely a by-product of good architectural connectivity between risk, control and assurance functions.
Early design discussions should explore questions such as:
– Who owns each type of information?
– Where is independence required (e.g., assurance vs. risk owners)?
– What should be transparent vs. restricted?
– How do we provide strong governance without slowing people down?
Addressing these questions early creates a security model that protects the organization while supporting practical, efficient ways of working.
