The GRC Software Boom Has a Shadow Side

Key Takeaways

• The Demo-to-Enterprise Gap: Vibe coding has dramatically shortened the path from an idea to a functioning application, but architecture, security, integration, governance, support, and operational resilience remain difficult enterprise problems.
• The Rise of Shadow GRC: As individual functions build their own applications, organizations risk recreating the fragmented data, controls, definitions, and accountability structures that GRC technology was supposed to eliminate.
• Context Is What Makes GRC Intelligent: Generative AI can produce convincing answers, but effective GRC depends on understanding the relationships among objectives, risks, controls, obligations, incidents, suppliers, and business processes.
• Software Is Not a Software Company: New GRC providers still need implementation capabilities, support, customer success, operational maturity, and the ability to survive long enterprise buying cycles. Building the technology is only part of the job.
• Speed Does Not Replace Trust: Vibe coding can accelerate innovation, but it can just as easily accelerate fragmentation and technical debt. Enterprise trust still depends on architecture, discipline, experience, and judgment.

Deep Dive

A few weeks ago, I wrote about what I called the Draupnir Effect, borrowing from the golden ring in Norse mythology that produced eight new rings every ninth night. It seemed an appropriate metaphor for what I was watching happen across the GRC technology market. New risk applications, compliance tools, AI governance solutions, third-party risk platforms, control-testing engines, and supposedly comprehensive GRC platforms were appearing at an extraordinary pace, many of them built with a speed that would have been difficult to imagine only a few years ago.

I remain enthusiastic about much of this. GRC technology needs disruption, and anyone who has spent enough time with the established market knows there is plenty to disrupt. Some platforms are expensive and difficult to implement. Others carry years of technical debt or have grown through acquisition into collections of interfaces, data models, and code bases joined together with varying degrees of elegance. Some licensing structures appear to have been designed by Loki after a particularly mischievous evening. If AI and conversational development can make this market faster, more intuitive, and more responsive to the people who actually use GRC technology, I welcome it.

What concerns me is what we are beginning to confuse with that innovation. Vibe coding has made it extraordinarily easy to move from an idea to something that looks and behaves like software. A risk professional can describe an assessment process and have a functioning application in days. A compliance team can replace a spreadsheet without waiting six months for an IT project. A consultant can take years of methodology and turn it into an interactive application without first assembling a traditional software development organization. This democratization is real, and some genuinely excellent technology will emerge because people who understand the problem can finally participate directly in building the solution.

But the ability to build an application quickly does not mean that we have suddenly made enterprise software easy.

The Demo Is Not the Enterprise

The first part is increasingly impressive. A user answers a few questions, and the application generates a risk statement, recommends controls, summarizes a regulation, and produces a dashboard. An AI assistant drafts a policy, classifies an incident, or proposes remediation. The interface is modern, the workflow makes sense, and the entire experience may be considerably better than what the user has been dealing with for the past decade.

This is usually the moment when someone announces that legacy GRC has finally been disrupted.

Perhaps it has, or at least it should be worried. But disruption requires considerably more than improving the portion of the application that appears in the demonstration. The difficult part begins when that application encounters an actual enterprise, with inconsistent data, complicated organizational hierarchies, disputed ownership, regional differences, inherited controls, overlapping regulatory requirements, legacy integrations, and users who have an extraordinary ability to find the one workflow nobody considered during development.

The speed of modern development can make this easy to underestimate because so much of the visible application arrives so quickly. The workflow works. The dashboard loads. The model produces sensible answers. It feels as though most of the work is finished.

Then the enterprise wants single sign-on, granular permissions, segregation of duties, configurable hierarchies, APIs, encryption, audit logging, retention schedules, accessibility, multilingual support, data residency, delegation, workflow escalation, historical reporting, reliable integrations, backup, recovery, testing, and an upgrade path that does not break everything that worked yesterday. It wants one control mapped to twenty requirements, several business units, multiple jurisdictions, and different versions of the same policy. It wants to know exactly what changed between last quarter and this quarter and who approved it.

In the original Draupnir piece, I described this supposedly final twenty percent as another continent. I still think that is the right way to understand it. 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.

That distinction matters even more in GRC because GRC is not, despite what an alarming amount of technology would have us believe, a collection of forms.

GRC Is a System of Relationships

A risk does not matter simply because someone entered it into a risk register. It matters because it creates uncertainty around an objective. That objective depends upon processes and services, which in turn depend upon people, technology, information, facilities, suppliers, and other resources. Controls address risks and obligations. Regulations connect to policies, procedures, controls, evidence, tests, issues, and accountable individuals. An incident can reveal a control failure, trigger a reporting obligation, expose a supplier dependency, disrupt a critical service, and threaten an objective at the same time.

GRC is a many-to-many world, and every relationship carries context.

This is why I become cautious when an application presents a risk form, a control form, an issue form, a few dashboards, and an AI assistant and then declares itself an enterprise GRC platform. It may be an excellent application. It may solve a real problem, and it may do so considerably better than the technology that came before it. None of that automatically makes it an enterprise platform.

Enterprise GRC requires the system to understand and preserve the relationships among these things. It matters who owns a control, which version was effective, where it applied, what evidence supported it, which obligations depended upon it, and what changed after an incident. It matters whether someone could view a record but not change it, whether responsibility was properly delegated, and whether an approval can be reconstructed for an auditor, regulator, board, or investigation two years later.

That is architecture rather than decoration, and generative AI does not make the requirement disappear. If anything, AI makes context more important because the quality of an answer is not enough. A language model can produce an excellent description of an access-control failure and recommend perfectly reasonable remediation. An intelligent GRC environment should also understand which application experienced the failure, which business processes depend upon it, which jurisdictions and obligations are implicated, which controls were expected to operate, and what the failure means for the objectives the organization is trying to achieve.

