Blog

In Norse mythology, Odin possessed a golden ring called Draupnir. Every ninth night, Draupnir produced eight new rings of equal weight. It represented abundance, power, and the almost supernatural multiplication of something valuable.

Someone appears to have dropped Draupnir into the modern software market.

Every day, another platform appears in my inbox . . .

• A new risk application.
• A new compliance tool.
• A new AI governance solution.
• A new third-party risk platform.
• A new control-testing engine.
• A new supplier/third-party risk application.
• A new enterprise GRC platform.

Increasingly, these are presented not as focused applications, but as entirely new GRC platforms poised to disrupt an established market because they have a modern interface, a conversational assistant, and none of the obvious baggage of legacy technology.

One ring becomes eight. Eight become sixty-four. By the end of the month, the marketplace is covered in golden circles, each polished for a demonstration and each claiming to be the original artifact.

This is not simply a GRC issue . . . Vibe coding is changing software development across every industry. It allows people to move from an idea to a functioning application at extraordinary speed. A consultant can turn a methodology into software . . . A risk professional can build a workflow without waiting for the technology department . . . A compliance team can replace a spreadsheet . . .A founder can create a prototype without first raising millions of dollars or assembling a large engineering organization . . .

That democratization is real, and I welcome it. Some of the most interesting innovations in software will come from subject-matter experts who can finally express their ideas directly in technology.

But democratized creation also produces democratized delusion.

The ability to create a working application does not mean someone has built a viable product. A viable product is not automatically an enterprise platform, nor is it automatically a sustainable company, and a sustainable company is not automatically capable of competing in a complex, crowded, and demanding market such as GRC.

Vibe coding has dramatically shortened the distance between an idea and a demonstration. It has not eliminated the much greater distance between a demonstration and dependable enterprise software.

The Marketplace of Golden Rings

The current software market is being flooded with applications that look impressive at first glance. A polished interface asks a user a few questions, generates a risk statement, assigns a score, recommends a control, summarizes a regulation, and creates a dashboard. A chatbot then drafts a policy, classifies an incident, or recommends remediation. The demonstration is smooth, modern, and often more attractive than the interfaces of platforms that have been in the market for fifteen or twenty years.

Then comes the declaration that the established GRC market has been disrupted!!!

I understand the temptation. Many established platforms are slow, expensive, difficult to configure, and frustrating to use. Some carry years of technical debt. Others have grown through acquisition and now consist of multiple products, interfaces, data models, and code bases joined together with varying degrees of elegance. Their licensing structures sometimes appear to have been designed by Loki after a particularly mischievous evening (particularly Service Now’s).

There is room for disruption. There is a need for it.

But disruption requires more than a prettier screen and an artificial intelligence model that has partially learned the language of risk and compliance.

A consultant may understand a regulatory framework exceptionally well and create an elegant application around it. That risk professional may design a better assessment workflow than anything found in a traditional platform. Or that bank, insurer, hospital, or technology company may build an internal application that perfectly suits one part of its operating model. These can all be valuable achievements.

They do not automatically constitute an enterprise GRC platform that can be sold, implemented, secured, maintained, supported, and evolved across hundreds of organizations.

This is where the current enthusiasm becomes dangerous. The ease of creating the first visible portion of an application gives teams the impression that most of the work is complete. In reality, the demonstration is often the easiest part. Beneath that demonstration sit several much harder disciplines:

• Architecture must preserve coherence as complexity grows. The application has to support relationships, hierarchies, histories, permissions, workflows, integrations, and changing organizational structures without becoming brittle every time a customer adds another business unit, framework, jurisdiction, or use case.
• Security and governance must be designed into the product rather than added when the first large prospect asks difficult questions. Identity, access, segregation of duties, encryption, auditability, retention, privacy, model governance, and explainability are not optional enterprise features. They are conditions of entry.
• The product must be repeatable. A platform that works only when the founders configure every workflow, repair every integration, and personally explain every design decision is not yet an enterprise product. It is a collection of bespoke projects held together by heroic effort.
• The provider must be able to deliver what it sells. Implementation methodology, migration tools, documentation, testing, upgrades, support, training, customer success, and operational resilience are part of the solution, even though they rarely appear in the opening demonstration.

The front end may shimmer like gold. That tells me very little about what lies beneath it.

GRC Is Not a Collection of Forms

One of my greatest frustrations is the persistent belief that GRC is essentially a collection of digital forms, questionnaires, registers, attestations, and dashboards. This misconception existed long before vibe coding, but vibe coding now makes it easier to perpetuate.

A developer creates a risk form, a control form, and an issue form. The records can be linked. A dashboard shows red, amber, and green (BARF). Perhaps an AI assistant generates descriptions and recommends scores. Suddenly, the application is described as an enterprise GRC platform.

But GRC is not a set of isolated records. It is a complex and dynamic system of relationships.

An objective may depend on several business processes. Those processes rely on people, technology, facilities, information, suppliers, and services. Each dependency introduces uncertainty. Risks may affect multiple objectives, entities, products, or jurisdictions. Controls may address several risks and obligations but operate differently across business units. A regulatory requirement may connect to policies, procedures, controls, evidence, tests, issues, and accountable individuals. An incident may reveal a control failure, trigger a legal obligation, expose a supplier dependency, disrupt a critical service, and threaten a strategic objective.

This is a many-to-many world. Everything connects to something else, and every connection carries context.

That context includes ownership, authorization, history, versioning, geography, legal entity, business hierarchy, data sensitivity, applicability, evidence, accountability, and time . . .

• It matters who approved a control, which version was effective, what evidence supported it, which business units relied upon it, and what changed after an incident.
• It matters whether a user can view a record but not edit it, whether responsibility can be delegated, whether approval requires segregation of duties, and whether the entire history can be reconstructed for a regulator, auditor, board, court, or internal investigation.

A simple application can create a relationship between two records. An enterprise GRC platform must manage thousands or millions of relationships consistently, securely, and historically across the organization.

That is architecture, not decoration.

Without that architecture, organizations gradually accumulate disconnected applications . . .

• The risk tool does not communicate with incident management.
• The compliance application maintains its own control library.
• The third-party risk solution uses a different supplier record than procurement. Policy management has its own workflow and identity structure.
• Audit tracks findings somewhere else.
• Operational resilience has another view of critical processes and dependencies.

The same employee may exist in five applications. The same control may be duplicated eight times. The same supplier may have three names and four risk ratings. The same obligation may be interpreted differently by compliance, legal, information security, and internal audit.

Eventually, the organization exports everything into spreadsheets to reconcile reality . . . That is not GRC transformation. It is fragmentation with a modern user interface.

When Every Department Becomes Its Own Software Company

The external flood of new software companies is only half of the Draupnir effect. The same multiplication is now happening inside organizations.

For years, GRC teams have waited for overloaded technology departments and slow enterprise platforms to address relatively simple needs. They submit enhancement requests, enter project backlogs, compete for development resources, and wait months for changes that appear straightforward. When someone can now describe the application they want and generate a functioning version in days, the temptation to bypass those constraints is entirely understandable.

In many cases, internal experimentation is healthy. A team may use vibe coding to test an idea, replace a spreadsheet, automate a narrow process, or prove that a better workflow is possible. The problem begins when experimentation quietly becomes production, and production quietly becomes critical infrastructure . . .

• Compliance creates an application for regulatory assessments.
• Information security builds another for control testing.
• Operational risk develops an RCSA tool.
• Internal audit generates an evidence-management application.
• Procurement creates a supplier-risk workflow.
• Business continuity builds another application for impact analysis and recovery plans.

Each application solves a real problem. Each team is proud of what it has created. Each application may work exceptionally well within its original boundary . . . Collectively, they can become a governance nightmare.

The resulting problems are not theoretical:

• Definitions fragment. Risk, control, issue, incident, asset, supplier, process, and business service begin to mean different things in different applications. The organization gains several technically correct but operationally incompatible versions of reality.
• Identity and accountability fragment. The same person receives different roles, permissions, and responsibilities across separate tools. A control owner in one application may not be recognized as the same owner in another, while approvals and delegations become impossible to reconcile.
• Data fragments. A critical supplier in one system may not match the supplier record used by procurement. A control tested by information security may be duplicated in compliance and duplicated again in internal audit. An incident may remain isolated from the obligations, policies, risks, and objectives it affects.
• Governance fragments. Each team creates its own retention rules, security decisions, model prompts, workflows, evidence standards, and approval structures. Local flexibility grows while enterprise assurance quietly erodes.

The organization has not democratized GRC. It has democratized fragmentation.

There are also serious questions of ownership and sustainability . . .

• Who supports the application when its creator leaves?
• Who validates the security model?
• Who tests changes?
• Who monitors integrations?
• Who ensures the AI continues behaving appropriately?
• Who manages privacy, retention, records requirements, accessibility, resilience, and recovery?
• Who is accountable when the application produces a flawed recommendation or quietly stops working?

The irony is difficult to miss. An organization may create an internally vibe-coded third-party risk application while failing to apply equivalent due diligence to the libraries, models, cloud platforms, connectors, and development services on which that application depends.

Internal development does not eliminate third-party risk. It often hides it.

The answer is not to prohibit internal innovation. A blanket prohibition would drive experimentation underground and preserve many of the inefficiencies that created the demand for these tools in the first place. The answer is governed enablement.

Organizations need an architecture and operating model that allow teams to innovate without creating uncontrolled islands. This requires more than publishing a policy that says “use AI responsibly.” It requires practical infrastructure and decision rights:

• Teams need approved environments and reusable foundations. Common identity services, security controls, enterprise records, integration patterns, data models, and monitoring services allow local innovation without requiring every team to rebuild the foundations of enterprise technology.
• Every application needs an accountable owner and defined lifecycle. The organization should know what is being built, what data it uses, which decisions it influences, who supports it, how changes are tested, and what happens when it fails or is no longer needed.
• There must be a path from experimentation to industrialization. A prototype may remain a local tool, be rebuilt on an enterprise platform, become part of a broader GRC architecture, or be retired after proving the concept. What it should not do is drift silently into becoming a critical control environment.
• AI behavior must be governed as part of the application, not treated as an invisible service. The organization needs to understand which models are used, what data is shared, how prompts and agents are controlled, which actions require human approval, and how recommendations can be traced and challenged.

Without these guardrails, every department becomes its own software company without possessing the architecture, engineering, governance, funding, or support capabilities of an actual software company.

That is not agility. It is shadow IT with an AI accelerator.

Intelligence Requires Context, Not Merely Conversation

The arrival of generative AI has introduced another layer of confusion. The market increasingly equates conversational interaction with intelligence, as though the ability to ask a question in natural language proves that the system understands the organization.

A language model can produce an excellent risk statement. It can summarize a regulation, draft a policy, classify an incident, or recommend controls. These capabilities are useful and will become normal elements of GRC technology. But polished language is not the same as organizational intelligence.

Real GRC intelligence requires context. It must understand what the organization is trying to achieve, what processes and services support those objectives, which assets and suppliers those processes and services depend upon, what controls are expected to operate, what evidence exists, what incidents have occurred, and what uncertainty threatens performance.

Suppose an access-control failure is detected. A generic AI assistant may explain the weakness and propose remediation. A contextually intelligent GRC system should understand that the failed control applies to a specific application, that the application supports a critical payment process, that the process serves customers in several jurisdictions, that the application relies upon a particular cloud provider, that the provider has experienced recent incidents, and that the combined exposure threatens an important business objective and may create regulatory reporting obligations.

That intelligence does not arise because the system can chat. It arises because the system understands relationships, dependencies/interdependencies, history, permissions, and organizational context. It needs access to authoritative data, but access alone is not enough. The data must be governed, structured, connected, and understood within the operating model of the organization.

This is why I become cautious when a provider tells me that it has connected a general-purpose language model to several forms and created an intelligent GRC platform. The model may be intelligent in a broad linguistic sense, but the application may remain organizationally ignorant. It can speak convincingly about controls without understanding whether the controls exist, operate, apply, or have failed.

A chatbot may provide an answer. A GRC platform must support a defensible decision.

The Forge Matters More Than the Spark

The Norse gods possessed extraordinary artifacts, but those artifacts did not emerge from casual experimentation. Draupnir, Mjölnir, and Skíðblaðnir were forged by craftsmen with deep skill. Their value was not simply that they looked impressive; their value came from what they could reliably do.

Vibe coding provides the spark. It can help create prototypes, accelerate configuration, automate repetitive development, and bring new ideas to life. But the spark is not the forge, and it is certainly not the finished artifact.

The forge is the accumulated discipline required to build technology that survives the enterprise. It includes an architecture capable of handling complex relationships without collapsing under scale. It includes security models that enforce access across business units, legal entities, geographies, and sensitive data. It includes audit trails that preserve who did what, when, why, and under whose authority. It includes reliable performance, backup, recovery, release management, testing, and upgrade paths.

It also includes the institutional knowledge that comes from implementing software in real organizations. Experienced providers learn where implementations fail, where users resist, which configurations become unmanageable, and which apparently harmless customizations create years of technical debt. They learn that every customer believes its processes are unique, while many of the underlying problems are remarkably consistent. They learn when to adapt the technology and when to tell the customer that a requested design is a bad idea.

This knowledge is rarely visible in a demonstration, but it determines whether the system succeeds after the sales team leaves. A new provider may have brilliant engineers and a compelling idea. It may still lack the scars that produce sound enterprise judgment.

The Last Twenty Percent Is Another Continent

Vibe-coded development creates a psychological trap. Because the initial application appears quickly, founders and internal teams begin to believe the product is almost finished. The dashboard works . . . The workflow runs . . . The model generates output . . .The application can be shown to a prospect or executive sponsor . . .

Then reality arrives.

The enterprise customer wants single sign-on, granular permissions, configurable hierarchies, bulk data loading, APIs, data residency, encryption, audit logging, multilingual support, accessibility, role delegation, configurable notifications, retention schedules, workflow escalation, mobile access, and integration with a collection of systems that were last meaningfully documented during the reign of a previous CIO.

The customer wants the solution to support not one framework but twenty. It wants one control to map to multiple requirements. It wants inherited controls, shared services, regional variations, historical reporting, and evidence that can be reused without being blindly duplicated. It wants to understand what changed between last quarter and this quarter. It wants the platform to support twenty thousand users even though only two hundred may log in regularly. It wants the implementation completed in three months without disrupting the business.

Suddenly, the weekend prototype is standing at the edge of a very large ocean . . . or abyss!

This is where many promising solutions stall. The team built the visible application but not the administrative tooling, migration utilities, implementation accelerators, security architecture, monitoring capabilities, or support processes required to make the application repeatable across customers.

The remaining work is not another twenty percent. It is another continent.

Building Technology Is Not Building a Company

The deeper concern is that many new entrants underestimate not only the work required to finish the product, but also what it takes to bring the product to market.

The GRC market contains many strong technologies that have never achieved meaningful scale. Some have better architectures than larger competitors. Some offer more innovative approaches, stronger analytics, better usability, or more compelling ideas. Yet they remain relatively unknown, struggle to win enterprise deals, or eventually disappear.

Great technology is only one component of a successful technology company. Remember VHS vs BetaMAX from the 1980’s (well I do, showing my age) . . .

A provider entering this market has to execute across several interdependent disciplines:

