Compliance Is an Audit Outcome. Confidence Is a Security Outcome.

Compliance is an audit outcome. Confidence is a security operations outcome. They are not the same thing, and conflating them is how technically compliant environments still get breached.

That distinction came from Anecdotes Field CISO Maril Vernon during a recent panel on the future of GRC, joined by Kat Bell (Head of GRC Implementation Services at Anecdotes) and Conor Russo (who runs Anecdotes' internal GRC program). Maril spent the early years of her career in GRC before moving into purple teaming and red teaming, and the pattern she kept seeing on the offensive side wasn't subtle. She would walk into environments that were beautifully documented and technically compliant, then still gain initial access, execute, and operate post-exploitation. The paperwork was clean. The operational reality wasn't.

"You get what you inspect, not what you expect," she said during the panel. Most GRC programs are still built around what teams expect to be true, validated once a year by an external party. That assumption worked when environments were stable. Cloud, ephemeral identities, non-human accounts, and AI-driven systems killed it years ago.

The Delivery Vehicle Outgrew the Objective

The three panelists arrived at the same conclusion from different angles.

Connor described his time at a previous company: weeks lost in Slack channels reminding colleagues to send screenshots, missing a column or a timestamp during the audit week, and starting the cycle over. The team eventually onboarded a GRC platform, and his read on it was direct. "At the end of the day, it was still kind of broken because you're still chasing people for screenshots. It was just in a prettier tool." The automation changed the UI, not the underlying motion.

Kat described it from the customer side. "If a control's been failing for four months, if there's drift, if a process that's documented isn't actually being followed, you don't find out until the auditor asks for it, you know, four, five, ten months later." By that point, it's a finding, not a fix.

Maril framed the diagnosis cleanly: the objectives outgrew the delivery vehicle. Traditional GRC was built for environments that changed slowly. Modern environments don't. The model itself, not the practitioners running it, is what stopped working.

The Architecture Problem 

Sounds like teams just need to work faster, right? Not quite.

Connor pointed out that automating evidence requests faster just creates faster ways to wait for humans to make decisions. Kat noted that the GRC workload itself consumes the time teams would need to improve the program. Most GRC teams own everything: vendor assessments, policies, customer security questionnaires, security training, and every framework the company holds. There is no spare bandwidth to redesign the system from inside the system.

Maril's read: every other discipline in cybersecurity built feedback loops years ago. OpSec did it through continuous threat exposure management, vulnerability management built continuous scanning, and engineering moved to CI/CD. GRC mostly didn't. It stayed in a top-down, framework-first model where controls are static, environments are assumed to be stable, and proof is gathered episodically.

That's why so many GRC teams feel disconnected from operational reality. They are.

{{ banner-image }}

What GRC Engineering Actually Means

The panel offered a working definition worth quoting directly. Connor said, "Traditional GRC asks us to assemble proof. GRC engineering asks systems to produce it."

Connor's framing moves controls from artifacts humans collect to signals environments emit, and it moves the GRC analyst from coordinator to designer. The unit of work shifts from a screenshot's existence to a control's health.

A few things change when you operate that way.

1. Build once, map to many. Frameworks overlap heavily. ISO 27001, PCI-DSS, HIPAA, and FedRAMP share most of their underlying controls. When the control is engineered and live, you stop rebuilding evidence for each framework and start mapping the same live signal across all of them. In many cases, the estimated overlap is 70 to 80 percent.
   
   
2. The role becomes more technical. Kat described the practitioner shift: stop being the person who chases screenshots, become the person who can read live data and explain what the program is actually doing. Connor's practical entry point was simple: ask engineering for read-only API access, open Postman, and pull data from a security awareness tool to compare it against the HR roster. See what falls out. That's where GRC engineering starts.
   
   
3. Auditor conversations get sharper. When controls produce live data, auditor calls stop being a defensive exercise. As Connor put it, when you actually understand the data behind a control, you can push back when an auditor is wrong. The asymmetry of information flips.
   

Continuous Controls Monitoring Is the Inflection Point

The panel converged on CCM (continuous controls monitoring) as the natural next step. The framing matters. Connor was specific about what CCM is and isn't. "Some people think of CCM as faster automation, when it should really be thought about as the system producing truth continuously."

Faster automation still treats compliance as an event, where evidence is gathered for a specific moment. Continuous truth treats compliance as a state of the system, where the practitioner has a feedback loop they can actually use to manage risk in real time.

Kat described what this looks like operationally. A customer turns on live monitoring rules aligned to their actual policies. Gaps surface immediately. The conversation shifts from "we'll see what the auditor finds" to "we have a problem in HR, let's go fix the background check process this week." Residual risk becomes dynamic, weighted against the live health of the mitigating controls underneath it.

That last point is the one most GRC tools still miss. Risk scores that don't move when controls fail are decorative. Risk scores that adjust automatically when a control breaks are operational.

Practical Steps for GRC Teams That Want to Start

The panel offered a few concrete moves, useful for teams who don't yet have the buy-in for a platform shift.

1. Treat it as an engineering problem. Engineering problems get project managers, timelines, and budgets. Administrative ones don't. Reframe the ask and the resources change.
   
   
2. Sit with engineering teams and learn the underlying processes. Kat's point: a GRC practitioner needs to be the subject matter expert on every process in the organization. You can't engineer controls for processes you don't understand.
   
   
3. Get read-only API access to your systems. Start small by pulling user lists from one tool, comparing them against another, and finding the first drift. That single comparison is your first feedback loop.
   
   
4. Push for advocacy, not org chart purity. The panel was honest that there's no universally right place for GRC to sit. What matters is reporting to a leader who will advocate for the function and get executive buy-in. Independence from the teams being assessed matters more than the specific reporting line.
   
   

The Measured Close

Cloud changed the environment. AI accelerated the change, and complexity finished the case for treating GRC as a purely administrative function. In environments that are increasingly autonomous, ephemeral, and AI-driven, that model doesn't survive.

The organizations that get this right won't have the prettiest dashboards. Green doesn't always equal good, as Maril noted in the closing. They'll be the ones whose controls can continuously prove how they actually operate in real time, based on real data sources. The proof needs to be continuous, contextual, and measurable in real time, instead of generated once a year for an external party.

That's how the field gets from compliance to confidence.

Frequently Asked Questions

What is the difference between compliance and confidence in GRC?

Compliance is an audit outcome that proves controls existed at a specific point in time. Confidence is a security operations outcome that proves controls are working continuously, based on live data from the systems themselves. An environment can pass an audit and still be operationally vulnerable, which is why both matter.

What is GRC engineering?

GRC engineering is the practice of treating controls as live signals produced by systems, rather than static artifacts assembled by humans. The GRC analyst shifts from coordinator to designer, working alongside engineering teams to pull data directly from source systems and monitor control health in real time.

What is continuous controls monitoring (CCM)?

Continuous controls monitoring (CCM) is the practice of using live data from source systems to verify that controls are functioning as intended in real time. The systems produce evidence continuously, so practitioners can see drift the moment it happens and remediate before it becomes a finding.

Why is traditional GRC struggling to keep up with modern environments?

Cloud, ephemeral identities, non-human accounts, and AI-driven systems change faster than annual audit cycles. Traditional GRC was built for environments that changed slowly. When the environment shifts daily, point-in-time attestations and screenshot evidence stop reflecting operational reality.

How can a GRC team start moving toward GRC engineering?

The most practical first step is reframing the work as an engineering problem so it earns project management, timelines, and budget. From there, sit with engineering teams to learn the underlying processes, ask for read-only API access to one source system, and find a single point of drift. That first feedback loop is the entry point.

Where should GRC sit in an organization?

The panel agreed there is no universally right reporting line, and that the placement matters less than the advocacy behind it. GRC needs to report to a leader who will champion the function and unlock executive buy-in. Independence from the teams being assessed matters more than the specific reporting structure.

‍