When it comes to any discussion involving the acronym GRC (Governance, Risk and Compliance), understanding the speaker’s frame of reference is paramount.
From a vendor’s perspective, GRC refers to an automated suite of capabilities designed to address a broad range of challenges associated with critical disciplines managed by the client (e.g. compliance, risk management, audit, corporate governance etc.), allowing that same company to reduce uncertainty, achieve the entity’s key strategic objectives and meet its stakeholder obligations.
Again, that perspective on GRC, which sounds straightforward enough, is being viewed through the eyes of the vendor.
Probably the same for every vendor, right?
Not so fast.
More holistically, would it be identical to how the client defines GRC?
Another no.
Let’s look at the delineating factors.
From a vendor perspective, what comprises each individual GRC system is totally dependent upon each vendor.
Simply put, not all systems are created with identical features.
The rationale is straightforward and understandable.
Look no further than the broad construct of the GRC umbrella – consisting of risk, compliance and a final element of governance that, drilling down to more specific risks, can be incredibly broad and wide-ranging (e.g. audit, corporate governance oversight, policy management, fraud, model, ESG, AI etc.).
It’s not hard to understand how the inevitable differences in system emphasis and packaging could (and do) result.
As a consequence, the GRC marketplace has found itself flooded with competing vendor-centric solutions, each seemingly in search of the next, new GRC challenge.
A skeptic could argue that each successive GRC solution becomes more inflexible, costly, complex and/or esoteric than the prior one.
With all these drivers, the “ask” of the GRC client often becomes to:
- Accept a system that is unwieldy and inflexible
- Tolerate system features that you don’t need
- Sacrifice other elements that you (or your Board of Directors) really want
- Endure a bevy of reports, scorecards etc. that are neither pertinent nor understandable
- Tolerate service standards that seem average, at best
Needless to say, this is not really music to the client’s ears.
From a client’s perspective, therefore, the pursuit of a GRC solution all too often narrows to a choice that is best termed as “one-size-fits-all” or “take-it-or-leave-it”.
That’s not the way it’s supposed to be, if you roll back the tape and try to comprehend what GRC means, at the 40,000 foot level. Maybe it’s time to take all this in and perform a sanity check of your GRC system.
After all, system capabilities and design should be all about the client.
With that in mind, how does a client think about GRC and, as a result, how should the vendor “ideally” design the system to meet those client needs?
First, the basic governing premise for GRC needs to be established, as follows:
The profound, pervasive and vitally important challenges that drive GRC emanate from the company, not from the vendor.
This principle, which always has been, and always will be, true, cannot be overstated.
It’s not about forcing the client to perform contortions – and sacrifice functionality – to align with an inflexible, rigid tool.
As a 35-year real-life practitioner in the GRC space (25 years as a corporate risk manager and 10 years in the ERM Governance and Disclosure world), I know whereof I speak.
While the concept of GRC is said to have been created over 20 years ago (2002), the underlying challenges actually constituting those GRC exposures have been around forever.
They were certainly there in front of me on my first day as a risk manager in 1985, well before that “umbrella” concept of GRC was “created” and/or the first automated tool was developed.
Having said that, and mindful that there is no one “best” prescribed system or solution, it can be stated with certainty that a GRC automated tool should possess the following attributes:
- Capable of evolving and growing over time
- Potential upgrades should be straightforward
- Solution must be dynamic, nimble and agile
- As such, it should be configurable
- Can be either modular or holistic
- Data must be able to be shared across modules
- There needs to be cross-functional coordination
- The system must be unified and linkable
- There should be rich, robust functionality
- The system needs to understand the business context of the company (what it does) as well as its culture and stakeholders
- GRC strategy must be aligned with the overall business objectives
- The tactical execution for each of the constituent parts of the GRC automated application must be part of the tool
- Monitoring of GRC system performance must involve a robust, fully-embedded business intelligence platform
With all these features in hand, a unified approach to GRC capabilities within the overall solution should allow a company to leverage GRC information across the enterprise.
By linking key elements across risk, compliance, audit and corporate governance (as well as related disciplines), the solution should be able to streamline processes and maximize utilization of information dashboard and analytics that cross boundaries.
Similarly, linked solutions reduce overlap, share overall insight, reuse work and tackle siloed GRC responses while securing what’s private.
A representative listing of GRC system activities might be, as follows:
Compliance
- Document controls, assess performance, manage exceptions
- Tools to manage regulatory change and document compliance framework
- Test or assess performance, manage remediation and share status results with stakeholders
- Financial (SOX, PCI); Industry (NERC, HIPAA); Departmental (HR, IT)
- Approvals, Attestations, and Certifications
Risk
- Systematic approach to identify, assess, mitigate and monitor risks
- Centers on risk register
- Empower Risk Owners to manage and assess their own topic risk set
- Goal is to collaborate with risk owners and other internal and external associates in a clear and transparent manner
- Board-level reports and scorecards should be available to be generated in order to assess performance and establish risk priorities
Audit
- Program definition based on client-specific reporting
- Management insight into audit execution and planning
- Management review, overrides to final plan
- Engagement planning
- Electronic workpaper management
- Issue and remediation management
Governance
- Policy definition
- Policy review and renewal
- Demonstrable performance
Other GRC-Related Activities
- Model risk surveys, including reliance on Artificial Intelligence (AI)
- Fraud-risk studies
- Cyber risk (information security)
Summary
An “ideal” GRC solution revolves around specific customer needs. Enterprise GRC software that supports Compliance, Risk, Audit or Governance needs should be highly configurable solutions that can be tailored to a company’s users, data and processes. Embedded Business intelligence features should generate dashboards and reports that are needed for internal and external purposes. GRC Solutions should support business processes, not the other way around. Each of the components of GRC are integrally linked to the achievement of a company’s corporate objectives.
About the Author:
Michael Cawley is a risk management executive with a 35-year record of broad and diversified accomplishment in the strategic and tactical elements of corporate enterprise risk management (ERM). He performed day-to-day development and execution of a risk management program that covered all elements in the identification, assessment, mitigation and monitoring of all exposures within the corporate risk universe. Specific experience involved being a corporate risk manager for a service-related conglomerate (15 years) and then a biopharmaceutical manufacturer (10 years) before assuming an ERM governance and disclosure leadership role (10 years, through 2021) for a major worldwide financial entity. Currently, Mike serves as a Subject Matter Expert (SME) in an advisory role for ERM Best Practices for the advancement of DoubleCheck’s new ERM One™ application.