The AI-Era GRC Market: What Investors Fund, What Practitioners Need, and Which Platforms Survive

Editor’s note: I’m very excited to share this guest post by Ayoub Fandi. If you don’t know Ayoub, he currently does GRC Engineering at Lovable, hosts a podcast and a newsletter on GRC Engineering, and is one of the most influential people behind the application of software engineering practices to GRC, otherwise known as the GRC Engineering movement. Enjoy!

Mike P.

Security investors and GRC practitioners are telling two different stories. Return on Security's 2025 market report tracked $25.1 billion across 743 cybersecurity funding deals and $76.4 billion in disclosed acquisition value across 320 deals. In my State of GRC 2026 report, 59.1% of participating practitioners used noncommercial approaches, and 73.6% of surveyed CISOs reported using no commercial GRC platform.

One side is funding increasingly sophisticated security products. The other is still running governance, risk, and compliance through spreadsheets, internal workflows, and tools it already owns.

As Mike put it in The Security Bandwidth Gap,

The pressure is familiar across security. Your SOC has too many alerts. Your cloud team has too much infrastructure to inspect manually. In GRC, more code ships, more vendors enter the environment, customer commitments multiply, and your team doesn't suddenly become ten times larger.

GRC enters this transition from an awkward starting point. Much of the market still makes money helping companies prepare for audits. Much of its AI makes the surrounding paperwork easier. Some advertised breakthroughs can already be reproduced with a capable general-purpose model, a sensible knowledge base, and an afternoon.

I co-authored the GRC Engineering manifesto, and in my earlier analysis of the GRC automation market, I argued that customer segments, data quality, and enterprise integration matter more than feature checklists. I also work at Lovable, helping build customer-trust and security-assurance capabilities, so I'm examining a market I operate in. The next chapter is about where GRC work happens, which parts stay valuable, and what security teams should expect from the function.

My research collected 795 survey submissions representing 748 unique respondents after deduplication. The sample was self-selected rather than an industry-wide census. Among them, 93 respondents identified spreadsheets as their primary tool.

The contradiction becomes sharper in one February 2026 reporting week: Return on Security recorded $75 million for third-party risk, $16.1 million for AI governance, $12 million for compliance automation, and $7.2 million for continuous controls monitoring. That's $110.3 million across five disclosed deals in one bounded week, not an annual GRC-market estimate. Investors and practitioners are clearly describing different versions of the same market.

Start with the market's concentric circles.

GRC covers governance, risk, and compliance. In many organizations, compliance gets the most visible attention. Inside compliance, audits set the calendar. Inside audits, control testing and evidence collection consume much of the operational effort.

GRC. Compliance. Audit. Controls. Evidence.

Each layer represents a smaller part of the discipline and a larger share of the conversation. That's how an entire market can claim to reinvent governance while competing over whether a screenshot gets attached to the right control.

My survey also found that 51% of participating GRC teams had four people or fewer, and 18.5% ran the function alone. If that's your team, you need capabilities that reduce coordination while keeping security decisions reliable, not another dashboard to administer.

Buyers had rational reasons for getting here. Passing an audit is concrete, budgeted, time-sensitive, and easy to explain. A certification can satisfy a customer, open a market, or close a deal. Software that shortens the path solves a real commercial problem.

The buying trigger shapes the product. When audits drive the purchase, risk management, policy, supplier review, and customer assurance become supporting modules instead of independent operating capabilities.

Those incentives explain both the market's progress and the ceiling it's approaching.

Traditional GRC platforms acted as systems of record. They tracked enterprise risks, documented controls, scheduled assessments, recorded exceptions, and stored evidence. The actual security decisions lived somewhere else.

A risk register could describe an application-security concern while knowing nothing about the codebase. A control could require encryption without touching the cloud environment. Someone had to ask an engineer, collect a screenshot, and translate the answer for an external framework.

Compliance automation changed that. Platforms connected to cloud providers, identity systems, code repositories, and device-management tools. They could query an API and determine whether a storage configuration reported encryption as enabled.

GRC moved closer to the systems it was supposed to understand.

A passing configuration check still tells you little about complete coverage, effective enforcement, current evidence, or reduced business risk. You need to know which assets were checked, whether the integration is healthy, whether the requirement applies, and what a failed or missing result actually means. In many programs, the new telemetry was still collected primarily to prepare for the same audit.

If you've watched a SIEM drown a team in alerts, you know the problem. More telemetry helps only when you can distinguish meaningful signals from noise. GRC gained visibility while keeping an operating model organized around the next examination.

Security already distinguishes AI for security from security for AI. One applies AI to investigation, analysis, prioritization, and response. The other secures models, agents, data, and their operating environments.

GRC has its own versions.

AI for GRC applies language models and automation to governance, risk, compliance, and assurance workflows.

GRC for AI governs the use of AI itself: acceptable use, accountability, model risk, delegated authority, oversight, and obligations. This side of the market remains less mature, partly because many organizations still approach AI governance as a policy exercise rather than an operational discipline.

These markets overlap while solving different problems. This article focuses on AI for GRC, where existing products, interfaces, and economic assumptions are being forced to change.

The useful question is what a vendor's agent actually does.

Today's most common GRC use cases cluster around painful, repetitive work that produces relatively weak security assurance.

Third-party risk teams review supplier questionnaires, SOC 2 reports, penetration test summaries, and contracts. One assessment can involve dozens of pages; teams repeat the exercise across hundreds of vendors.

On the customer-assurance side, teams answer security questionnaires, reuse approved responses, explain policies, and gather evidence to move sales forward.

Compliance teams map evidence to controls, compare requirements across frameworks, interpret documents and screenshots, and identify gaps against new standards.

The work is slow, frustrating, and expensive. Reading an artifact faster still tells you very little about whether the underlying security condition is true.

Picture the questionnaire exchange: one company's AI prepares and reviews the questions; another company's AI answers them. Both sides save time. Neither necessarily learns much more about the vendor's actual exposure.

AI asking AI about security can make the ceremony more efficient without making the assurance much stronger.

Risk management exposes the gap even more clearly. Much of the AI-enabled risk work I've seen stops at suggesting a relationship between a risk and a control. That's miles away from defining a threat scenario, estimating plausible exposure, assessing control strength, comparing overlapping mitigations, or helping your business choose an intervention. Cyber risk quantification only becomes useful when assumptions, uncertainty, and business consequences remain visible.

Here's the uncomfortable paradox: the easiest AI wins are also the easiest for your customers to reproduce.

Give a practitioner a general-purpose model, approved responses, and a reusable review checklist. A SOC 2 report can be assessed against defined criteria. A questionnaire can be drafted from an internal knowledge base with instructions to stay accurate, concise, and within the approved scope.

You still need current knowledge, controlled access, and human review for consequential claims. For repetitive administrative work, though, good enough captures most of the benefit.

High friction creates a sales opportunity. Low assurance makes that opportunity easier to commoditize.

A common sales demo calls an entire workflow AI-powered when only one step actually needs a language model.

Ask an agent whether production storage is encrypted. The model interprets your question, identifies the relevant system, and chooses a tool. The answer comes from an ordinary API request and a deterministic configuration check.

An agent can generate a SQL query while the database remains deterministic. It can summarize evidence while the original system remains the source. It can recommend an action while the human retains approval authority.

AI helps you decide what to ask and what the answer means. Conventional software retrieves the facts, enforces permissions, and executes the check.

That's a useful division. Deterministic execution is predictable and inspectable. The hard questions are whether the source is trustworthy, the data is current, the subject is correct, and the conclusion is supported.

Ask an auditor where the answer came from, and you'll land on the real distinction: can the system show that the control applies, that the relevant population was covered, and that the evidence supports the outcome?

Those questions become commercially significant once your customer brings their own AI.

I see the shift when a product manager, an engineer, and someone in legal can start in the same AI interface but need completely different context, permissions, and decision rights. Work increasingly happens wherever that interface can reach documents, repositories, meeting notes, security tools, and internal data.

MCP can connect those sources. For your GRC team, the important question is which capability the connection actually delivers.

At the first level, a model reviews a report, summarizes a policy, drafts a questionnaire response, or suggests a framework mapping. Many teams can do this with approved documents and clear instructions.

At the second level, an agent retrieves authorized live data, inspects a deployment, connects a customer commitment to a policy, and gives a human the context needed for a decision.

The second level requires identity, authorization, data quality, freshness, reliability, source ownership, and human oversight. Who can delegate an action? Which system supplies the authoritative answer? What happens when evidence is missing or a customer's commitment conflicts with the current deployment? A connector gives you access; those properties determine whether access is useful.

Ask the vendor directly: are you paying for something difficult to provide, or for a wrapper around tools and models your team could already use?

A product with maintained organizational context, governed integrations, reliable execution, and measurable quality earns its place. A product survives on borrowed time when its main advantage is that customers haven't learned how to assemble a comparable workflow.

Renting out someone else's learning curve can generate revenue. It's a fragile long-term moat.

Group the market around where products create value.

Systems of record organize controls, assessments, risks, policies, evidence, and audit workflows. They're deeply embedded in larger organizations.

Operational connectors execute deterministic checks. Their value comes from source coverage, reliability, semantic accuracy, and evidence usefulness.

AI workflow products accelerate questionnaires, supplier reviews, document classification, framework mapping, and audit preparation. Convenience is real; defensibility varies.

Extensible governance platforms offer workflows, agent tooling, and interfaces for a customer's preferred AI environment. Their value depends on useful context, controlled execution, and accountability.

Decision-support products connect risk, controls, business impact, ownership, and operational activity. This is the least mature category and potentially the most consequential.

A company can occupy several positions. 

Evaluate each against three questions: does it merely answer a question, can it execute a governed workflow, and does it improve an actual security or business decision? The defensible layer is the one that remains valuable as models improve, interfaces converge, and customers become more technical.

Every market position still answers to the same immediate buying trigger: the audit. Ignoring that would miss how the category actually works.

Certifications support deals, contractual commitments, and regulatory obligations. Independent examination matters. Audit gravity appears when the examination becomes the program's entire definition of success.

I've argued before that most GRC programs serve the audit when the audit should be one consumer of a well-run governance program. When the roadmap, evidence format, control scope, and risk reviews orbit the next examination, your organization is running an audit-response function.

I've also argued that risk management can become a compliance control when a register exists because a framework demands one. It gets refreshed before the audit, lists control gaps instead of business exposure, and succeeds when an auditor accepts it.

Vendors want the language of GRC Engineering, continuous assurance, and modern security operations. Buyers still understand the return on investment from reducing audit preparation time.

That's rational behavior. It's what a market built around one urgent buying trigger produces.

The strategic question is whether audit efficiency opens the door to a stronger operating model or keeps your team inside the same loop with better branding.

The competitive fight extends far beyond AI features.

A platform with an existing compliance relationship can expand into privacy, third-party risk, customer assurance, policy, or emerging governance requirements. Sometimes that's revenue. Sometimes it's protecting the account from another entrant.

Distribution matters too. Consultants represented 29% of my survey respondents, and 64.9% of participating consultants used noncommercial solutions. Your competitor might be the advisor telling customers a spreadsheet or existing internal tool is good enough.

Compliance workflows become sticky quickly. Migrating consent processes, rebuilding control libraries, and retraining teams creates genuine switching costs. Early distribution can outlast an early technical advantage.

Existing customers and new customers face different choices.

An organization with years of records and entrenched workflows may reasonably add an AI interface to the platform it already uses.

A new company building around adaptable models, direct integrations, and lightweight internal workflows may never buy that kind of platform.

The land grab is to reach teams while their habits, systems, and customer relationships are still forming.

Distribution buys access. Defensibility depends on what remains valuable after access becomes common. Historical evidence can be stale. Customer data remains subject to agreed rights and permissions. And years of records can say less than a well-governed query against the original source.

The strongest positions combine current information, legitimate authorization, difficult-to-recreate context, and decisions your organization actually cares about. Integration count, historical document volume, and an MCP endpoint matter only when they produce reliable evidence, controlled actions, or better business outcomes.

Here's the kind of decision your dashboard probably misses.

Your infrastructure team wants stronger runtime scanning across cloud infrastructure or Kubernetes. Your application-security team wants stronger build-time checks in CI. Both want to reduce vulnerability exposure, and both need engineering time and political capital.

Now ask whether the runtime findings duplicate vulnerabilities already caught during the build. Which proposed controls overlap? Which exposure remains untouched?

Your dashboards can show two productive teams. Your framework can show two documented controls. Neither tells you whether the combined investment reduces the right risk.

With the right risk scenario, technical findings, control definitions, deployment context, and business priorities, your GRC team can ask the question that changes the conversation: where does the next unit of engineering effort reduce the most risk? You can compare control coverage, residual exposure, remediation cost, risk appetite, and the political capital each engineering team would spend getting its preferred change adopted.

Build-time checks still don't replace runtime security. Production drift, deployment differences, new vulnerabilities, exploitability, and asset exposure can all justify independent runtime coverage.

Your job is to understand the overlap, identify genuinely incremental protection, and weigh it against organizational cost.

A technically correct recommendation can still be the wrong business decision if it duplicates existing coverage or consumes resources needed for a more consequential threat.

That's where GRC contributes a view individual security teams rarely have: how controls, risk, business priorities, and the cost of intervention interact.

Two teams can make rational local decisions while the organization makes a worse overall one. Useful governance closes that gap.

If your customer can reproduce the easiest administrative work, durable value has to come from something harder to replace.

One possibility is governance-relevant telemetry generated as work happens. A deployment, access change, supplier decision, or policy exception can emit scoped information about the subject, authority, requirement, and resulting condition.

Instead of rebuilding a control from a screenshot afterward, you can interpret meaningful operational events as they occur.

Telemetry alone still can't prove effectiveness or independent assurance. A complete-looking dataset can miss assets, misclassify activity, or reflect unhealthy sources. The value comes from sound semantics, trustworthy collection, visible limitations, and human judgment.

Another possibility is legitimately governed domain data: which control patterns fail, which evidence misleads, where decisions diverge, and how operational changes affect governance outcomes.

Customer consent, privacy, contractual rights, and confidentiality come first. Access to data never grants unlimited rights to aggregate it or train on it. Domain-specific learning becomes defensible only when the underlying collection is lawful, permissioned, representative enough for its purpose, and tied to outcomes you can actually evaluate.

Authorized data can support better GRC evaluations. Test whether a system distinguishes missing evidence from control failure, catches the wrong subject or time window, recognizes unsupported claims, escalates consequential decisions, and expresses uncertainty. Measure it against a strong general-purpose model running the same approved workflow. A polished demo tells you less than a reproducible benchmark with realistic cases.

That's a stronger proposition than an agent that summarizes a SOC 2 report.

The frontier is generating better operational signals, grounding decisions in the right context, and proving the result outperforms a strong general-purpose model with a well-designed workflow. Processing the same artifacts faster is the old game with better tooling.

Early adopters will likely combine technical velocity with governance pressure: fast-growing technology companies, AI-native businesses, fintechs, biotechs, and other regulated or security-sensitive environments.

The earliest adopters and biggest beneficiaries may be different customers.

A cloud-native company with mature compliance automation might gain little from another connector. A traditional organization managing hybrid infrastructure, on-premises systems, fragmented records, and manual work could gain far more from trustworthy operational context.

It may also be substantially harder to serve.

That's the market nuance a startup-versus-enterprise label misses: adoption speed, technical feasibility, regulatory pressure, implementation cost, and potential improvement point to different customers.

The real opportunity is to bring GRC inside consequential security decisions.

Nobody wants pointless evidence requests, vague control language, or another interruption before a release. Reducing useless friction matters because it gives your team room to contribute where governance actually changes the outcome.

AI gives GRC practitioners access to code changes, security findings, architecture decisions, supplier information, and work-tracking systems. I've written before that the context problem has inverted: your challenge is increasingly choosing the right information and using it well.

Use that context only to prepare a cleaner audit binder, and you've automated the profession's least strategic work.

The stronger possibility is a GRC team that understands what systems say, what controls do, what the business is willing to risk, and when decision-makers need that information. Instead of treating engineers as people to avoid interrupting, you work with them on decisions where risk, customer commitments, and limited capacity intersect.

It requires collaboration with the people shipping and securing the product. It requires accountable interpretation of what the evidence actually proves. It requires business-first judgment about which safeguards deserve limited engineering capacity.

The future of GRC is in the room, with enough context to make the decisions there better.

Getting out of the way more efficiently was never the job.

If your most impressive feature can be reproduced with a good prompt, an approved knowledge base, and a shared folder, your problem probably runs deeper than messaging.

Build the thing that creates trustworthy context, improves a difficult decision, or does work your customer can't reasonably recreate.

An MCP endpoint is an interface, not a moat.

Ask who owns the customer relationship, who maintains useful context, who governs access, who can prove better outcomes, and whether the business solves a real security problem or just rents out somebody else's learning curve.

Thank you for reading! If you liked this analysis, please share it with your friends, colleagues, and anyone interested in the cybersecurity market.