In my recent GRC 20/20 Strategy Perspective, Agentic AI in GRC: Pulling Back the Curtain, I explored why much of the current market conversation around agentic AI in GRC is more theater than substance, what real agency requires, and how the next generation of GRC earns Business Confidence through connected context, governed action, and proof.

That report was intentionally direct. The GRC market is filled with bold claims about AI, agents, copilots, autonomous compliance, intelligent risk management, automated assurance, and instant transformation. A few of these claims are real. Most are exaggerated. Many are little more than an eloquent chatbot attached to an aging workflow engine and presented as if the future has arrived.

But the report was not written as an argument against AI. Quite the opposite. AI will and is reshaping GRC. Agentic AI will transform aspects of governance, risk management, compliance, audit, resilience, third-party governance, policy management, and assurance. The warning is not that AI lacks value. The warning is that buyers must distinguish between useful assistance, scripted automation, polished demos, and true governed agency.

The future is coming. In fact, it is already here. But the market needs to be honest about what is changing . . .

A powerful way to understand the moment we are in is to look back at Fifth Avenue in New York City at the beginning of the twentieth century. There is a famous pair of images often used to illustrate technological transformation. In the first, Fifth Avenue in 1900 is filled with horses, carriages, and wagons. The question posed is: Where is the car?

Then comes the second image, Fifth Avenue in 1913. Just thirteen years later, the street is filled with automobiles. The horse has nearly disappeared. The question now is: Where is the horse?

The point is not simply that cars replaced horses. The point is that an entire operating model changed.

In 1900, New York City was built around the horse. The visible street traffic was only the surface layer. Beneath it was a vast infrastructure of stables, feed supply, manure removal, blacksmiths, wheelwrights, harness makers, veterinary services, carriage builders, watering stations, street cleaning, and labor organized around the needs of animal-powered transportation. The city’s transportation architecture was not only what people saw on the street. It was everything required to make that street function.

By 1913, the automobile had not merely added another transportation option. It rearchitected the infrastructure of movement. Streets, fuel, repair shops, manufacturing, traffic rules, parking, supply chains, insurance, financing, licensing, and urban planning all had to adapt. The change was not only in the vehicle. It was in the ecosystem.

That is what is happening in GRC technology right now . . .

The GRC technology market is not in another ordinary product refresh cycle. This is not another generation of dashboards, forms, workflow routing, heat maps, and prettier reports. This is a transformation in the underlying architecture and infrastructure of GRC. The system of roads is changing. The means of motion is changing. The skills required to build, sell, implement, govern, and use GRC technology are changing.

And unlike the transformation from horse to automobile on Fifth Avenue, this shift in GRC architecture will not take thirteen years . . . it will unfold over the next few years.

The GRC Market Has Been Built Around the Horse

For the past two decades, most GRC technology has been built around the system-of-record model. This was necessary. Organizations needed a structured place to document risks, controls, policies, obligations, issues, incidents, vendors, assessments, audits, evidence, and remediation activity. Before GRC platforms, much of this work lived in spreadsheets, email, shared drives, disconnected databases, and heroic manual effort.

The system of record brought order. It helped organizations centralize information, enforce accountability, route tasks, collect attestations, track approvals, document evidence, and report status to management, executives, regulators, and the board. These capabilities mattered then, and they still matter now.

But much of the GRC technology market became comfortable competing on the artifacts of this model, which boiled down to features to support:

• Do you have risk assessments?
• Do you have control testing?
• Do you have issue management?
• Do you have policy attestations?
• Do you have third-party questionnaires?
• Do you have regulatory change workflows?
• Do you have incident management?
• Do you have audit planning?
• Do you have dashboards?
• Do you have reporting?
• Do you have Monte Carlo analysis/risk quantification?

For years, the market rewarded feature expansion. Vendors added modules. Buyers created long RFP checklists. Analysts, consultants, and procurement teams compared capabilities line by line. GRC technology providers competed on whether they had the required functions, how configurable the platform was, how much workflow could be automated, and how quickly reports could be generated.

That model is running out of road.

• Not because systems of record are useless . . . they are not.
• Not because workflow no longer matters . . . it does.
• Not because evidence, controls, reporting, and documentation are going away . . . they are not.

The issue is that these capabilities are no longer enough to define the future of GRC technology. They are increasingly the old infrastructure of the horse-drawn city. Necessary in many environments, but no longer sufficient for where the market is going.

AI Is Collapsing the GRC Feature Advantage

AI is changing the economics of software development. Capabilities that once required months or years of engineering can now be prototyped, tested, refined, and delivered in a fraction of the time. I recently heard a respected head of product say that what once required fifty developers can now be done with five developers and AI. Another firm demonstrated the rapid construction of Monte Carlo capabilities in hours with AI, which took a competitor nearly a year to build without AI.

I am not presenting either example as a universal formula. Every development environment, product architecture, data model, and engineering culture is different. But these examples are signals. AI is collapsing development cycles. It is reducing the barriers to building functionality. It is making feature replication easier.

That matters profoundly for GRC . . .

A traditional relational database GRC feature set built around fields, forms, records, tables, relationships, workflows, and reports can be copied faster than ever before. A risk register can be created. A control testing workflow can be configured. A third-party questionnaire can be built. A policy attestation process can be automated. A dashboard can be generated. A Monte Carlo feature can be added.

This does not mean GRC technology is becoming less important. It means technology differentiation is moving . . .

The future of GRC technology differentiation is not simply whether a platform has a feature. The question is whether the platform has the architecture, intelligence, context, governance, methodology, content, user experience, and orchestration to improve the organization’s GRC program and deliver measurable value.

Buyers should not be impressed by a checklist of features that everyone else can increasingly claim. They should ask deeper questions.

• Does the provider understand our business objectives?
• Does the provider understand our industry and regulatory environment?
• Does the provider understand our operating model?
• Does the provider understand how risk, compliance, controls, resilience, audit, policy, third-party governance, and performance interrelate?
• Does the provider bring experience, content, frameworks, expertise, and leading practices that improve our program?
• Does the provider help us move from fragmented, manual, and document-centric activity to business-integrated GRC?
• Does the provider understand the role of digital twins, semantic ontologies, contextual intelligence, and agentic AI in the future of GRC?
• Does the provider help us reliably achieve objectives, address uncertainty, and act with integrity?

This is where the market is headed. Features are becoming the price of admission. Program improvement is the sale. This was apparent in one RFP I worked on for a global aerospace firm. The final two . . . both of them could meet all the feature requirements. They chose the solution that challenged them and told them we could do it your way, but have you thought of doing it this way and why? That one the sale.

The GRC Buyer Does Not Need Another Better Horse

When the automobile first emerged, many people probably evaluated it through the frame of the horse.

• Is it faster than a horse?
• Is it more reliable than a horse? C
• an it pull the same carriage?
• Can it travel the same roads?
• Can it be managed with the same assumptions?

That is natural. New technology is often first understood through the lens of what it replaces . . .

The same is happening in GRC. Buyers are often evaluating AI-enabled GRC through the lens of traditional GRC technology.

• Does the AI summarize the risk register?
• Does it draft the control narrative?
• Does it write the policy?
• Does it classify obligations?
• Does it generate an issue description?
• Does it produce an executive summary?

These capabilities can be useful. They can save time. They can reduce administrative burden. They can make information more accessible. They can help GRC teams translate technical detail into business language.

But they are not the real transformation . . .

The real transformation is not that the old GRC system speaks more fluently. The real transformation is that the architecture of GRC begins to change from a system that records work to a system that observes, contextualizes, reasons, decides, acts, and learns within defined governance boundaries.

That is the difference between AI assistance and agentic GRC . . .

A chatbot that summarizes a policy is useful. A document assistant that reviews a supplier assurance report is useful. A model that drafts a remediation plan is useful. But useful does not equal agentic. Fluency is not agency. Summarization is not orchestration. Search is not intelligence. Workflow with a better voice is not transformation.

True agentic GRC requires a system that can operate toward an objective, understand context, maintain state over time, use tools with purpose, act within defined boundaries, preserve accountability, escalate when needed, and explain what it did. In a regulated enterprise, it must know when to act, when to recommend, when to stop, and when a human must decide.

That is a much higher standard than “our assistant can summarize a control test.”

From GRC System of Record to System of GRC Orchestration

The old model of GRC technology was primarily a system of record built on a relational database. It captured risks, controls, policies, obligations, issues, incidents, third parties, assessments, audits, and evidence. This will remain important. Organizations need structured accountability. They need records. They need evidence. They need repeatable processes. They need defensible documentation.

But the next generation of GRC technology is a system of orchestration . . .

GRC 7.0 – GRC Orchestrate is about connecting the organization’s objectives, processes, risks, controls, obligations, policies, third parties, assets, services, resilience dependencies, intelligence, actions, decisions, and assurance into a coordinated architecture. It is not simply about documenting what happened. It is about understanding what is happening, what could happen, what matters, who needs to act, what options exist, what evidence supports the decision, and how actions connect to objectives and outcomes.

This requires three connected layers . . .

1. First, the system of record provides the structured foundation. It contains the entities, relationships, workflows, documentation, evidence, and accountability required to manage GRC activity. This is where much of the market has been. It is still relevant, but it is not sufficient.
2. Second, the system of intelligence brings internal and external context into the GRC environment. This includes regulatory intelligence, risk intelligence, third-party intelligence, control intelligence, business intelligence, operational telemetry, horizon scanning, scenario analysis, and analytics. This is where GRC becomes more aware of change, dependency, and context.
3. Third, the system of action brings automation. Where agentic AI enables and brings together decision support, workflow orchestration, continuous monitoring, task execution, escalation, and governed response together. This is where GRC moves beyond documentation into coordinated action.

The future is not one of these layers by itself. The future is their integration . . .

A system of record without intelligence becomes administrative. A system of intelligence without action becomes advisory noise. A system of action without governance becomes dangerous. The next generation of GRC requires all three: record, intelligence, and action connected through architecture, accountability, and proof.

The Market Infrastructure Is Changing

The Fifth Avenue analogy matters because it reminds us that transformation is not limited to the visible object. It is not just the car replacing the horse. It is the entire infrastructure changing around it.

The same is true in GRC technology . . .

The visible change is AI. The deeper change is the transformation of the GRC architecture and operating infrastructure. Buyers should look beyond the visible assistant, the glowing dashboard, the polished demo, and the confident narrative. They should ask what infrastructure supports it.

• What is the underlying data model?
• Is the platform still primarily a set of tables and forms, or does it understand relationships and dependencies?
• Can it connect objectives to risks, risks to controls, controls to obligations, obligations to policies, policies to evidence, evidence to assurance, and assurance to decisions?
• Does it have a semantic layer or ontology that gives meaning to GRC information?
• Can it observe behavior through telemetry and evidence streams, or does it rely only on manual attestations and self-reported records?
• Can it maintain state over time?
• Can it take governed action?
• Can it explain what it did?
• Can it be audited?
• Can it learn without losing control?

These are infrastructure questions. They are the GRC equivalent of asking whether the city has roads, fuel stations, repair shops, traffic rules, and manufacturing capacity. The car is not enough. The ecosystem matters.

This is where many legacy GRC architectures are under pressure . . .

They were designed for a world of centralized records, configurable forms, defined workflows, scheduled assessments, periodic reporting, and human-driven updates. That world is not disappearing overnight. But it is being overtaken by the need for connected context, real-time intelligence, behavioral evidence, digital twins, continuous monitoring, and governed action.

Legacy providers that simply bolt AI onto old architectures will struggle . . .

A chatbot on top of a fragmented system does not make the system agentic. A summarization feature inside an aging workflow engine does not create orchestration. A policy drafting assistant does not solve the deeper challenge of connecting obligations, controls, behavior, evidence, decisions, and outcomes.

The providers that succeed will be those that are fair to the past but honest about the future. Systems of record still matter. Workflow still matters. Evidence still matters. Reporting still matters. But the future requires something more.

Context Is the New Competitive Battlefield

In the old market, the database mattered. In the new market, context matters more.

A relational database is not the enemy . . .

Tables are useful. Records are necessary. Structured data remains essential. But GRC is increasingly a relationship and dependency problem, not simply a table problem . . .

• A table can tell you that a supplier is critical . . . a dependency model can show what happens when that supplier fails.
• A table can tell you that a control is ineffective . . . a connected context model can show which obligation, policy, business process, service, customer commitment, risk appetite statement, executive objective, and assurance conclusion are affected.
• A table can tell you that a regulation changed . . . a semantic GRC architecture can show which obligations changed, which policies need revision, which controls need retesting, which business units are impacted, which third parties are implicated, and which executives need to know.

This is where graph-oriented context, semantic models, ontologies, and digital twins become so important. GRC is not a filing cabinet. It is an operating map of the enterprise. It connects objectives, processes, systems, data, obligations, policies, controls, tests, findings, remediation, resources, decisions, and outcomes.

Without that contextual fabric, AI hovers above fragments. It retrieves text. It summarizes records. It generates plausible answers. It may sound intelligent, but it does not truly understand the operating environment in which GRC decisions are made.

Generic AI gives generic answers. GRC AI needs tenant-specific context. It needs the organization’s policies, controls, objectives, risk appetite, obligations, terminology, evidence, business processes, third parties, systems, services, decision rights, and governance boundaries. It needs scoped context, not a massive indiscriminate dump of documents. It needs to understand the difference between a risk statement, a control procedure, a policy requirement, an audit finding, an issue, an obligation, and a business objective.

Context architecture is the differentiator!

Truth Comes Before Intelligence

There is another issue buyers must not overlook: where does the truth come from?

It is one thing for AI to reason across policies, risk registers, control libraries, questionnaires, audit reports, and attestations. It is another thing to know whether those artifacts reflect reality. Controls do not fail on paper. They fail in behavior. A policy can say one thing while the business does another. A control owner can attest that a control is operating while system telemetry tells a different story. A third party can complete a questionnaire while evidence reveals gaps. A process can look mature in the workflow and fragile in actual execution.

This is one of the most important shifts in the next generation of GRC technology. GRC cannot become truly intelligent by reasoning only over documents and self-reported data.

GRC needs observation . . .

The future of GRC requires a behavioral observation layer. This may include continuous control monitoring, automated evidence collection, identity and access signals, transaction monitoring, system configuration checks, vulnerability data, incident feeds, third-party evidence, process mining, regulatory intelligence, and other forms of machine-verifiable signal. The point is not to collect every possible data point. The point is to connect the right signals to the right objectives, obligations, risks, controls, and decisions.

A thermostat cannot regulate the temperature of a room by reading the building policy on climate comfort. It needs a sensor.

Likewise, GRC cannot become truly intelligent by reading the policy library and risk register alone. It needs signals from the operating environment. It needs evidence that is relevant, contextualized, validated, and tied to objectives.

This does not mean telemetry is truth by magic. Data can be incomplete, biased, stale, noisy, misclassified, or disconnected from business context. Continuous monitoring can create false confidence if it monitors what is easy rather than what is material. But the answer is not less observation. The answer is better observation connected to better context.

In GRC, trust systems start with signals . . .

• The buyer question should NOT be “what can the AI generate?”
• The better question is “what can the system reliably observe, decide, enforce, and prove over time?”

The GRC Professional Services Boundary Is Also Changing

This market transformation is not limited to software vendors. Professional services firms are also being reshaped by AI.

Historically, the GRC ecosystem often separated technology and advisory. Software providers brought the platform. Professional services firms brought methodology, advisory expertise, implementation support, program design, transformation guidance, and client relationships. At times professional service firms built a platform to only divest of it to focus on services. That partnership model still matters, but it is becoming more complicated.

AI makes it easier for professional services firms to productize their intellectual property. They can build applications, workflow layers, assessment tools, analytics, reporting environments, AI agents, and implementation accelerators around their methodologies faster than before. They can wrap technology around their content. They can deliver technology-enabled services. They can blur the line between advisory, managed services, and software.

This means GRC advisor partners may become GRC vendor/solution provider competitors . . .

Boutique firms with deep domain expertise may build focused GRC solutions around specific use cases. Large global firms may develop technology-enabled service platforms that compete with software providers in targeted areas. Advisory firms may use AI to turn frameworks, maturity models, regulatory content, control libraries, and delivery playbooks into repeatable technology assets.

For GRC technology providers, this creates risk and opportunity. The risk is that implementation partners can become competitors. The opportunity is that technology providers can build stronger, more strategic partnerships with firms that bring domain expertise, industry insight, transformation capability, and market trust.

But those partnerships must evolve. They cannot be based only on referral agreements and implementation capacity. They need aligned market strategy, differentiated value, shared understanding of buyer outcomes, and mutual recognition that the market is changing.

For buyers, this shift means more choice, but also more confusion. Some “software” will increasingly look like advisory packaged in technology. Some “services” will increasingly look like software-enabled operating models. The buyer will need to ask: who owns the architecture, who owns the methodology, who owns the content, who owns the data, who governs the AI, and who is accountable when the system acts?

Legacy GRC Providers and New GRC Entrants Both Face Risk

It is tempting to assume that legacy GRC providers are at risk and new entrants are advantaged. The truth is more balanced.

Legacy providers do face significant pressure . . .

Many have deep functionality, large customer bases, broad market presence, and years of implementation experience. But some are built around older assumptions: centralized systems of record, complex configuration, heavy implementation, feature checklists, and incremental product evolution. These assumptions are being challenged by AI-native development, digital twins, semantic architectures, agentic AI, behavioral observation, and the buyer demand for faster time to value.

Legacy providers that only repaint the old house will struggle. Those that simply add AI features to aging architectures may create short-term excitement but long-term disappointment. The market will increasingly distinguish between AI-enabled workflow and real GRC orchestration.

At the same time, new entrants are not guaranteed success . . .

Innovation alone is not enough. A clever product is not enough. A better interface is not enough. A dazzling demo is not enough.

The GRC market is not a generic enterprise software market. It is shaped by regulation, accountability, governance, assurance, risk, trust, professional judgment, organizational politics, and executive concern. Buyers do not simply buy features . . . they buy business confidence.

