The Current State of GRC Platforms
Some of us remember the days when we used Word documents, Excel spreadsheets, and folders to manage compliance. Each GRC person had their own organization of various artifacts and spreadsheets to track progress and outstanding items. In fact, there are companies that still use this system to great effect.
Then, the GRC tools came along. The ability to properly categorize various documents—policies, standards, controls, SOPs, findings, etc.—assign owners, create links, manage their lifecycle, reviews, and updates, along with the workflows associated with compliance management, was a huge improvement. Content providers followed, offering pre-determined links between industry standards like ISO 27001 and existing controls, paving the way for Common Control Frameworks. Add on top the reporting and some basic analytics, and we have the modern GRC platform with different modules that address different artifacts and capabilities—policy management, compliance management, risk management, and more.
These platforms are highly sophisticated, and many companies use them to manage very complex environments: multiple regulations, global presence, large product lines, extended supply chains. Enterprise GRC platforms even offer integration with other enterprise tools for workflow management, inventory, ERP systems, and specialized tools like vulnerability management, directories, and software repositories. We have graduated to a point where many GRC systems automatically pull the necessary evidence for controls, greatly reducing the non-GRC teams’ efforts.
These mature GRC platforms have significantly simplified our lives by retrieving, cataloging, and managing the lifecycle of various artifacts, along with corresponding workflows like risk assessments and audits.
The Challenges with Current GRC Platforms
However, some challenges are starting to emerge.
Most of these GRC platforms assume a high level of centralization as a requirement to properly manage the catalog of artifacts. Many of us regularly participate in discussions about the “source of truth.” While various mechanisms exist—a process to sync artifacts across multiple platforms, links instead of document copies, etc.—especially in complex environments, that can be a challenge. This often leads to out-of-date or specialized local copies. A more concerning outcome is doing something “for compliance” while, in reality, following a different process.
Even though we can benefit from systems with (almost) all the necessary information and high integrity, achieving more sophisticated compliance automation and analytics remains a challenge. A basic task like establishing and maintaining the links between policies and controls takes specialists with deep knowledge of the environment and several quarters of free time. There are GRC teams that have groups focused exclusively on “optimizing” the control environment. While we know what needs to be done and have the information to do it, the task requires so much effort that many of us settle for running a suboptimal environment—inefficient and less effective. If you recall my previous post about the risks GRC functions bring into the environment, this is one of them.
We could all agree that a high level of compliance automation is the obvious answer. In fact, the community has been working on a machine-readable format of GRC artifacts to enable such automation. But converting and maintaining your artifacts in OSCAL is a serious undertaking in itself. Meanwhile, imagine a marketing person reading an OSCAL-converted policy and understanding it—this brings us back to maintaining multiple versions of the same artifact.
Modern GRC systems do not exist in a vacuum; they must integrate with other systems across the enterprise. This integration must be two-way. For example, we often pull evidence from various sources and create tickets for people to perform reviews. While these integrations have come a long way, there are still quirks to iron out: limited integration (e.g., ticket status is not propagated), required manual intervention, or non-existent connections.
The Evolution of GRC Platforms
One of the main reasons we have evolved toward centralized GRC platforms is to maintain consistency and integrity of information. However, we have a bias toward that over ease of use and maintenance. Arguably, the HR team would prefer to keep HR policies and procedures in their own system and manage them there (which they often do, creating the integration issues mentioned earlier). The question is: how can we achieve a single pane of glass with all the integrity checks and managed consistency in a distributed system?
A GRC team cannot scale at the same rate as the organization. At the same time, there is no person on the team who knows everything about the environment and can single-handedly analyze all angles of a proposed change or nonconformity. Add to this the significant performance boost that other teams like engineering receive from various AI tools, and we reach the theoretical limit of a GRC organization maintaining the environment. Increased effectiveness and efficiency become a distant dream—the team is simply trying to survive.
Naturally, GRC teams will also turn to AI assistants. Initially, this will help with simpler but high-demand tasks like answering questionnaires. But once the GRC artifacts and linkages are contextualized within the AI assistant, teams will start leveraging it for more complex tasks like linking controls to policies and evaluating control evidence. The AI assistant, with its comprehensive view of the environment, can perform these analyses more thoroughly than any single person—and much faster. The role of the GRC person will shift toward identifying improvement opportunities and verifying the assistant’s analysis. Many would prefer reviewing the answers to a questionnaire rather than collecting them.
The next (and somewhat scary) level is the GRC agent. While the AI assistant relies on human action, the agent performs the action itself. For example, the platform will not only analyze the gap against a certain framework but also update the policies, draft the control language, link to necessary evidence, and potentially even change configurations or deploy packages. In this way, compliance automation may finally catch up with the developer world, where AI copilots already assist with code creation.
At this point, we may start asking ourselves: “Why do we need a centralized GRC platform at all?” If the GRC AI platform knows where the artifacts are located, it can create and maintain the necessary linkages and manage the workflows directly. With its agentic nature, the system could perform many tasks autonomously, reducing even the need for traditional workflow management.
A Thought to Leave You With
AI assistants and GRC agents are already being considered—or deployed—by other functions within the company. What if our GRC AI could talk directly to the Engineering AI? Based on our policies, it could instruct the engineering copilot on what code to develop, handle incoming inquiries, update controls as required, and notify us when instructions are unclear or incomplete—providing recommendations and references where needed.
This may sound like science fiction today, but it might not be far-fetched a few years from now.