• Positioning determines whether the market understands why the company exists. The provider must define the problem it solves, the buyer it serves, the outcomes it creates, and the reasons it is meaningfully different from dozens or hundreds of alternatives. Technical originality means little when the market cannot understand the value.
• Marketing creates sustained visibility and credibility. This is not a few enthusiastic posts announcing that legacy GRC is dead. It requires market education, thought leadership, customer evidence, events, analyst engagement, competitive intelligence, and a narrative that reaches beyond the founder’s immediate relationships.
• Sales converts interest into durable commercial relationships. Enterprise GRC purchases involve risk, compliance, audit, legal, information security, procurement, technology, privacy, finance, and executive stakeholders. The sales cycle may include workshops, demonstrations, proofs of concept, security assessments, references, contracting, and procurement processes extending for a year or longer.
• Delivery converts promises into outcomes. A provider needs repeatable implementation methods, trained consultants, migration capabilities, documentation, governance models, integration expertise, and the judgment to prevent every customer request from becoming permanent custom code.
• Support and customer success determine whether the customer stays. The platform must be maintained, upgraded, monitored, explained, and improved. Customers need someone accountable when the implementation becomes difficult, the model behaves unexpectedly, or a critical workflow fails.
• Capital and operational discipline allow the company to survive the gap between ambition and scale. Product development, long sales cycles, implementation capacity, market awareness, and customer support all consume resources before they create sustainable returns.

A company may close a significant enterprise customer and discover it has no repeatable implementation methodology, insufficient consultants, limited documentation, weak training materials, and no reliable way to migrate data. The founders become the implementation team, product support, solution architects, and escalation path. Every customer receives a different configuration. Every implementation creates new custom code. The product roadmap becomes hostage to the loudest account.

That is how an innovative platform becomes an unsustainable services project.

Sales, marketing, implementation, support, customer success, partnerships, and capital are not secondary functions to be added after the technology succeeds. They are part of the product’s ability to succeed.

Technology earns the right to enter the market. Execution determines whether it remains there.

The Demo-to-Delivery Chasm

I have seen many excellent demonstrations. Demonstrations are controlled environments. The data is clean, the workflow is logical, the user has exactly the right permissions, and nothing unexpected occurs. The AI correctly interprets the question. The dashboard loads. The process reaches its conclusion in ninety seconds.

Real organizations do not behave like demonstrations.

They have inconsistent taxonomies, duplicate records, unclear ownership, political disputes, fragmented systems, unfinished inventories, conflicting policies, regional exceptions, legacy processes, and users who enter data differently despite receiving the same instructions. One business unit believes the risk belongs to technology. Technology believes it belongs to operations. Operations believes compliance owns it. Compliance believes the business accepted it three years ago, although no one can locate the approval.

This is where a platform and its provider prove their value. The technology must be flexible enough to support reality but disciplined enough not to reproduce every organizational dysfunction inside the system. The implementation team must understand how to rationalize data, simplify workflows, establish governance, and guide the customer toward a sustainable operating model.

No amount of generative AI eliminates this work. In some cases, AI may accelerate the wrong design.

The ability to generate applications quickly can result in every department building its own version of risk, compliance, incidents, controls, and policies. Each application may be well designed in isolation, but together they recreate the silos that GRC was supposed to address.

Speed without architecture can industrialize fragmentation.

The Market Does Not Need Another Digital Risk Register

I am not interested in another application that takes a traditional risk register, places it in a browser, adds a chatbot, and describes the result as the future of GRC.

The market already has enough electronic filing cabinets, digital questionnaires, compliance checklists, and red-amber-green dashboards. Organizations do not need faster ways to document disconnected activity. They need technology that helps them reliably achieve objectives, address uncertainty, and act with integrity.

That requires systems that connect governance, risk management, and compliance to the actual business. It requires understanding how objectives depend upon operations, technology, people, suppliers, information, and decisions. It requires intelligence capable of identifying patterns, dependencies, and emerging exposure. It requires action that moves work forward and configuration that allows the organization to adapt without destroying coherence.

This is where AI, agents, orchestration, and conversational development become genuinely transformative. They can make GRC technology easier to use, more responsive, more proactive, and more aligned with decisions. But they must operate across a strong System of Record that preserves trusted data, relationships, accountability, and evidence.

The System of Record is not the obsolete past from which AI liberates us. It is the foundation that prevents AI-enabled GRC from becoming confident chaos.

Buyers Need to Look Beneath the Interface

Buyers need to become much more rigorous in evaluating new solutions. A modern demonstration and a compelling founder are not enough. They need to examine the technology, but they also need to examine the company expected to stand behind it.

At a minimum, buyers should press deeply into four areas:

• The architecture: How does the platform model relationships, histories, entities, permissions, inherited controls, shared services, and large volumes of records? Can it grow beyond the narrow use case shown in the demonstration without creating another silo?
• The governance: How are identity, security, auditability, retention, privacy, AI actions, model behavior, and configuration changes controlled? Can the provider explain what the system did, why it did it, what data it used, and who authorized the action?
• The delivery model: Does the provider have an implementation methodology, trained resources, migration tools, documentation, partners, and references? What happens when the customer’s data is inconsistent, its ownership is disputed, and its processes are nothing like the demonstration?
• The viability of the provider: Does the company have the leadership, funding, market strategy, support structure, and operational maturity to remain accountable throughout a multi-year relationship? Is the capability generally available, in beta, or still living entirely in a presentation?

Innovation deserves consideration. It does not deserve immunity from due diligence.

Builders Need to Decide What They Are Actually Building

Builders also need to confront reality . . .Building software has become easier. Building a durable software company has not.

A team entering the GRC market should decide what it is truly creating. It may be an internal application, a focused point solution, a technology-enabled service, a commercial product, or an enterprise platform. Each can be valuable, but each requires a different operating model, investment level, and market strategy.

Not every useful application should become a standalone software company. A consulting firm may create technology that strengthens its services without attempting to compete with global platforms. An internal compliance team may build an excellent application for its own environment without assuming that the same configuration will work elsewhere. A founder may choose to dominate a narrow problem rather than claiming to solve all of GRC.

There is discipline in focus.

A provider that genuinely intends to become a GRC software company must plan for years of investment. It must build product depth while also building sales, marketing, implementation, support, customer success, partnerships, and operational resilience. It must develop references, survive long buying cycles, and prove that its platform can move beyond a controlled demonstration.

The market does not reward technology simply because it is clever. It rewards providers that can turn technology into sustained customer outcomes.

Vibe Coding Is an Accelerator, Not an Exemption

I am not opposed to vibe coding. I expect it to become a normal part of software development and configuration. It will allow experienced providers to innovate faster, enable customers to shape applications around their needs, and bring valuable ideas into the market that might otherwise remain trapped in spreadsheets or presentation decks.

But vibe coding does not exempt anyone from architecture, governance, security, expertise, or execution.

It accelerates whatever already exists. In the hands of a disciplined team with deep domain knowledge and sound architecture, it can accelerate meaningful innovation. In the hands of a team that does not understand the problem, it can accelerate the production of fragile applications and technical debt.

It can scale good judgment . . . It can also scale bad judgment

The critical question is not whether a solution was vibe coded. The critical question is whether the people behind it understand what they are building, why it matters, how it fits into the broader enterprise, and what it will take to deliver and support it over time.

Forging Something Worthy of the Market

Draupnir produced endless rings, but mythology remembers the original because the original carried meaning, history, and power. Multiplication alone did not create significance. The same will be true in software.

The market will continue producing new applications at an extraordinary rate. Many will look polished. Some will solve meaningful problems. A few will mature into strong products. Fewer will become sustainable companies, and fewer still will establish the credibility, architecture, and execution required to become enduring enterprise platforms.

That is not cynicism. It is the reality of building technology that organizations can trust with governance, risk management, compliance, resilience, accountability, and decisions.

I welcome disruption. I want better GRC technology. I want platforms that are more intelligent, contextual, conversational, adaptive, and capable of orchestrating action. I want new providers to challenge legacy assumptions and force the market forward. I also want organizations to innovate internally and solve problems that established technology has neglected.

But I want buyers, builders, and internal teams to stop confusing speed with maturity, a demonstration with a product, a product with a platform, and a platform with a viable company.

Use AI. Experiment aggressively. Challenge the established market. Build applications through conversation. Create experiences that are dramatically better than what came before. Just remember that a spark is not a forge, a ring is not Draupnir, and a weekend prototype is not an enterprise platform.

The technology may be created quickly . . .Trust still has to be earned!

The Long Voyage Back to Purpose

I went to see The Odyssey, and somewhere between the fall of Troy, the restless sea, angry gods, seductive islands, terrible monsters, and one remarkably patient wife, it occurred to me that Homer may have written one of the greatest stories about governance, risk management, and compliance nearly three thousand years before I compressed those ideas into the acronym GRC back in February 2002 while I was at Forrester.

This may simply be an occupational hazard. After thirty years in this profession, it has become difficult for me to watch anything without eventually finding myself in a boardroom. Star Trek becomes a study in leadership, operational resilience, decision-making, and the governance of uncertainty. Douglas Adams becomes an uncomfortable reminder that organizations can build immensely sophisticated systems while remaining uncertain about the question they are trying to answer. Apparently, ancient Greek warriors sailing across the Mediterranean now reveal themselves as risk leaders struggling to reconnect their profession with the purpose of the business.

Yet the connection did not feel manufactured. The longer I watched Odysseus struggle toward Ithaca, the more familiar his journey became. He begins as a leader of intelligence, courage, and strategic imagination. He understands what must be achieved, sees what others cannot, and succeeds where repeated applications of brute force have failed. Through wit and ingenuity, he helps conquer Troy and earns the acclaim of kings and warriors. At that moment, Odysseus possesses almost everything we should want in a great Chief Risk Officer: clarity of purpose, awareness of uncertainty, the ability to challenge assumptions, and the courage to recommend a different path when the obvious one has become an expensive habit.

Then the journey home begins . . .

One crisis follows another. Every island produces a new emergency, every horizon reveals another threat, and every decision creates consequences that could not have been fully anticipated when the ships first left Troy. Odysseus spends years fighting monsters, managing frightened crews, escaping traps, navigating storms, and responding to dangers that demand immediate attention. He survives much of it brilliantly, but survival gradually becomes the measure of success. The work of the voyage grows larger than the reason for the voyage, and the leader who once knew precisely where he was going becomes consumed by what is directly in front of him.

Odysseus does not merely lose his way on the sea. He slowly loses sight of who he is . . . That is where The Odyssey becomes a GRC story.

NOTE: Christopher Nolan’s movie is an absolutely amazing adaptation of The Odyssey, but readers will notice below that my analysis ties back to Homer’s written work and not the movie adaptation.

---

Troy Was Never the Destination

Odysseus becomes famous at Troy, but Troy was never his destination. He did not leave Ithaca because he dreamed of spending ten years beneath foreign walls, arguing with kings and inventing increasingly creative ways to defeat an enemy that refused to be defeated. He went because obligations called him, circumstances demanded it, and history placed him in a struggle larger than himself. Once the war was won, however, his purpose was clear. He was not meant to remain forever on the battlefield collecting acclaim for old victories. He was meant to return home.

It is easy to forget this because the Trojan Horse is such a magnificent story. For ten years, the armies of Greece attacked Troy and failed. Warriors fought, heroes died, strategies collapsed, and the city endured. Odysseus eventually recognized that the answer would not be found in greater force but in a different way of thinking. The horse was not simply a clever deception; it represented the triumph of imagination over repetition and strategy over the dangerous assumption that doing more of what has already failed will somehow produce a different result.

That is risk leadership at its best. It is not the person standing behind the army announcing that the walls are high, the probability of a breach is low, and the risk should therefore be plotted as red in the upper-right corner of a heat map. Nor is it the administrator recording that the Greeks have attempted to breach the walls for ten consecutive years and assigning another overdue action to the head of siege operations. It is the person who steps back, examines the objective, challenges the assumptions, and asks whether the entire approach is wrong.

Odysseus understood that the objective was not to attack Troy. The objective was to defeat Troy. Those statements sound similar, but they lead to very different decisions. One describes activity; the other describes an outcome. Organizations confuse the two constantly. They measure the completion of risk assessments rather than whether uncertainty is being understood. They count controls rather than determining whether the business is better protected and enabled. They celebrate the closure of audit findings without asking whether the organization is more resilient, more agile, or more capable of making good decisions.

GRC has often made the same mistake. We become absorbed by the machinery of the profession and forget that the machinery is not the purpose. Risk registers, controls, policies, workflows, assessments, obligations, findings, committees, dashboards, reports, and attestations all have a place, but none of them is Ithaca. They are instruments carried aboard the ship. When an instrument becomes more important than the destination, it no longer helps the voyage; it begins to weigh it down.

The business does not exist to manage risk. It exists to achieve objectives, create value, serve customers, develop products, enter markets, build communities, deploy capital, and generate returns. Risk exists because decisions need to be made, objectives need to be set, and performance against those objectives is uncertain. Governance provides direction and accountability. Risk management helps leaders understand the effects of uncertainty on their choices. Compliance establishes the boundaries of integrity within which the journey must occur. GRC, properly understood, is therefore not the destination of the enterprise. It is the capability that helps the enterprise reliably reach its destination.

Odysseus knew where he was going when the gates of Troy finally opened. The trouble began when the sea placed one urgent problem after another between him and home.

---

The Sea Does Not Care About the Strategic Plan

There is something wonderfully honest about the sea in The Odyssey. It does not care who Odysseus is, how impressive his victory at Troy may have been, or how carefully he has planned his route home. It does not attend strategy workshops, review board presentations, or acknowledge that the voyage has already consumed more time and money than originally budgeted. The sea remains vast, changeable, and entirely indifferent to confidence.

Organizations encounter uncertainty in much the same way. A strategy can be elegant, thoroughly researched, and approved by the board, yet the world is under no obligation to cooperate with it. Markets change, governments fall, suppliers fail, technologies disrupt, competitors behave irrationally, customers alter their preferences, and events occurring thousands of miles away suddenly transform the economics of decisions made months earlier. The sea is not malicious simply because the voyage becomes difficult. It is simply the sea.

Poseidon gives this uncertainty a face. He is not a discrete risk that can be entered into a register, assigned an owner, rated red-amber-green, and brought within tolerance by the end of the quarter. He is the reminder that actions create consequences and that not every consequence can be contained through intelligence alone. Odysseus can navigate brilliantly, but he cannot command the ocean. He can prepare his ships, advise his crew, study the weather, and choose among imperfect routes, but he cannot remove uncertainty from the voyage.

This is where risk management so often damages its own credibility. Organizations ask risk professionals to make uncertainty disappear, and some risk professionals are tempted to pretend they can. The result is false confidence wrapped in precise language, quantitative-looking scores, and brightly colored dashboards that suggest the future has agreed to follow administrative rules. A risk described as “medium-high” with a score of nine out of ten may look authoritative, yet the number often reveals more about the scoring methodology than about the decision the business is trying to make.

The purpose of risk management was never to manufacture certainty. It is to help decision-makers understand uncertainty well enough to pursue value with greater intelligence, resilience, and agility. Odysseus does not succeed because he eliminates the sea; he succeeds because he learns how to continue across it.