New entrants need market strategy. They need positioning. They need use-case clarity. They need credibility. They need proof. They need partner strategy. They need to understand the complexity of GRC buying. They need to know where to compete, where to focus, and where to partner.

The market will reward both established providers and new entrants that can show substance. It will punish both established providers and new entrants that rely on theater.

What GRC Buyers Should Be Asking

The buyer’s job is not to be dazzled by the face on the screen. It is to ask what is behind the curtain.

When a provider claims to have agentic AI, buyers should ask what that means in practical terms . . .

• What can the system actually do?
• What actions can it take?
• What decisions can it support?
• What evidence does it use?
• What tools can it invoke?
• What permissions govern it?
• What happens when evidence conflicts?
• What happens when the AI is wrong?
• What gets logged?
• What can be audited?
• What can be rolled back?
• What is in production, and what is still roadmap?

Buyers should ask to see the work . . .

• Do not show me a summarized policy and call it governance.
• Do not show me a chatbot answering questions and call it agency.
• Do not show me a dashboard and call it intelligence.
• Do not show me a workflow with prettier language and call it orchestration.
• Do not show me a protocol diagram and call it proof.

• Show me how the system observes signals.
• Show me how it connects those signals to objectives.
• Show me how it understands dependencies.
• Show me how it distinguishes weak evidence from strong evidence.
• Show me how it selects tools.
• Show me how it maintains state.
• Show me how it compares options.
• Show me how it escalates.
• Show me how it asks for human approval.
• Show me how it logs actions.
• Show me how it learns from outcomes.
• Show me how it helps the organization make a better decision than it would have made otherwise.

That is the GRC buyer’s refrain: show me the work.

The Balanced View: Warning and Opportunity

The warning is real. AI can create false confidence. It can make weak architectures look modern. It can make shallow workflows sound intelligent. It can make old processes run faster without making them better. It can produce polished language that disguises poor evidence, weak context, and disconnected accountability.

A weak GRC process with AI can feel more mature than it is. The reports improve. The summaries improve. The interface improves. The language improves. But the organization may still lack connected context, behavioral evidence, defensible decisions, and accountable action.

That is the danger . . . But the opportunity is equally real . . .

When done properly, AI can reduce administrative burden. It can accelerate evidence review. It can identify patterns. It can improve consistency. It can brief leaders. It can support investigations. It can help compliance teams connect obligations to operational behavior. It can help risk teams spend less time chasing artifacts and more time advising the business. It can help audit teams understand evidence trails and control history. It can help executives understand what matters now. It can help boards gain confidence because conclusions are tied to signals, relationships, evidence, actions, and accountability.

The future is not simply headcount reduction. That is too narrow and too shallow. The future is expertise reallocation. Scarce GRC expertise should move away from repetitive administration, evidence chasing, document reconciliation, and manual coordination toward scenario analysis, advisory work, control improvement, resilience planning, assurance quality, and better decision support.

The goal is not to purchase AI. The goal is to improve how the organization is governed. AI is a means. Orchestration is a mechanism. Business Confidence is the outcome.

The Fifth Avenue Moment for GRC

The GRC market is standing on Fifth Avenue . . .

In one direction, you can still see the old infrastructure: systems of record, workflows, forms, dashboards, heat maps, attestations, questionnaires, manual evidence requests, and periodic reporting. These will not disappear immediately. They still have value. They still support important accountability. They are still embedded in organizations.

But look closely at the street . . .The automobile is already here . . .

Agentic AI, digital twins, semantic ontologies, knowledge graphs, continuous controls monitoring, behavioral observation, contextual intelligence, governed automation, and systems of action are beginning to rewrite the movement of GRC. The change is not simply in the visible tool. The infrastructure around the tool is changing.

The question for buyers is not whether they should abandon everything they have . . the question is whether their GRC architecture can evolve . . .

• Can it move from static records to connected context?
• Can it move from self-reported artifacts to observed evidence?
• Can it move from workflow automation to governed action?
• Can it move from dashboards to decision support?
• Can it move from administrative GRC to business-integrated GRC?

The question for providers is equally direct. Are you building the future, or are you putting a more eloquent face on the past?

The 1900 street did not know how quickly it would change. The infrastructure of the horse looked permanent because it was everywhere. But permanence is often an illusion created by familiarity.

GRC technology is now in that kind of moment.

The market will adapt. Buyers will adapt. Providers will adapt. Professional services firms will adapt. But the architecture and infrastructure of GRC are undergoing a significant transformation. It will not take thirteen years between pictures. It will happen in just a few years.

Some will still be asking, “Where is the car?” . . .Others will soon be asking, “Where is the horse?”

The organizations that succeed will not chase AI theater. They will build and buy GRC technology that provides connected context, grounded intelligence, governed action, evidence, accountability, and proof. They will demand architecture, not adjectives. They will insist that AI supports the purpose of GRC: to reliably achieve objectives, address uncertainty, and act with integrity.

That is the future explored in Agentic AI in GRC: Pulling Back the Curtain. The curtain is being pulled back. The market is changing. Buyers should be ambitious, but also demanding. The future of GRC should not be built around illusion. It should be built around proof.

The next phase of AI in GRC is not a better wizard. It is better machinery.

Last week, I wrote about the Wizard of Oz problem in the current agentic AI conversation in governance, risk management, and compliance in Pay No Attention to the GRC AI Behind the Curtain. The market is full of booming voices, green lights, theatrical demos, confident claims, and promises of autonomous assurance, intelligent orchestration, and instant transformation. The message was simple: do not be dazzled by the AI spectacle. Pull back the curtain.

When you do, too often you find a familiar machine. A workflow engine. A chatbot. A retrieval layer. A few prompts. Some scripted API calls. A dashboard with better language. A forms-and-workflow platform dressed up in the language of agency.

That is not agentic AI. That is theater.

But pulling back the curtain is only the beginning. The more important question is what should be behind the curtain if the market is serious about the next generation of GRC technology and architecture.

The answer is not a louder wizard. It is not a more fluent chatbot. It is not a more polished demo. It is not a generative AI assistant that can summarize a policy, draft a control narrative, or explain a regulatory change in executive language. Those capabilities can be useful, and in many cases they deliver real productivity gains. But they do not, by themselves, transform GRC.

The next generation of GRC requires something more substantial. It requires connected context. It requires a dependency-aware architecture. It requires systems that can observe, model, compare, decide, act, and prove. It requires deterministic, explainable, reproducible decision support where the organization must make choices under real constraints.

In other words, AI for GRC must become part of a decision system.

GRC Is a Dependency Problem, Not a Table Problem

For decades, GRC technology has largely been organized around records and workflows. A risk is entered into a register. A control is documented. A policy is published. An issue is created. A third party is assessed. An obligation is mapped. A task is assigned. A report is generated.

This architecture brought order to chaos. It helped organizations move beyond spreadsheets, email, shared drives, and heroic manual effort. It created accountability, repeatability, documentation, evidence, approvals, and reporting. Those things still matter.

But the core problem of GRC was never simply the lack of tables. It was never simply the absence of records. Nor that the organization needed a better place to store risks, controls, policies, issues, and assessments.

The real problem is relationships.

GRC is a dependency problem. Objectives depend on processes. Processes depend on systems. Systems depend on data. Data depends on controls. Controls depend on people, procedures, configurations, access rights, and evidence. Business services depend on third parties. Third parties depend on subcontractors, geographies, infrastructure, financial viability, cybersecurity posture, and operational resilience. Regulations create obligations. Obligations shape policies. Policies require controls. Controls influence behavior. Failures cascade.

• A table can tell me that a supplier is critical . . . A dependency model can show me what happens when that supplier fails.
• A table can tell me that a control is ineffective . . . A dependency model can show me which business service, regulatory obligation, customer commitment, operational process, and executive objective are exposed.
• A table can tell me that a system is down . . . A dependency model can show me what decisions must be made, which recovery options are constrained, which third parties are involved, which controls are bypassed, which obligations are triggered, and which business outcomes are at risk.

That is the architectural shift. GRC is not a filing cabinet. It is an operating map of the enterprise.

This is why the next generation of GRC technology cannot be built around disconnected modules with AI decoration. The market does not need another risk module with a chatbot. It does not need another compliance module with a summarization button. Nor does it need another third-party risk workflow that can generate a nicer email.

The market needs an enterprise service-and-dependency model that maps relationships across objectives, processes, systems, services, data, controls, obligations, third parties, incidents, issues, and decisions. It needs to make cascades visible before everyone is guessing. It needs to move GRC from static administration to dynamic understanding.

This is where AI becomes meaningful. Not because it can produce fluent answers, but because it can help the organization understand relationships, identify weak signals, model consequences, and support decisions in context.

Fluency Is Not Agency

One of the greatest mistakes in the current AI cycle is the belief that a system that speaks well must therefore understand well.

Large language models are remarkable. They can summarize, classify, translate, draft, explain, and synthesize. They can take a dense regulation and produce an executive summary. They can review a policy and suggest improvements. They can summarize an audit finding. They can help a control owner understand evidence requirements. They can make GRC knowledge more accessible across the enterprise.

That is valuable. It is not agency.

A fluent answer is not the same as a defensible decision. A well-written recommendation is not the same as a validated course of action. A confident paragraph is not the same as a model that has compared constraints, dependencies, evidence quality, recovery options, business priorities, regulatory obligations, and operational feasibility.

In GRC, the difference matters because the work has consequences. Consider . . .

• A system that writes a remediation plan may save time. A system that understands whether the remediation plan will actually reduce exposure, fit available resources, meet regulatory commitments, preserve business continuity, and avoid creating new dependencies is doing something very different.
• A system that summarizes a supplier report may improve productivity. A system that understands how that supplier supports a critical service, what data it handles, what subcontractors it relies on, what obligations apply, what controls are missing, and what alternative suppliers exist is doing something very different.
• A system that answers questions about a policy may help employees. A system that observes behavior, detects drift from policy, connects that drift to control failures, escalates exceptions, and supports accountable decisions is doing something very different.
• This is why the market needs a sharper vocabulary. Assistive AI is useful. Generative AI is useful. Search is useful. Summarization is useful. Workflow automation is useful. But assistance is not agency. Automation is not intelligence. Fluency is not decision capability.

If the AI cannot show what it observed, what context it used, what options it considered, what constraints applied, what assumptions were made, what action was permitted, what human approval was required, and what outcome followed, then buyers should be cautious.

The standard remains simple: show me the work.

From Systems of GRC Record to Systems of GRC Orchestration

Historically, GRC technology from GRC 1.0 through GRC 6.0 has been built primarily as a system of record. The underlying architecture has largely been relational databases, structured forms, tables, records, workflows, and reports. A risk was a record. A control was a record. A policy was a document. An obligation was mapped to a control. A third party was assessed through a questionnaire. An issue was opened, assigned, tracked, and closed. The system’s purpose was to document, organize, route, evidence, and report on GRC activity.

That architecture was necessary. It brought structure to what had too often been managed through spreadsheets, email, shared drives, and fragmented departmental processes. It created accountability. It supported repeatability. It helped organizations maintain evidence, manage approvals, document decisions, and produce defensible reports. Systems of record still matter, and they will continue to matter in GRC 7.0.

But in GRC 7.0, the system of record is no longer the center of gravity.

The shift at the core of GRC is from systems of record to systems of orchestration. GRC 7.0 – GRC Orchestrate is not simply about storing more records, adding more workflow, or generating more reports. It is about coordinating intelligence, context, decisions, and action across the enterprise. It is about understanding how objectives, risks, controls, obligations, policies, processes, systems, services, third parties, evidence, issues, incidents, and decisions connect. It is about moving from static documentation to dynamic enterprise coordination.

At the center of this orchestration architecture are two essential subsystems:

1. The first is a system of intelligence. This is where agentic AI and other analytical capabilities gather information, interpret signals, connect context, and make sense of what is happening across the organization. It draws from other business systems, documents, policies, regulations, controls, evidence, telemetry, incidents, third-party data, system logs, business process information, and external intelligence. But its purpose is not merely to summarize information. Its purpose is to understand relationships, identify patterns, surface weak signals, detect gaps, explain context, and support decision-making. Contextualizing information is critical.
2. The second is a system of action. This is where autonomous or semi-autonomous capabilities move beyond insight into governed execution. A system of action can initiate a process, request evidence, assign a task, create a finding, escalate an exception, update a record, recommend remediation, trigger a review, or execute a defined action within approved boundaries. But in GRC, action must always be governed action. It requires permissions, approvals, audit trails, segregation of duties, policy constraints, human oversight, exception handling, and evidence of what was done and why.

This is the architectural distinction that matters. A system of intelligence helps the organization understand. A system of action helps the organization respond. A system of orchestration coordinates both so that GRC becomes more than documentation and workflow. It becomes an enterprise capability for observing the business, understanding dependencies, comparing options, making decisions, taking accountable action, and learning from outcomes.

This is why GRC 7.0 is not simply another phase of feature expansion. It is a shift in the core model of GRC technology. The relational database and the system of record were important foundations, but they are no longer sufficient. The future of GRC requires orchestration across connected context, intelligent interpretation, and governed action.

That is where agentic AI becomes meaningful. Not as a chatbot attached to a legacy workflow engine. Not as a fluent assistant generating polished text. Not as a magical interface layered over disconnected records. Agentic AI becomes meaningful when it operates within a system of orchestration that can gather information, understand context, maintain state, use tools, respect governance boundaries, take or recommend action, and prove the work.

This is the move from GRC as administration to GRC as orchestration. It is the move from managing artifacts to coordinating decisions. It is the move from recording what happened to helping the organization decide what should happen next.

But action in GRC is not merely execution. It is accountable execution.

This is where many AI claims become thin. It is easy to show an assistant that recommends a task. It is harder to show a system that can safely operate as a governed participant in GRC work. Governed action requires permissions, approvals, segregation of duties, audit trails, rollback, exception handling, evidence lineage, policy boundaries, model evaluation, performance monitoring, and human accountability.

It also requires comparison. A language model can propose options. But comparing options often requires structured data, quantification, optimization, scenario analysis, constraints, risk appetite, cost, timing, resources, operational feasibility, and outcome evidence.

This is where the real architecture of GRC AI becomes more interesting than the demo. The future is not one magical model answering every question. The future is an architecture in which different capabilities do different jobs. Such as . . .

• Language models help with interaction, summarization, explanation, classification, drafting, and translation between technical and business language.
• Machine learning and statistical analytics help with pattern detection, anomaly identification, signal interpretation, and predictive indicators where sufficient quality data exists.
• Knowledge graphs and ontologies help connect relationships across objectives, obligations, risks, controls, processes, systems, third parties, evidence, and decisions.
• Rules engines and deterministic logic enforce non-negotiable requirements, policy boundaries, approvals, and segregation of duties.
• Optimization models help compare response options, sequence recovery, allocate resources, and choose the best available path under constraints.
• Human judgment remains essential for accountability, interpretation, challenge, ethics, policy ownership, and final decisions where consequences require human responsibility.

That is not theater. That is architecture.

Absolutely — this version avoids Expose, Model, Optimize as a named structure, shifts the phrase to Enterprise Risk & Resilience Decision System, and frames it more in your GRC 7.0 – GRC Orchestrate language. 🟢

The Enterprise Risk & Resilience Decision System

A useful way to frame the next generation of GRC is the Enterprise Risk & Resilience Decision System. This is not simply another module. It is not a dashboard. It is not a chatbot. It is not a document repository with AI search. It is an operating architecture that helps the organization understand risk and resilience in context, evaluate choices under real-world constraints, and support accountable action across the enterprise.

The Enterprise Risk & Resilience Decision System is an expression of GRC 7.0 – GRC Orchestrate. It moves GRC beyond the historical system-of-record model that defined GRC 1.0 through GRC 6.0. Those earlier generations were largely built on relational databases, structured records, forms, workflows, and reports. They documented risks, controls, obligations, policies, issues, incidents, third parties, and assessments. That foundation remains important. Organizations still need evidence, accountability, approvals, records, and reporting.

But the center of gravity changes in GRC 7.0. The core is no longer the record. The core is orchestration.

At the heart of this orchestration is a decision architecture that connects risk and resilience to the operating reality of the business. It maps how objectives depend on processes, how processes depend on systems, how systems depend on data, how services depend on third parties, how controls depend on evidence, how obligations constrain action, and how failures cascade across the enterprise. It moves the organization from isolated inventories to a living model of operational dependencies.

This matters because risk and resilience decisions are not made in a vacuum. When disruption occurs, organizations do not operate with unlimited time, unlimited staff, unlimited budget, unlimited technology capacity, and perfect information. They operate under constraints. Some systems must be restored before others. Some services are more critical than others. Some teams are overloaded. Some facilities are unavailable. Some third parties are delayed. Some controls cannot be bypassed. Some regulatory obligations cannot be ignored. Some customer commitments have priority. Some recovery actions reduce risk in one area while creating exposure in another.

A true Enterprise Risk & Resilience Decision System helps the organization understand these relationships before decisions are made. It provides visibility into dependencies, context for consequences, and decision support for action. It asks: what is connected, what is exposed, what choices exist, what constraints apply, what trade-offs matter, and what action is defensible?

Consider recovery optimization as an example of what real GRC AI should look like. Recovery Optimization should not be a fluent paragraph saying, “restore the most critical services first.” That is obvious. The real question is how to sequence recovery when criticality, dependency, capacity, time, resource availability, contractual obligations, regulatory requirements, control implications, and business impact all collide.

That is not a job for a chatbot. That is a job for decision intelligence supported by optimization.

Constraint programming and linear programming can help sequence recovery under real operational constraints. They can evaluate what is possible, not merely what sounds good. They can compare alternatives. They can show why one recovery sequence is better than another. They can identify bottlenecks. They can expose infeasible assumptions. They can help the organization understand trade-offs between resilience, compliance, cost, timing, capacity, and impact.

Most importantly, this type of decision support can be deterministic, explainable, and reproducible.

