A decade ago, software engineering faced a problem that looks remarkably familiar. Monitoring platforms confirmed that servers were running. They could tell you whether a service existed and was reachable. They could not tell you what it was doing, for whom, under what conditions, or how it was performing for the users who depended on it. Existence was confirmed. Behavior was invisible.

The field solved this by replacing existence checks with behavioral telemetry. Modern observability platforms continuously measure latency, error rates, trace paths, and user-facing performance across distributed systems. The question shifted from “is the service up?” to “what is the service actually doing, and where is it degrading?” That shift transformed how engineering teams understood, managed, and improved production systems.

Enterprise GRC is about to undergo the same transformation, and for the same reason. GRC platforms have historically confirmed that controls exist. The next generation will measure whether controls are being adopted, where they are failing to execute, which ones produce measurable risk reduction, and which ones generate overhead without improving security outcomes.

Organizations still operating on the documentary model will generate increasingly expensive compliance programs that drift further from operational reality. Those that instrument their security programs the way engineering teams instrument production systems will continuously improve both security outcomes and program efficiency.

Three security failures illustrate what the documentary model costs. One operational case study illustrates what behavioral measurement produces.

From Documentation to Behavior: What the Evidence Shows

Equifax’s 2017 breach sits at the center of this argument. In March of that year, US-CERT alerted organizations to a critical Apache Struts vulnerability, and Equifax’s security team issued an internal directive requiring the patch to be applied within 48 hours. No accountability mechanism existed to verify it had been carried out, and the patch was never applied to a critical consumer-facing system. Attackers entered in May 2017 and spent 76 days undetected inside one of the most sensitive financial data systems in the United States. By July, 145.5 million Americans had their personal financial information compromised, and the FTC settlement reached $575 million. Equifax had measured the existence of its patching policy. Its GRC program had no telemetry confirming whether that policy was executing.

Colonial Pipeline’s 2021 breach followed the same structural failure at a different scale. DarkSide ransomware forced the shutdown of a pipeline delivering 45% of the East Coast’s fuel supply by entering through a single VPN credential that lacked multi-factor authentication on a legacy account that had reportedly fallen out of active use. Colonial had measured MFA as a documented requirement. Its program had no signal indicating where MFA had failed to reach. A forensic review conducted afterward found numerous known and preventable vulnerabilities, including unpatched and outdated systems. The Department of Transportation later cited Colonial for multiple control room management violations identified during inspections conducted months before the attack. Regulators had been on-site and controls were documented. The behavioral gap between what the policy required and what the environment ran remained invisible until the ransom demand arrived.

SolarWinds is the most consequential illustration of what the documentation gap looks like at scale. In December 2020, FireEye disclosed that attackers attributed to Russia’s SVR had compromised SolarWinds’ software build pipeline and injected the SUNBURST backdoor into Orion updates distributed to approximately 18,000 organizations, including multiple U.S. federal agencies. Internal documents reviewed by the SEC showed that as early as 2018, a company engineer had warned in a shared presentation that SolarWinds’ remote access configuration was “not very secure” and that an attacker could “basically do whatever without us detecting it.” That assessment reached senior security leadership and produced documentation that the risk was known. It did not produce a remediated control or any telemetry indicating whether the underlying behavior had changed. The SEC charged SolarWinds and CISO Timothy Brown in 2023 with securities fraud and internal controls failures, alleging that public security statements bore no relationship to the company’s actual security posture. SolarWinds reached a $26 million settlement. The charges rested on the distance between what the compliance program documented and what behavioral measurement would have revealed.

None of these organizations lacked documentation. Each had policies, compliance programs, and recorded controls. What each program lacked was any telemetry about whether those controls were functioning as designed, where adoption had broken down, or which gaps were generating genuine risk exposure. The GRC platform confirmed existence. The security question went unanswered.

Every Mature Discipline Has Made This Transition

GRC is not unique in confronting this problem. The shift from existence-checking to behavioral measurement has occurred across every discipline that manages complex, continuously operating systems.

Manufacturing quality assurance once confirmed that inspection procedures existed. Statistical process control replaced it with continuous measurement of process behavior, tracking variation in real time and surfacing defects before they left the production line. The question shifted from confirming that an inspection protocol was in place to measuring what the process was actually producing at each stage.

DevOps engineering once measured whether deployments were completed. Continuous integration and delivery pipelines replaced that with behavioral telemetry across build success rates, test coverage, deployment frequency, lead time, and change failure rates. Confirming that a deployment ran gave way to measuring how the pipeline was performing and where it was degrading.

Customer analytics once measured whether users had logged in. Product analytics replaced it with behavioral data on feature adoption, task completion, drop-off rates, and retention. Confirming that users were present gave way to measuring what users were actually doing and where they were encountering problems.

The pattern holds in each case: existence-checking was sufficient when systems were simple and change was infrequent. Behavioral telemetry became necessary when systems grew complex, continuous, and consequential enough that the cost of undetected failure was high. Enterprise security programs today fit that description precisely. Annual snapshots of control existence no longer reflect operational reality in environments where software ships continuously, vendors are onboarded continuously, and infrastructure is modified continuously.