A great Chief Risk Officer does not stand on the shore warning that sailing is dangerous. Everyone already knows that. Nor does the role exist to prohibit the voyage until the sea can be proven safe, because the sea will never provide such proof. The role is to help the organization understand the currents, anticipate the storms, prepare for disruption, recognize when conditions have changed, and remember where the ship was meant to go in the first place.

The tragedy of the voyage is that Odysseus gradually becomes so consumed by surviving the sea that he begins to live as though survival itself were the destination. This is not because he consciously abandons Ithaca. Urgency simply narrows the horizon until the next crisis becomes the only thing visible.

---

The Lotus-Eaters and the Comfortable Forgetting of Purpose

Of all the dangers Odysseus encounters, the Lotus-Eaters may be the most unsettling because they are not violent. There is no battle, no roaring monster, and no obvious threat. The island appears peaceful. Its people offer hospitality, food, and relief from the exhausting demands of the journey. The lotus does not kill those who consume it; it merely causes them to forget why they were traveling.

That is a far more dangerous temptation than destruction because a destroyed ship is recognized as a crisis, while a forgotten destination can be mistaken for stability.

Organizations rarely wake up one morning and deliberately abandon their purpose. The loss occurs gradually. An activity created to support an objective becomes a permanent process. The process generates reports, the reports require meetings, the meetings create committees, and the committees establish governance structures. Before long, an entire ecosystem exists to support something no one can clearly connect to a current business decision. Everyone remains busy, documentation expands, workflows circulate, evidence accumulates, and the organization becomes exceptionally disciplined at completing work whose original purpose has faded from memory.

The GRC profession has its own lotus. It appears in the comfortable repetition of annual assessments that ask the same questions and produce almost identical answers. It can be found in risk registers that have survived so many reorganizations that no one remembers who first created them or what decisions they were intended to inform (if at all, too often it is a compliance exercise). It appears in controls that continue to be tested because they were tested last year, policies that grow longer with every revision, and dashboards that present impressive volumes of information without helping anyone determine what to do next.

The people doing this work are not lazy or incompetent. Like the sailors who tasted the lotus, they may be highly capable individuals who have become absorbed by the immediate environment. Their calendars are full, deadlines are real, regulators are demanding, audits must be completed, and evidence must be supplied. There is always another questionnaire, another issue, another control test, another regulatory mapping exercise, and another committee paper waiting to be written. The work is real, but activity becomes detached from outcome.

The organization remembers every requirement, every risk plotted on a heat map, and forgets Ithaca . . . the decisions and objectives and the context of the organization.

Odysseus has to drag his men back to the ships because persuasion is no longer enough. They do not want to continue the journey. The island has relieved them of the burden of purpose, and purpose can indeed be burdensome. Objectives require movement, movement creates uncertainty, and uncertainty demands decisions for which someone must eventually be accountable. A comfortable process asks only that it be repeated.

This is why the most important question in GRC is often not whether an activity has been completed, but why it exists.

• What objective does it support?
• What decision does it inform?
• What uncertainty does it help the organization understand?
• What value does it protect or enable?
• What return does it help the organization pursue?
• What would happen if the activity stopped, and would anyone outside the GRC function notice?

The lotus is seductive because it does not feel like failure. It feels orderly, controlled, and mature. The danger is that an organization can become very orderly while drifting farther from where it intended to go.

---

The Cyclops and the Danger of Seeing Only One Thing

The Cyclops is terrifying not simply because he is enormous, violent, and inclined to eat visitors. His deeper problem is that he possesses only one eye. He sees the world from a single perspective, and his strength convinces him that no other perspective is required.

Organizations encounter Cyclopes everywhere. Compliance may view every issue primarily through the lens of regulation. Cybersecurity may see the enterprise as a collection of vulnerabilities and attack surfaces. Audit may see control deficiencies. Finance may see cost. Operations may see disruption. Strategy may see growth. Each perspective contains truth, but none contains the whole truth. The problem begins when one function becomes so powerful, so specialized, or so confident in its own view that it assumes its single eye can see the entire landscape.

GRC programs frequently reproduce this blindness in both process and technology. Organizations create separate systems for enterprise risk, compliance, audit, resilience, privacy, third-party management, cybersecurity, policy, regulatory change, and sustainability. Each system sees its own domain clearly and may perform excellent work within that boundary. Yet the business itself does not live in those boundaries. A single supplier may create financial exposure, operational disruption, cyber vulnerability, regulatory consequences, reputational damage, strategic dependency, and concentration risk at the same time. The supplier is one relationship, but the organization examines it through seven different eyes that rarely focus on the same decision.

The enterprise has many eyes and still behaves like a Cyclops.

Odysseus cannot defeat the Cyclops through strength. He survives by understanding identity, perception, and consequence. He calls himself “Nobody,” exploits the monster’s limited view, and escapes beneath the sheep. It is clever, theatrical, and entirely consistent with the man who conceived the Trojan Horse. Yet wisdom is followed by pride. Once safely at sea, Odysseus cannot resist revealing his name, ensuring that the Cyclops knows precisely who defeated him.

That moment changes the voyage. Success produces acclaim, and acclaim can become its own source of blindness. Odysseus no longer wants merely to escape; he wants recognition. His need to claim the victory provokes Poseidon and turns a difficult journey into a prolonged ordeal. The clever strategist who understood how to use anonymity becomes trapped by ego.

Risk leaders face a similar temptation. They can become so invested in being right that they forget their purpose is to help the organization succeed. The objective is not to win an argument with the business, prove that a warning was ignored, or stand after a crisis announcing that the risk register accurately predicted the disaster. There is little strategic value in being correct among the wreckage.

A Chief Risk Officer should seek influence rather than vindication. The role is to shape decisions before consequences arrive, not to collect trophies afterward. Odysseus defeats the Cyclops but extends his suffering because he needs the monster to know who won. Sometimes wisdom requires leaving the cave without issuing a press release.

---

Circe and the Transformation of the Chief Risk Officer

Circe’s island presents another kind of danger. She does not destroy Odysseus’ men; she transforms them into swine. They remain alive, but they are no longer what they were. Their nature has been altered, and their identity reduced to appetite and confinement.

There is a quiet tragedy in that image that feels familiar to anyone who has watched talented risk leaders gradually transformed by the machinery surrounding them. They begin their careers fascinated by strategy, uncertainty, decision-making, and the relationship between risk and return. They want to challenge assumptions, explore scenarios, understand how the business creates value, and help executives make better choices. Then the organization hands them an expanding collection of administrative obligations.

The strategic advisor becomes the owner of the risk register. The navigator becomes the custodian of the policy library. The challenger of assumptions becomes the organizer of committee papers, the collector of evidence, the chaser of overdue actions, and the administrator of a platform that requires more attention than the decisions it was purchased to support. None of these responsibilities is inherently unimportant, but together they can transform the role until the Chief Risk Officer spends more time feeding the system than advising the business.

Bad risk management accelerates the transformation. Instead of beginning with objectives and decisions, the function begins with a list of risks. Rather than exploring uncertainty around strategic choices, it sends templates throughout the organization asking people to identify their “top risks.” Those risks are plotted on heat maps whose colors imply a level of precision the underlying judgments cannot support. Red becomes urgent, amber becomes tolerable, and green becomes safe, although the colors often say little about velocity, interconnection, exposure, resilience, or the value the organization is pursuing.

The heat map becomes an icon of false simplicity. Complex uncertainty is flattened into colored boxes, and executives are encouraged to focus on whatever has drifted toward the upper-right corner. It has no context of objectives and the business. The map rarely shows the assumptions behind the strategy, the relationships among risks, the cascading impact of disruption, or the returns associated with the decision. It is a picture of risk separated from the reason the risk exists.

Circe’s magic works because transformation often occurs without immediate pain. The meetings continue, reports are delivered, and the function appears productive. Over time, the organization forgets that the person buried beneath workflows, registers, and administrative tasks was recruited to provide wisdom at the point of decision.

Odysseus resists Circe with the help of Hermes and eventually persuades her to restore his crew. Yet even after the danger has passed, he remains on the island for a year. That detail matters. Not every delay is caused by an enemy. Some delays persist because the place where we became distracted is comfortable enough to make departure inconvenient.

GRC technology can become such an island. A platform may begin as a means of connecting risk information, automating routine work, and providing intelligence. Eventually, enormous energy is consumed configuring workflows, maintaining taxonomies, debating fields, reconciling data, managing upgrades, and persuading users to complete forms. The organization begins serving the system instead of the system serving the organization.

Technology is essential to modern GRC, and the next generation will require richer data models, connected intelligence, automation, AI, orchestration, and digital twins. Yet none of these is Ithaca. A sophisticated ship that sails in circles is still lost.

The measure of GRC technology is not the number of workflows it contains, the volume of controls it can store, or how impressive its dashboard appears during a demonstration. Its value lies in whether it helps the organization make better decisions, identify cracks before they become failures, respond quickly when conditions change, understand relationships across the enterprise, and pursue objectives with greater confidence.

Circe’s island reminds us that tools and processes can transform those who use them. The Chief Risk Officer must therefore remain vigilant not only about the uncertainty facing the business, but also about the risk that the function itself becomes something it never intended to be.

---

The Sirens and the Promise of Effortless Answers

The Sirens offer Odysseus something every leader desires: knowledge without uncertainty. Their song promises insight, understanding, and answers hidden from ordinary people. They do not threaten him with violence . . . They invite him to listen.

Every generation has its Sirens. In GRC, they sing through frameworks, methodologies, maturity models, technologies, consultants, and increasingly artificial intelligence. Their songs are not necessarily false. Many contain genuine wisdom and can create enormous value. The danger lies in the promise that the difficult work of understanding context, objectives, culture, incentives, uncertainty, and human behavior can somehow be replaced by a universal answer.

The Siren song tells organizations that one more framework will bring order, one more platform will integrate everything, one more scoring methodology will make risk objective, one more dashboard will provide complete visibility, or one more AI assistant will remove ambiguity from decision-making. Each promise contains enough truth to become irresistible.

Odysseus does not ignore the Sirens. That would be too simple, and he is far too curious. He wants to hear what they know, but he recognizes that curiosity without governance may destroy him. He instructs his crew to bind him to the mast and fill their own ears with wax. The solution is not ignorance; it is disciplined engagement.

For example, one of many, this may be one of the better metaphors for AI governance. Organizations should not close their ears to artificial intelligence, nor should they surrender the ship to every seductive promise made in its name. They need structures that allow them to explore its value while remaining anchored to accountability, integrity, and purpose. The question is not whether the Sirens can sing. They clearly can. The question is whether the organization can listen without steering onto the rocks.

A mature GRC function does not respond to innovation with reflexive prohibition. It establishes the conditions under which experimentation can occur responsibly. It understands the objective, examines the uncertainty, defines accountability, evaluates consequences, and creates resilience for the moment assumptions fail. It binds the organization to the mast not to prevent movement, but to ensure that fascination does not overpower purpose.

There is also humility in Odysseus’ approach. He knows he cannot rely entirely on his own judgment once the song begins, so he creates governance before the temptation arrives. Organizations frequently wait until they are already enchanted before deciding that guardrails might be useful. By then, the rocks are uncomfortably close.

---

Between Scylla and Charybdis: The Appetite Is for Value

Perhaps no part of The Odyssey better captures executive decision-making than the passage between Scylla and Charybdis. On one side is a many-headed monster that will seize and kill members of the crew. On the other is a whirlpool capable of swallowing the entire ship. There is no safe route, no option without consequence, and no decision that can honestly be described as risk-free.

This is the reality executives face far more often than conventional risk methodologies acknowledge. Risk management sometimes presents an idealized world in which every risk can be reduced to an acceptable level if the organization simply adds enough controls. Yet significant decisions rarely offer such comfort. Entering a market creates exposure, but remaining outside may surrender growth. Accelerating innovation introduces operational, ethical, and regulatory uncertainty, but moving slowly may make the business irrelevant. Concentrating suppliers improves efficiency while increasing dependency; diversification improves resilience while raising cost and complexity.

Organizations do not possess an appetite for risk in the abstract. Risk is not a meal placed before the board from which directors decide how much they would enjoy consuming. Organizations have an appetite for value. They seek growth, return, innovation, market access, customer trust, resilience, efficiency, and strategic advantage. In pursuing that value, they become willing to accept certain uncertainties and exposures because the potential outcome justifies taking them.

The distinction is essential. When risk appetite becomes detached from value, it turns into another administrative fiction: a polished statement filled with categories, thresholds, and colors that may have little connection to actual decisions. The meaningful conversation is not “How much risk do we want?” but “What value are we pursuing, what uncertainty accompanies that pursuit, what consequences are we prepared to absorb, and what would threaten the viability or integrity of the enterprise?”

Odysseus chooses the route past Scylla because losing part of the crew is preferable to losing the entire ship. It is a terrible decision, but leadership is not measured by whether every choice feels good. Sometimes it is measured by whether the organization survives an unavoidable trade-off without pretending that the sacrifice was painless.

A great Chief Risk Officer does not stand beside the channel demanding that both monsters be removed. That is not advice; it is fantasy. The role is to help leaders understand the full landscape, the value attached to each route, the uncertainty surrounding their assumptions, and the consequences the organization can or cannot withstand. The decision begins with what the enterprise is trying to achieve, not with an isolated list of dangers.

The voyage exists because Ithaca is worth reaching.

---

Calypso and the Comfortable Prison of Compliance

Calypso’s island is not a dungeon. Odysseus is not chained to a wall or starved into submission. He is offered comfort, beauty, safety, and even immortality. After years of conflict and loss, the island gives him something the voyage has consistently denied him: rest.

Yet it remains a prison because it is not Ithaca.

There are many comfortable prisons in GRC, and one of the most obvious is compliance for compliance’s sake. Compliance offers clarity. There is a rule, an obligation, a deadline, and evidence that can demonstrate completion. Compared with the ambiguity of strategic risk and executive decision-making, compliance can feel reassuringly concrete. The work is necessary, expectations are visible, and success can often be documented.

Over time, a GRC function may retreat into this certainty. It becomes exceptionally good at demonstrating adherence while growing increasingly distant from the strategic and operational realities of the business. It can report how many policies were reviewed, how many controls were tested, how many findings were closed, how many employees completed training, and how many regulatory obligations were mapped. These achievements may be important, but they do not necessarily reveal whether the organization is making better decisions, protecting value, improving resilience, or enabling opportunity.

The island is pleasant. The reports are green. The committees are satisfied. The voyage has stopped.

Compliance is necessary, but compliance should serve integrity and the objectives of the organization. When compliance becomes the organizing purpose of GRC, the function begins managing itself inwardly. It becomes more concerned with proving that required activity occurred than with understanding whether the enterprise remains capable of achieving what it set out to do.

Odysseus spends years with Calypso, but he continues to look toward the sea. That detail preserves his identity. Beneath the comfort and exhaustion, he still understands that his life has a purpose beyond the island.

GRC needs the same restlessness. It should never become fully comfortable with inward-looking measures of success. It must keep asking whether the business is receiving value from the function, whether executives seek its advice before decisions are made, whether intelligence arrives early enough to influence action, and whether GRC helps the enterprise move faster with greater confidence rather than merely documenting what has already occurred.

Compliance matters. Controls matter. Audit matters. Documentation matters. But they are not home.

---

Athena Still Whispers

Throughout the story, Athena is the presence of wisdom. She does not remove every obstacle or spare Odysseus from every consequence. Instead, she guides, challenges, disguises, reveals, and intervenes at the moments when the journey could otherwise collapse. She understands both the hero’s brilliance and his flaws.

Every great leader needs an Athena.

For the organization, this should be the role of the Chief Risk Officer at their best: not the god of “no,” not the administrator of fear, and not the custodian of a static register, but the voice of wisdom that helps the enterprise remember who it is when pressure, pride, urgency, external forces, and distraction threaten to pull it away from purpose.

Athena does not command Odysseus to avoid uncertainty. She helps him navigate it. She does not promise a voyage without loss. She helps him preserve what matters through the losses that cannot be avoided. Her influence is strategic because she sees the whole story while others see only the immediate scene.

The modern Chief Risk Officer must cultivate the same perspective. This requires a deep understanding of the business, its objectives, economics, dependencies, culture, and decisions. It requires looking beyond historical incidents and compliance obligations toward scenarios, external intelligence, emerging uncertainty, and the assumptions upon which strategy depends. It requires confidence to challenge executives without becoming an adversary and humility to recognize that risk and opportunity are inseparable because both emerge from uncertainty.

The most valuable risk leader is not the person with the longest list of risks or the most colorful heat map. It is the person who helps the organization understand which uncertainties matter, how they connect, what value is being pursued, and what should be done next.

Wisdom is not the elimination of risk. It is the disciplined pursuit of purpose through uncertainty.

---

Penelope Is Still Waiting

While Odysseus battles monsters and crosses seas, Penelope remains in Ithaca. She is not passive. She protects the kingdom through patience, intelligence, and a strategy of her own, weaving by day and undoing her work at night to delay the suitors consuming the household and competing for the throne. Telemachus, meanwhile, grows from a child into a young man beneath the shadow of an absent father.

Their stories matter because the cost of Odysseus’ delay is not measured only in storms survived or ships lost. It is measured in the life that continues without him.

The business continues while GRC is distracted . . .

• Customers still expect products and services. Employees continue making decisions.
• Competitors move, markets change, technologies emerge, and capital seeks return.
• Strategy does not pause while the risk function completes another assessment cycle, redesigns its taxonomy, debates the difference between inherent and residual risk, or tries to decide whether a square on the heat map should be amber or red.

Every year GRC spends focused primarily on itself is a year in which the organization learns to make decisions without it.

Penelope represents the enduring purpose of the enterprise. She is the mission, the objective, and the value that called the voyage into existence. Telemachus represents the future developing while the leader is away: new markets, technologies, generations of employees, and opportunities that will not wait indefinitely for GRC to become relevant.

The suitors represent forces that consume resources without creating value. They fill the hall, demand attention, and gradually take possession of a kingdom they did not build. Every organization has them: unnecessary complexity, duplicated systems, political agendas, administrative burdens, control activities that no longer address meaningful exposure, and processes that survive simply because no one has the energy to remove them.

Odysseus’ return is therefore not merely a personal homecoming. It is the restoration of order and purpose. He must reclaim the kingdom, reconnect with his family, and become the leader he was before the voyage consumed him.

The Chief Risk Officer faces a similar return. The role must come home to the business.

---

The Return to Ithaca

When Odysseus finally reaches Ithaca, he does not arrive with the splendor of the conqueror who left Troy. He returns disguised, weathered by experience, stripped of ships, armies, and acclaim. The man who once devised the strategy that ended a legendary war must enter his own home as a stranger.

There is wisdom in that humiliation. The voyage has changed him. He has learned that intelligence without humility becomes pride, strength without purpose becomes wandering, and survival without identity becomes another form of loss.

GRC is approaching its own homecoming.

The profession has spent decades building frameworks, functions, technologies, taxonomies, controls, registers, and reporting structures. Much of this work was necessary. Organizations needed consistency, evidence, accountability, and systems capable of managing growing regulatory and operational complexity. Yet the journey has also pulled GRC inward. We have too often defined maturity by the sophistication of the function rather than the quality of the decisions it enables.

Coming home requires restoring the business to the center. Governance must be about setting direction, defining accountability, and ensuring decisions align with purpose and integrity. Risk management must begin with objectives and decisions, helping leaders understand the effect of uncertainty on what they are trying to achieve. Compliance must be about acting with integrity, not merely satisfying the minimum wording of an obligation. Together, GRC should help the enterprise reliably achieve objectives, address uncertainty, and act with integrity.

Reliably achieving objectives includes return. That word is sometimes treated with suspicion in risk conversations, as though creating value were separate from responsible governance. It is not. An organization that protects every resource but produces no return has not fulfilled its purpose. Capital must be deployed, decisions must be made, and opportunities must be pursued. The goal is not reckless growth, but neither is it perfect protection at the price of irrelevance.

Odysseus does not return to Ithaca merely to stand safely on the shore. He returns to rule, rebuild, restore relationships, and resume the responsibilities that gave his journey meaning.

The same must be true for GRC. The profession must move beyond being a defensive function that documents threats and enforces boundaries. It must become an active participant in strategy, performance, resilience, and value creation. It must help the organization pursue the right value while understanding the uncertainty involved. It must help leaders examine the routes available, the monsters hidden along each path, the assumptions beneath each decision, the consequences of delay, and the returns that make the voyage worthwhile.

This does not make GRC less disciplined. It makes the discipline matter.

---

Remember Why We Set Sail

What makes The Odyssey endure is not simply its collection of monsters, gods, storms, and adventures. Those provide spectacle, but spectacle alone does not survive for three thousand years. The story endures because every reader understands, at some level, what it means to become distracted from a purpose, to be changed by the journey, and to wonder whether the person returning home is still the person who first departed.

The Chief Risk Officer begins with a noble purpose. The role exists to help the organization navigate uncertainty in pursuit of objectives worth achieving. Yet the voyage is long, and the profession encounters its own Cyclopes, Sirens, storms, lotus fields, and comfortable islands. Crises demand attention. Regulations multiply. Technologies promise salvation. Processes become entrenched. Risk registers become the starting point instead of objectives. Heat maps replace serious analysis. Compliance activity becomes confused with integrity. Gradually, the function becomes very good at managing the journey while forgetting why the journey began.

The path back does not require abandoning controls, compliance, technology, or structure. Odysseus does not return home by pretending the sea no longer exists. The path back requires putting everything in its proper place. The ship serves the voyage. The voyage serves the destination. GRC serves the objectives and value of the business.

The question every Chief Risk Officer should ask is therefore not simply whether the organization has identified its risks, tested its controls, completed its assessments, or satisfied its obligations. Those questions matter, but they are insufficient. The deeper question is whether GRC is helping the organization decide where to go, understand the uncertainty in getting there, remain resilient through disruption, act with integrity along the way, and generate the returns that justify the voyage.

Perhaps that is what inspired me most as I left the theater. Odysseus does not reclaim his identity by returning to the glory of Troy. He does not need another conquest, title, or monument to his cleverness. He reclaims himself by remembering the promise that existed before the war, before the monsters, before the storms, and before the voyage became his entire life.

He remembers Ithaca.

GRC must do the same. The business is not an interruption to the work of GRC; the business is the reason GRC exists. Its objectives are our destination. Its decisions are the waters we must help navigate. Its appetite is for value, not for risk in isolation. Its resilience is the strength of the ship. Its integrity determines whether the voyage is worthy. Its returns make the journey sustainable.

Troy may bring acclaim. Monsters may provide exciting stories. Storms may fill calendars and justify budgets. Heat maps may decorate board packs. Risk registers may prove that work was done. Compliance reports may offer comfort. But none of them is home.

The business is Ithaca, and it is time for GRC to complete the voyage.

Why GRC 8.0 Begins After 2030—and Why Organizations Cannot Skip GRC 7.0

The GRC market is becoming fascinated with the future. Nearly every technology provider now has an AI story, and many are racing to attach words such as agentic, autonomous, predictive, and intelligent to products that were originally designed around relational databases, forms, workflows, tasks, and reports. Some of these developments are meaningful. Most are little more than a conversational interface placed on top of an architecture that was never designed to understand the complexity, interconnectedness, and velocity of the modern enterprise.

I believe GRC is moving toward something much more profound than better chatbots, automated questionnaires, or faster compliance reporting. The next generation will transform how organizations understand uncertainty, evaluate possible futures, govern interconnected systems, and continuously adjust their operations to remain aligned with decisions, objectives, values, obligations, and acceptable boundaries of risk.

I call this future GRC 8.0 — Quantum GRC.

GRC 8.0 is not the market we are entering today. It is the GRC environment I expect to emerge from 2030 onward, when agentic systems, digital twins, causal intelligence, advanced simulation, continuous controls, autonomous action, and potentially quantum computing begin operating together as a new organizational nervous system.

However, no organization can leap directly from today’s fragmented and largely administrative GRC environment into Quantum GRC. Before GRC 8.0 can become operational, organizations must build the architectural, informational, and governance foundations of GRC 7.0 — GRC Orchestrate.

GRC 7.0 is the bridge between the systems of record that dominate the market today and the adaptive, multidimensional, continuously learning environments that will define GRC 8.0. It is the necessary period of rearchitecture in which organizations mature agentic AI, build systems of orchestration, develop connected systems of intelligence and action, use AI to configure GRC capabilities rapidly, and construct digital twins that represent the living enterprise.

Quantum GRC is the destination beyond 2030. GRC Orchestrate is the journey we must undertake now between now and 2030.

Why I Call It Quantum GRC

I use the word quantum deliberately, but I do not use it carelessly. I am not suggesting that every GRC platform will suddenly run on a quantum computer in 2030, nor am I attempting to borrow a fashionable scientific term simply to make the future sound more exciting. Quantum GRC describes a fundamental shift in the nature of the problem GRC must solve and the way organizations will understand uncertainty, relationships, and possible outcomes.

Traditional GRC is largely linear and deterministic. An assessment is distributed, someone completes it, another person reviews it, an issue is created, a remediation task is assigned, and a report is eventually presented to management. The process advances through predefined stages, often across spreadsheets, documents, email, ticketing systems, and disconnected GRC applications. Even when the workflow is automated, the underlying model remains sequential: one input leads to one process, which produces one output.

The real world does not behave this way.

Organizations exist in an environment of multiple simultaneous possibilities . . .

• A strategic decision may succeed under one set of economic assumptions, fail under another, and produce unexpected secondary consequences under a third.
• A supplier may appear financially healthy today while becoming exposed tomorrow through sanctions, political instability, cyberattack, concentration risk, labor disruption, climate events, or the collapse of a critical sub-tier provider.
• A control may appear effective when tested periodically while its actual state is degrading between assessments.
• A technology platform may be secure from one perspective while creating resilience, privacy, regulatory, and dependency risks from another.

This is where the quantum analogy becomes useful. Quantum physics describes a world in which systems cannot always be understood through simple binary states and predictable linear cause-and-effect. Possibilities coexist. Relationships matter profoundly. Observation changes understanding. Seemingly separate entities can be connected in ways that are not obvious when examined individually. Outcomes are probabilistic until conditions, interactions, and decisions cause a particular state to emerge.

GRC 8.0 will operate in a similar conceptual environment. It will not view risk as a static point on a heat map or a single score stored in a register. It will represent uncertainty as a dynamic field of possibilities connected to objectives, decisions, dependencies, controls, external events, and human behavior. It will continuously evaluate how different scenarios could evolve and what combination of actions would preserve or create value.

That is why I call it Quantum GRC.

Risk Exists in a State of Possibilities

One reason the quantum metaphor fits is that risk does not exist as a fixed and observable fact. Risk is the effect of uncertainty on decisions and objectives. Until events unfold, there are multiple possible states, each with different likelihoods, consequences, dependencies, and opportunities.

Broken paradigms of risk management try to collapse this complexity into a score. A risk becomes “high,” “medium,” or “low.” It is given a color, assigned an owner, and placed on a report. This creates the appearance of certainty, but it often destroys the very context decision-makers need.

Consider an organization deciding whether to enter a new market. The decision cannot be reduced to a single risk rating. It exists across a field of possible futures involving political stability, regulatory change, currency movements, customer demand, workforce availability, third parties, supply chains, technology infrastructure, competitive reactions, and reputational consequences. Some scenarios create tremendous value. Others create unacceptable exposure. Most exist somewhere between those extremes.

GRC 8.0 will model these possibilities simultaneously. It will not simply identify risks; it will simulate alternative futures, evaluate how they interact, and help leadership understand the trade-offs among different decisions. Digital twins will allow organizations to test actions against virtual representations of operations, third-party ecosystems, technology environments, and business services before making changes in the real world.

In this sense, Quantum GRC is not about predicting one inevitable future. It is about understanding a landscape of possible futures and improving the quality, speed, and resilience of decisions made under uncertainty.

Risks Are Entangled

The second reason I use the word quantum is entanglement. In quantum physics, entangled particles remain related even when they appear physically separate. In business, risks, controls, objectives, processes, technologies, regulations, and third parties are similarly interconnected. A change in one area can alter the state of many others . . .

• A cyber incident is not merely a cybersecurity risk. It can become an operational disruption, a regulatory breach, a privacy incident, a financial loss, a supply-chain failure, a customer-trust issue, and a board-governance crisis.
• A third-party failure can simultaneously affect service delivery, compliance, resilience, reputation, financial performance, and strategic objectives.
• A new regulation can require changes to policies, controls, contracts, technology, training, reporting, and business processes across multiple jurisdictions.

Traditional GRC architectures fragment these relationships. Cybersecurity is managed in one system, third-party risk in another, compliance in another, audit in another, and business continuity somewhere else. Each function may perform its own assessment, use its own taxonomy, and produce its own report. The organization accumulates information, but it does not gain understanding.

Quantum GRC requires a model of the enterprise in which these relationships are explicit. Risks must connect to objectives, controls, assets, processes, obligations, incidents, suppliers, technologies, people, and performance indicators. The architecture must represent not only direct relationships but also second-, third-, and fourth-order dependencies.

A disruption at a small technology provider may affect a critical service because it supports another supplier that supports a cloud platform used by a business process tied to a material objective. That relationship may be invisible in a conventional register but obvious in a graph-based digital twin.

Quantum GRC understands that nothing significant happens in isolation.

Observation Changes the System

A third element of the quantum analogy is the role of observation. In physics, measurement affects what is observed. In organizations, measurement also changes behavior.

The moment management begins measuring a risk, control, objective, or performance indicator, people respond. Business units may alter processes, prioritize certain activities, change reporting behavior, or optimize around the metric. Sometimes this produces improvement. Sometimes it produces gaming, superficial compliance, or unintended consequences.

Traditional GRC often assumes that measurements are neutral. They are not. A control effectiveness score influences funding. A risk rating affects executive attention. A compliance metric shapes incentives. A resilience target changes operational behavior. The way an organization observes itself becomes part of the system being observed.

GRC 8.0 must therefore understand not only the state of risks and controls but also how measurement, incentives, decisions, and human behavior alter that state. This requires more than data collection. It requires causal reasoning, behavioral context, feedback loops, and the ability to identify when a metric is no longer representing the reality it was designed to measure.

Quantum GRC will not merely report the organization. It will recognize that the act of governance influences the organization.

Quantum Does Not Mean Random

The quantum metaphor should not be misunderstood as suggesting that GRC becomes mysterious, unpredictable, or detached from accountability. Quite the opposite. Quantum GRC is about managing complexity with greater discipline.

The future of GRC will involve probabilities rather than false certainty, but those probabilities must be grounded in evidence, context, and transparent reasoning. Systems must explain what information they used, how they evaluated it, what assumptions were made, and why a particular action was recommended.

Agentic systems operating in GRC 8.0 will need to be governed with clear permissions, constraints, validation, auditability, and human accountability. Greater intelligence does not eliminate governance. It makes governance more important.

The objective is not to create an all-knowing machine that makes decisions for the organization. The objective is to create an environment in which humans and machines can understand more possibilities, evaluate more relationships, test more scenarios, and respond more effectively than either could alone.

GRC 8.0 Is a Quantum Leap, Not an Incremental Upgrade

The phrase quantum leap is often misused to describe any large improvement. In this context, however, it is appropriate because GRC 8.0 represents a transition to a different operating state.

The difference between traditional GRC and Quantum GRC is not comparable to adding another module or improving a dashboard. It is the difference between documenting the organization and modeling it, between reviewing the past and simulating the future, between periodically testing controls and continuously sensing their state, and between routing tasks to people and orchestrating coordinated action across humans, agents, systems, and digital twins.

GRC 8.0 will operate across dimensions that traditional GRC cannot process effectively:

• Multiple possible futures evaluated simultaneously
• Interconnected risks and dependencies modeled dynamically
• Continuous sensing of internal and external change
• Causal analysis of how events propagate through the enterprise
• Digital twins used to simulate decisions and disruptions
• Agent ecosystems coordinating intelligence and action
• Adaptive controls responding to changes in context
• Homeostatic mechanisms maintaining the organization within acceptable boundaries
• New computing capabilities processing scenarios at unprecedented scale

This is not an enhancement to the old GRC model. It is a new model. Yet every element of this future depends on foundations that most organizations do not currently possess.

GRC 7.0: The Architecture Quantum GRC Requires

GRC 7.0 — GRC Orchestrate — is the current period in which organizations rearchitect GRC for this future. It is not a temporary collection of AI features. It is the transformation of GRC from fragmented systems of record into a connected system capable of coordinating intelligence, decisions, and action.

Many current GRC platforms were designed when the central challenge was replacing spreadsheets and managing documentation. Their architecture is built around relational databases, forms, workflows, tasks, and reports. These capabilities remain useful, but they are insufficient for a world of continuous change, interconnected dependencies, external intelligence, agentic automation, and simulation.

A relational database can tell an organization that a risk is linked to a control. It struggles to represent the full web of relationships among objectives, decisions, suppliers, technologies, processes, obligations, incidents, scenarios, and downstream consequences. It can store the result of an assessment, but it does not inherently understand how a change in one part of the enterprise alters the state of everything connected to it.

GRC 7.0 addresses this through a system of orchestration supported by connected data, graph architectures, ontologies, agents, digital twins, and governed automation. The purpose of GRC 7.0 is to make GRC capable of understanding and coordinating the enterprise before attempting to make it autonomous.

The System of Orchestration

The central architecture of GRC 7.0 is the system of orchestration. This is the capability that coordinates people, processes, information, technologies, agents, and actions across GRC.

I often compare this to a symphony orchestra. The strings, brass, woodwinds, and percussion each have distinct roles. Their individuality is not a problem. The problem arises when they play independently without coordination. The conductor does not replace the musicians; the conductor ensures that their contributions are aligned in timing, context, and purpose.

The same is true across GRC. Enterprise risk, compliance, cybersecurity, audit, privacy, third-party risk, resilience, legal, policy management, investigations, and AI governance each require specialized expertise. GRC Orchestrate does not eliminate these disciplines or force them into one homogeneous process. It connects them so that the organization can understand how their work relates to common objectives, dependencies, and decisions.

The orchestration layer establishes the context in which intelligence is interpreted and actions are coordinated. Without it, AI agents merely automate fragments of an already fragmented environment.

Within the system of orchestration are the core subsystems that will mature throughout GRC 7.0: the system of intelligence, the system of action, and the system of configuration.

The System of Intelligence

The system of intelligence is the sensing and understanding layer of GRC 7.0. Its purpose is to gather information, connect it to business context, reduce noise, identify patterns, and surface what matters.

Organizations are drowning in data. They have threat intelligence, regulatory updates, sanctions lists, adverse media, control evidence, audit findings, third-party assessments, financial indicators, performance metrics, geopolitical analysis, incident reports, and operational telemetry. The challenge is no longer obtaining information. The challenge is distinguishing signal from noise.

Agentic AI can gather and process this information at a scale that human teams cannot match. However, intelligence only becomes useful when it is connected to the organization’s objectives, services, assets, processes, suppliers, obligations, controls, and decision-makers.

A regulatory change is not important merely because it exists. It is important because it affects particular jurisdictions, products, obligations, controls, contracts, processes, and accountable owners. A cyber alert is not material merely because it is technically severe. Its significance depends on the business service, data, customer impact, resilience requirements, and strategic objectives connected to the affected technology.

The system of intelligence therefore requires a connected model of the enterprise. It must understand relationships and context, not simply ingest more data. This is where graph architectures, ontologies, knowledge models, and digital twins become essential. They allow GRC to understand how information relates to the organization and why it matters.

The System of Action

The system of action transforms intelligence into coordinated response. It is the automation layer of GRC 7.0, but it is more than conventional workflow.

Traditional workflow routes tasks. Agentic action can gather evidence, evaluate conditions, apply decision criteria, create findings, recommend remediation, initiate assessments, update risk exposure, escalate issues, and coordinate responses across systems.

The system of action will mature gradually. Early agents will operate under significant human supervision. They will prepare recommendations, complete repetitive work, and route decisions to accountable people. Over time, organizations will allow agents to execute increasingly complex activities within established boundaries.

This progression is necessary because trust must be built through experience. Organizations need to understand how agents behave, how decisions are explained, how mistakes are detected, and how accountability is maintained.

Autonomous GRC cannot begin with autonomy. It begins with governed, transparent, human-in-the-loop action.

GRC 7.0 provides the years of operational maturity required to establish that trust. By the time organizations reach GRC 8.0, they may allow certain systems to act with significant autonomy, but that autonomy will be the result of tested governance, not blind technological enthusiasm.

The System of Configuration

The system of configuration is an emerging capability that deserves a formal place within GRC 7.0. AI is changing not only how GRC work is performed but also how GRC capabilities are designed, built, and modified.

Traditional implementations require administrators, consultants, and developers to translate requirements into data structures, forms, workflows, roles, reports, integrations, and controls. Even no-code platforms demand knowledge of the platform and significant configuration effort.

A system of configuration allows organizations to provide requirements through natural language, documents, frameworks, process diagrams, meeting transcripts, policies, and regulations. AI can interpret those materials, recommend an operating model, identify missing decisions, construct workflows, create data relationships, configure agents, and deploy the capability into a controlled environment.

This is significant because the future organization must be able to adapt GRC rapidly. Regulatory change, acquisitions, new business models, geopolitical events, and technological innovation will require programs to evolve continuously. Waiting months for a conventional implementation cycle will be incompatible with the velocity of the environment.

However, rapid configuration must not become rapid chaos. AI-generated applications still require architectural discipline, testing, permissions, change control, and lifecycle governance. The system of configuration must operate within the system of orchestration and be subject to the same accountability as every other part of GRC.

The objective is not simply to build faster. It is to adapt faster without losing control.

Digital Twins as the Bridge to Quantum GRC

Digital twins are one of the most important capabilities of GRC 7.0 because they establish the modeling foundation for GRC 8.0.

A digital twin is a dynamic representation of an entity, process, service, system, third party, control environment, or enterprise. It is continuously updated with real-world information and can be used to evaluate scenarios before actions are taken in the real environment.

In GRC, digital twins can represent a critical business service and all its dependencies: people, processes, applications, data, cloud services, facilities, telecommunications, suppliers, controls, obligations, and recovery capabilities. The organization can then simulate what happens when one or more of those elements fail . . .

• What happens if a cloud region becomes unavailable while a critical supplier is also experiencing financial distress?
• What happens if a new regulation restricts data transfer while the organization is migrating systems?
• What happens if a ransomware attack occurs during a product launch or geopolitical crisis?

Traditional GRC records these dependencies. Digital twins allow the organization to experience their consequences virtually.

This is essential for Quantum GRC because GRC 8.0 will rely on networks of digital twins interacting with systems of intelligence and action. The organization will continuously simulate possible futures, evaluate responses, and adjust controls or decisions before disruption becomes irreversible.

Without digital twins, Quantum GRC has nothing meaningful to simulate.

Homeostatic GRC and the Evolution Toward GRC 8.0

The long-term destination of this architecture is homeostatic GRC: an environment capable of sensing change, understanding its implications, deciding what response is appropriate, and acting to keep the organization within acceptable boundaries.

The human body provides a useful analogy. It continuously regulates temperature, oxygen, hydration, blood chemistry, and other conditions without requiring conscious intervention for every adjustment. When conditions move outside acceptable limits, the body detects the change and responds.

GRC 8.0 will apply a similar principle to organizational governance, risk, compliance, resilience, and performance. It will continuously evaluate whether the organization remains aligned with objectives, obligations, values, and risk boundaries. When conditions change, it will recommend or initiate actions to restore stability or pursue opportunity.

This does not mean eliminating human leadership. Homeostasis does not determine the purpose of the organization. Humans establish strategy, objectives, values, and acceptable boundaries. The system helps maintain alignment as the environment changes.

GRC 7.0 builds the sensory, nervous, and action systems. GRC 8.0 allows them to operate as an adaptive whole.

Quantum Computing May Eventually Matter

Although Quantum GRC is primarily a description of a new operating model, literal quantum computing may eventually contribute to it. Quantum computing is particularly relevant to problems involving optimization, complex simulation, probabilistic modeling, and enormous numbers of interacting variables.

Future organizations may use quantum or hybrid quantum-classical systems to evaluate supply-chain configurations, financial exposures, cyberattack pathways, geopolitical scenarios, portfolio risks, and operational resilience options at a scale that is impractical with conventional computing.

This could allow GRC 8.0 to evaluate vast numbers of potential scenarios and identify patterns or optimal responses that would otherwise remain invisible.

However, quantum computing is not the prerequisite for Quantum GRC. The foundational shift begins with architecture, context, orchestration, agents, and digital twins. Quantum computing may accelerate the analysis, but it cannot compensate for fragmented data, unclear objectives, weak governance, or poorly understood dependencies.

A quantum processor will not fix an organization that does not understand itself.

Why GRC 7.0 Cannot Be Skipped

The greatest mistake organizations and technology providers can make is attempting to jump directly from legacy GRC into the language of autonomous and quantum GRC.

An organization cannot simulate the enterprise if it has not modeled its objectives, assets, services, processes, controls, and dependencies. It cannot trust autonomous agents if it has not established permissions, boundaries, auditability, and validation. It cannot act on intelligence if it cannot connect information to business context. It cannot maintain homeostasis if it has not defined acceptable conditions and measurable states.

Most importantly, it cannot build GRC 8.0 on architectures designed primarily to store forms and route tasks.

GRC 7.0 is where organizations do the difficult work of rearchitecture. They create connected data models, establish common taxonomies, develop graph and ontology foundations, mature agent governance, implement systems of intelligence and action, build configurable capabilities, and construct digital twins.

This will take years. That is why the transition must begin now.

The vendors that treat GRC 7.0 as a cosmetic AI upgrade will drift toward irrelevance. The platforms that continue bolting conversational interfaces onto old architectures may look impressive in demonstrations but will struggle to deliver the context, scalability, and adaptability required by the next generation.

The organizations that understand the sequence will be prepared. They will use the remainder of this decade to orchestrate GRC, mature agentic systems, and model the enterprise. When the market moves into GRC 8.0 after 2030, they will possess the architecture and experience required to operate in that environment.

The Future Has an Order

I am enthusiastic about Quantum GRC because I believe it represents the most significant transformation of governance, risk management, compliance, and assurance since the emergence of the GRC market itself. It will change GRC from an administrative capability into a dynamic system for navigating uncertainty, testing possible futures, protecting value, and enabling performance.

But the future must be built in sequence.

• GRC 7.0 — GRC Orchestrate — is the architecture we must build now. It gives us the system of orchestration, the system of intelligence, the system of action, the system of configuration, and the digital-twin foundation required for everything that follows.
• GRC 8.0 — Quantum GRC — is the 2030-and-beyond horizon. It is the environment of interconnected digital twins, advanced agent ecosystems, causal intelligence, continuous simulation, adaptive controls, homeostatic response, and potentially quantum-enhanced analysis.

Organizations cannot collapse multiple stages of architectural and operational maturity into one technology purchase. They cannot prompt their way out of fragmented data, inconsistent processes, and weak governance.

Quantum GRC is coming . . . But the route to GRC 8.0 runs directly through GRC 7.0—and there is no shortcut around it.

From Documentation to Continuous Proof

For decades, compliance has been managed by the calendar. Annual audits, quarterly reviews, periodic attestations, scheduled assessments, point-in-time certifications, and recurring evidence requests have shaped how organizations understand whether they are compliant, controlled, resilient, and trustworthy. The compliance calendar became the operating rhythm of governance, risk management, and compliance (GRC). It told people when to gather documentation, when to test controls, when to complete questionnaires, when to update policies, when to review access, when to certify obligations, and when to prepare for the auditor.

The problem is that the calendar was never designed for the velocity of modern business.

Point-in-time compliance assumes the organization can periodically pause, collect evidence, review activity, and determine whether controls were operating effectively during a defined window. That model may have been workable when business change was slower, technology environments were simpler, third-party ecosystems were smaller, and regulatory expectations were more stable. It is structurally broken in today’s organization.

Compliance risk does not wait for the annual audit. Regulatory change does not wait for the next compliance review. Cyber threats do not wait for quarterly testing. Third-party failure does not wait for the next vendor assessment. Access privileges, configurations, exceptions, policies, controls, incidents, and obligations change constantly. Yet many compliance programs still operate as though assurance is meaningfully achieved through periodic evidence collection and retrospective documentation.

This is the death of the compliance calendar. Not because . . .

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

As season 4 Star Trek: Strange New Worlds returns later this month, I find myself reflecting on one of the most important risk management scenes from the first episode of the previous season (season 3, episode 1, Hegemony Part II) . That may sound odd to some. Most people watch Star Trek for the exploration, the characters, the ethical dilemmas, the humor, the tension, and the enduring optimism that humanity can become something better than it is today. I watch it for all of that as well. But I also watch Star Trek because it has always understood something about risk that too many organizations still struggle to grasp . . .

Risk is not simply danger to be avoided. Risk is the terrain of the mission.

That idea goes back to Captain Kirk in The Original Series, in season two, episode twenty, “Return to Tomorrow,” when he states plainly, “Risk is our business.” That line has stayed with me for decades, and is the theme of my Risk Is Our Business Podcast. It is more than a memorable piece of Starfleet bravado. It is one of the clearest statements of enterprise leadership I know . . .

The mission requires uncertainty. Exploration requires exposure. Strategy requires movement into the unknown. The role of leadership is not to eliminate risk, because that would eliminate the mission itself. The role of leadership is to understand uncertainty, make informed decisions, preserve integrity, protect the crew, and continue toward the objective.

That is the heart of modern GRC!

• Governance sets the mission, makes decisions, sets objectives in context of decisions, and engages for performance.
• Risk management addresses uncertainty in decisions and achieving those objectives.
• Compliance keeps the organization acting with integrity within obligations, boundaries, and values.

Together, they are not a bureaucratic exercise. They are the operating capability by which an organization moves through uncertainty without losing its way.

This is why one story line from that first episode of season 3 last year of Strange New Worlds has stayed with me. Captain Batel is infected by a Gorn parasite. The situation is urgent, complex, and beyond standard medical treatment. The crew cannot simply apply a checklist and hope for the best. They cannot rely on instinct alone. They cannot wait for perfect certainty, because time itself has become a risk factor. What they need is a way to understand her condition dynamically, test possible interventions, explore consequences, and choose a path before acting in the real world.

So they create a digital twin.

That moment is science fiction, but it is also one of the clearest pictures I have seen of where GRC and particularly risk management must go. The digital twin of Batel is not a static record. It is not a medical file. It is not a dashboard of yesterday’s indicators. It is a living model that allows the crew to simulate decisions before making them. It creates a space between uncertainty and action where intelligence can operate.

That is GRC 7.0 – GRC Orchestrate!

GRC 7.0 — what I call GRC Orchestrate — is not about digitizing the stale forms and workflows of the past. We have done enough of that. In too many organizations, technology has simply made bad risk processes faster, more expensive, and more visible. A broken process with automation is still a broken process. A risk register with a prettier dashboard is still a risk register. A heat map in a modern interface is still a heat map. The future of GRC is not another workflow layer over yesterday’s thinking. The future of GRC is a living architecture that can sense, model, decide, act, and learn.

The digital twin is at the center of that future.

From Captain Kirk’s Philosophy to GRC Orchestration

Captain Kirk’s statement that “risk is our business” is not a call to recklessness. It is a call to disciplined courage. The Enterprise does not drift aimlessly through space looking for danger. It has a mission. It has command structure. It has science, engineering, medical, navigation, communications, and tactical capabilities. It has protocols, but it also has judgment. It has systems, but it also has people. It operates in uncertainty, but it does not surrender to uncertainty.

That is what organizations need from GRC.

Too often, GRC has been reduced to documentation, reporting, and compliance activity. Risk becomes a list. Controls become evidence. Compliance becomes attestation. Governance becomes a committee calendar.

The living system of the organization gets flattened into artifacts that can be reviewed, archived, and audited. These artifacts may be necessary, but they are NOT enough. They do not tell leadership how uncertainty moves through the business. They do not show how decisions create consequences. They do not reveal how dependencies connect. They do not allow the enterprise to simulate options before acting.

The Starfleet bridge is not a filing cabinet.

It is a command center. It brings together information from specialized systems, interprets it in the context of the mission, and supports decisions under uncertainty. That is where GRC must go. The board and executive team down into business operations need a bridge view of the enterprise. They need to understand the mission, the environment, the systems, the crew, the controls, the obligations, the dependencies, the risks, and the possible courses of action.

GRC Orchestrate is the architecture for that bridge view.

The Strange New Worlds Moment: Modeling Before Acting

In the Batel scene, the medical team faces a situation where direct experimentation on the patient could be catastrophic. Acting without understanding could kill her. Waiting too long could also kill her. The answer is not paralysis. The answer is simulation. The digital twin allows the crew to explore interventions, evaluate consequences, and improve the quality of decisions and actions.

This is exactly the challenge boards, executives, business operations, and risk leaders face in the modern enterprise. They cannot wait for perfect certainty. Nor can they run the business by instinct alone or assume that yesterday’s controls, yesterday’s suppliers, yesterday’s markets, yesterday’s geopolitical assumptions, or yesterday’s regulatory models will hold tomorrow. They need to model uncertainty before it becomes reality.

Consider the common scenarios organizations face:

• A new regulation is passed in one jurisdiction that affects products, services, policies, controls, reporting, third parties, and customer commitments across several others.
• A company considers acquiring a business that brings with it hidden compliance obligations, cyber vulnerabilities, cultural issues, third-party dependencies, contractual exposures, and control gaps.
• A divestiture requires separation of shared services, technology, data, policies, processes, licenses, controls, and supplier relationships that were never designed to be pulled apart.
• A move into a new market creates new geopolitical exposures, local regulatory obligations, sanctions concerns, labor issues, tax implications, privacy requirements, and operational resilience demands.
• A supplier failure appears local at first, but cascades into production delays, customer commitments, financial exposure, regulatory reporting, and reputational damage.
• A cyber incident starts in technology but quickly becomes an operational, legal, financial, customer trust, and board-level crisis.

These are not theoretical possibilities. They are the everyday reality of enterprise risk. The problem is that many organizations still try to manage this reality through fragmented systems, disconnected taxonomies, static risk registers, periodic assessments, and departmental reporting. Each function sees part of the picture. Few see the whole.

The digital twin changes that.

The Business Digital Twin

When many people hear “digital twin,” they think of a physical asset: a factory, an aircraft engine, a wind turbine, a ship, a production line, an offshore platform, or a data center. These are important applications, and some industries are already quite mature in using digital twins to monitor assets, anticipate maintenance, optimize performance, and improve resilience.

But the next frontier is broader. It is the business digital twin.

A business digital twin models the enterprise as a living system. It connects objectives to processes. Processes to assets. Assets to systems. Systems to data. Data to obligations. Obligations to controls. Controls to assurance. Assurance to confidence. Confidence to decision-making. It also connects third parties, suppliers, geographies, people, contracts, policies, regulatory requirements, cyber dependencies, financial exposures, and strategic initiatives.

The digital twin is not a glorified dashboard. A dashboard tells you what is happening or what has happened. A digital twin helps you understand what could happen, why it could happen, how it could unfold, and what actions might change the outcome.

This is the shift from rearview reporting to forward-looking decision support.

In traditional approaches, organizations often begin with the risk register. They ask people to identify risks, score them, assign owners, link controls, and update status. That may provide some structure, but it often misses the most important point. Risk does not begin with the risk register. Risk begins with decisions and objectives. If risk is the effect of uncertainty on objectives (ISO 31000), then the model must begin with what the organization is trying to achieve.

The risk register is not the center of the universe. Objectives are.

A business digital twin starts with the mission, decisions, and objectives of the organization. It then models the uncertainty that could affect those decisions and objectives, the controls that support them, the obligations that constrain them, the dependencies that enable them, and the scenarios that could threaten or advance them. This is how risk management becomes decision- and objective-centric. This is how GRC becomes meaningful to the business.

Risk Intelligence Feeds the Twin

A digital twin is only as useful as the intelligence that feeds it. A model without current intelligence becomes an elegant fiction. It may describe the organization as it once was, or as leadership wishes it to be, but it will not reflect the reality of changing conditions.

This is where risk intelligence becomes essential . . . The enterprise needs to continuously sense the external and internal environment. That includes geopolitical developments, regulatory change, enforcement actions, sanctions, tariffs, supplier distress, cyber threats, vulnerability data, climate events, litigation trends, market shifts, customer sentiment, workforce signals, financial indicators, peer incidents, and emerging technologies. It also includes internal signals such as control performance, incidents, audit findings, policy exceptions, project changes, third-party issues, and operational disruptions.

Risk intelligence feeds the digital twin with reality. But intelligence alone is not enough. Many organizations already have more data than they can interpret. The problem is not the absence of signals. The problem is connecting signals to business context.

A geopolitical event matters differently depending on suppliers, contracts, routes, customers, jurisdictions, products, and strategic objectives. A regulatory change matters differently depending on obligations, policies, controls, business processes, systems, and third parties. A cyber vulnerability matters differently depending on critical services, data flows, operational dependencies, and recovery capabilities.

Risk intelligence must be contextualized . . . This is where agentic AI becomes powerful.

Agentic AI Interrogates and Orchestrates

The future of AI in GRC is not simply faster policy drafting, automated control narratives, better regulatory summaries, or chatbots that answer compliance questions. Those capabilities are useful, but they are not the transformation. They are efficiencies. The deeper transformation is when agentic AI can work with the digital twin to interpret signals, test scenarios, recommend actions, and orchestrate response.

Risk intelligence feeds the twin. Agentic AI interrogates the twin. GRC Orchestrate acts through the twin. This is the architecture that matters. AI without a digital twin lacks business context. A digital twin without risk intelligence lacks current reality. Risk intelligence without orchestration lacks action. GRC 7.0 brings these together into a living system.

Agentic AI can help answer questions such as:

• Which objectives are affected by this regulatory change?
• Which controls need to be updated if we enter this new market?
• Which third parties create concentration risk in this scenario?
• Which business services are exposed if this system fails?
• Which policies, obligations, and training requirements are inherited in this acquisition?
• Which controls must be separated, redesigned, or retested in this divestiture?
• Which cyber vulnerabilities matter most because of business criticality?
• Which emerging geopolitical events could affect suppliers, logistics, sanctions exposure, or revenue?
• Which assurance activities provide confidence, and where are we relying on assumptions?

This does not mean AI replaces human judgment. That would be the wrong lesson. Spock and Chapel did not use the digital twin so they could stop thinking. They used it so they could think better. The purpose of AI in GRC is not to remove accountability. It is to improve the quality, speed, and context of accountable decisions.

AI should not replace governance. It should strengthen governance. AI should not replace risk professionals. It should elevate them. AI should not turn GRC into a black box. It should make the enterprise more transparent, more explainable, and more prepared.

Three Levels of Risk and Resilience, with Digital Risk Embedded Across Operations

To make this practical, GRC 7.0 must operate across three connected levels of risk and resilience, with digital risk and resilience embedded deeply within the operational layer. These are not separate silos. They are different views of the same enterprise system. The digital twin has to model their relationships.

Strategic Risk and Resilience

Strategic risk and resilience focus on the decisions that shape the future of the organization. This is where boards and executive teams make choices about markets, products, mergers, acquisitions, divestitures, capital allocation, business models, major partnerships, and long-term positioning. These decisions are filled with uncertainty, and too often that uncertainty is not modeled deeply enough before action is taken.

A business digital twin can help leadership test strategic decisions before they become irreversible.

• What happens if we acquire this company?
• What obligations, controls, culture issues, data risks, third-party dependencies, cyber exposures, litigation history, geopolitical concerns, and operational weaknesses come with it?
• What happens if we divest this business unit?
• Which shared services, data flows, systems, licenses, controls, people, policies, and contracts have to be separated?
• What happens if we enter a new market?
• What regulations apply?
• What local authorities matter?
• What sanctions, corruption, human rights, labor, privacy, tax, supply chain, and resilience issues must be understood?

This is where risk becomes a tool of strategic clarity. It is not there to say no to the mission. It is there to make sure leadership understands the terrain before crossing it.

Strategic risk also requires understanding the difference between local performance and enterprise value. A project may appear to be failing because it misses a schedule KPI, but from the enterprise view, preserving value may matter more than preserving the date. Another project may look successful locally while creating long-term risk for the enterprise. The digital twin helps leadership see across the portfolio and ask whether decisions are optimizing the mission or merely optimizing metrics.

Objective-Centric Risk and Resilience

Objective-centric risk and resilience begin with a simple but often ignored truth: risk must be understood in relation to objectives.

Too many risk processes start by asking, “What are your risks?” That question is incomplete. The better question is, “What are you trying to achieve, and what uncertainty could affect that?”

This is the foundation of meaningful risk management. Decisions and objectives give risk context. Without objectives, risk becomes a list of concerns. With objectives, risk becomes decision intelligence.

The business digital twin allows the organization to map objectives to the processes, controls, obligations, resources, systems, third parties, and people that support them. It helps leadership see whether objectives are realistic, whether controls are sufficient, whether dependencies are understood, whether obligations are changing, and whether uncertainty is increasing or decreasing.

This is particularly important in regulatory change. A new law, rule, supervisory expectation, enforcement trend, or reporting obligation should not simply trigger a compliance task. It should be modeled against objectives and operations.

• What products are affected?
• What business units are affected?
• What jurisdictions are affected?
• What policies must change?
• What controls must be redesigned?
• What training is required?
• What third parties are involved?
• What data is needed?
• What evidence will prove compliance?
• What strategic decisions are constrained or enabled by this change?

Regulatory change is not just a legal update. It is a business change.

The same is true for corporate transformation. A merger, acquisition, divestiture, restructuring, new product launch, new market entry, or major technology implementation changes the shape of the enterprise. If GRC cannot model that change, it will always be reacting after the fact. GRC 7.0 requires the ability to model change before change breaks the business.

Operational Risk and Resilience

Operational risk and resilience focus on whether the organization can deliver its products, services, commitments, and obligations in the face of disruption. This is where the digital twin becomes very tangible. It maps processes, assets, systems, facilities, suppliers, people, controls, incidents, issues, recovery plans, and dependencies. It allows the organization to understand not simply that something failed, but what that failure means.

This is also where digital risk and resilience lives. Digital risk is not separate from operational risk. It is now one of the primary ways operational risk materializes . . .

• A ransomware attack on a system is not merely a cyber event. It is an operational event that may affect order fulfillment, manufacturing, customer service, safety, regulatory reporting, contractual commitments, financial close, and executive decision-making.
• A cloud outage is not merely an IT outage. It may become a business outage.
• A data integrity issue is not merely a technical issue. It may become a compliance, financial, customer, and trust issue.
• An AI failure is not merely a model issue. It may become an operational, ethical, regulatory, and reputational issue.

Digital risk and resilience deserve a distinct lens because digital technology now underpins the operating fabric of the enterprise. But that lens should sit within the broader operational risk and resilience picture. The point is not to separate cyber, technology, data, cloud, identity, and AI from operations. The point is to understand how deeply they are embedded in operations.

A digital twin of the enterprise must therefore understand the digital fabric of the business. It must know . . .

• Which systems support which objectives.
• Which data flows support which obligations.
• Which identities have access to which processes.
• Which third parties support which services.
• Which vulnerabilities matter because of business criticality.
• Which AI models create regulatory, ethical, operational, or reputational exposure.
• Which digital dependencies could become single points of failure.

Operational resilience requires modeling the chain of consequence. A supplier failure is not just a procurement issue. It may affect production, quality, sustainability commitments, customer obligations, revenue, and brand trust. A natural disaster is not just a business continuity scenario. It may affect people, assets, logistics, compliance obligations, insurance, and market reputation. A cyber incident is not just a technology scenario. It may affect the organization’s ability to operate.

This is where controls become critical. Controls are not merely compliance artifacts. They are operating mechanisms that help the organization remain within a desired state . . .

• A recovery plan is a control.
• A supplier exit strategy is a control.
• A system configuration is a control.
• An identity access rule is a control.
• A quality checkpoint is a control.
• A safety procedure is a control.
• A local regulatory engagement process in a high-risk jurisdiction can be a control.
• A decision cadence can be a control.
• A culture of escalation can be a control.

In the digital twin, controls should be modeled as measurable states . . .

• Are they present?
• Are they operating?
• Are they effective?
• Are they sufficient for the current level of uncertainty?
• Are they aligned to the objective?
• Are they creating friction without reducing risk?
• Are they duplicated?
• Are they failing because of technology, process, ownership, culture, or people?

These are very different questions from, “Did someone complete the attestation?”

Modeling Business Change Before Change Breaks the Business

One of the most powerful applications of digital twins in GRC is modeling business change. Most organizations are better at modeling financial outcomes than GRC consequences. A business case for an acquisition may include revenue synergies, cost savings, valuation assumptions, and integration timelines, but the other GRC implications are often scattered across legal, compliance, cyber, finance, HR, procurement, operations, and audit. By the time the hidden obligations, control gaps, culture conflicts, third-party exposures, data risks, and policy misalignments are discovered, the deal is already in motion.

GRC 7.0 changes that. It brings GRC into strategic decision-making before the decision is locked. A digital twin can model the GRC impact of . . .

• Mergers and acquisitions
• Divestitures and separations
• New market entry
• New product and service launches
• Major technology transformations
• Supplier transitions
• Outsourcing and managed service arrangements
• Regulatory change
• Restructuring and operating model changes
• Geopolitical shifts and sanctions exposure

This is not about slowing the business down. It is about preventing the business from flying blind. The goal is not to create more bureaucracy around change. The goal is to give leadership better visibility into the obligations, controls, risks, dependencies, and resilience requirements that change creates.

In the language of Starfleet, you do not wait until the ship is inside the anomaly to ask whether the shields work.

Homeostatic GRC

The concept I keep returning to is homeostasis. A living organism survives because it senses change, interprets signals, acts, and restores stability within viable boundaries. Temperature, oxygen, infection, fatigue, pressure, and stress are continuously monitored and adjusted. The organism does not wait for a quarterly meeting to notice that something is wrong. It responds because survival requires responsiveness.

The enterprise needs the same capability. Homeostatic GRC continuously senses internal and external change, understands objectives and thresholds, detects drift, recommends action, orchestrates response, and learns from the outcome. This is not annual risk management. It is not quarterly compliance theater. It is not a static risk register waiting for someone to update it. It is GRC as a living system.

A homeostatic enterprise can ask:

• Where are we exposed?
• Where are controls weakening?
• Where are objectives threatened?
• Where are obligations changing?
• Where are local incentives undermining enterprise value?
• Where are emerging risks forming before they become visible?
• Where are we resilient, and where are we brittle?
• Where do we need to adapt before disruption forces adaptation upon us?

This is where GRC Orchestrate becomes more than a technology vision. It becomes an operating model. The digital twin provides the model. Risk intelligence provides the signals. Agentic AI provides interpretation and recommended action. Controls provide the mechanisms. Governance provides accountability. Assurance provides confidence. Resilience provides the ability to absorb, adapt, and continue.

People Risk as Field Zero

No digital twin of the enterprise is complete if it ignores people. We are comfortable modeling assets, systems, suppliers, applications, regulations, financial exposure, and operational processes. We are less comfortable modeling the human conditions that determine whether any of those things work as intended. Yet people affect nearly every dimension of risk and resilience.

People affect control effectiveness. People affect fraud, safety, cyber hygiene, escalation, decision quality, culture. People affect whether issues are surfaced early or hidden until they become crises. A tired crew makes mistakes. A fearful crew hides problems. A poorly trained crew bypasses controls. A misaligned crew optimizes locally and damages the mission. A culture that punishes bad news will eventually become blind.

In many organizations, people risk is not simply one category among many. It is closer to field zero.

This does not mean turning the organization into a surveillance state. That would be the wrong lesson, and certainly not a Starfleet one. It means understanding how capacity, competence, culture, incentives, leadership behavior, turnover, accountability, and trust affect the operating state of the organization. The ship is not just the warp core. It is the crew. The enterprise is not just systems and processes. It is people making decisions under uncertainty.

The Boardroom Needs a Bridge View

Boards and executives do not need more disconnected reports, each produced by a different function with its own taxonomy, scoring model, and version of reality. They need a bridge view. They need to see the mission, the environment, the dependencies, the controls, the weak signals, the scenarios, the thresholds, and the decision options. They need to understand not only what the top risks are, but how those risks affect objectives.

They need to know . . .

• Where assurance is strong and where it is thin.
• Which controls matter most.
• When the organization is resilient and when it is simply lucky.
• When local metrics are creating enterprise exposure.
• When regulatory change affects strategy.
• When a merger brings inherited obligations that could undermine value.
• When a divestiture could fracture controls, systems, data, and accountability.
• When entering a new market creates risks the business case did not fully price.

The boardroom needs mission intelligence.

That is where digital twins change the conversation. They move GRC from rearview reporting to forward-looking decision support. They allow leaders to explore plausible futures, challenge assumptions, and evaluate trade-offs. They help the organization understand whether it is preserving value, creating value, or simply protecting metrics that no longer tell the whole story.

The Risk Professional as Navigator

By 2030, the best risk programs will look very different from the ones many organizations operate today. They will still have policies, controls, assessments, reports, and assurance activities. Those things are not going away. But they will be connected into a living architecture.

• Risk management will be less about collecting updates and more about modeling uncertainty in relation to decisions and objectives.
• Compliance will be less about chasing attestations and more about enabling integrity across changing business models.
• Controls will be less about documentation alone and more about measurable operating states.
• Assurance will be less about periodic comfort and more about continuous confidence.

The risk professional of the future is not a clerk of the risk register. The risk professional of the future is a navigator. Someone who understands the mission, the objectives, the uncertainty, the systems, the dependencies, the controls, and the consequences of action. Someone who can stand on the bridge with leadership and say: here is where we are, here is what is changing, here is what we know, here is what we do not know, here are the scenarios, here are the options, and here is what this means for the mission.

That is why the Star Trek analogy matters. The crew does not succeed because they avoid uncertainty. They succeed because they face uncertainty with intelligence, discipline, technology, ethics, teamwork, and command judgment. They model what they can. They challenge assumptions. They make decisions. They act.

Risk Is Our Business

Captain Kirk gave us the philosophy: risk is our business. Strange New Worlds gave us the model: the digital twin. GRC 7.0 gives us the enterprise architecture: GRC Orchestrate, where digital twins, risk intelligence, agentic AI, controls, assurance, resilience, and governance come together to help organizations make better decisions under uncertainty.

The world is not becoming simpler. Geopolitics is not becoming calmer. Regulation is not becoming less complex. Technology is not becoming less embedded. Supply chains are not becoming less fragile. Cyber threats are not becoming less disruptive. Climate, people, resilience, trust, and performance are not separate conversations. They are all part of the same mission.

The organizations that thrive will be those that build the capability to sense, think, model, decide, act, and learn. They will not treat risk as a compliance artifact or a color-coded chart. They will treat risk as part of the mission. They will build digital twins to understand the enterprise. They will use risk intelligence to keep those twins connected to reality. They will use agentic AI to interrogate scenarios and orchestrate action. They will use controls as measurable states. They will use assurance to build confidence. They will use governance to preserve accountability and integrity.

The mission is not simply to avoid danger. The mission is to explore, adapt, protect the crew, preserve the ship, uphold integrity, and keep moving toward the objective . . . Risk is not the enemy of the mission . . . Risk is the terrain of the mission.

Risk is our business!

Why Predictive Risk Intelligence Will Define the Next Generation of GRC

For decades, governance, risk management, and compliance (GRC) programs have been built around monitoring. Organizations monitor controls, risks, regulations, issues, incidents, third parties, policies, audits, key risk indicators, and performance metrics. Monitoring is necessary. It tells the organization what is happening, what has failed, what is out of tolerance, and what requires attention. But monitoring has a fundamental limitation: it is often looking at the present through evidence from the past.

In a world of volatility, interconnected risk, geopolitical instability, regulatory velocity, cyber disruption, third-party fragility, economic uncertainty, and rapid technological change, monitoring alone is no longer enough. By the time many risks appear on a dashboard, the organization may already be exposed. By the time an issue is escalated, the impact may already be spreading. By the time a control fails, the damage may already be underway. By the time a regulatory change is mapped, the business may already be behind.

Monitoring Is Necessary, But It Is Not Sufficient

Traditional risk monitoring has focused on . . .

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

---

Why integrated GRC is required for risk, resilience, trust, and sovereignty . . .

I have spent more than three weeks in Europe in June, moving between London, Oslo, Zurich, Frankfurt, Copenhagen, and Berlin. Last month it was another two weeks across London and Zurich. I am in Europe every month, sometimes several weeks of the month . . . and for several years it has been the busiest market for GRC technology solutions and professional services. In each city, I setup a range of meetings. That is my job, research. They are practical conversations with organizations trying to understand what governance, risk management, compliance, cybersecurity, resilience, data protection, AI governance, third-party risk, and digital sovereignty mean when they are interconnected from a European perspective (and with that a region and a country perspective).

And that is the point. In Europe, they are heavily interconnected . . .

There is a saying that “the USA invents, China copies, and the EU regulates.” Like most sayings, it is too simple, but it captures something important. Europe regulates with intent. It regulates to shape markets, protect rights, create trust, strengthen accountability, preserve resilience, and increasingly assert digital and data sovereignty. But what many outside Europe misunderstand is not just what Europe regulates. They misunderstand how Europe regulates.

Too many organizations, particularly those shaped by a U.S. compliance mindset, approach European regulation as if it were a set of disconnected requirements that can be assigned to different project teams . . .

• Privacy gets GDPR.
• Security gets NIS2.
• Financial-services risk gets DORA.
• Product teams get the Cyber Resilience Act.
• Data teams get the Data Act.
• AI teams get the AI Act.
• Legal gets contract clauses.
• Procurement gets vendor questionnaires.
• Compliance gets evidence.
• The board gets a dashboard.

That may look organized on paper. In practice, it creates fragmentation . . .

The European regulatory model does not lend itself to fragmented compliance activity. It increasingly combines detailed legal obligations with principle-based, risk-based, outcome-based accountability. The EU’s own better regulation agenda emphasizes coherence, effectiveness, proportionality, implementation, and laws that achieve their intended impact. That does not mean European regulation is vague or light-touch. Many EU laws are highly detailed. But the logic underneath them is different from the way compliance is often operationalized in the United States.

In Europe, the organization is not simply being asked to prove that a control exists. It is being asked to demonstrate that it understands the risk, governs the risk, can evidence accountability, and can sustain resilience when things go wrong.

This is why applying a U.S. regulatory lens to Europe is dangerous. In the United States, compliance too often gets in the way of risk management. It becomes a defensive exercise: satisfy the auditor . . . produce the evidence . . . close the finding . . . and move on.

In Europe, compliance demands risk management, a risk-based approach to compliance. It requires the organization to connect obligations to business processes, data flows, technology dependencies, third parties, critical services, and operational resilience. It requires the organization to see the whole.

That is the heart of this article!

European GRC cannot be managed as a series of disconnected regulatory projects. It has to be managed as an integrated architecture because the regulations themselves overlap, cascade, reinforce, and sometimes create tension with one another. The value of GRC is not in proving that individual compliance activities happened. The value of GRC is in helping the organization understand how these obligations intersect and what that means for risk, resilience, accountability, trust, and business decision-making.

---

The European Regulatory Agenda Is an Ecosystem, Not a Timeline

It is tempting to look at the European regulatory agenda as a timeline over the past decade we have seen . . .

• GDPR
• Cybersecurity Act
• Open Data Directive
• Data Governance Act
• Digital Markets Act
• Data Act
• Digital Services Act
• NIS2
• DORA
• AI Act
• Critical Entities Resilience Directive
• Cyber Resilience Act

The dates matter, of course. Deadlines matter. Enforcement matters. Transposition matters. Implementation matters.

But the timeline is not the story . . . the story is the ecosystem . . .

These laws are not isolated towers. They are more like a city grid, where roads, power lines, water systems, rail, fiber, public services, and emergency routes all intersect beneath the surface. You can stand on one street corner and think you are looking at a single road, but underneath it are layers of dependency. Cut the wrong line and the disruption appears somewhere else. That is how European regulation increasingly works.

• GDPR is not merely a privacy regulation. It established accountability as a governing expectation for personal data, requiring organizations not only to comply but to be able to demonstrate compliance. The European Data Protection Board describes accountability under GDPR in exactly those terms: controllers are responsible for, and must be able to demonstrate, compliance. That idea of demonstrable accountability now echoes far beyond privacy.
• The Data Governance Act and the Data Act are not simply data-sharing laws. They sit inside Europe’s broader ambition to create a trusted data economy. The Commission describes the Data Act as complementing the Data Governance Act, while the Data Act itself addresses access to and use of data, interoperability, cloud switching, and safeguards against unlawful third-country government access to non-personal data held in the EU. That is not a privacy silo. That is data governance, market structure, digital sovereignty, cloud strategy, and operational control all converging.
• The Digital Services Act and Digital Markets Act are not simply platform laws. The Commission describes the DSA as complemented by the DMA: one focused on safer digital services and fundamental rights, the other on gatekeeper power and contestability in digital markets. But the moment a platform changes advertising, recommender systems, researcher access, interoperability, or user choice, it is also touching privacy, cybersecurity, AI governance, data access, and competition.
• DORA is not simply an ICT compliance regulation for financial services. It is a digital operational resilience regime that expects financial entities to withstand, respond to, and recover from ICT disruptions, including cyberattacks and system failures. It harmonizes expectations around ICT risk, incident reporting, resilience testing, and third-party ICT service providers. NIS2 is not merely another cybersecurity directive; it is about cybersecurity risk-management measures and coordinated response across essential and important services. The Cyber Resilience Act is not merely product security; it complements NIS2 and pushes security obligations into the lifecycle of products with digital elements.

When seen together, the message is clear: Europe is not building a set of isolated compliance programs. Europe is building connected regulatory infrastructure.

---

The Intersection Is the Point

The central question for an organization should not be only, “Which regulation applies to us?” That question matters, but it is not enough. The better question is . . .

• “How do these regulations intersect across our data, systems, products, services, vendors, customers, countries, infrastructure, and operating model?”

This is where GRC becomes real . . .

A single business process can trigger multiple European regulatory regimes. A connected product may raise Data Act obligations because users have rights to access data generated through use of the product. If that data includes personal data, GDPR is immediately in scope. If the data is shared into a sectoral data space, the Data Governance Act may become relevant. If the data is used to train or operate an AI system, the AI Act enters the conversation. If the product contains digital elements, the Cyber Resilience Act may apply. If the product supports an essential or important service, NIS2 or the Critical Entities Resilience Directive may become relevant. If the customer is a financial institution, DORA expectations may cascade contractually through the supply chain.

That is not a theoretical compliance puzzle. That is what organizations are dealing with in real life . . .

I see this repeatedly in my conversations across Europe. One team believes it is working on privacy. Another believes it is working on cyber. Another believes it is working on operational resilience. Another believes it is working on AI governance. Another believes it is working on third-party risk. Another believes it is working on digital sovereignty. But when you trace the actual business process, they are often talking about the same data, the same system, the same vendor, the same service, the same incident pathway, and the same executive accountability.

This is why fragmented risk, resilience, and compliance fails . . . It does not fail because people are not working hard. It fails because the structure is wrong. Separate projects create separate inventories, separate assessments, separate controls, separate evidence repositories, separate risk language, separate reporting, and separate versions of the truth. The organization may be busy, but it is not necessarily governed.

A fragmented approach produces motion. An integrated approach produces direction.

---

Europe Is a Rail Network, Not a Filing Cabinet

One of the better ways to think about European regulation is not as a filing cabinet, but as a rail network.

The filing cabinet analogy is how many organizations still operate. GDPR goes in one drawer, DORA in another, NIS2 in another, the AI Act in another, the Data Act in another, and the Cyber Resilience Act somewhere else entirely. Each drawer has its own owner, its own spreadsheet, its own controls, and its own evidence. Every now and then someone opens multiple drawers and tries to reconcile what is inside.

But Europe is not a filing cabinet . . . Europe is a rail network . . .

Each regulation is a line, but the complexity and importance are in the connections. Some lines run in parallel. Some cross at major stations. Some share infrastructure. Some carry different passengers into the same hub. A disruption on one line can cascade into others. If you only manage one track at a time, you do not understand the network.

Data is one of those hubs. Cybersecurity is another. Third-party risk is another. AI governance is another. Operational resilience is another. Digital sovereignty is quickly becoming one of the most important hubs of all.

Integrated GRC is the discipline that allows the organization to see the network rather than stare at individual tracks. It helps management understand where obligations overlap, where controls can serve multiple purposes, where evidence can be reused, where risks compound, where incidents trigger multiple reporting duties, and where a local regulatory nuance changes the operating reality.

---

Data Is the First Intersection

Data is the most obvious place where these regulations converge. Europe wants data to move, but it does not want data to move without governance. That distinction is critical.

The Open Data Directive, the Data Governance Act, the Data Act, and the broader European data strategy all reflect Europe’s desire to unlock the value of data. Common European Data Spaces are intended to make more data available for access and reuse in a trustworthy and secure environment for European businesses and citizens.The Data Act creates clearer rules for access to and use of data, emphasizes fair access and user rights, and addresses interoperability and cloud switching.

But none of this overrides GDPR. None of this eliminates security obligations. None of this removes the need for lawful purpose, transparency, proportionality, confidentiality, contractual control, or accountability. Europe is NOT saying, “Open the data and let the market sort it out.” Europe is saying, “Unlock the value of data within a governed environment that respects rights, competition, security, sovereignty, and trust.”

That is a fundamentally different posture.

A U.S.-centric approach may hear “data sharing” and immediately think about monetization, analytics, platform integration, or AI development. In Europe, the question is broader and more disciplined . . .

• Can we access the data?
• For what purpose?
• Under what lawful basis?
• Who has rights to it?
• Who else can use it?
• Does it include personal data?
• Does it contain commercially sensitive data?
• Is it subject to contractual restrictions?
• Does it support a critical service?
• Does it flow to a third country?
• Does a cloud provider or subcontractor have access?
• Could it be used in AI?
• Could it create unfairness, opacity, or dependency?

This is why European GRC should not start with a regulation map. It should start with a data map . . . A regulation map tells you which laws exist . . . A data map tells you where risk lives.

---

AI Is Not an AI Problem

The same logic applies to AI. Many organizations are treating the AI Act as if it were an AI compliance project. That is understandable, but it is way too narrow.

The AI Act is explicitly risk-based, with the Commission describing four levels of risk for AI systems and corresponding obligations. But AI risk does not live only inside the model. It lives in the data used to train it, the context in which it is deployed, the decisions it influences, the people affected by it, the cloud environment that runs it, the vendors that supply it, the documentation that explains it, the controls that monitor it, and the resilience of the process that depends on it . . .

• An AI system used in financial services may intersect with DORA.
• An AI system used by an essential service provider may intersect with NIS2.
• An AI system embedded in a connected product may intersect with the Cyber Resilience Act and the Data Act.
• An AI system trained on personal data may intersect with GDPR.
• An AI system used by an online platform may intersect with the DSA.
• An AI system deployed in employment, education, healthcare, law enforcement, financial access, or public services may create fundamental-rights considerations that cannot be reduced to a model inventory.

The visible object is the AI system, but the risk sits in the ecosystem around it . . .

This is why an AI inventory by itself is insufficient. It may be necessary, but it is not enough. The organization needs to connect AI use cases to data governance, lawful basis, vendor dependency, model monitoring, cybersecurity, human oversight, transparency, incident response, resilience, and accountability. Otherwise, AI governance becomes another isolated project, when in reality it should be one of the central intersections in the organization’s GRC architecture.

---

Resilience Is Not Just Cybersecurity

Cybersecurity in Europe is increasingly inseparable from operational resilience. It is why I talk about digital risk and resilience to deliver digital trust. That is another theme I hear constantly in European conversations, particularly in financial services, critical infrastructure, manufacturing, healthcare, technology, and public-sector environments . . .

• NIS2 brings cybersecurity risk management and reporting expectations across essential and important sectors.
• DORA goes deeper for financial services by focusing on the ability to withstand, respond to, and recover from ICT disruption.
• CER broadens the conversation even further by focusing on the resilience of critical entities against natural hazards, terrorist attacks, insider threats, sabotage, and public health emergencies.
• The Cyber Resilience Act then pushes security into products with digital elements, extending the conversation into manufacturers, software supply chains, vulnerability handling, and lifecycle obligations.

The direction is unmistakable. Europe is moving from cybersecurity compliance to enterprise, operational, and digital risk and resilience management.

That changes the nature of the conversation . . .

• A bank cannot look at DORA only as an ICT regulation. It has to ask how cloud dependency, third-party concentration, data protection, incident reporting, AI-enabled operations, outsourced services, and cyber resilience come together.
• A manufacturer cannot look at the Cyber Resilience Act only as a product compliance obligation. It has to understand component security, software supply chains, vulnerability disclosure, connected-product data, customer obligations, and downstream regulatory expectations.
• A healthcare organization cannot treat NIS2 as an IT security project when patient data, clinical operations, critical services, medical devices, cloud platforms, AI tools, and emergency response all intersect.

Resilience is where the regulatory ecosystem becomes operational. It is where policies either become real or are exposed as paperwork.

---

Digital and Data Sovereignty Belong at the Center

Europe is asking a strategic question: who controls Europe’s digital future? That question sits underneath the EU’s approach to data, cloud, AI, cybersecurity, platforms, critical infrastructure, semiconductors, open source, and digital markets. The Commission’s 2026 technological sovereignty package focuses on strengthening Europe’s capacity in semiconductors, AI, cloud, and open source, and describes technological sovereignty as tied to competitiveness, resilience, and strategic autonomy.

For GRC, sovereignty is not simply a political phrase . . . It becomes a risk question . . . It becomes a resilience question . . . It becomes a procurement question . . . It becomes a cloud architecture question. It becomes a third-party question . . . It becomes a board question.

In the United States, data sovereignty is often interpreted narrowly as data location . . .

• Where is the data hosted?
• Is it in the EU? Is it in a European data center?

Those questions matter, but in Europe they are only the beginning. Sovereignty is not just about location. It is about control . . .

• Who can access the data?
• Who controls the encryption keys?
• Who controls the infrastructure?
• Which legal regimes apply?
• What subcontractors are involved?
• What happens when there is a foreign-government access request?
• Can the organization switch providers?
• Can it exit?
• Can it continue operations during geopolitical tension, provider failure, cyber disruption, or market instability?

That is why sovereignty connects directly to GDPR, the Data Act, the Data Governance Act, NIS2, DORA, CER, the AI Act, and the Cyber Resilience Act. The Data Act’s provisions on unlawful third-country government access, interoperability, and cloud switching show that sovereignty is not just rhetoric; it is becoming embedded in operational and regulatory expectations.

Europe wants data to move, but it wants it to move through trusted structures . . . Europe wants AI, but not AI built on opaque data practices and uncontrolled dependencies . . . Europe wants cloud adoption, but not irreversible lock-in . . . Europe wants digital markets, but not private gatekeepers that become more powerful than public rules . . . Europe wants innovation, but not innovation that undermines rights, resilience, sovereignty, or accountability.

This is where the European agenda can be summarized in five words:

Rights. Risk. Resilience. Sovereignty. Trust.

---

Europe Is One Market, but It Is Also Many Markets

Europe is one of the most active GRC markets in the world because organizations are struggling to solve this intersection problem. But Europe is also misunderstood when it is treated as a single, uniform operating environment.

There is consistency, but there is also variance . . .

EU regulations generally apply across Member States, while directives have to be transposed into national law. The Commission emphasizes that EU laws must be applied correctly and on time across Member States, and directives require incorporation into national legal frameworks within defined time limits. This matters because NIS2 and CER, for example, are directives. The European objective is common, but national implementation, regulator maturity, supervisory practice, enforcement posture, language, and sector interpretation can vary.

This creates the European paradox: Europe is one regulatory market, but it is also many operational markets!

The same pattern applies beyond the EU . . .

• Norway is not an EU Member State, but through the EEA Agreement it participates in the internal market with the EU Member States, Iceland, and Liechtenstein, governed by the same basic rules.
• Switzerland is not in the EEA, but it still responds to EU regulatory gravity, including in data protection; Swiss authorities note that the EU confirmed in January 2024 that Switzerland continues to provide an adequate level of data protection.

This is why organizations need both a European baseline and national overlays. A single European model provides consistency, but local overlays capture transposition, supervisory expectations, enforcement nuance, sector practice, and country-specific interpretation. Treating every country as entirely separate creates complexity. Treating Europe as entirely uniform creates risk. Integrated GRC has to hold both truths at the same time.

---

What Integrated GRC Has to Look Like

An integrated European GRC approach does not begin by asking each department to run its own regulatory project. It begins by mapping the organization as it actually operates: products, services, entities, countries, customers, data flows, systems, AI use cases, cloud platforms, vendors, subcontractors, critical processes, incidents, resilience dependencies, and decision rights. Only after that should the organization map the regulations.

That is why business process modeling comes up so often in European RFPs and seldom in North American RFPs for software. And mature European firms want objective management in this context, after all GRC starts with reliably achieving objectives (OCEG), and risk is the effect of uncertainty on objectives (ISO 3100) . . . but very few platforms have a module for objective and business management.

That sequencing matters. A regulation-first approach produces silos. An operating-model-first approach reveals intersections.

The practical architecture does not need to be overcomplicated, but it does need to be connected. Organizations need a common obligation taxonomy, a shared control model, a unified evidence strategy, integrated third-party governance, an enterprise data map, an AI inventory connected to business processes, a resilience-testing model, and board reporting that shows exposure rather than activity. The purpose is not to centralize everything into bureaucracy. The purpose is to create a shared language and a shared source of truth.

This is where a few questions become especially powerful:

• What obligations overlap across the same process, system, vendor, or data set?
• Which controls satisfy multiple regulations and reduce actual risk?
• Which gaps create exposure across several regulatory regimes at once?
• Which incidents would trigger multiple notification duties?
• Which third parties create concentration, sovereignty, resilience, or data-access risk?
• Which country overlays change the operating expectation?
• What evidence demonstrates accountability rather than mere activity?

These questions move the organization from fragmented compliance to integrated GRC. They also move the conversation from “Are we compliant?” to “Are we governed, resilient, and in control?”

That is the shift Europe is forcing!

---

What This Means for Organizations

For organizations operating in Europe, the message is direct: do not manage European regulation as a sequence of disconnected projects. That approach creates duplication, cost, gaps, inconsistent evidence, and organizational confusion. It also creates the illusion of progress because every project can report activity while the enterprise remains fragmented.

• The same data will appear in GDPR, the Data Act, AI governance, incident response, third-party risk, and sovereignty discussions.
• The same cloud provider may matter for DORA, NIS2, GDPR, the Data Act, AI operations, and resilience.
• The same vendor may support a critical process, process personal data, provide software components, host AI functionality, and create exit risk.
• The same incident may trigger contractual notice, GDPR breach assessment, NIS2 reporting, DORA reporting, customer communication, operational resilience response, and board escalation.

If each team sees only its own slice, no one sees the enterprise.

Integrated GRC is what allows the organization to see the whole. It connects compliance to risk. It connects risk to resilience. It connects resilience to strategy. It allows the organization to understand not only whether it has obligations, but how those obligations affect operations, decisions, investments, contracts, technology architecture, customer trust, and market access.

That is why this is not just a compliance topic. This is a business-governance topic.

---

What This Means for Solution and Service Providers

Europe is the busiest and most active GRC market I am seeing because organizations are trying to solve this intersection problem. They are not merely looking for another checklist. They are looking for ways to connect obligations, controls, risks, evidence, third parties, resilience, and reporting.

This is where many U.S.-centric vendors and service providers get Europe wrong . . . They come to the market with a control library, a regulatory mapping, or a point solution labeled for GDPR, DORA, NIS2, or the AI Act, and they assume that is enough. It is not. European organizations need solutions and services that understand the regulatory ecosystem, not just individual regulations.

A provider selling into Europe has to show how it supports integrated GRC . . .

• How does it map overlapping obligations?
• How does it reuse evidence?
• How does it connect controls to business processes?
• How does it support national overlays?
• How does it address data sovereignty, cloud concentration, third-party risk, AI governance, and operational resilience?
• How does it help the board understand exposure rather than drowning management in project status?

The providers that win in Europe will be those that understand the intersection. The providers that lose will be those that sell one regulation at a time.

---

The European Lesson

The European lesson is that regulation cannot be understood in isolation. GDPR, the Cybersecurity Act, the Open Data Directive, the Digital Markets Act, the Data Governance Act, the Data Act, the Digital Services Act, NIS2, DORA, the AI Act, CER, and the Cyber Resilience Act are not separate stories. They are chapters in a larger European narrative about rights, trust, data, markets, cyber, AI, infrastructure, resilience, and sovereignty.

This is why organizations cannot apply a U.S. compliance mindset (and solution/service providers a U.S. marketing approach) to Europe and expect it to work. Europe does not reward fragmented activity. Europe increasingly expects demonstrable accountability, risk-based governance, operational resilience, and control over the digital ecosystem on which the organization depends.

That is also why integrated GRC matters so much. Not because integration sounds better in a strategy deck, but because the regulations themselves are integrated in their impact. They touch the same processes, the same systems, the same data, the same vendors, the same incidents, and the same executive accountability.

The organization that understands this will build GRC as an enterprise capability. The organization that does not will build disconnected compliance projects that move in different directions and fail to see the whole.

Europe is forcing GRC to mature . . .

• Not into more compliance activity, but into real governance.
• Not into more checklists, but into better risk management.
• Not into more reporting, but into resilience.
• And increasingly, not just into resilience, but into sovereignty: the ability to understand, control, and trust the digital environment the organization depends on.

Artificial intelligence has become one of the most overused and misunderstood terms in the governance, risk management, and compliance (GRC) technology market. Every platform claims AI. Every solution promises automation. Every vendor presentation seems to suggest that AI will remove friction, reduce manual effort, and transform GRC overnight… there is certainly value in automation, but much of what is being marketed as AI in GRC is still operating at the shallow end of the pool. It is focused on collecting evidence, routing tasks, summarizing documents, populating fields, and accelerating workflows.

The real question for GRC is not simply whether AI can collect evidence faster. The real question is whether AI can help determine if the evidence is correct, complete, reliable, current, relevant, and actually demonstrates control effectiveness, obligation fulfillment, risk treatment, and policy adherence. This is where the market needs to separate automation hype from assurance reality . . .

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

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.