That matters in GRC. A recovery decision cannot be based on a mysterious answer from a black box. Leaders need to understand the assumptions, constraints, priorities, dependencies, and trade-offs behind the recommendation. Risk, compliance, audit, legal, security, operations, technology, and executive management need to be able to challenge the model, review the evidence, and understand the basis for action.

This is what “show me the work” looks like in practice.

• Show me the dependencies.
• Show me the constraints.
• Show me the recovery options considered.
• Show me the decision criteria.
• Show me the rejected paths and why they were rejected.
• Show me what assumptions changed the recommendation.
• Show me what evidence supported the decision.
• Show me where human approval was required.
• Show me what was logged.
• Show me what happened after the decision.
• Show me what the system learned.

This is the difference between AI that describes risk and resilience and AI that helps manage risk and resilience. It is the difference between an assistant that can produce language and a decision system that can support action. It is the difference between GRC as documentation and GRC as orchestration.

The Enterprise Risk & Resilience Decision System is where GRC 7.0 becomes practical. It combines a system of intelligence that gathers information, interprets signals, and makes sense of context with a system of action that supports autonomous or semi-autonomous activity within defined governance boundaries. Together, these subsystems allow GRC to move from recording what happened to helping the organization decide what should happen next, act within constraints, and prove why the action was taken.

The Yellow Brick Road Has to Lead Somewhere

The Wizard of Oz metaphor works because the market has created so much spectacle. But the more useful part of the story is not only the curtain. It is the journey.

The yellow brick road is full of promises. Follow this path and you will get intelligence. Follow this path and you will get assurance. Follow this path and you will get autonomy. Follow this path and all the hard work of GRC will become easier.

But the road has to lead somewhere real.

If the road leads only to a louder wizard, buyers will be disappointed. If it leads to another generation of disconnected modules with AI-generated language, the market will have missed the point. If it leads to faster production of weak artifacts, organizations will simply do the wrong things more quickly and with more confidence.

The road has to lead to better decisions.

That is the purpose of GRC. Not maintaining artifacts. Not producing dashboards. Not generating reports. Not filling repositories. Not checking boxes. GRC exists to help the organization set and achieve objectives, address uncertainty, and act with integrity.

AI must be judged against that purpose . . .

• Does it help the organization understand what matters?
• Does it connect obligations, risks, controls, evidence, and actions to objectives?
• Does it reveal dependencies before they become surprises?
• Does it distinguish strong evidence from weak evidence?
• Does it compare choices?
• Does it support action within governance boundaries?
• Does it improve decisions?
• Does it preserve accountability?
• Does it prove what happened?

These are the questions that move the conversation beyond theater.

The Brain, the Heart, and the Courage of GRC AI

If the Wizard of Oz metaphor continues, then perhaps the next phase of GRC AI needs three things: a brain, a heart, and courage.

• The brain is connected intelligence. It is the ability to understand relationships, dependencies, context, signals, evidence, patterns, and consequences. It is not merely the ability to generate text. It is the ability to reason across a model of the enterprise.
• The heart is purpose and integrity. GRC technology must stay anchored to business objectives, accountability, ethical conduct, regulatory obligations, customer commitments, and the organization’s values. Intelligence without integrity is dangerous. Automation without accountability is reckless. Efficiency without purpose simply accelerates confusion.
• The courage is governed action. It is easy to summarize. It is harder to act. It is easy to recommend. It is harder to compare options and take accountable steps within defined boundaries. It is easy to demo intelligence. It is harder to expose the machinery to scrutiny.

This is where the market must mature. Vendors need the courage to be precise about what their AI does and does not do. Buyers need the courage to challenge vague claims. Boards and executives need the courage to demand proof before trusting AI-enabled systems with decisions that affect resilience, compliance, control, performance, and integrity.

The next generation of GRC will not be built by pretending that every assistant is an agent. It will be built by showing how intelligence becomes accountable action.

Business Confidence Comes From Proof

The outcome of all of this should be Business Confidence.

Business Confidence is not blind trust that everything is fine. It is not a dashboard ritual. It is not a green indicator that no one can explain. It is not the absence of risk. It is the confidence that leaders have enough relevant, reliable, contextualized information to make better decisions.

Business Confidence comes when the organization can see the signals, understand the relationships, evaluate the options, act within boundaries, and prove the outcome.

This is where agentic AI in GRC has real promise. It can scale scarce expertise. It can reduce administrative friction. It can help risk and compliance teams spend less time chasing evidence and more time advising the business. It can help audit teams understand evidence lineage. It can help executives receive briefings tied to objectives and decisions rather than static reports. It can help boards understand not only what is red, amber, or green, but what those indicators mean in context.

But Business Confidence does not come from AI language alone. It comes from connected context, ground truth, governed action, optimization, accountability, and evidence.

The future of GRC technology will be shaped by this distinction. Providers that merely attach AI to legacy workflow will have a story, but not a strategy. Providers that build dependency-aware, decision-capable, governed architectures will define the next era.

This is why architecture is becoming more important than features. AI is already changing the economics of software development. Features that once took months or years to build can increasingly be prototyped in days or weeks. That does not eliminate the need for product discipline, validation, security, usability, governance, and support. But it does mean that feature breadth alone will become less defensible.

When everyone can build features faster, differentiation moves to context, architecture, expertise, trust, and outcomes.

The question is no longer simply whether a GRC platform can do something. The question is whether it can help the client do it well.

• Can it represent the enterprise as a connected system?
• Can it support decisions, not just records?
• Can it observe behavior, not just collect attestations?
• Can it model dependencies, not just store objects?
• Can it optimize action, not just route tasks?
• Can it prove its work, not just produce fluent language?

That is where the future of GRC technology is going.

Do Not Ask for a Better Curtain

The market does not need a better curtain. It does not need more smoke, brighter lights, or a louder voice from the Emerald City. It does not need AI slogans stitched into legacy workflows. It does not need every chatbot renamed as an agent.

The market needs substance.

• It needs enterprise service-and-dependency models that make cascades visible.
• It needs systems of action that operate within governance boundaries.
• It needs decision systems that expose, model, and optimize.
• It needs deterministic optimization where deterministic optimization is the right tool.
• It needs language models where language models are the right tool.
• It needs human judgment where human judgment is required.
• It needs auditability, explainability, accountability, and proof.

Last week, in my blog article, the message was to pull back the curtain. This week, the message is to inspect the machinery.

When a vendor says it has agentic AI, ask what the system can observe. Ask what it knows. Ask what it can model. Ask what decisions it can support. Ask what actions it can take. Ask what constraints it understands. Ask what is deterministic, what is probabilistic, what is generative, what is optimized, and what is governed. Ask what is in production and what is roadmap poetry. Ask how it proves that the organization made a better decision than it otherwise would have made.

• Do not accept fluency as agency.
• Do not accept automation as intelligence.
• Do not accept workflow decoration as transformation.
• Do not accept the wizard’s voice when what the enterprise needs is a working decision system.

The future of GRC AI is not the illusion of magic. It is the discipline of architecture. It is the ability to connect context, understand dependencies, compare choices, govern action, and prove outcomes.

That is how GRC moves from theater to trust. That is how AI becomes useful. That is how organizations gain Business Confidence.

Why I am drawing a line in the sand on “agentic AI” in GRC

Below is a blog based on my soon to be published (next week) market research paper which is a Strategy Perspective called “Agentic AI in GRC: Pulling Back the Curtain.” Clients of GRC 20/20 Research can request to get an early copy of the draft before it is published to review.

There is a famous moment in The Wizard of Oz when Dorothy and her companions finally discover that the great and powerful Oz is not quite what he claims to be. The voice is booming. The fire is dramatic. The room is filled with spectacle, authority, and fear. Then Toto pulls back the curtain and there he is: a man at the controls, pulling levers, creating the illusion of something far more powerful than what is actually there.

That, increasingly, is how I feel about much of the “agentic AI” conversation in GRC.

The market is full of smoke, mirrors, flames, booming voices, and green-tinted lighting. Every vendor now seems to have agents, copilots, autonomous workflows, AI orchestration, intelligent automation, next-generation reasoning, and some magical path to automated assurance. The demos are polished. The language is confident. The roadmaps sound like they were written somewhere between Silicon Valley and the Emerald City. But when you pull back the curtain, too often what you find is not real agency. It is a chatbot. It is prompt-based assistance. It is retrieval-augmented generation. It is a workflow rule with a large language model draped over it like a theatrical costume.

That is not agentic AI. That is theater. And in some . . . many . . . cases, it is dangerously close to a lie.

I want to be clear: I am not anti-AI. Quite the opposite. I believe AI has tremendous potential in governance, risk management, and compliance. It can help summarize complex information, review documents, classify risks, analyze third-party evidence, draft policies, support investigations, and make scarce GRC expertise more scalable. It can help reduce the administrative sludge that too often buries talented risk and compliance professionals under a mountain of forms, attestations, spreadsheets, and follow-up emails. Used properly, AI can help GRC move closer to its true purpose: helping organizations set and achieve objectives, make better decisions amid uncertainty, and act with integrity.

But that is exactly why the language matters. If everything is called agentic, then nothing is. If every chatbot is an agent, every automated workflow is orchestration, and every AI-generated paragraph is intelligence, then buyers are being led down a yellow brick road that ends in disappointment. There is nothing wrong with assistive AI. In many cases, assistive AI is precisely what organizations need. The problem is calling assistance agency.

The yellow brick road to agentic confusion

Here is my line in the sand: if a system cannot understand context, choose tools, manage state, take governed action, and explain what it did, it is not truly agentic.

That does not mean it has no value. A policy drafting assistant can be valuable. A control summary tool can be valuable. A regulatory Q&A interface can be valuable. A third-party document review assistant can be very valuable. But value does not automatically equal agency. A calculator is valuable. A filing cabinet is valuable. A search engine is valuable. We do not call them agents simply because they help us do work.

Real agency requires something more demanding. An agent operates toward an objective in an environment. It must understand enough of the environment to know what matters, what tools are available, what constraints apply, what actions are permitted, and what steps should come next. In GRC, this becomes even more demanding because the environment is not a video game or a consumer app. It is a regulated, permissioned, audited, accountability-heavy operating model involving policies, risks, controls, obligations, issues, evidence, third parties, incidents, assets, business services, and objectives.

A real agent in GRC cannot simply produce a plausible answer. It has to work within the governance of the organization. It has to know when to act, when to ask, when to escalate, and when to stop. It has to respect permissions, segregation of duties, approvals, audit trails, human oversight, and the boundaries of policy. In other words, the great and powerful AI must itself be governed.

The 13 questions that pull back the curtain

I am publishing the deeper Strategy Perspective on this topic, but the practical buyer test starts here. When a vendor claims to have agentic AI in GRC, do not simply admire the Emerald City. Pull back the curtain. Ask the questions that reveal whether there is real machinery, real architecture, real governance, and real action behind the show.

1. How do you define agentic AI in your platform? This is the first test because many vendors use the phrase as if assistants, copilots, bots, workflow automation, orchestration, and agents are all interchangeable. They are not. I want to know where the system is assistive, where it is deterministic, where it has discretion, where it can act, and where the human remains in control. If the vendor cannot define the term clearly, then the term is probably doing more marketing work than technical work.
2. What autonomous actions can the system actually take? Can the system initiate a process, request evidence, create a finding, update a record, assign a task, route an issue, trigger a review, or follow up on an exception? Or does it simply generate recommendations and wait for a human to do the work? Recommendations are useful, but there is a world of difference between a system that helps a user think and a system that operates as a governed participant in a process.
3. How does the agent decide what to do next? This question reveals whether there is a real planning layer. Can the system decompose a goal into steps, evaluate intermediate outcomes, re-plan when information is missing, and determine when it has enough evidence to proceed? Or is it simply walking through a pre-designed workflow with a little language generation attached? If the path is fixed and the AI is only narrating the journey, then the wizard is back there pulling the same old levers.
4. How does tool use actually work? Everyone now says their AI uses tools. Fine. Which tools? Selected how? Sequenced how? Governed how? A real agent should be able to choose among internal functions, APIs, knowledge sources, external systems, and platform actions based on the context of the work. If tool use is just a hard-coded demo path, then it is not much different from an old workflow script wearing a shiny hat.
5. What is your approach to MCP? MCP may be useful infrastructure, especially for interoperability. But MCP is not proof of agency. A better pipe does not make the water clean. Buyers should ask whether MCP is being used to support governed tool discovery and action, or whether it is just a fashionable wrapper over weak APIs and disconnected legacy architecture. The issue is not whether a vendor can say “MCP.” The issue is whether the platform has the context, permissions, auditability, and action fabric underneath it.
6. What memory model does the system use? GRC work unfolds over time. Issues remain open. Remediation stalls. Evidence arrives late. Obligations change. Incidents branch into investigations. Vendors move through lifecycle stages. Controls fail, get retested, and sometimes fail again. If the AI cannot maintain state across that messy reality, then it is not operating in enterprise GRC. It is simply re-running inference against the latest prompt and pretending it remembers the journey.
7. Does the AI understand the connected data model? This may be the most important architectural question. GRC is not a pile of disconnected records. It is a web of relationships among objectives, risks, controls, policies, obligations, assets, processes, third parties, evidence, incidents, findings, and actions. A real agent must be able to reason across those relationships. If it cannot trace how a regulatory change affects an obligation, how that obligation maps to policy, how policy maps to control, how control failure affects a business service, and how that impacts objectives, then it is hovering above fragments rather than understanding the enterprise.
8. Where does deterministic workflow end and AI-driven orchestration begin? Traditional GRC platforms have long had workflow engines, triggers, routing, approvals, and rules. There is no need to rebrand those capabilities as agentic when they are doing what they have always done. Buyers should ask what is fixed, what is adaptive, what is rules-based, what is inferred, what is governed by policy, and what is genuinely orchestrated across context. If nearly everything remains pre-scripted, the AI is probably decorative rather than foundational.
9. What governance guardrails exist for action-taking AI? This is non-negotiable. In GRC, the goal is not uncontrolled autonomy. The goal is governed agency. That means permissions, approvals, review thresholds, exception handling, audit logs, rollback, segregation of duties, policy enforcement, and explicit boundaries on what the agent can and cannot do. An AI system that can take action without serious governance is not innovation. It is risk wrapped in marketing language.
10. How are decisions explained, monitored, and audited? If the AI recommends action, takes action, or influences a control environment, the organization needs to know what happened. What context did it use? What data did it rely on? What tools did it invoke? Why did it make the recommendation? Who approved it? What changed? A black box in GRC is not a breakthrough. It is a future audit issue waiting patiently for someone to discover it.
11. What is the underlying AI and orchestration architecture? At some point, buyers have to move past the stage show and look at the machinery. What models are being used? How is context selected? How is state stored? How are tools registered and governed? How are permissions enforced? What is production today, and what is roadmap poetry? A vendor that has truly built agentic architecture should be willing and able to explain the controls behind the curtain.
12. Can customers configure agents, or only consume canned AI features? Every organization has its own objectives, risk appetite, policies, controls, terminology, operating model, and accountability structure. Can the customer define goals, permissions, escalation points, action scopes, review thresholds, memory boundaries, and success criteria? Or is the buyer merely getting a few pre-packaged tricks with a conversational interface? Real value comes when AI can be shaped around the organization’s own context, not forced into generic wizardry.
13. What production use cases prove this is real? This is where the curtain comes down. Show me where the agent has worked through a multi-step GRC process in production. Show me how it gathered information, interpreted context, used tools, managed dependencies, handled exceptions, escalated appropriately, maintained auditability, and delivered measurable value. Do not show me summarization and call it agency. Do not show me drafting and call it autonomy. Do not show me search with a pleasant interface and call it orchestration . . . Show me the work!

The future is not a louder wizard

The next generation of GRC will not be defined by whoever has the loudest AI claims or the most theatrical demo. It will be defined by platforms that can connect context, intelligence, action, and accountability in a way that helps organizations make better decisions. That requires more than an LLM. Large language models are powerful interaction and productivity engines, but GRC also needs validation, comparison, deterministic checks, control evidence, behavioral observation, human judgment, risk quantification, optimization, and governed execution.

The future is not one magical model answering every question from behind a curtain. The future is an architecture where different capabilities do different jobs: language models for interaction and explanation, machine learning for pattern detection, knowledge graphs for connected context, deterministic rules for policy enforcement, telemetry for ground truth, optimization for improving action, and human oversight for accountability.

That may not be as theatrical as the booming voice of Oz, but it is far more useful.

GRC at its best is not about paperwork, dashboards, or risk registers. It is about helping the organization set and achieve objectives, navigate uncertainty, make better decisions, and act with integrity. AI can help us get there, but only if we stop confusing the performance of intelligence with the architecture of intelligence.

The market has had enough theater. It is time to pull back the curtain.

And when we do, the question is simple: has the vendor built a new brain for GRC, or merely placed a more eloquent face on an aging workflow machine? Because a lot of what is being sold today as agentic AI is not the future. It is the old machine, painted green, booming through a microphone, hoping no one notices the person behind the curtain.

Risk is boring. And that is our fault.

That was the provocation at the heart of my session this morning at Risk-in conference in Zurich today, where I had the honor of sharing the stage and co-presenting with my good friend, risk collaborator, and fellow provocateur Stefan Gershater. The session, “Value-Based Risk Management: From Noise to Decision Advantage,” was not about polishing the traditional language of risk management. It was about challenging it.

Too much risk management today creates activity, not advantage. It creates registers, workshops, heat maps, assurance routines, policy attestations, and management reports. Some of these things are necessary. Some are useful. But too often they are disconnected from what the business is actually trying to achieve. They satisfy process requirements without improving decisions. They document uncertainty without helping leaders navigate it. They produce artifacts that risk teams can point to, but not outcomes that executives value.

And that is the problem.

If the CEO, COO, CFO, or other senior leaders are not giving risk leaders time in their diaries, it may not be because they do not care about risk. It may be because risk has been presented to them as a long list of scary things that might happen, organized into the three famous colors of red, amber, and green, accompanied by the promise that the list will be updated before year-end. That is not a leadership conversation. That is administrative noise.

