GRC 7.0: What Michael Rasmussen's GRC Orchestrate means for organisations

Why GRC 7.0 is being discussed right now

Michael Rasmussen coined the term GRC. By his own account, he first described governance, risk management and compliance as an integrated approach in February 2002, as an analyst at Forrester Research, and created the acronym for it. GRC 20/20 Today he leads the analyst firm GRC 20/20 Research and classifies the market in generations.

In October 2026, he published a 143-page Market Perspective on the subject: “GRC 7.0 – GRC Orchestrate: The Architecture, Economics, and Competitive Reset of the GRC Market”. GRC 20/20 The full report is reserved for clients. The public summary, the table of contents and several freely available articles by Rasmussen nevertheless make clear what it is about. This article summarises the model and shows which questions organisations can derive from it for selecting and operating their GRC tools.

The core thesis: features become cheap, accountability becomes valuable

Rasmussen's starting point is a shift in the market. Artificial intelligence makes visible software features less scarce. At the same time, four things are gaining in importance: reliable information, business context, specialised domain methodology and execution for which someone is accountable. GRC 20/20

This leads to the report's central distinction: GRC 7.0 is an operating architecture, not an accumulation of AI features. A chat window can improve usability, but it does not replace the work on architecture and methodology, Rasmussen writes. GRC 20/20 He states the benchmark just as clearly: technology must improve efficiency, effectiveness, resilience and agility through better decisions and verifiable outcomes.

From GRC 1.0 to 6.0: generations, not a buying recommendation

Rasmussen describes the market's evolution in generations. He stresses that these are overlapping capabilities, not a ladder of stages and not an invitation to buy eight platforms one after another. GRC 20/20

Rasmussen describes the limit of the previous generations like this: a system can contain excellent records and still leave people on their own when it comes to assembling the context, deciding on the next step and building the capability required. This is exactly where GRC 7.0 comes in.

The three systems of GRC 7.0

The System of Record remains the foundation. Around it, GRC 7.0 places a system of orchestration that connects three complementary systems. GRC 20/20

System of Intelligence: from signal to decision context

The System of Intelligence collects internal and external signals and turns them into decision context. A supplier disruption, a new regulatory requirement or a deviation in performance must be connected to the affected objectives, services, obligations and dependencies. The useful outcome is a reasoned explanation of the consequences and options, including missing information and uncertainties.

Rasmussen places emphasis on one distinction here: executives must be able to tell what is an established fact, what is an inference and what is an assumption that could change the decision. Among other things, the report's table of contents lists the provenance and timeliness of information, entity resolution, ontologies and permission-checked queries for this purpose.

System of Action: execution with clear authority

The System of Action coordinates the response. Agents can work autonomously within defined limits, act semi-autonomously with human approval and coordinate tasks across people and systems. An agent can collect evidence, prepare an impact analysis, route a decision or carry out a permitted change.

What matters is that authority is explicitly defined: what may happen, under which conditions, who is accountable and how the outcome is verified. Rasmussen illustrates this with two examples. The ability to recommend a supplier does not mean the authority to approve it. And a completed workflow does not prove that a service has been restored. The system must connect actions to an observable business outcome and escalate when authority or evidence is insufficient.

System of Configuration: building capabilities in business language

The System of Configuration is meant to build and adapt GRC capabilities quickly, in the language of the business function. A team describes what it needs, such as a new assessment or a process for obligations, and the technology helps generate the data structures, relationships, rules, interfaces and integrations for it.

Rasmussen ties this promise to clear conditions: validation, permissions, testing and controlled deployment. A clearly described intent is the beginning of a reliable capability, not proof that the generated result is correct. Accordingly, the report states that tests must be independent enough to challenge the generation, and that deployment is a governance decision.

The value lies in the connection

None of the three systems is new on its own. What makes the difference is how they are connected: intelligence detects a changed situation, action coordinates an appropriate response, configuration builds the capability that the new situation requires. Learning may improve the interplay, but without any system quietly rewriting its own authority.

Agents earn their authority

In an earlier series of articles on GRC Orchestrate, Rasmussen describes agents as part of a cycle of observing, analysing, acting and escalating. If a situation exceeds an agent's threshold, it informs the responsible person. GRC 20/20

There, he also acknowledges that the market is still at an early stage. So far, he says, AI has mainly arrived through individual features such as risk assessments, regulatory mapping and chat interfaces. Genuine orchestration of coordinated agents is still emerging. As prerequisites up to 2030, he names:

• unified taxonomies and metadata across all GRC domains
• policies, risks, controls and obligations in machine-readable form
• ethical and operational guardrails for AI behaviour
• a governance culture that treats AI as a participant, not just as a tool

For organisations, the second point in particular is a good touchstone. Those who already maintain requirements, controls and evidence in a structured, machine-readable form today, for example in the open OSCAL format, create the foundation on which agents can work reliably. You can read more in What is OSCAL?

Outlook: GRC 8.0 and digital twins

For the period from around 2030, Rasmussen describes GRC 8.0, “Quantum GRC”. This refers to deep digital twins of the organisation and its supply chain on three levels: strategic direction, objectives and performance, and operations and execution. Organisations are meant to use them to play through possible futures before committing. Rasmussen speaks of a “Risk Holodeck”. GRC 20/20

He explicitly presents this as a vision of the future, not as a capability that is already available. Even a convincingly presented simulation can be wrong; its value depends on the quality of the model and of the information, and on honest handling of what remains unknown. The term has only marginally to do with quantum computing in the literal sense; the report treats that as a separate question.

Which questions organisations should now ask vendors

Rasmussen advises against replacing working foundations without good reason. Replacing a system merely because its generation number sounds outdated is, he says, an expensive misunderstanding. Instead, organisations should have vendors demonstrate a coherent business scenario and ask: GRC 20/20

1. Which objective does this capability serve, and how is the improvement measured?
2. How does an internal or external change become relevant information?
3. What may the system do by itself, what requires human approval, and how is authority enforced?
4. Can a meaningful capability be built in business language, and can the result then be reviewed and tested?
5. How does the system behave when information is contradictory, a dependency is missing or an approver cannot be reached?
6. What evidence proves that the desired outcome has actually occurred?

To get started, he recommends a tightly scoped approach: one objective, one bounded use case, one accountable person, one baseline and one resilience test. What should be measured are the assumed outcomes and the total operating effort, including review, correction, integration and oversight. The evidence then decides whether to expand, adjust or stop.

What we take from this at Secani

What we find most helpful is Rasmussen's distinction between the ability to propose something and the authority to decide it. We align the Secani agent with it: it prepares assessments, establishes connections and gives reasons for its proposals. The decision on whether a control counts as effective or a risk is accepted should stay with the person accountable. Why a source link alone is not enough for this either is explained in AI in GRC: Citation Is Not Verification.

Just as important to us is Rasmussen's call for machine-readable requirements, controls and evidence. An agent can only work as reliably as the structure it builds on. For what the major analyst firms say about the market as a whole, read GRC market 2026: What Forrester, Verdantix and GRC 20/20 say about AI and platforms.

Conclusion

GRC 7.0 is less a new product category than a yardstick. Rasmussen describes an architecture in which authoritative data, decision context, controlled execution and verifiable adaptation work together. AI agents are an important building block within it, but they are only progress if their authority is clearly defined and their outcomes are verified. Organisations should therefore have vendors show them, on their own use case, where an agent only proposes, where it may act and who bears responsibility in each case.

Sources

• GRC 7.0 – GRC Orchestrate: The Architecture, Economics, and Competitive Reset of the GRC Market (GRC 20/20 Research, October 2026)
• GRC: An Ancient Discipline, a Snowy February, and the Architecture of What Comes Next (Michael Rasmussen, 14 October 2026)
• GRC 7.0 – GRC Orchestrate: Agentic AI and the Autonomous Force Behind Risk, Integrity, and Objectives (Michael Rasmussen, 10 July 2025)