A chatbot can produce an answer. A GRC platform has to support a defensible decision.

When Every GRC Function Can Build Its Own Software

The flood of new vendors is only part of the Draupnir Effect. The same multiplication is beginning to happen inside organizations, and this may ultimately prove more consequential.

For years, risk and compliance teams have waited for overloaded technology departments and slow enterprise platforms to address relatively straightforward needs. A workflow needs to change, so an enhancement request enters a backlog. Compliance needs another assessment, and suddenly there is a project plan. Risk wants two systems connected and discovers that something which sounds simple involves architecture reviews, budgets, security assessments, and several months of work.

Now someone on the team can describe what they need and build a functioning version themselves.

The temptation to use it is entirely understandable, and in many cases it should be encouraged. Compliance may build a better regulatory assessment process. Information security may create a useful control-testing application. Operational risk may develop an RCSA workflow that fits its methodology. Internal audit may improve evidence management, while procurement builds something for supplier risk and business continuity develops an application around impact analysis and recovery planning.

Each application solves a real problem, and each may work exceptionally well within the boundary for which it was created. The problem becomes visible when we stop looking at them individually and start looking across the enterprise.

Risk begins to mean slightly different things in different applications. The same control exists in compliance, information security, and internal audit with different owners, evidence, or testing histories. Procurement has one supplier record while third-party risk has another. An incident sits in one application without a reliable connection to the obligations, controls, services, or objectives it affected. Identity and permissions are managed differently, retention rules diverge, and every team develops its own approach to AI prompts, evidence, approval, and accountability.

Eventually, someone exports everything into spreadsheets to reconcile what is actually happening.

We have spent decades trying to solve precisely this problem in GRC. It would be a remarkable irony if the democratization of software development allowed us to recreate it at dramatically greater speed.

This is shadow GRC with an AI accelerator, and the answer cannot simply be to prohibit it. Organizations that respond by banning internal experimentation will push it underground while preserving many of the inefficiencies that caused people to build their own applications in the first place. The better answer is governed enablement, with approved environments, reusable foundations, common identity and security services, defined ownership, and a clear path for deciding what happens when an experiment becomes successful enough that the organization starts depending upon it.

That transition is where organizations need to pay attention. A prototype used by three people is one thing. An application that begins influencing compliance decisions, storing evidence, assigning control ownership, or supporting regulatory reporting is something else. Experimentation has become production, production has become dependency, and dependency can quietly become critical infrastructure without anyone making a deliberate decision that it should.

At that point, someone needs to know who owns the application, who tests changes, who validates its security model, what happens when its creator leaves, which AI models it depends upon, what information those models receive, and how decisions can later be traced and challenged. Internal development does not eliminate governance requirements simply because procurement never signed a software contract. It also does not eliminate third-party risk when the application itself depends upon external models, libraries, connectors, cloud services, and development platforms.

Sometimes internal development simply makes the third parties less visible.

Building Software Is Not Building a Software Company

The same reality confronts the new providers entering the GRC market. Building software has become easier. Building a durable software company has not.

I have seen many excellent GRC technologies over the years that never achieved meaningful scale. Some were more innovative than their larger competitors. Some had better architectures or better user experiences. What they lacked was not necessarily technology but the machinery required to turn that technology into sustained customer outcomes.

Enterprise GRC involves long buying cycles and an uncomfortable number of stakeholders. Risk, compliance, audit, legal, information security, privacy, procurement, technology, finance, and executive management may all have something to say about the purchase. Then come security reviews, demonstrations, proofs of concept, references, contracting, implementation, migration, integration, training, and support.

A provider can win an important customer and quickly discover that the founders have become the implementation team, support desk, solution architects, and escalation path. Every customer gets a different configuration. Every implementation creates more custom code. The product roadmap gradually becomes a record of whichever customer shouted most recently.

That is not a scalable enterprise software company. It is an increasingly complicated services project with a software interface.

This is why buyers need to look beneath the demonstration, particularly as the number of new entrants grows. They should understand how the platform models relationships and history, how permissions and AI actions are governed, how it handles real organizational complexity, how data is migrated, and what happens when something goes wrong. They should also understand the provider standing behind it. Does it have implementation capability, documentation, support, customer references, operational resilience, and enough organizational maturity to remain accountable throughout a multi-year relationship?

A polished interface deserves attention. It does not deserve immunity from due diligence.

Vibe Coding Is an Accelerator

None of this diminishes my enthusiasm for what conversational development and generative AI can do for GRC. I expect vibe coding to become a normal part of how software is developed and configured. It will allow established providers to innovate faster, enable customers to shape technology around their needs, and bring ideas into the market that might otherwise have remained trapped in spreadsheets, methodologies, and presentation decks.

What it does not do is exempt anyone from architecture, governance, security, expertise, or execution.

That is the distinction I keep returning to as the Draupnir Effect continues. The important question is not whether an application was built quickly or whether AI played a significant role in creating it. The question is whether the people behind it understand what they have built, how it fits into the broader enterprise, what dependencies it creates, and what will be required to govern, secure, support, and evolve it over time.

There is tremendous opportunity here. GRC technology can become more intelligent, contextual, conversational, adaptive, and useful than the systems many organizations have struggled with for years. New providers should challenge the established market, and internal teams should experiment with better ways of solving problems that enterprise technology has neglected.

But we should not confuse the ability to create software faster with the ability to create trustworthy enterprise technology faster. The former has changed dramatically. The latter still requires architecture, discipline, experience, and judgment.

Vibe coding can accelerate all of those things when they are present. It can also accelerate fragmentation, technical debt, and bad decisions when they are not.

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

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey.