How will AI shape the future of GRC platforms?
The Current State of GRC Platforms
Some of us remember the days when compliance was managed through Word documents, Excel spreadsheets, and shared folders. Each GRC person had their own system for organizing various artifacts and tracking progress and outstanding items. In fact, there are still companies today that use this approach effectively.
Then came the GRC tools. The ability to properly categorize documents—policies, standards, controls, SOPs, findings, and more—assign owners, create links, manage lifecycles, reviews, and updates, along with automating workflows, was a significant improvement. Content providers followed, offering pre-determined mappings between industry standards like ISO 27001 and existing controls, which paved the way for Common Control Frameworks. Layer on reporting and basic analytics, and we arrived at the modern GRC platform—complete with modules for policy management, compliance management, risk management, and beyond.
These platforms are highly sophisticated, and many companies rely on them to manage complex environments involving multiple regulations, global operations, broad product lines, and extended supply chains. Enterprise GRC platforms even integrate with other enterprise systems—workflow management, inventory, ERP systems, specialized tools like vulnerability management, directories, and software repositories. Many mature GRC systems can now automatically gather evidence for controls, significantly reducing the burden on non-GRC teams.
These platforms have greatly simplified our lives by retrieving, cataloging, and managing the lifecycle of artifacts and associated workflows like risk assessments and audits.
Challenges with Current GRC Platforms
However, some significant challenges are emerging.
Most of these platforms assume a high level of centralization to properly manage the catalog of artifacts. Many of us regularly engage in debates about the elusive “source of truth.” While various mechanisms—syncing artifacts across platforms, linking instead of duplicating documents, and so on—exist to maintain consistency, they often fall short in complex environments. This frequently results in outdated or fragmented local copies. A more concerning outcome is when teams perform activities “for compliance” while actually following different processes in practice.
Even with systems that maintain (almost) complete information integrity, achieving more sophisticated analytics remains difficult. Simple tasks like establishing and maintaining links between policies and controls often require specialists with deep knowledge of the environment—and quarters of free time. Some GRC teams dedicate entire groups solely to “optimizing” the control environment. While we know what needs to be done and have the information to do it, the effort required is so high that many settle for suboptimal setups—inefficient and less effective. As I mentioned in my previous post, this is one of the risks GRC functions can introduce into an organization.
High levels of automation seem like the obvious solution. In fact, the community has been working toward machine-readable formats for GRC artifacts to enable such automation. But converting and maintaining artifacts in OSCAL, for example, is a major undertaking. Imagine asking a marketing person to read and understand a policy converted into OSCAL format—it’s back to maintaining multiple versions of the same artifact.
Modern GRC systems do not exist in a vacuum; they must integrate with other enterprise systems. Crucially, this integration must be bidirectional. For example, we often pull evidence from various sources and create tickets for people to perform reviews. While integration capabilities have improved, there are still many gaps: ticket status may not be synchronized, manual intervention may still be required, or integration may simply not exist.
The Evolution of GRC Platforms
One key reason we’ve moved toward centralized platforms is to maintain consistency and integrity of information. However, this often comes at the expense of ease of use and maintenance. Consider how HR teams often prefer to manage their policies and procedures within their own systems—this frequently creates the very integration issues I mentioned earlier. The question becomes: how do we maintain a single pane of glass, complete with integrity checks and managed consistency, in a distributed environment?
A GRC team cannot scale at the same rate as the organization itself. No single person on the team knows everything about the environment or can analyze every proposed change or nonconformity. Meanwhile, other teams like engineering are experiencing massive productivity gains through AI tools. GRC teams, by contrast, are approaching their operational limits—where increased effectiveness and efficiency feel like distant goals, and survival becomes the daily priority.
Naturally, GRC teams will also turn to AI Assistants. Initially, these will help with simpler but high-demand tasks like answering questionnaires. However, once artifacts and linkages are contextualized within the AI Assistant, teams will begin leveraging it for more complex work—such as linking controls to policies and evaluating control evidence. Importantly, an AI Assistant can have a comprehensive view of the environment, performing analyses more thoroughly and quickly than any one person. This shifts the GRC person’s role toward identifying improvement opportunities and verifying the Assistant’s work. Many would prefer reviewing the answers to a questionnaire rather than collecting and compiling them.
The next—and perhaps somewhat unsettling—step is the GRC Agent. Unlike the Assistant, which relies on humans to take action, the Agent performs the actions itself. For example, not only will the platform analyze gaps against a framework, but it could also update policies, draft control language, link to necessary evidence, and perhaps even make configuration changes or deploy necessary packages. In this way, GRC may begin to mirror the developer world, where AI copilots now routinely assist with coding.
This naturally leads to a provocative question: Why do we need a centralized GRC platform at all? If the GRC AI platform knows where the artifacts are located, it could create and maintain the necessary linkages and workflows directly. With agentic capabilities, many traditional workflow management tasks would be automated away.
A Thought to Leave You With
AI Assistants and Agents are already being considered—or even deployed—by other functions within the company. What happens when our GRC AI begins to communicate directly with the Engineering AI? Based on our policies, it could instruct the engineering copilot on what code to develop, handle incoming inquiries, update controls as needed, and notify us only when it encounters situations where instructions are unclear or missing, providing recommendations and references when it does.
This may sound like science fiction today, but it’s not as far off as it seems.