The Observability Analogy Applied to GRC

Software observability is the most instructive case because it happened recently enough to observe directly. Early monitoring platforms answered a binary: was the server reachable? When it wasn’t, an alert fired. When it was, the platform had nothing more to say about what was happening inside the system.

Modern observability changed the question entirely. An engineering team today can ask why latency is increasing only for users in a specific region after a particular deployment, which downstream services are failing when an upstream dependency degrades, and what trace data reveals about where a given transaction is spending its time. That kind of question requires continuous behavioral telemetry across metrics, logs, and traces. It requires measuring how the system actually behaves under real conditions, with real users, at real scale.

The GRC analogue is direct. The program that confirms a control was documented produces exactly what a monitoring system produces when it confirms a server is reachable: evidence that something exists at a point in time, and nothing about how it behaves in practice. A GRC program instrumented with behavioral telemetry can ask whether a patching policy is executing as designed across the environments where it should run, where MFA enrollment has stalled, which control remediation findings are recurring across multiple audit cycles, and which controls correspond to measurable reductions in incident rates. Those are the questions that would have surfaced Equifax’s unexecuted patch directive, Colonial’s unenforced MFA requirement, and SolarWinds’ gap between documented security posture and engineering reality.

What Behavioral Measurement Looks Like in Practice

The distance between documentary and behavioral metrics is concrete. Each control that appears in a standard GRC program has both a documentary form and a behavioral form, and the two measure fundamentally different things.

A published policy measures existence; policy adoption rates by department and role measure behavior. MFA marked as required measures existence; MFA enrollment rates across endpoints and user populations measure behavior. Training completions measure existence; phishing simulation failure rates measure whether the training changed anything. A patch SLA documented in a control register measures existence; median patch latency across systems and criticality levels measures execution. PAM recorded as deployed measures existence; privileged session coverage and utilization rates measure whether the deployment is doing anything. Audit findings tallied by cycle measure the documentary record; risk reduction trends correlated with control execution measure outcomes.

The distinction matters because programs optimized for the documentary form can produce clean audit results while the behavioral reality diverges significantly. That divergence is precisely what the three case studies above document.

ServiceNow’s own GRC transformation is the clearest available demonstration of what moving toward behavioral measurement produces. The company redesigned its internal compliance program from periodic manual control testing to continuous telemetry-based monitoring, and changed what the program measured, not merely how fast it collected evidence. The results, published through ServiceNow’s own “Now on Now” case study series, are specific: control certification effort dropped 66%, status tracking time dropped 85%, and coordination effort with external auditors dropped 90%. Total savings from automating end-to-end GRC processes reached $2.6 million annually. Those outcomes came from introducing telemetry that told the program which controls were performing and which were not, so the compliance team could spend its time on the controls behavioral measurement revealed were not executing as designed.

The Cost of the Documentary Model

Compliance programs are expensive, and the cost trajectory is steepening. Financial services firms have seen compliance expenditures rise 43% since 2011, averaging more than $5 million annually across the sector. A substantial share of that investment produces audit readiness. When the controls underlying that audit readiness are not being adopted, not being enforced, or not producing measurable risk reduction, the program has generated a liability dressed as assurance.

Equifax, Colonial, and SolarWinds did not fail because their compliance programs were underfunded. Each operated with documented controls and completed audit cycles. They failed because existence-checking produced no signal about whether controls were executing, and the gap between documented posture and operational reality stayed invisible until an external event forced it into view. Organizations that continue on the documentary model will spend more each year to produce the same answer with decreasing confidence in what it reflects.

What the Next Generation Looks Like

The shift from documentary to behavioral GRC is primarily a program design decision. The platform matters less than the discipline of defining measurable outcomes for each control before the audit cycle begins, establishing telemetry to track those outcomes, and treating deviations as operational signals that warrant investigation, not administrative exceptions to log and close.

The questions that define this operating model are specific. Which controls show adoption below threshold, and in which teams or environments? Which remediation findings recur across multiple cycles without closure? Where are employees bypassing requirements, and what does that pattern reveal about the control’s design or its operational fit? Which controls, when functioning, correspond to lower incident rates in the environments where they run? These are the questions that behavioral telemetry can answer, and that documentary evidence cannot.

The security professionals managing next-generation GRC programs will spend less time adding frameworks and more time improving control adoption, identifying which controls measurably reduce risk, and redesigning the ones that generate overhead without security outcomes.

The next generation of GRC platforms will look less like policy repositories and more like product analytics platforms. The software that wins this category will resemble Datadog more than SharePoint. It will instrument security programs the way engineering teams instrument production systems: continuously, behaviorally, and with enough fidelity to answer whether a control was required, whether it ran, how well it performed, and what the environment looked like the last time it did not.

About the Author

Kimly Hong is a Principal Cybersecurity and GRC Consultant with more than ten years of experience building enterprise security programs across regulated financial services, hospitality, and technology environments. Her work spans governance, risk, and compliance program design, third-party risk management, access governance, and incident response readiness. She has built these programs from the ground up across complex, multi-region environments and currently consults across financial services, SaaS, and retail organizations. Connect on LinkedIn to continue the conversation.