Executives do not wake up in the morning excited to discuss whether the risk register is up to date. They care about growth. They care about performance. They care about execution. They care about protecting what has been built and expanding what is possible. They care about whether the organization will deliver on its objectives, whether it will seize the right opportunities, whether it will avoid catastrophic missteps, and whether it can act with confidence in the face of uncertainty.

That is where risk management must evolve. Risk management should not be the handbrake on the business. It should be the navigation system that helps the business move forward, steer through uncertainty, and achieve its objectives.

Risk Is Our Business

I opened the session with a familiar theme from my work and podcasts: Risk is our business. It comes from one of my favorite moments in the original Star Trek series, when Captain Kirk declares, “Risk is our business.” That line captures something too many organizations forget. Every organization is, in its own way, a starship of risk. It exists to pursue objectives in uncertain environments. It moves toward opportunity while facing disruption, constraint, competition, regulation, operational fragility, and change.

The business of not taking risk is the business that is out of business.

The question is not whether the organization takes risk. It already does. The question is whether it takes the right risks, in the right context, with the right intelligence, controls, resilience, and confidence. The question is whether risk management is helping the organization understand the road ahead or merely documenting the potholes already passed in the rearview mirror.

This is where many traditional risk programs fall short. They are too often rearview-mirror exercises. By the time a risk is fully identified, documented, assessed, scored, and placed on a register, it may already have become an event. The risk function becomes an observer of uncertainty rather than a participant in decision-making. It records what the business fears, but it does not help the business decide what to do.

Value-Based Risk Management changes the starting point. It begins not with the risk register, but with objectives. It asks: What are we trying to achieve? What value are we trying to create or protect? What uncertainty could affect that value? What decisions must be made? What confidence do leaders need to act?

This aligns with the essential insight of ISO 31000: risk is the effect of uncertainty on objectives. Yet too many organizations focus almost entirely on the uncertainty and not nearly enough on the objective. Stefan made this point powerfully. Risk people spend a great deal of time defining, scoring, and debating uncertainty, but far too little time understanding what an objective is, how it generates value, and how uncertainty affects the ability to deliver that value.

That imbalance is why risk becomes noise.

Organizations Do Not Have an Appetite for Risk. They Have an Appetite for Value.

One of the central themes of our session was a statement that challenges one of the most established phrases in the risk profession:

Organizations do not have an appetite for risk. They have an appetite for value.

The traditional language of “risk appetite” often starts in the wrong place. It asks whether we are willing to accept a particular risk, as though risk itself is the thing the organization desires. But no executive, board, investor, or stakeholder truly wants risk for its own sake. What they want is the value that may be achieved by pursuing an objective under uncertainty.

Stefan illustrated this with a simple example. Ask someone to leave an expensive watch unattended on a table, and they will refuse. Ask them to leave the watch there with a meaningful possibility that a better watch will be there when they return, and the conversation immediately changes. They will ask about probability. They will ask about the conditions. They will ask about the upside and downside. They will ask about the decision.

The appetite was never for risk. The appetite was for the outcome.

That distinction matters because it reframes the entire risk conversation. Risk management should not begin by asking how much risk the organization is willing to take in the abstract. It should begin by asking what value the organization is trying to create or protect, and what uncertainty surrounds that value.

A growth objective has risk. A resilience objective has risk. A compliance objective has risk. A transformation objective has risk. A market expansion objective has risk. A strategic decision not to act also has risk. Risk is not separate from the objective; it is embedded in the pursuit of the objective.

This is why risk management must move from risk-centric language to value-centric language. The business does not need to be trained to speak risk. Risk professionals need to learn to speak the language of the business.

From Risk Activity to Decision Advantage

The phrase “decision advantage” is critical. Risk management earns its seat at the table when it helps leaders make better decisions faster.

That is a very different ambition from maintaining a risk inventory. A risk register may be useful, but it is not the destination. A heat map may be a visual aid, but it is not intelligence. A control library may be necessary, but it is not confidence. The real value of risk management is realized when uncertainty is translated into insight that improves decisions.

Executives are not asking, “Can you give me a perfectly maintained risk taxonomy?” They are asking, even if they do not use these words:

• Can we achieve the plan?
• Where are we most uncertain?
• What assumptions are fragile?
• What external conditions could change the strategy?
• What internal capabilities are weak?
• Where should we invest?
• Where should we slow down?
• Where should we take more risk?
• Where should we avoid, transfer, mitigate, or accept risk?
• Where do we have confidence, and where are we pretending?

That is the conversation risk leaders must be prepared to have. It is not enough to say, “Here are the top risks.” The better question is, “Here are the objectives, here is the uncertainty around them, here are the decisions required, and here is the level of confidence we have in achieving the outcomes.”

This is where risk management becomes strategic. It is no longer a compliance exercise. It becomes a leadership capability.

The Human Dimension of Risk

One of the most powerful aspects of Stefan’s contribution was his insistence that risk is a human phenomenon. Probability exists without humans. The probability of two asteroids colliding in deep space exists whether anyone observes it or not. But whether that event is good, bad, meaningful, irrelevant, threatening, or advantageous depends on the observer.

Risk requires context. It requires objectives. It requires value. It requires judgment.

The same event may be catastrophic for one organization and advantageous for another. A market disruption may destroy one business model and create another. A regulatory change may burden one organization and differentiate another. A supply chain shock may expose fragility in one enterprise while rewarding resilience in another. A technology shift may be a threat to incumbents and a launchpad for challengers.

This means risk management sits at the intersection of mathematics, probability, psychology, ethics, strategy, and decision science. It is not simply a matter of data. It is not simply a matter of technology. It is not something that can be fully outsourced to a dashboard, an algorithm, or an AI-generated summary.

Technology matters. Data matters. Analytics matter. But risk management still requires human judgment. It requires understanding why people pursue objectives, how they perceive value, what they fear, what they desire, what trade-offs they are willing to make, and what confidence they need to act.

This is also why the conversation cannot be reduced to fear. Fear may get attention, but only briefly. A risk conversation built only on fear becomes exhausting. Leaders may respond to immediate threats, but they will not build a lasting relationship with risk management if every interaction is framed as danger, restriction, and loss.

The stronger conversation is about value creation and value protection. It is about helping leaders succeed.

The Ancient Problem: Controls Without Context

One of the most memorable moments in the session came when Stefan referenced a cuneiform tablet: an ancient receipt for two cows. It was funny, particularly in Switzerland, where the idea of a receipt drew laughter and applause. But the point was serious.

Human beings invented agriculture, numbers, writing, and control mechanisms because value had to be documented, transferred, protected, and trusted. That ancient receipt was, in a way, a control against misstatement or misaccounting. It recorded who had what, what changed hands, and where value moved.

The problem is that too much of modern risk and control thinking has not moved far enough beyond that ancient control mindset. We still focus heavily on whether the numbers are recorded correctly, whether the report is complete, whether the control exists, whether the evidence is retained, whether the policy was attested to, whether the register was updated.

These things matter. But they are not enough.

Stefan used the analogy of a patient in a hospital bed. If the doctor only tells you the patient’s temperature is 37 degrees, that is a data point. It is not a diagnosis. It does not tell you whether the patient is improving or declining. It does not tell you what condition the patient is in, what intervention is required, or what outcome is likely. It is one measurement in a complex system.

The same is true in organizations. A control test result is not the health of the business. A financial metric is not the full story of performance. A risk score is not a decision. A compliance report is not resilience. Each may be a useful signal, but the organization needs to understand the system.

Value-Based Risk Management requires moving beyond isolated indicators and toward connected insight.

Internal and External Risk: What We Can Control and What We Must Prepare For

A recurring image in the session was the ship. Stefan spoke from experience, using HMS Chatham as an example, and the analogy fits beautifully with the broader “starship of risk” theme.

A ship has internal risks: systems may fail, engines may break, food or fuel may run low, people may lack capability, processes may not work. These are risks the organization can influence directly. It can affect their probability through maintenance, training, investment, process design, controls, and leadership.

But a ship also faces external risks: weather, rocks, enemies, currents, darkness, time, and the surrounding environment. These are risks whose probabilities the ship cannot control. It cannot change the weather. It cannot move the rock beneath the water. It cannot prevent every external shock. But it can prepare. It can navigate. It can build resilience. It can sense, respond, adapt, and steer.

This distinction is vital for modern GRC and risk management. Too many risk programs treat all risks as if they can be managed in the same way. They cannot. Some risks require reducing probability through better internal controls. Others require improving preparedness, resilience, optionality, and response. Some require changing strategy. Others require strengthening capability. Some require accepting uncertainty because the value at stake justifies the exposure.

This is where risk and resilience converge. External uncertainty shapes strategy. Internal capability determines whether the organization can execute that strategy. Controls, policies, processes, capital investment, assurance, and actions all exist to create confidence that objectives can be achieved.

Surprise Is Still Risk — Even When the Outcome Is Positive

Another important challenge in the session was the idea that uncertainty is not only a problem when the outcome is negative. If an organization materially exceeds its target and leadership is surprised, that still indicates a failure to understand uncertainty.

Stefan shared the example of a company that made significantly more money than expected. The CFO was delighted. More money meant bigger bonuses. But the risk question was different: How did we not see this coming?

That is the discipline of Value-Based Risk Management. It is not simply about preventing downside. It is about understanding uncertainty around objectives. If the organization is 25% below target, something was misunderstood. If the organization is 25% above target and had no idea why, something was also misunderstood. In both cases, the organization lacked insight into the drivers of performance.

This matters because the upside may not repeat. The organization may confuse luck with competence. It may allocate capital based on false assumptions. It may reward outcomes without understanding causes. It may miss signals that should shape future strategy.

Risk management must help organizations understand variance, not just loss. It must help leaders understand why performance deviates from expectations, whether in a favorable or unfavorable direction. This moves risk into the heart of performance management, strategy execution, and decision-making.

ORCA: Objectives, Risks, Controls, Assurance, Actions

One of the practical models Stefan introduced was ORCA:

Objectives. Risks. Controls. Assurance. Actions.

The simplicity of the acronym matters because it changes the flow of risk management. It does not start with a list of risks. It starts with objectives.

The objective defines the value the organization is trying to create or protect. The risks are the uncertainties that may affect that objective. The controls are the mechanisms that make the objective more achievable. Assurance provides confidence that those mechanisms are working. Actions define what must change, improve, invest, respond, or adapt.

This creates a system, not a list. It creates a flow of information from strategy to uncertainty, from uncertainty to control, from control to assurance, and from assurance to action. It also closes the loop. Actions affect capabilities. Capabilities affect objectives. Objectives evolve as the environment changes.

Importantly, opportunities are not separate from this model. When someone asked whether there should be another “O” for opportunities, Stefan’s answer was that opportunities are embedded in objectives. An objective may be to grow, expand, enter a new market, launch a product, transform a business model, or protect existing value. Opportunity and risk are both expressions of uncertainty around value.

This is a more mature way to think about risk. It avoids the false separation between risk management and opportunity management. The organization is not managing risk on one side and opportunity on another. It is managing uncertainty in pursuit of objectives.

The Future of Risk: Systems, Causality, and Connected Intelligence

The session also moved into the future of risk management: systems thinking, causal inference, Bayesian logic, graph databases, and connected models of risk and performance.

This is where risk management must go. Organizations are not flat lists of risks. They are complex systems operating in dynamic environments. One failure can cascade. One decision can shift multiple exposures. One control weakness can affect several objectives. One external shock can create operational, financial, compliance, reputational, and strategic consequences at the same time.

The future of risk management is not simply more automation of old processes. It is not AI-generated risk descriptions placed into the same tired registers. It is not faster production of heat maps. That may create speed, but not necessarily intelligence.

The future is understanding relationships.

• How does one risk influence another?
• How does a control affect the probability or impact of multiple outcomes?
• How does an external condition change the feasibility of a strategy?
• How does a weakness in one capability affect several objectives?
• How does uncertainty in the financial plan connect to supply chain, workforce, technology, regulatory, geopolitical, and operational uncertainty?

This is where Bayesian thinking, causal inference, and graph-based approaches become important. They allow organizations to move beyond static risk lists and toward dynamic models of how things connect. They support a more intelligent understanding of cause and effect, probability, dependency, and decision impact.

The caution, however, is equally important. AI is not a substitute for risk management maturity. An AI-powered risk platform does not automatically mean better risk management. If the underlying model is weak, if objectives are not defined, if relationships are not understood, if the AI hallucinates and leaders believe it, the organization may make worse decisions faster.

Technology should strengthen decision-making, not create a more efficient illusion of insight.

Controls as Decision Levers

The session also reframed controls in a powerful way. Controls are often treated as static mechanisms: policies, procedures, approvals, reconciliations, access restrictions, monitoring activities, and evidence requirements. They are cataloged, tested, and reported. But in a value-based model, controls become decision levers.

Stefan described controls in terms of time and effect.

Some risks are structural or systemic. They require transformation, capital investment, capability development, or major redesign. These are long-term controls. They may take years to produce meaningful benefit because they address deep structural uncertainty.

Other risks relate to business performance and execution. They may be addressed through better processes, clearer policies, improved management routines, training, accountability, and operational discipline. These controls may produce benefit within the year.

Still other risks and opportunities require immediate action. Incident response, crisis management, and opportunity exploitation are immediate controls. They are how the organization acts when uncertainty becomes urgent.

This time-based view of controls is important because it connects risk management to decision horizons. Not every risk response belongs in the same governance cycle. Not every control should be judged by the same timeframe. Not every action is a remediation plan. Some actions are strategic investments. Some are operational improvements. Some are immediate responses to events or opportunities.

This moves controls from a compliance inventory to a management discipline.

Stop Training the Business to Be Risk Experts

Another challenge from the session was direct and necessary: Do not train business leaders to become risk experts. Risk experts must learn the business.

This reverses a common mistake. Risk teams often try to bring the business into the language, structures, taxonomies, scoring models, and reporting rituals of the risk function. They ask the business to identify risks, score risks, update risks, attest to controls, and participate in risk workshops. Some of that may be necessary, but it often reinforces the perception that risk management is an administrative burden.

The better approach is to meet the business where it is.

Talk to strategy leaders about strategic objectives, assumptions, scenarios, and choices. Talk to operations leaders about execution, capacity, resilience, process performance, and disruption. Talk to financial planning and analysis teams about uncertainty in the plan, error bars around forecasts, and where confidence weakens across the year. Talk to business unit leaders about what they are trying to achieve, where they are exposed, and what would help them win.

This requires new alliances. Risk teams have historically spent much of their time with auditors, lawyers, accountants, and compliance teams. These relationships remain important. But value-based risk management also requires stronger relationships with strategy, operations, finance, product, commercial leadership, transformation teams, resilience leaders, and the people who own performance.

Risk professionals should be known as people who help the business succeed, not people who arrive with templates.

The Financial Plan Is a Risk Model — Whether Finance Calls It That or Not

One of the audience questions went straight to the reality of organizations: businesses are often run through the financial plan. Objectives, incentives, bonuses, investments, and performance conversations are frequently anchored in annual financial targets.

That creates both a challenge and an opportunity for risk management.

The challenge is that financial planning often presents a single line: the budget, the target, the forecast, the expected outcome. But reality is not a single line. Reality has uncertainty. It has ranges, assumptions, dependencies, volatility, and confidence levels. The plan may show what the organization intends to achieve, but risk management can help reveal where the plan is fragile.

The opportunity is to make risk management useful in-year while also pushing the conversation beyond the financial year. Risk professionals can help finance and business leaders ask: Where are we less certain? Which assumptions matter most? What could cause us to outperform or underperform? What would we do if the curve changes? Where do we need leading indicators? Where do we need options?

This does not require forcing finance to speak risk. It requires risk professionals to speak finance.

Start with the plan. Add uncertainty. Discuss the drivers. Identify the decisions. Build confidence. That is how risk becomes relevant.

Confidence Is the Product of Risk Management

Perhaps the strongest closing theme from Stefan was that risk professionals do create something. They create confidence.

That is profound.

Risk management does not create products in the traditional sense. It does not always generate revenue directly. It does not own the strategy, operate the factory, sell the service, or manage the customer relationship. But it does create confidence that the organization can pursue objectives, protect value, grow responsibly, remain resilient, stay safe and legal, and make better decisions under uncertainty.

Confidence is difficult to create and easy to lose. It is built through clarity, discipline, intelligence, assurance, transparency, and action. It requires knowing where the organization is strong and where it is exposed. It requires understanding what is controlled, what is not controlled, what can be influenced, what must be prepared for, and what decisions must be made.

Confidence is not blind optimism. It is not the absence of risk. It is the justified belief that the organization understands its objectives, its uncertainty, its capabilities, its controls, and its choices.

This is the real output of Value-Based Risk Management.

From Noise to Advantage

The message of the session was clear: risk management must evolve from noise to decision advantage.

• Noise is a risk register disconnected from objectives.
• Noise is a heat map that simplifies complexity into colors without improving decisions.
• Noise is a control report that says the temperature is 37 degrees but does not diagnose the health of the patient.
• Noise is a business case built around saving 75% of time in risk assessments when the business does not care how busy the risk team is.
• Noise is asking executives to care about risk without first understanding what they are trying to achieve.

Decision advantage is different.

Decision advantage starts with objectives. It understands value. It maps uncertainty. It connects internal and external risk. It distinguishes between what can be controlled and what must be prepared for. It uses technology and data intelligently, but does not confuse automation with insight. It builds causal understanding. It aligns controls to decision horizons. It creates confidence. It helps the business protect and grow.

This is what Value-Based Risk Management is about.

It is not risk for risk’s sake. It is not compliance theater. It is not administrative activity. It is not a prettier register or a faster assessment. It is a leadership capability that enables the organization to pursue objectives with clarity, confidence, and resilience.

Risk is our business. But risk is not the point.

The point is value. The point is objectives. The point is better decisions. The point is helping the organization boldly go where strategy, process, and technology have never gone before.

Or, How to Avoid Booking a Table to Watch Your GRC RFP Decision Explode

Somewhere in the vast and bewildering expanse of governance, risk management, and compliance, there is a restaurant with a truly spectacular view. It is not located at the end of the universe in distance, as that would be far too simple and would merely require a travel policy exception, three approvals from procurement, and a debate about whether the journey should be categorized as operational risk, third-party risk, or a strategic resilience exercise. No, this restaurant is located at the end of the GRC universe in time .

It is the place where one sits down, orders something suitably expensive, and watches a poorly conceived GRC technology decision finally explode.

Douglas Adams fans of Hitchhiker’s Guide to the Galaxy know what I am talking about, and do not forget my Hitchhiker’s Guide to the GRC Technology Galaxy Podcast in this context.

I have been to this restaurant many times. Not by choice, exactly. I do not seek it out. I do not maintain a preferred table by the window. I certainly do not enjoy watching organizations spend significant time, money, political capital, and executive goodwill on a decision that was visibly doomed before the ink dried on the contract. But in my work advising organizations around the world on GRC-related RFPs, I have seen enough of these outcomes to recognize the cosmic tremors long before the final detonation.

I get involved in a lot of RFPs. Enterprise GRC platforms. Regulatory change management. Third-party risk management. Digital risk and resilience. Policy management. Internal control. Operational risk and resilience. Compliance management. ESG/sustainability. Internal audit. Cyber risk. You name the part of the GRC galaxy, and I have likely seen an RFP drift through it with great ambition, a spreadsheet of requirements, and a procurement portal that appears to have been designed by a committee of Vogons who were told to make risk management more painful.

Organizations engage me as a sounding board. They ask me to advise, challenge, validate, pressure-test, and help them understand the vendor landscape. Sometimes I am brought in early, when the organization is still defining its requirements and market approach. Sometimes I am brought in midway, when the longlist has become a shortlist and everyone is beginning to suspect that the demos all somehow look impressive in exactly the same way. Sometimes I am brought in at the very end, when the organization wants a final independent perspective before making a decision that will shape its GRC architecture for years.

At its best, this work is deeply rewarding. A well-run RFP can be an excellent discipline. It can clarify the organization’s needs, expose assumptions, align stakeholders, and lead to a solution that genuinely fits the business. I have worked with many organizations that did the hard work, asked the right questions, listened carefully, challenged the marketing, validated the references, and selected solutions that were right for their objectives, maturity, operating model, and future direction.

But I have also seen the other kind . . . The kind where I can see the explosion coming.

The View from the Edge of the GRC Universe

The central joke of Douglas Adam’s The Restaurant at the End of the Universe is not merely that diners watch the universe end over dinner. It is that the end is known, scheduled, and presented as entertainment. The catastrophe is not a surprise. It has been commercialized. It is on the menu.

That is what some GRC RFPs feel like to me. I am sitting in the process, listening to the discussion, reviewing the requirements, watching the vendor demonstrations, and I can already see where the decision is headed. I can see the gravitational pull of the wrong choice. I can see the organization being seduced by market noise, analyst positioning, mock-ups, artificial intelligence claims, and a demo environment so perfectly staged that one half expects the data model to offer a polite bow at the end.

The problem is rarely that people are careless. In most cases, the people involved are intelligent, dedicated, and genuinely trying to make the right decision. The problem is that the RFP process often rewards the wrong things . . .

• It rewards the vendor that answers “yes” to the most requirements, even when those yeses conceal a small universe of configuration, services, custom work, roadmap promises, and interpretive dance.
• It rewards the best presentation, not necessarily the best fit.
• It rewards brand recognition and analyst placement, even when those signals are only loosely connected to the organization’s actual needs.

I have seen organizations follow advice from large analyst firms that were entirely wrong for their situation. Large analyst firms may provide broad market visibility, but broad market visibility is not the same as contextual fit. A solution that appears strong in a quadrant, wave, market guide, or other cartographic artifact of analyst civilization may still be the wrong solution for a specific organization, use case, maturity level, regulatory environment, operating model, or technology architecture.

There have been times when I have advised an organization against a direction and watched them proceed anyway. Two years later, the outcome is what I expected: the implementation is stalled, the solution is not adopted, there are zero users, the cost has multiplied, the internal team is frustrated, the business has gone back to spreadsheets, and the executive sponsor has quietly moved to another role (or often another organization) where the word “transformation” is no longer spoken in their presence. In some cases, people have lost their jobs because the chosen solution never should have been selected.

That is not a pleasant thing to witness. There is no joy in being right about avoidable failure. I would rather be wrong about doom and see the organization succeed than be correct in my prediction and watch a program collapse. My goal in advising RFPs is not to be negative. It is to prevent organizations from booking a reservation at the end of their own GRC universe.

The Raccoon and the Shiny Object

This is where an entirely different literary image becomes useful: the raccoon trap in Where the Red Fern Grows. A shiny object is placed in a hole, nails are angled around the opening, and the raccoon reaches in to grab the prize. Once its paw is closed around the object, it cannot pull its fist back through the opening. The raccoon could escape by letting go, but it refuses. It is not trapped only by the mechanics of the device. It is trapped by desire.

GRC buyers can behave the same way.

The shiny object may be a stunning demo. It may be an artificial intelligence capability that works beautifully in a controlled video but has not yet survived contact with actual regulatory complexity, messy control libraries, inconsistent taxonomies, or business units with strong opinions. It may be a vendor’s claim that the solution is “fully integrated,” which often means something very different in marketing than it does in implementation. It may be an elegant dashboard that shows exactly what the board wants to see, provided the organization first solves every underlying data, process, ownership, and accountability problem that the dashboard quietly assumes has already been solved.

I have seen buyers reach into the log and grab the shiny object. Then the warning signs appear. The client references are weak or not comparable. The implementation examples are shallow. The vendor has strong capability in one domain but is overextended in another. The roadmap is being asked to do the work of the current product. The workflow is attractive, but the data model is fragile. The solution can technically do what is required, but only after significant services work that was not fully understood during selection.

At that moment, the organization has a choice. It can let go and reconsider. Or it can tighten its grip.

Too often, it tightens its grip.

This is one of the great tragedies of GRC technology selection. Organizations sometimes know, at some level, that something is not right. The doubts are there. The questions are there. Someone in the room has asked why the reference was not similar. Someone has noticed that the vendor avoided a live configuration question. Someone has pointed out that the implementation timeline seems optimistic in the same way that building a bypass through one’s house might be described as “minor civic improvement.” But momentum takes over. The shortlist has been approved. The executive team likes the story. Procurement wants closure. The vendor has promised partnership. The shiny object remains firmly clenched in the organizational paw.

And somewhere, very far away in time, a waiter confirms the reservation.

When RFPs Work Well

It is important to say clearly that not all RFPs end in cosmic fire. Many are successful, and those are the engagements I enjoy most (and the ones that listen and adhere to my advice). In a strong RFP, the organization does not treat technology selection as a beauty contest. It treats it as a disciplined exercise in alignment. The objective is not to find the vendor with the most features, the loudest claims, or the most fashionable terminology. The objective is to find the solution that best fits the organization’s purpose, processes, risk profile, compliance obligations, maturity, culture, and future direction. And the solution that is easy to work with and engage. People matter as much as technology for success.

One of my favorite RFP experiences happened when I was brought in near the very end of the process. The organization told me they had narrowed the field to two finalists. Before they revealed the names, they asked me which three solutions I believed they should have considered based on their requirements and operating model. I named three. Two of the three were their final two. I have been doing this for 26 years as an analyst. So often I can come in and know right from the get go which solutions should be the finalists, if not the specific solution that they should go with.

That was a good sign. It told me that their process had led them to a credible destination. My role from that point was not to overturn the process or impose my own preference. It was to help them pressure-test the final decision, understand the trade-offs, and move forward with confidence. That is what good advice should do. It should sharpen the decision, not replace the organization’s judgment.

The best RFPs have several characteristics in common:

• They begin with business clarity, not technology fascination. The organization understands what it is trying to achieve before it starts asking vendors what they can do. It defines the outcomes it needs, the decisions it wants to improve, the processes it must connect, and the pain points it must resolve. This prevents the RFP from becoming a fishing expedition in which every impressive capability becomes a potential requirement.
• They distinguish between current need and future ambition. A good GRC technology decision should support the organization’s future direction, but it should not be built entirely on fantasy architecture. There is a difference between selecting a solution that can grow with the organization and selecting one that requires the organization to become a completely different species before value is realized.
• They demand evidence, not performance. Strong RFP teams look beyond the demo. They ask for comparable references, realistic scenarios, live configuration examples, implementation details, and proof that the vendor has delivered similar outcomes in similar environments. They know that a beautiful demo is useful, but only as one piece of evidence.
• They understand that fit is multidimensional. The right solution must fit the use case, maturity level, operating model, geography, regulatory complexity, data architecture, internal skills, and change capacity of the organization. It is possible for a solution to be excellent and still be wrong for a specific buyer.

This is where my work adds the most value. I know the GRC technology market. I know the vendors, the categories, the use cases, the overlaps, the strengths, and the gaps. I know where marketing claims tend to outrun operational reality. I know which solutions are truly strong in specific domains and which ones are borrowing credibility from adjacent capabilities. I know when vendors are demoing capabilities that do not exist in their product and was a fictitious mockup. I also know that most vendors are not simply “good” or “bad.” They are strong or weak relative to a particular need. The art of the RFP is understanding that difference.

The Demo Is Not the Implementation

One of the most dangerous assumptions in GRC technology selection is that the demo represents reality. It does not. A demo is a staged performance. That does not make it dishonest, but it does make it incomplete. The demo environment has clean data, obedient workflows, cooperative users, tidy organizational structures, and just enough complexity to appear credible without becoming inconvenient.

Reality has none of these manners.

Reality has overlapping regulatory obligations, inconsistent naming conventions, inherited control libraries, unresolved ownership questions, business units that insist their process is unique, third parties that refuse to respond on time, policies that have not been reviewed since the age of steam, and executives who want a dashboard that answers questions no one designed the data model to support. Reality also has resource constraints, competing initiatives, implementation fatigue, integration complexity, and change management issues that no vendor demo can fully capture.

This is why RFPs must move from demonstration to validation. I want vendors to show how their solution behaves under pressure. Show me how it handles exceptions. Show me how obligations map to policies, controls, risks, issues, and business units. Show me what happens when the same third party supports multiple critical services across multiple jurisdictions. Show me how the platform manages regulatory change when one rule affects five policies, twelve controls, three products, two regions, and one executive who has just asked why this was not escalated sooner.

A good demo answers the question, “What can the solution do?” A strong RFP goes further and asks, “Can the solution do what we need, in the way we need it done, with the resources and maturity we actually have?”

Those are very different questions.

The Client Reference Problem

Client references are one of the most important and most underused disciplines in GRC technology selection. Too many organizations accept references that are not sufficiently comparable. A vendor may provide a happy client, but happiness is not the same as relevance. The reference may be in the same industry but using the solution for a different purpose. It may have a similar use case but far less complexity. It may be a strong implementation but under a completely different operating model. Some solutions refuse to provide a comparable client reference and that is a huge warning signal that too often is ignored.

For references to be meaningful, they must be tested against the organization’s reality. A global financial services organization evaluating regulatory change management should not rely on a reference from a smaller domestic firm using the platform primarily for policy attestations. A manufacturer evaluating third-party risk and supply chain resilience should not be satisfied with a reference that covers basic vendor onboarding but not ongoing monitoring, performance, concentration risk, geopolitical exposure, or offboarding. An enterprise seeking integrated GRC should not confuse success in one department with proof of enterprise-wide capability.

The reference conversation should be specific, practical, and candid. I want to know what worked, what did not, what took longer than expected, what required services, what the vendor handled well, where the client had to compromise, and whether the organization would make the same decision again. I want to know how much internal capacity was required. I want to know whether the business adopted the process or worked around it. I want to know whether the promised reporting is actually being used by management and the board.

The most useful reference is not the one that says everything was perfect. The most useful reference is the one that tells the truth.

Where RFPs Most Often Go Wrong

Most RFP problems are not caused by one dramatic mistake. They are caused by a series of small distortions that accumulate until the organization finds itself committed to a path that no longer reflects its original needs. The process starts with good intentions, but the gravitational pull of market noise, internal politics, and vendor performance changes the trajectory.

The most common failure patterns include:

• Confusing breadth with depth. Many GRC solutions can claim coverage across a wide range of functions. The more important question is how deeply and effectively they support the specific use cases that matter most. A platform may have a third-party risk module, but that does not mean it can support complex third-party governance across onboarding, due diligence, ongoing monitoring, issue management, performance, resilience, concentration risk, and offboarding. A solution may claim regulatory change management, but that does not mean it provides the intelligence, relevance, obligation mapping, workflow, accountability, and evidence needed by a global organization.
• Buying the roadmap instead of the product. Roadmaps matter, but they are not the same as current capability. If a critical requirement depends on a future release, the organization should treat that as a risk, not as a solved problem. There is nothing wrong with selecting an innovative vendor with a strong direction, but there is great danger in pretending that a future promise is equivalent to a present capability.
• Letting analyst positioning substitute for judgment. Analyst research may be helpful (and I would say that my research is), but it should not become a decision-making crutch. Rankings and market graphics are not a substitute for understanding fit. They often reflect broad market presence, vendor strategy, and general capability, not the precise needs of a specific organization.
• Underestimating implementation and adoption. The software selection is only the beginning. GRC technology succeeds or fails in implementation, governance, data design, process alignment, ownership, and change management. A solution that looks powerful in selection can fail if the organization does not have the capacity, discipline, or clarity to implement it well. This is where so many ServiceNow GRC/IRM implementations fail.
• Failing to challenge the shiny object. The newest capability is not always the most important capability. Artificial intelligence, automation, digital twins, analytics, and integrated intelligence all have tremendous potential in GRC, but they must be evaluated against operational reality. The raccoon’s problem was not curiosity. The problem was refusing to let go when the trap became obvious.

These patterns are avoidable. That is the point. The Restaurant at the End of the GRC Universe may have excellent views, but no organization should want to appear on the reservation list.

What Organizations Should Do Instead

A better RFP begins with the organization looking inward before it looks outward. Before asking vendors what they offer, the organization must understand what it needs. That requires more than collecting requirements from every stakeholder and turning them into a spreadsheet large enough to have its own weather system. It requires prioritization. It requires clarity on what matters most. It requires distinguishing essential capabilities from preferences, future ambitions, and decorative features that look impressive but do not materially improve outcomes.

The organization should define the business problem in operational terms.

• What processes are broken?
• What decisions are poorly supported?
• What risks are not visible?
• What obligations are not mapped?
• What evidence is hard to produce?
• What third-party relationships are not governed consistently?
• What reports require manual heroics?
• What accountability is unclear?
• What regulatory, operational, or strategic pressures make change necessary now?

Only after that should the organization turn to the market.

When it does, the RFP should be designed to test fit, not collect affirmations. Vendors should be asked to demonstrate the organization’s scenarios, not generic ones. They should be asked to explain implementation realistically, including services, timelines, internal resource needs, configuration ownership, integration requirements, and common challenges. They should be asked where they are strong and where they are not. A vendor that cannot explain its limitations is either inexperienced, overconfident, or selling fiction.

A disciplined GRC RFP should include several practical tests:

• Scenario-based demonstrations using real use cases. Do not let the demo remain abstract. Provide vendors with specific scenarios that reflect the organization’s complexity. For regulatory change, test how the solution identifies relevance, maps obligations, assigns accountability, tracks implementation, and produces evidence (within your jurisdictions of interest, a solution built for reg change in the USA does not always perform well in Europe as regulatory approaches vary). For third-party risk, test the lifecycle from intake and onboarding through monitoring, issue management, performance, resilience, and offboarding. For enterprise GRC, test how risks, controls, policies, obligations, issues, incidents, metrics, and objectives connect.
• Comparable client references. Require references that align with the organization’s industry, size, geography, complexity, and use case. Ask practical questions about implementation, adoption, reporting, support, and lessons learned. Listen carefully for what is not said.
• Data and architecture review. Understand the underlying data model. GRC is not just workflow. It is the relationship between objectives, risks, controls, obligations, policies, assets, processes, third parties, incidents, issues, and decisions. If those relationships are weak, the solution will struggle to deliver integrated insight.
• Implementation realism. Require clarity on what is configured by the client, what requires the vendor, what requires professional services, what is included, what costs extra, and what assumptions are embedded in the timeline. Many failures begin with an implementation plan that was written with more optimism than evidence.
• Governance and ownership alignment. Determine who will own the platform, who will govern data standards, who will maintain taxonomies, who will manage change, and how business units will be engaged. A GRC platform without governance quickly becomes a very expensive filing cabinet with workflow aspirations.

These disciplines are not bureaucratic obstacles. They are protections against expensive regret.

Fit: The Real Answer to Life, the Universe, and GRC

In Douglas Adams’ universe, the answer to life, the universe, and everything is famously simple (42), though not especially useful without understanding the question. GRC technology has a similar problem. Many organizations want the answer to be a product name. They want the answer to be the market leader, the best platform, the top-ranked vendor, the most innovative solution, or the one with the most compelling artificial intelligence story.

But the real answer is fit.

Fit to purpose. Fit to maturity. Fit to architecture. Fit to process. Fit to culture. Fit to regulatory complexity. Fit to the operating model. Fit to the organization’s internal capabilities. Fit to the decisions that need to be made. Fit to the future the organization is actually capable of building.

This is why I resist simplistic vendor rankings. I do not do quadrants or waves. There is no universal best GRC solution. There are excellent solutions for specific contexts. There are strong vendors that fit certain use cases very well and others poorly. There are emerging vendors that are innovative and worth serious consideration, but not necessarily ready for every enterprise requirement. There are established platforms with deep capability, but also complexity that may overwhelm an organization that is not prepared for it.

The right question is never simply, “Who is best?” . . . The better question is, “Who is best for us, for this purpose, at this stage of maturity, given where we need to go?”

That question changes the entire RFP.

My Role as a Guide Through the GRC Galaxy

When I advise organizations, I am not there to replace their decision-making. I am there to improve it. I help them understand the market, challenge assumptions, ask better questions, and recognize patterns that may not be visible to a team that only runs a major GRC RFP every several years. Vendors live in the market every day. Analysts and advisors live in the market every day. Buyers often do not. That imbalance matters.

My role is to bring context. I know where solutions are strong. I know where claims need to be tested. I know which capabilities are mature and which are mostly presentation. I know where a vendor’s center of gravity is and where it may be stretching beyond its proven strength. I know the difference between a platform that can truly support integrated GRC and one that has assembled a set of modules under a common brand. I know where regulatory content matters, where workflow matters, where intelligence matters, where configurability matters, and where implementation discipline matters most.

Most importantly, I know that GRC technology decisions are not really about technology. They are about enabling the organization to reliably achieve objectives, address uncertainty, and act with integrity. Technology supports that capability, but it cannot substitute for clarity, governance, accountability, and sound judgment.

That is why I push organizations to slow down at the right moments. Not to delay the process unnecessarily, but to prevent preventable mistakes. There is a great difference between urgency and haste. Urgency is appropriate when the organization faces regulatory pressure, operational risk, resilience gaps, or fragmented processes that need attention. Haste is what happens when the organization mistakes motion for progress and signs a contract because everyone is tired of the RFP.

The universe is full of tired decision-makers. Some of them are now reviewing dessert menus at the end of time.

Avoiding the Restaurant

The Restaurant at the End of the GRC Universe will always be there. There will always be bad RFPs, shiny objects, overconfident vendors, vague requirements, weak references, inflated claims, and decisions made because the room wanted closure more than confidence. There will always be organizations that discover too late that the solution they selected was not wrong in general, but wrong for them.

But the table does not have to be booked.

A well-run RFP can be one of the most valuable exercises an organization undertakes. It can align stakeholders, clarify priorities, expose weak assumptions, and establish a foundation for better GRC outcomes. It can help the organization move beyond fragmented processes and toward an integrated approach to governance, risk management, and compliance. It can connect objectives, risks, obligations, controls, policies, issues, third parties, and performance in a way that supports better decisions.

The key is discipline. Know what you need before you ask the market what it sells. Demand evidence. Test the real use cases. Validate the references. Understand the data model. Be honest about maturity. Challenge the roadmap. Beware the mock-up. Respect the demo, but do not worship it. Above all, be willing to let go of the shiny object when the trap becomes clear.

Because somewhere, at the far end of the GRC universe, there is always a table available.

The wise organization never makes the reservation.

The highlight of my current business trip to Denmark has not been a meeting, a briefing, an RFP conversation, or a strategy session. The highlight was going to Alchemist in Copenhagen with my oldest son, Noah, who is a chef . . .

That made the experience personal. It was father and son, but also analyst and chef, both of us looking at craft, design, precision, execution, and imagination from different professional angles. Noah sees cuisine with a depth that I appreciate but cannot fully inhabit. I see operating models, governance structures, taxonomies, information architectures, and systems of accountability where others simply see dinner. My family has learned to live with this condition, as there is no known cure.

Alchemist is consistently reviewed as one of the best restaurants in the world, and Chef Rasmus of Alchemist has been voted best chef in the world the past two years. But calling Alchemist a restaurant is like calling the Starship Enterprise a vehicle. Technically accurate, but it misses the entire point.

Alchemist is an experience: theater, science, cuisine, technology, design, choreography, social commentary, hospitality, precision, and imagination. It is not merely about eating. It is about entering a world deliberately constructed to transform how you perceive food, space, story, and meaning.

And that is where this becomes a GRC story . . .

Too much of GRC has been trapped in the mechanics of the past. We have built repositories, workflows, assessments, issue logs, control libraries, obligation inventories, policy portals, risk registers, and dashboards. These are all important: they are the ingredients of GRC. But ingredients alone do not make a meal. A pantry full of fine components does not produce a great dining experience. A kitchen full of jars, spices, herbs, and carefully labeled extracts is still only potential until someone with vision understands how they come together. Organizations should not ask, “What tool should we buy?” They should ask, “What should GRC become?” . . . That is the right question to be asking.

Entering the Experience

The Alchemist experience does not begin with a menu. It begins with a shift in perception.

When Noah and I first set foot into the experience, we entered a visual multimedia room where images were projected in front of us with our faces transposed onto them; moving across history, humanity, culture, science, and imagination. This was not a waiting room. This was not decoration. This was the threshold . . . It was an intentional transition from the ordinary into the extraordinary.

The opening experience concluded that opening sequence with the statement:

“Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand.” – Albert Einstein

The fuller point was that knowledge is limited to what we now know and understand, while imagination reaches toward the whole world and what there will be to know and understand. Imagination can be the birthing chamber to more knowledge. For example, some of the techniques used at Alchemist were entirely new and innovative, creating something new that has introduced new knowledge into the culinary sphere. While there were also other aspects of Alchemist that were intentionally attempting to resurrect and revive knowledge that has nearly been lost to time, at least to most of the world. In this sense, new knowledge is introduced into the modern compendium through imagination.

That thought stayed with me throughout the evening. It also stayed with me through my GRC conversations in Denmark the next day and through this past weekend.

Because this is exactly where GRC is today. We have more knowledge than ever. We have more data, more regulations, more frameworks, more controls, more risk indicators, more audit findings, more cyber telemetry, more third-party intelligence, more sustainability metrics, more resilience data, more regulatory alerts, more policies, more evidence, more questionnaires, more issues, more exceptions, more dashboards, more, more and more . . .

We are swimming in knowledge. Some organizations are drowning in it. But knowledge is not enough. Knowledge tells us what exists. Imagination helps us decipher what it means. Knowledge catalogs the present: imagination designs the future. Knowledge can document the ingredients, while imagination creates the experience.

That is the lesson of Alchemist. It is also the lesson for the future of GRC.

The Alchemist as a Model for GRC

Alchemist describes its experience through the language of transformation. Alchemists in centuries long past sought to purify, mature, and perfect physical objects. In the same way, Alchemist aims to transform and transcend the nature and perception of food and dining.

That is a powerful metaphor for GRC. GRC, at its best, is also an act of transformation. It takes fragmented things and makes them coherent. It takes uncertainty and gives it structure. It takes obligations and connects them to accountability. It takes risks and places them in the context of objectives. It takes controls and shows whether they are relevant, effective, redundant, or missing. It takes incidents, issues, losses, complaints, findings, and failures and turns them into learning. It takes governance out of the boardroom, risk out of the register, and compliance out of the checklist, bringing them into the rhythm of the business.

That is not bureaucracy. That is alchemy. The problem is that many organizations still approach GRC as if it were a storage problem. They gather risks in one place, controls in another, obligations somewhere else, policies in a portal, third-party data in a procurement system, audit findings in spreadsheets, incidents in a case management tool, resilience plans in documents, and objectives in strategy decks that never shake hands with the rest of the architecture.

Then organizations wonder why GRC feels fragmented. That is like giving a chef access to a warehouse of ingredients but no kitchen, no recipe, no menu, no service model, no trained team, no understanding of the diner, no coordination, no timing, and no purpose beyond “please produce something impressive by the end of the quarter.”

Good luck. Bon appétit. May the risk register be ever in your favor.

Alchemist works because everything is expertly curated and designed. The experience has strategy. It has process. It has information. It has technology. It has choreography. It has timing. It has roles. It has space. It has story. It has purpose. It has execution.

That is exactly what GRC needs.

Strategy: The Experience Begins Before the First Course

One of the most important lessons from Alchemist is that the experience begins long before anything is served. Even the anticipation build up as you are forced to wait outside the door. It is intentionally designed to reset your mind to enter a new world and create intrigue.  

There is a clear vision. There is a purpose. There is a philosophy. Every element exists in relation to the whole. The evening is not a random sequence of clever dishes. It is an orchestrated journey.

This is where many GRC programs fail.

They begin with activity instead of strategy. Someone needs a risk assessment. Someone else needs a control test. Compliance needs policy attestations. Audit needs evidence. Procurement needs third-party due diligence. Legal needs regulatory change tracking. The board wants reporting. The regulator wants accountability. The business wants all of this to stop getting in the way.

In response, the organization buys tools, configures workflows, launches assessments, builds dashboards, and creates committees. Then it calls the result “integrated GRC.”

But activity is not strategy. In the restaurant industry, my son says his colleagues and him have a term for people who take this approach. They call them ‘busy idiots.’

An integrated GRC strategy begins with the decisions and objectives of the organization. 

• What is the business trying to achieve? 
• What uncertainty could affect those objectives? 
• What obligations define the parameters of integrity? 
• What controls are necessary to ensure reliability? 
• What information is needed to make decisions? 
• What assurance is required to build confidence? 
• What technology architecture supports this in a way that is agile, connected, and sustainable?

Strategy gives GRC its purpose. Without strategy, GRC becomes a mundane, aimless buffet of disconnected functions. Everyone fills their plate. Nobody has designed the meal.

Process: The Choreography of GRC

The experience at Alchemist is intentionally choreographed. Guests move through physical spaces, and the experience unfolds through different stages. Each impression has a place, a sequence, a role, and a moment. Nothing feels accidental.

Good GRC is also choreography. It is not enough to define a risk process, a compliance process, an audit process, a third-party process, a policy process, and an incident process as separate operating models. These processes interact. They overlap. They inform each other. A regulatory change may require a policy update, control redesign, training, third-party communication, monitoring, and assurance. A third-party incident may affect operational resilience, contractual obligations, cyber risk, business continuity, customer commitments, and board reporting. A failed control may indicate a weak process, a poorly understood obligation, insufficient accountability, or a technology dependency that no one mapped correctly.

GRC processes are not parallel lines. They are an ecosystem.

This is where imagination matters. Anyone can draw a process map, and many do. Some are even useful. But imagination asks how the process works in reality. 

• How does the business experience it? 
• Where does accountability break down? 
• Where do handoffs fail? 
• Where is data duplicated? 
• Where are decisions delayed? 
• Where does the process create friction without reducing risk? 
• Where does the organization mistake motion for progress?

The future of GRC requires process design that is business-integrated, role-aware, risk-informed, and adaptive. It has to recognize that the organization is not static. Strategies change. Markets shift. Regulations expand. Third parties come and go. Technologies evolve. Threats emerge. Controls degrade. People move. Data changes. Business models transform.

The GRC process has to be designed for movement.

Information: The Wall of Flavors

One of the most striking parts of Alchemist is the test kitchen and the wall of flavors in jars (see blog article post picture). To a chef, this is not simply a wall of interesting ingredients. It is a vocabulary. It is possibility stored in physical form. It is knowledge waiting to be combined through imagination.

That wall is a perfect metaphor for GRC information architecture. Imagine the GRC equivalent: a wall of objectives, risks, obligations, controls, policies, assets, processes, third parties, incidents, issues, metrics, losses, regulations, authorities, business units, products, geographies, and assurance activities. Each jar matters. Each has its own identity. Each contains something useful. But the real value is not in the jar. The value is in the relationship between the jars.

This is where so many GRC platforms and programs have historically struggled. They collect the jars. They label the jars. They count the jars. They produce reports on jar ownership, jar status, jar review cycles, and overdue jar attestations. 

But they do not understand the recipe. A risk without an objective is abstract. A control without an obligation or risk context is noise. A policy without mapped requirements is a document. A regulatory change without business impact analysis is a news alert. A third-party assessment without relationship context is administrative theater. An issue without root cause analysis is a recurring future failure politely waiting its turn.

The future of GRC depends on connected information. Organizations need a common information architecture that understands the relationships between objectives, risks, obligations, controls, processes, assets, third parties, policies, incidents, issues, and performance. This is the foundation for what I increasingly talk about as GRC 7.0: GRC Orchestrate. It is not simply workflow. It is not simply content. It is not simply analytics. It is the orchestration of governance, performance, risk, and compliance across the extended enterprise.

The wall of flavors becomes powerful and effective when the chef knows how to combine them.

The wall of GRC information becomes powerful and effective when the organization understands context and objects. This is why GRC technologies need to move beyond traditional relational databases to object oriented graph databases (more on that coming next week in this blog).

Technology: The Architecture of the Experience

At Alchemist, technology is everywhere, but it does not dominate the experience. It supports the experience. It enables the imagination. It creates atmosphere, timing, coordination, and precision. While not always visibly apparent, it is present, but it is not the point.

That is exactly how GRC technology should work. Too many organizations still let the tool define the program. They buy a platform and then conform their GRC operating model to whatever the system can do most easily. This is backwards. Technology should support the strategy, process, and information architecture of GRC. It should enable the experience of governance, risk management, and compliance across the business. It should not force everyone into rigid forms and workflows that were designed for another organization, another decade, or another regulatory problem.

The best GRC technology is not merely a system of record. It is a system of intelligence. It brings together structured and unstructured information. It connects internal and external data. It supports decision-making. It enables accountability. It provides visibility into change. It understands relationships. It integrates with the broader business technology environment. It becomes part of the organization’s nervous system.

This is where AI enters the conversation. AI is very good at processing knowledge. It can read, summarize, classify, map, compare, detect patterns, generate drafts, identify anomalies, recommend linkages, and accelerate analysis. In GRC, that is enormously valuable. AI can help organizations process regulatory change, map obligations to controls, analyze policy gaps, summarize incidents, review third-party risk intelligence, draft control narratives, and identify patterns across issues and losses.

But AI does not have imagination. AI can process what is known. It can work from patterns, data, language, models, and training. It can accelerate the handling of knowledge. But imagination is different. Imagination asks what could be. It sees the unusual connection. It challenges the assumption. It creates a new model. It recognizes that the future may not be a more efficient version of the past.

That is human. The future of GRC is not AI replacing human judgment. It is AI augmenting human capability. It is AI handling the knowledge burden so humans can focus more deeply on context, judgment, creativity, ethics, strategy, and imagination.

• Knowledge and imagination are both needed.
• Knowledge without imagination becomes bureaucracy.
• Imagination without knowledge becomes fantasy.
• Together, they become transformation.

The Business-Orchestrated Future of GRC

The organizations I am interacting with are wrestling with this reality. They are not simply asking for another tool to automate existing tasks. They are trying to understand how GRC becomes more connected, intelligent, agile, and aligned with the business.

This is the right direction. The future of GRC is not a bigger repository. It is not another layer of workflow. It is not more dashboards showing stale data in prettier colors. It is not an AI chatbot sprinkled on top of a fragmented architecture like parsley on a poorly assembled plate.

The future of GRC is business-orchestration. It connects governance to objectives. It connects risk to uncertainty. It connects compliance to integrity. It connects performance to accountability. It connects controls to obligations and risks. It connects issues to root causes. It connects third parties to business services and resilience. It connects regulatory change to operational impact. It connects assurance to confidence. It connects data to decisions.

This requires imagination because the organization must see GRC differently, and . . .

• Not as a compliance burden.
• Not as a risk reporting exercise.
• Not as an audit support function.
• Not as a technology implementation.
• Not as a department.

GRC is the capability of the organization to reliably achieve objectives, address uncertainty, and act with integrity. That capability has to be designed with intent. It has to be orchestrated with skill. It has to be experienced by the business in a way that is useful, meaningful, and sustainable.

That is where many GRC programs need their own Alchemist moment.

They need to step through the threshold and leave behind the assumption that GRC is a collection of disconnected activities. They need to see the whole. They need to understand the ingredients, but also the experience. They need to know the jars on the wall, but also the combinations. They need the discipline of knowledge and the courage of imagination.

From the Test Kitchen to the Boardroom

The test kitchen at Alchemist is not just a place where food is prepared. It is where ideas are discovered, explored, refined, tested, matured, and transformed. Some combinations work while others do not. Some become part of the experience while others remain experiments. That is the nature of innovation.

GRC needs more test kitchens. This does not mean reckless experimentation with compliance obligations or controls. I am not suggesting that organizations should take their regulatory requirements, toss them into a blender, add foam, and serve them to the audit committee under a smoke-filled dome.Despite that, I have seen some board reporting that was not far off.

What I mean is that organizations need safe spaces that are cultivated to rethink how GRC works. They need to pilot new approaches. They need to test new information models. They need to explore how AI can improve regulatory analysis, control testing, policy management, third-party monitoring, resilience mapping, and issue management. They need to examine how digital twins can model the organization as well as its processes, dependencies, controls, risks, and obligations. They need to consider how agentic AI can assist in monitoring, routing, escalation, evidence gathering, and decision support.

But all of this must be anchored in governance. Innovation without governance becomes chaos. Governance without innovation becomes stagnation.

The test kitchen is where imagination and discipline meet. That is what GRC needs.

The Human Element

One of the reasons the Alchemist experience works is that it is unapologetically human. Technology supports it. Process structures it. Information informs it. Strategy guides it. But people bring it to life.

That is also true for GRC. We can have the best technology, the most elegant taxonomy, the most complete obligation library, the most advanced analytics, and the most sophisticated AI; but if people do not understand their role in governance, risk management, and compliance, the program will fail. If the business sees GRC as something done to them instead of something that enables them, the program will fail. If accountability is unclear, the program will fail. If culture rejects integrity, the program will fail. If leadership treats GRC as a regulatory cost center instead of a strategic capability, the program will fail.

• Human judgment matters.
• Human imagination matters.
• Human courage matters.

AI can help process the knowledge, but humans must ask the crucial questions. Humans must decide what matters. Humans must challenge the assumptions. Humans must see around corners. Humans must connect ethics with objectives, risk with opportunity, compliance with trust, and governance with performance.

The organizations that will lead in GRC are not those that simply automate the known. They will be the ones that imagine better ways to govern, manage risk, and act with integrity in a world of constant change.

A Call to GRC Imagination

The quote that opened the Alchemist experience stayed with me because it captures the moment we are in.

Knowledge matters. It is essential. We need data. We need evidence. We need obligations mapped. We need risks understood. We need controls tested. We need policies governed. We need issues tracked. We need assurance documented. We need regulatory change monitored. We need third parties assessed. We need resilience validated.

But if all we do is process what is already known, we will only build more efficient versions of the past.

That is not enough.

The future of GRC requires imagination. It requires the imagination to see GRC as a business capability, not a compliance department. It requires the imagination to connect governance, performance, risk, and compliance into one integrated architecture. It requires the imagination to design processes that work in the rhythm of the business. It requires the imagination to build information models that show relationships and context. It requires the imagination to use technology and AI not as gimmicks, but as enablers of better decisions. It requires the imagination to ask what GRC should become, not merely how GRC can be automated.

Alchemist reminds us that transformation does not happen by accident:

• It is designed.
• It is orchestrated.
• It is experienced.

The same must be true of GRC. The organizations that get this right will move beyond fragmented systems, static reports, and compliance theater. They will build GRC that is alive to the business, responsive to change, grounded in knowledge, and elevated by imagination.

That is the future of GRC. And perhaps that is the real alchemy: transforming the raw materials of objectives, uncertainty, obligations, controls, information, technology, and human judgment into an integrated capability that helps the organization achieve what it sets out to achieve, navigate what could disrupt it, and act with integrity along the way.

Knowledge gives us the ingredients.

Imagination creates the experience.

Let’s get into the GRC kitchen and get cooking!

---

Reflections on my presentation at apexanalytix Icon 2026 on building the supplier risk business case

In my presentation at Icon 2026 in Scottsdale/Phoenix, I wanted to put one point on the table immediately and directly: we are measuring the value of third-party and supplier risk management wrong. Too often, organizations build the business case for supplier risk management as though it were simply a technology purchase, a compliance exercise, or an efficiency project . . . That framing is too small. It misses the real value.

The business case for supplier and third-party risk management is not primarily about workflow, questionnaires, or even controls. It is about avoided disruption, avoided loss, improved decisions, preserved continuity, and the confidence to move faster through uncertainty rather than slower. That was the heart of my session, Building the Supplier Risk Business Case: Quantifying Avoided Disruption and Loss, and it was a message that clearly resonated with the room.

Before going further, I want to thank apexanalytix for having me at Icon 2026, both on the analyst panel and in this breakout session. It was an excellent event, with a highly engaged audience and the kind of practical conversation that makes a conference worthwhile. People in the room were not there to be entertained by vague promises. They were there to work through a very real challenge: how to articulate the value of supplier risk management in a way that business leaders, finance leaders, procurement leaders, and risk leaders will actually support.

The business case has been framed too narrowly

For too many organizations, the TPRM story sounds something like this: better controls, better compliance, more streamlined onboarding, less manual work. None of that is wrong. It is simply incomplete.

Supplier and third-party risk management is a strategic business capability. It helps the organization understand and navigate uncertainty across the extended enterprise. It helps avoid fraud, disruption, cyber incidents, compliance failures, operational breakdowns, and supplier-driven surprises. It helps leaders understand what is actually at risk if a relationship fails. And it helps the organization move ahead with greater confidence because it is no longer operating blind.

That is why I argued in the session that TPRM should not be the handbrake. It should be the navigation system. It should help the organization steer safely through uncertainty toward its objectives in third-party relationships.

The modern organization is the extended enterprise

A core starting point in my presentation was that the modern organization is not limited to its employees, facilities, and owned assets. It is the extended enterprise: a network of suppliers, logistics partners, outsourcers, cloud providers, software vendors, manufacturers, agents, contractors, and service providers. Across industries, large portions of how value is created and delivered now happen across that network.

That changes the risk conversation fundamentally. If the business operates through third parties, then risk in those relationships is not peripheral. It is risk to the business itself. A supplier cyber incident, sanctions issue, fraud event, continuity failure, or labor problem is not someone else’s issue. It is the enterprise’s issue. That is why supplier risk is not an external side topic. It is central to how objectives are achieved.

The baseline is instability

Another point I stressed is that the baseline in the extended enterprise is not stability. It is instability. Too many organizations still act as though disruption is the exception and calm is the norm. That is backwards. Suppliers change ownership. Financial health shifts. regulations evolve. Cyber vulnerabilities emerge. Sanctions lists change. Extreme weather disrupts facilities. Transportation routes break down. The baseline is motion, change, and uncertainty.

That is why I used the image of a lighthouse in a storm. A lighthouse is not built for calm seas. It exists because instability is the operating context. TPRM has to be understood the same way. It is not there to manage rare exceptions. It exists because instability is normal. That means one-and-done onboarding, annual reviews, and static spreadsheets are not enough. Organizations need continuous visibility, sensing, prioritization, and response.

We focus too much on spend and not enough on value at risk

One of the most persistent mistakes I see is the assumption that the suppliers with the largest spend are automatically the riskiest. Spend matters, but spend does not equal exposure. A relatively small supplier can create enormous risk if it sits at a critical dependency point. A niche technology vendor with privileged access can create serious cyber exposure. A small sole-source supplier can halt production. A modest service provider handling banking or master data can become a fraud pathway.

This is where value at risk becomes essential. The better question is not simply what we spend with a supplier. The better question is: what is at risk if this supplier fails, is compromised, or creates disruption? That is the strategic lens leadership needs. It captures revenue, continuity, customer impact, compliance exposure, brand harm, and operational dependency, not just spend.

Too much TPRM is still looking in the rearview mirror

I also pushed on a point I feel strongly about: too much supplier and third-party risk management is still backward-looking. It tells us what questionnaire was completed, what review was filed, what issue was documented, and what approval happened. That may satisfy a recordkeeping instinct, but it often does little to help the organization see what is coming.

The rearview mirror matters, but you cannot drive by staring into it. You need to see the road ahead. TPRM has to become more present-aware and future-aware through better data, continuous monitoring, event-driven intelligence, and scenario analysis. The real value is not in describing the past more elegantly. It is in helping the organization anticipate the future with fewer surprises.

Risk is our business

Yes, I brought Captain Kirk into the room. Again.

I used the familiar Star Trek line, “Risk is our business,” because it gets to something important. Risk is not an exception to business. It is inherent in any mission worth pursuing. The question is not whether risk exists. The question is how intelligently the organization understands, governs, and navigates it.

That is especially true in the extended enterprise. If the business creates value through suppliers, service providers, and partners, then risk in those relationships is inseparable from the mission of the business itself. A third-party cyber incident, supplier failure, sanctions issue, corruption event, or continuity disruption is part of our business reality. TPRM, then, is not about becoming risk averse. It is about becoming mission capable in uncertainty.

TPRM requires orchestration

Supplier and third-party risk management is also inherently cross-enterprise. Procurement, finance, AP, legal, compliance, information security, privacy, sustainability, operations, and business owners all see different dimensions of third-party exposure. Without orchestration, the result is duplication, delay, supplier fatigue, conflicting data, and fragmented decisions.

That is why I used the metaphor of the orchestra and the conductor. Each function may be highly skilled, but without a conductor you do not get harmony. You get noise. Mature TPRM requires orchestration across strategy, process, information, and technology. That is not merely a nice design principle. It is what makes the function coherent enough to actually reduce exposure and support better decisions.

The value model: efficiency, effectiveness, resilience, and agility

The centerpiece of the session was the four-part model I use to frame TPRM value: efficiency, effectiveness, resilience, and agility. The business case is far stronger when it includes all four.

• Efficiency is the traditional ROI story: time saved, money saved, friction reduced, duplicate work eliminated, and capacity created. But efficiency is most powerful not because it cuts cost. It is powerful because it frees skilled people from administrative mechanics so they can spend more time on planning, analysis, and action.
• Effectiveness is where the case gets more strategic. You can make a process faster without making it better. Effectiveness asks whether exposure is actually being reduced. Are risky suppliers identified earlier? Are fraud exposures blocked? Are control failures and preventable issues reduced? That is why I emphasized: measure exposure reduced, not just controls added.
• Resilience is the ability to anticipate, absorb, and recover from disruption. No program eliminates all risk. The question is whether the organization can detect change faster, escalate sooner, understand dependencies better, and keep an issue from becoming a crisis.
• Agility is where TPRM becomes a true business enabler. It means moving ahead through uncertainty with speed and confidence. It means onboarding strategic suppliers faster, adapting to regulatory change, running scenario analysis more effectively, and shifting the function from reactive administration to predictive and prescriptive support.

Together, these four dimensions tell a fuller and more credible story than ROI alone ever can.

Quantification has to move beyond activity

A big part of the session was focused on quantification. We can and should measure more than activities completed. We can measure reductions in high-risk exposure, improvements in detection speed, reductions in unresolved critical issues, movement from inherent to residual risk, blocked fraud pathways, avoided loss events, faster response, and stronger continuity preparedness.

In the examples I used, including a large retailer case, the story quickly grew beyond labor savings into avoided fines, avoided legal costs, fraud prevention, cyber exposure reduction, and materially lower loss potential. That is exactly the point. Once organizations start quantifying avoided disruption and avoided loss, the conversation becomes much bigger than “better process.”

The end game is business confidence

I closed the session with what I believe is the real destination of this whole discussion: business confidence. Not blind optimism. Not the illusion of zero risk. But informed confidence. Confidence that the organization understands its third-party ecosystem well enough to act. Confidence that it can move with the right mix of speed and rigor. Confidence that it can identify meaningful uncertainty early enough to avoid surprise. Confidence that it can absorb disruption without losing continuity. Confidence that it can move forward strategically through a world where instability is the norm.

That is why we have to stop measuring TPRM value as though it were merely a control cost or a workflow automation story. We need to measure it in terms of avoided disruption, avoided loss, reduced uncertainty, stronger decisions, greater resilience, and better business confidence.

That is the call to action I brought to Icon 2026. Judging from the engagement at the conference, it is a conversation this market is ready to have.

The Market Has Outgrown the Collection-of-Modules Model

For years, governance, risk management, and compliance (GRC) has operated on an assumption that now needs to be challenged: that if you add enough modules together, you somehow create an enterprise platform. Organizations have accumulated solutions for enterprise risk, compliance, policy management, third-party risk, ethics, audit, cyber risk, business continuity, and operational resilience. Vendors have expanded portfolios, connected acquisitions, and wrapped broader messaging around these capabilities. But in too many cases, what emerged was not a true platform. It was a larger collection of disconnected parts.

That distinction matters. A shared interface is not orchestration. A common login is not a transformation. A broader portfolio is not, by itself, a command center for the enterprise. It may appear to converge, but the underlying reality often remains fragmented. Data moves imperfectly. Context is lost. Leadership receives reporting, but not always a clear understanding of how issues connect across the business.

This is why I continue to argue that the market is moving into a new phase . . .

[The rest of this blog can be read on the Mitratech Management blog, where GRC 20/20’s Michael Rasmussen is a Guest Blogger]

From the Kiosk to the Table: Why a True Industry Analyst Still Matters

I have been thinking about this a great deal lately, and oddly enough, the reflection sharpened while planning an intense stretch of work in Denmark this April.

I will be busy there, as I usually am when I travel, meeting with organizations, working through RFPs, discussing requirements, evaluating solutions, and engaging the broader market in real-world conversations. That is how I work. I do not believe meaningful market intelligence comes from sitting at a distance and processing submissions. It comes from being in the field. It comes from seeing how organizations actually struggle with decisions, where software succeeds, where it fails, where implementations break down, where services firms add value, and where the market is selling confidence without substance.

As I added several more days to my Denmark trip, I managed to secure reservations at Alchemist in Copenhagen. That, in itself, was reason enough to smile. Alchemist is not simply a restaurant. It is an experience. It is a place where every detail matters, where expertise guides the evening, where the experience is intentional, curated, and deeply personal. And as I thought about that reservation, and about the work I would be doing across Denmark before and around it, it struck me just how powerfully this contrasts with what is happening in the analyst industry today . . .

Too much of what passes for industry analysis now feels like walking into a fast-food restaurant and ordering from a kiosk.

You touch a screen. You get a standardized menu. The process is efficient, mechanical, and impersonal. The system does not know your tastes. It does not understand the occasion. It does not guide you to what is truly worth your time. It cannot tell you what to avoid. It cannot explain what pairs well together. It cannot call over the sommelier when the question becomes more nuanced. It gives you an output, but not an experience. It gives you an answer, but not wisdom.

That, increasingly, is what the large analyst firms have become.

By contrast, the true industry analyst, the kind of analyst I have always sought to be, in my 26 years as an analyst, and the kind I believe the market still desperately needs, is much more like the Michelin-star dining experience. The true analyst is not a kiosk. The true analyst is the informed guide. The trusted waiter. The professional who knows the menu, understands the kitchen, asks the right questions, learns what matters to the guest, and then helps shape the right experience. And when the moment calls for deeper specialization, the true analyst knows how to bring in the equivalent of the sommelier: the implementation expert, the specialist practitioner, the professional services perspective, the lived customer reality.

That is what meaningful analyst work should deliver.

The growing problem in the analyst industry

I have watched the major analyst firms commoditize their research as several continue to lose revenue and conduct layoffs. In doing so, they are losing something essential. They are losing relevance. They are losing trust. And yes, they are losing revenue because buyers increasingly sense the difference between generic process and genuine insight.

The old model of industry analysis, at its best, was relational, investigative, and grounded. It required analysts to spend time with buyers, to challenge solution providers, to sit through real demonstrations, to interview actual client references, to understand implementation realities, and to evaluate the broader ecosystem surrounding technology decisions. It was labor-intensive, but it produced insight that mattered.

Now, much of that has been replaced with shortcuts.

Instead of insisting on live demonstrations, some firms ask providers to submit recorded video demos. I find that deeply problematic. You can make almost anything look good in a video. A vendor can script the flow, avoid weak areas, skip over awkward transitions, hide usability issues, and present a polished fantasy rather than operational reality. A recorded demo may be tidy, but it is not truth. Truth is found in a live session where the analyst can interrupt and say . . .

“Stop there. Show me how this works across departments. Show me the exception path. Show me the reporting. Show me how you handle changes in regulatory obligations. Show me what this looks like when the process gets messy.”

That is where facts emerge.

The same issue applies to customer validation. Instead of talking live to client references, some firms rely on web surveys. Again, this is not the same thing. It is not even close. A survey gives you a set of answers. A conversation gives you understanding. In a survey, you rarely find the hesitation, the caveat, the side comment, the frustration, the work-around, the nuance that reveals what it is really like to buy, implement, and use a solution. And too often, I have discovered, the solution providers provide the answers for their client references to submit to these surveys to “make it easier” for them.

In a live conversation, I can ask why the customer chose the solution, what almost made them walk away, what the provider did well, what went wrong, what functionality is still missing, what the partner brought to the engagement, and what they would do differently if they had to start over.

And then I can follow the rabbit trails . . . Those rabbit trails matter. In fact, they are often where the truth lives.

Now we are also seeing more pressure to let AI answer buyer inquiries. I am enthusiastic about the role of AI in many areas. I have written and spoken extensively on the future of AI in GRC and beyond. But I do not confuse automation with judgment. I do not confuse generated answers with experienced counsel. AI can accelerate access to information. It cannot replace the informed discernment that comes from years in the field, thousands of conversations, direct observation of markets, and a willingness to challenge what looks polished on the surface.

What buyers need in complex markets is not just information. They need interpretation. They need perspective. They need context. They need someone who has been there, seen it, tested it, challenged it, and knows how to separate hype from substance.

Why the kiosk fails the buyer

The kiosk is not evil. It is simply limited.

It is built for standardization. It is built for scale. It is built to move people through a process efficiently. But analyst research is not supposed to be a mass-produced meal. It is supposed to be informed guidance through a complex decision.

When buyers are evaluating technology, especially in difficult markets, they do not need an impersonal interface that spits out generic recommendations. They need someone to understand their context.

• What are they actually trying to solve?
• What is their maturity?
• What are their regulatory exposures?
• What is their operating model?
• What level of configuration can they realistically support?
• What internal competencies do they have?
• Where are the fault lines in process, data, and ownership?
• What cultural issues will affect adoption?
• What dependencies will shape success?

A kiosk does not ask those questions well. A true analyst does.

At a Michelin-star restaurant, the experience begins with understanding the guest. The waiter guides, advises, suggests, and calibrates. They do not merely hand over options. They help make sense of them. They know what works together. They know what is excellent tonight. They know where the kitchen shines. And if you want to go deeper, they bring in the sommelier, someone with specialized expertise who can help craft a more complete experience.

That is a much better metaphor for how analyst work should function.

What a true industry analyst actually delivers

A true industry analyst delivers much more than market reports, rankings, and graphics. A true analyst delivers clarity.

That clarity starts with buyer needs and requirements. Too often, evaluations begin with the solutions and work backward. I think that is precisely the wrong place to start. The starting point must be the buyer:

• the objectives they are trying to achieve,
• the uncertainty they are trying to navigate,
• the integrity they are trying to maintain, and
• the capabilities they need to build.

The analyst has to understand not just a list of requirements, but the business and operational context in which those requirements exist.

From there, the analyst evaluates how software solutions actually map to those needs. Not in theory. Not in marketing slides. Not in a recorded vendor-submitted video. In reality.

• How does the solution perform?
• How flexible is it?
• How deep is the functionality?
• How coherent is the data model?
• How usable is it?
• How scalable is it?
• Where does it excel?
• Where does it require work-arounds?
• What does it take to make it successful?
• How much depends on implementation quality?
• How much depends on content?
• How much depends on internal governance?

And then there is the role of professional services firms . . . which is often underappreciated in market evaluations and yet critically important. A solution is not merely software. In many cases it is software plus implementation capability, configuration expertise, process design, integration knowledge, industry context, training, managed services, and long-term support. A weak services ecosystem can undermine an otherwise promising product. A strong services partner can elevate the value of a platform by helping the buyer operationalize it effectively. If you are not looking at the role of services, you are not looking at the complete market reality.

This is why I have long believed that good industry analysis must connect the full chain: buyer needs, solution capability, and services delivery.

Why this matters so much in GRC

This is especially true in governance, risk management, and compliance.

GRC is not a simple, clean, neatly bounded software market. It is broad, interconnected, and often misunderstood. It touches performance, objectives, risk, compliance, audit, policy, regulatory change, third-party risk, cyber risk, operational resilience, internal control, sustainability, investigations, incident management, and more. It spans industries, functions, lines of defense, and regulatory regimes. It is shaped by business objectives, uncertainty, and integrity. It is affected by organization structure, culture, process maturity, and technology architecture.

That means simplistic evaluations are especially dangerous in GRC.

A solution can look impressive in a narrow demo and still be the wrong fit for the organization. A platform can sit in the upper right of some glossy analyst graphic and still fail to meet the buyer’s actual needs. Another solution may not photograph as well in a two-dimensional ranking but may be far better aligned to the organization’s use case, maturity, and budget. This is why context matters so much. This is why I do not trust abstracted evaluations that reduce a complex decision to a picture.

I know how those graphics are made. I wrote four Forrester Waves during my time at Forrester. I understand the mechanics. I understand the desire to present market choices in a concise visual form. But I also understand how many bad decisions can result from taking a multidimensional market and flattening it into a two-dimensional graphic.

A quadrant or wave may create the illusion of clarity. It does not necessarily produce actual clarity. Markets are not that simple. Buyer needs are not that simple. GRC certainly is not that simple.

My approach: I require seeing and hearing the truth

My own view is straightforward . . .

I want to see the solution. In fact, I require seeing the solution. I am not interested in a choreographed video that lets a provider edit away the rough edges. I want live demonstrations where I can ask hard questions and go off script. I want to see how the solution really works, not merely how marketing wants it to appear.

I also require talking to client references. If a solution provider cannot provide live customer references, that raises immediate red flags for me, and I believe it should for buyers as well. I want to talk to those clients directly. I want to know why they selected the solution, what they hoped to achieve, what the experience was really like, what disappointed them, what functionality is missing, what went sideways in implementation, where the partner helped, where the provider underdelivered, and whether they would make the same decision again.

Those conversations are invaluable because they do not stay on the surface. They lead to follow-up questions. They reveal contradictions. They expose assumptions. They show where success was earned and where it was merely claimed.

But I do not stop with provider-arranged references . . .

As I travel the world, I make myself available to meet with organizations of all sizes and industries, whether or not they were introduced by the providers I cover. Those conversations often give me even more valuable perspective because they are less curated and more candid. I hear what organizations really struggle with. I hear what they wish they had known earlier. I hear how the market is behaving from the buyer’s seat, not just the provider’s podium. There are times I have had twelve meetings in one day while visiting a city . . . and that is true market research, analyst work!

I also spend time with the professional services firms implementing and advising on these solutions. That matters immensely. Services firms often know where the bones are buried. They know which platforms are elegant in a demo but difficult in the field. They know where configuration becomes complexity. They know where content is weak, where integrations break, where change management is underestimated, and where the difference between success and failure lies not in the feature list but in the delivery model.

And then there is the RFP work . . .

I roll up my sleeves and go deep in RFPs and objective advisory because that is where theory meets consequences. In those moments, requirements have to become real. Trade-offs have to be faced. Provider narratives have to be tested. This is where one sees whether a solution truly fits the buyer’s needs or merely sounds good in broad analyst language. It is one thing to discuss a market at thirty thousand feet. It is another thing entirely to help an organization make a decision that will shape operations, risk visibility, compliance posture, and investment for years to come.

That is real analyst work!

This is what GRC 20/20 Research is built to do

This is also exactly what I have built GRC 20/20 Research to deliver in the analyst world, as well as its sister company with the team at GRC Report to expand this to governance, risk management, and compliance news from around the world and curated expert commentary and insights.

GRC 20/20 Research provides clarity of insight into governance, risk management, and compliance solutions and strategies through objective market research, benchmarking, training, and analysis. We provide independent and objective insight into leading GRC practices and processes, including market dynamics and intelligence, risk, regulatory and technology trends, competitive landscapes, market sizing, expenditure priorities, and mergers and acquisitions.

But more than that, GRC 20/20 serves the entire ecosystem . . .

We serve buyers, the organizations purchasing and deploying GRC solutions and trying to navigate through a noisy, fast-changing, and often confusing market. We serve professional services firms that help organizations implement, operationalize, and optimize GRC strategies and technology. And we serve solution providers, helping them better understand market demand, buyer requirements, product direction, competitive positioning, partner strategies, and growth opportunities.

That is why I describe GRC 20/20 in three connected ways.

• First, we are a buyer advocate. I help organizations navigate hyperbole to select solutions that are practical and can actually deliver on requirements. Simply put, I help buyers select the right solution or set of solutions for their needs and get the most from their investment.
• Second, we are a solution strategist. I help GRC solution providers understand buyer demand and improve product, marketing, sales, partner, content, and growth strategies. Simply put, I help good GRC solutions become great GRC solutions.
• Third, we are a market evangelist. I educate and advocate for GRC strategies that deliver value and results through the right combination of technology, content, and services. Simply put, I define the future of GRC and help the market understand where it is headed.

These roles are connected. They have to be. You cannot advise buyers well unless you truly understand the provider landscape. You cannot guide providers well unless you understand buyer pain and market direction. You cannot evangelize the market well unless you are grounded in the reality of what works in practice.

Denmark, Alchemist, and the reminder of what excellence feels like

That is why this upcoming Denmark trip has stayed in my mind . . . I will be there doing what I always do: meeting with organizations, working through practical selection and strategy issues, engaging RFPs, discussing the market, and learning directly from those who live these challenges every day. That is not separate from analyst work. That is analyst work.

And then, because I extended the trip several more days, I will get to experience Alchemist!

I find that fitting.

Alchemist is known not for speed or standardization, but for depth, intentionality, craft, and an immersive experience guided by people who understand precisely what they are delivering. It is not simply about receiving food. It is about being led through an experience by people who know what matters and how to make the whole greater than the parts.

That is the opposite of a kiosk. And that is the opposite of commoditized analyst research.

The more I thought about it, the more the analogy stayed with me. Too much of the analyst industry is becoming a kiosk: impersonal, generic, efficient, and detached. Meanwhile, what buyers truly need, especially in a market as nuanced and consequential as GRC, is something much closer to the Michelin-star model: personal guidance, informed recommendation, contextual judgment, and the ability to bring in deeper expertise when necessary.

That is the kind of analyst experience I believe in. That is the kind of analyst experience I work to deliver.

The future belongs to trusted guides, not generic outputs

The future of industry analysis does not belong to those who commoditize insight into templates, surveys, videos, rankings, and automated responses. That may scale, but scale alone does not create relevance. It creates volume. Buyers are not starving for volume. They are starving for judgment.

The future belongs to trusted guides . . . It belongs to analysts who know how to connect buyer needs to solution realities and to the services ecosystem that makes outcomes possible. It belongs to analysts who are willing to ask hard questions, dig into uncomfortable truths, challenge polished narratives, and stay close to what is really happening in the field. It belongs to analysts who see markets not as graphics to be produced, but as ecosystems to be understood.

In GRC, perhaps more than anywhere else, this matters. The stakes are too high, the complexity too great, and the consequences too real to settle for kiosk thinking.

That is why I still believe so strongly in objective, rigorous, hands-on industry analysis. It is why I still insist on seeing the solution. It is why I still insist on talking to customers. It is why I spend time with professional services firms. It is why I stay engaged in RFPs. It is why I travel, meet, listen, challenge, and learn.

And it is why, as I prepare for Denmark, balancing a demanding schedule of real work in the GRC market with the anticipation of an evening at Alchemist, I am reminded of a simple truth:

When the choice matters, no one really wants a kiosk . . . They want a guide.

I am increasingly concerned by how loosely the term Agentic AI is being used across the governance, risk management, and compliance market. What should be a meaningful distinction in capability is rapidly becoming a fashionable label applied to almost anything with a prompt, a workflow trigger, or a generative text output. This is not a minor issue of terminology. It is a growing problem in market understanding, buyer expectations, and strategic technology decisions.

The GRC market has always had a tendency to repackage familiar capabilities in the language of the moment. We have seen this with “intelligent,” “predictive,” “cognitive,” “continuous,” and “autonomous.” Today, the favored term is “agentic.” It appears in product messaging, sales presentations, feature announcements, and roadmap conversations with increasing frequency. Yet in many cases, what is being described is not truly agentic AI. It is useful AI, yes. It may even be innovative AI. But that does not make it agentic in the fuller and more meaningful sense.

This matters because organizations are being asked to invest in these capabilities. Boards, executives, risk functions, compliance teams, audit leaders, and technology decision-makers are being told that a new era of intelligent digital workers has arrived. They are being encouraged to believe that their GRC platforms can now reason, act, and adapt in ways that fundamentally transform governance, risk, and compliance operations. In some cases, that promise may eventually be realized. But in far too many cases today, the reality falls well short of the rhetoric.

The Problem with the Label

The term “agentic AI” should imply something substantive. It should refer to AI that does more than simply respond to a prompt or generate content on demand. A genuinely agentic capability should be able to understand an objective, evaluate context, reason through a problem, develop a sequence of actions, use tools or data sources as needed, adapt to changing conditions, and work toward an outcome with some bounded level of autonomy. That is a meaningful step beyond traditional workflow automation or embedded AI assistance.

Yet much of what is being marketed as agentic AI in GRC today looks more like a familiar set of features with new branding layered on top. A system may populate a field with AI-generated text based on other fields in a record. A workflow may trigger an AI-generated summary when a status changes. A chatbot may answer questions from a limited body of content. A recommendation engine may suggest the next step in a process. A rules-driven automation may invoke a language model and present the result in a dashboard, a form, or a case record. These are not without value. In many cases, they are helpful, efficient, and commercially relevant. But they are not the same thing as an autonomous or semi-autonomous agent pursuing an objective across a broader business context.

The issue is not that these features exist. The issue is that the market increasingly collapses all AI-enabled capability into a single term and, in doing so, erodes precision. When everything becomes “agentic,” the word itself begins to lose meaning.

What Often Gets Labeled “Agentic” But Is Not

To be clear, there are many capabilities in the market that are useful and worthwhile but should not be described as agentic AI. Examples include:

• An AI-generated summary in a form, record, or case file that simply turns structured data into narrative text.
• A prompt-based assistant embedded in a workflow step that helps a user draft content, complete a field, or suggest a response.
• A rules-triggered automation that calls an LLM to classify, summarize, or enrich a record when a status changes.
• A chatbot over policies, controls, or regulations that retrieves and answers from a limited corpus but does not act on anything.
• A recommendation engine for next best action that suggests a task or reviewer based on predefined logic.
• An AI-enhanced workflow script that still follows a deterministic process but has generative output inserted into the flow.
• Auto-population of risk or compliance fields based on related record data, templates, or previous entries.
• A single-step task bot that performs one action in a narrow context but does not reason across a broader process or objective.

Again, these can be good capabilities. Some are very good capabilities. But a useful AI feature is not automatically an agent.

Why This Matters So Much in GRC

In many software markets, exaggerated language is annoying but manageable. In GRC, it is more consequential. Governance, risk management, and compliance are not casual administrative domains. They sit at the intersection of strategy, accountability, uncertainty, policy, ethics, internal control, regulatory obligation, and organizational integrity. The systems that support GRC are not simply there to make work faster. They are there to ensure that the organization reliably achieves objectives, addresses uncertainty, and acts with integrity.

That is why accuracy in describing AI capability matters so much.

If a buyer believes they are investing in technology that can coordinate risk analysis across multiple sources, interpret changing regulatory context, plan a sequence of response actions, escalate intelligently, maintain context across cases, and orchestrate work across departments, they are making a strategic architectural decision. If what they are actually buying is a workflow enhancement that generates content in a specific field or recommends the next task from a predefined pattern, then there is a material gap between expectation and reality. That gap will show up in failed transformation initiatives, poor implementation outcomes, misplaced trust, and executive disappointment.

In GRC, poor clarity is not just a product marketing issue. It is a governance issue. Organizations need to know what a system can actually do, where its autonomy begins and ends, how decisions are made, what guardrails are in place, how outputs are verified, how actions are logged, and where human oversight remains essential. Without that clarity, the market risks building castles on buzzwords.

Useful AI Is Not the Same as Agentic AI

Part of the problem is that the market has become uncomfortable with nuance. There is an apparent belief that if a capability is described too precisely, it will sound less exciting. So instead of saying, “this is an AI-assisted workflow feature that summarizes data and populates structured fields,” vendors jump to “agentic AI.” Instead of saying, “this assistant recommends next steps based on configured rules and contextual prompts,” they describe it as an intelligent agent. Instead of saying, “this capability generates outputs inside a defined process,” they imply something much closer to autonomous orchestration.

That kind of inflation helps no one.

There is nothing wrong with AI-assisted workflow features. In fact, many of them are exactly what organizations need right now. They can reduce manual effort, improve consistency, accelerate assessments, support issue management, strengthen policy workflows, help with control documentation, summarize evidence, and enhance user engagement. Those are real benefits. But the value of a capability should stand on its actual merits. It does not need to be elevated into something it is not.

The market should be able to say clearly: this is embedded AI, this is decision support, this is generative assistance, this is rules-driven automation enhanced with AI, and this is an actual agentic capability. Those are different categories. They should not be blurred together simply because “agentic” is currently the most marketable term.

What Truly Agentic Capability Would Look Like in GRC

When I think about real agentic AI in the context of GRC, I am not thinking about a clever chatbot sitting on top of a workflow or a form. I am thinking about a capability that can take an objective such as understanding third-party exposure, coordinating a regulatory change response, maintaining operational resilience, or orchestrating a control review process and then reason across multiple data sources, systems, and decision points to move work forward in a meaningful way.

A truly agentic system in GRC would need to do far more than generate text. It would need to understand objectives in context. It would need to work across processes, not just inside isolated tasks. It would need to manage state, maintain traceability, use tools intentionally, escalate intelligently, adapt when conditions change, and function within clear boundaries of authority and accountability. It would need to know when to act, when to recommend, when to pause, and when to defer to human judgment. It would need to support governance, not bypass it.

In other words, truly agentic AI in GRC would not simply automate pieces of work. It would orchestrate outcomes in alignment with business objectives, risk appetite, policy, and control structure. That is a very high bar. It is also a bar that most currently marketed “agentic” features do not meet.

What True Agentic AI in GRC Might Actually Look Like

To make this practical, examples of genuinely agentic AI in GRC would look more like:

• A third-party risk agent that identifies onboarding requirements, gathers internal and external intelligence, determines inherent risk, requests additional evidence, routes issues to the right stakeholders, tracks responses, and escalates unresolved concerns based on policy and risk appetite.
• A regulatory change agent that monitors changes, interprets relevance to the organization, maps obligations to policies, processes, controls, and business owners, recommends remediation actions, coordinates follow-up, and tracks completion with auditable traceability.
• An operational resilience agent that detects a disruption scenario, identifies impacted services, dependencies, third parties, controls, and obligations, proposes response actions, coordinates tasks across teams, and monitors progress against resilience tolerances.
• A policy governance agent that reviews changes in law, standards, incidents, and control failures, identifies which policies and procedures need revision, drafts proposed updates, routes them for review, tracks approvals, and verifies downstream attestation and training actions.
• An issue and action management agent that evaluates findings from audits, incidents, assessments, and complaints, clusters related issues, proposes remediation plans, coordinates ownership, monitors deadlines, and adjusts escalation paths as new information emerges.
• A control assurance agent that understands the control library, gathers evidence from systems, determines whether testing is needed, adjusts the testing plan based on prior results and risk context, flags exceptions, and coordinates follow-up validation.

These are not simple prompt-and-response features. These are multi-step, context-aware, goal-oriented capabilities operating with bounded autonomy inside a governed framework.

The Questions Buyers Need to Ask

Organizations evaluating GRC technology need to become much more disciplined in how they assess AI claims. They should not be dazzled by terminology or assume that a vendor’s use of the word “agentic” corresponds to a mature capability. Buyers need to interrogate the architecture behind the message.

They need to ask whether the AI is merely generating an output or whether it can actually reason through a sequence of actions. They need to ask whether the capability is confined to a single step in a workflow or whether it can work across a process. They need to ask what tools or systems it can access, how it decides among them, how it handles exceptions, and whether it adapts dynamically to changing context or simply responds to predefined triggers. They need to ask how memory is maintained, how accountability is assigned, how outputs are validated, and what audit trail exists for recommendations and actions. They need to ask where human oversight is required and what governance mechanisms constrain the system’s operation.

These are not peripheral questions. They are central questions. A GRC buyer who cannot answer them does not really understand what they are buying.

Market Clarity Requires Better Discipline

Vendors have every right to innovate. They should continue to push AI forward. The GRC market absolutely needs more intelligent, contextual, and orchestrated capability. It needs systems that reduce fragmentation, connect objectives to risk and compliance activity, and help organizations respond faster and more effectively to uncertainty. AI can and should play a central role in that future.

But the market also needs more discipline in how these capabilities are described.

Not every AI-enabled feature is agentic. Not every automated recommendation is intelligent orchestration. Not every workflow assistant is a digital worker. There is no shame in offering a useful, bounded, practical AI capability. In fact, there is often more value in that than in grand claims of autonomy. What undermines trust is not modest capability. What undermines trust is imprecise positioning.

Analysts need to challenge vague language. Buyers need to demand specificity. Vendors need to be clearer about what their capabilities actually do. If we fail to do that, “agentic AI” will become the next empty phrase in enterprise software, applied so broadly that it signals little and obscures much.

A Call to Action

This is my call to the market.

• Vendors: be precise in your language. Describe what the AI actually does, where it acts, what autonomy it has, and what constraints govern it.
• Buyers: do not purchase the label. Evaluate the architecture, the decision logic, the orchestration capability, the guardrails, and the auditability.
• Analysts and advisors: challenge vague claims and push for meaningful differentiation between AI assistance, AI automation, and true agentic capability.
• Organizations: demand market clarity so strategy, architecture, and investment decisions are grounded in reality rather than hype.

The future of GRC will involve agentic capabilities. I do believe that. But we are not served by pretending that every AI-enhanced feature has already arrived at that future. Precision matters. Integrity in market language matters. And in GRC, where the objective is not merely efficiency but trustworthy governance of the organization, that precision matters a great deal.

The market does not need less innovation. It needs more honesty about what innovation actually is.