From DevOps to DevSecOps to GRCops: The Next Evolution of Cyber Risk
Over the course of my career, I’ve watched organizations automate almost every part of technology delivery.
We automated builds, testing, infrastructure, deployments and vulnerability scanning. We built pipelines that can take an idea from a developer’s laptop to production faster and more reliably than most of us imagined twenty years ago.
And then someone from risk asks for a screenshot.
That disconnect has bothered me for years. Our technology environments have become continuous, dynamic and increasingly automated. Yet many of the processes we use to understand and communicate the risk of those environments remain periodic, manual and point-in-time.
DevOps helped solve this problem between development and operations. DevSecOps began solving it between engineering and security. I believe the next evolution is GRCops: bringing the same principles of automation, telemetry and continuous feedback to governance, risk, compliance and information assurance.
Put simply:
DevOps made delivery continuous.
DevSecOps made security continuous.
GRCops makes assurance continuous.
The Last Handoff
Before DevOps, development and operations lived in separate worlds. Developers built applications, operations teams ran them, and the handoff between the two created delays and friction. CI/CD, infrastructure as code, observability and shared ownership changed that. Deployment stopped being an event and became a process.
Security confronted the same problem. For years it arrived near the end of the lifecycle, assessing what had already been built. DevSecOps moved scanning, secrets detection, software composition analysis and configuration validation into the pipeline. We shifted security left.
One handoff remains unsolved: risk and assurance.
Between formal assessments, technology can change hundreds or thousands of times. Applications, infrastructure, permissions, vulnerabilities, third-party dependencies and data flows all shift. More and more, AI systems and agents are making decisions and taking actions. Meanwhile, the organization’s understanding of risk may still rest on a quarterly assessment, an annual audit, or evidence collected months ago.
That raises an uncomfortable question:
Why are we continuously deploying technology but only periodically assessing its risk?
There is a useful way to think about that gap: risk latency.
Risk latency is the time between a meaningful change in the technology environment and the organization’s ability to recognize, understand and act on the resulting change in risk.
DevOps dramatically reduced the time between writing software and deploying it. DevSecOps reduced the time between introducing a security weakness and detecting it. But risk processes often still operate on much longer cycles.
A control can fail today and remain “effective” in the GRC system until someone tests it months later. A vendor’s exposure can change tomorrow while its annual assessment remains green. An AI agent can accumulate privileges faster than a quarterly access review can detect them.
The objective of GRCops, then, isn’t simply to automate GRC.
It’s to reduce risk latency.
From Point-in-Time Compliance to Continuous Assurance
Traditional compliance processes were built for a different era.
Take a simple control: sensitive data must be encrypted at rest. The traditional process is to document the control, interview the owner, collect configuration screenshots, upload them to a repository, review them, and eventually conclude the control is operating effectively.
That works, but it only tells you about one moment in time. The environment may change the next day.
GRCops changes the model. Instead of periodically proving a control worked, organizations continuously determine whether it is working. The workflow looks like this:
Policy → Control → Telemetry → Evidence → Risk → Decision → Remediation
Apply that to the encryption example. The requirement becomes a machine-readable control. If someone deploys a database without the required encryption, the control detects the drift. That failure becomes evidence, the evidence updates the system’s control posture, and the posture informs risk. A remediation ticket opens automatically, and once the fix is in, the control validates it.
Instead of collecting evidence for the audit, the system produces evidence as a byproduct of operating securely.
GRCops Is More Than Compliance as Code
Policy as code, controls as code and compliance as code are important movements and are foundational to what I’m describing. GRCops is broader.
Compliance as code asks whether a requirement can be expressed and evaluated programmatically. GRCops asks how the entire risk and assurance lifecycle becomes operational: policy interpretation, control implementation, monitoring, evidence, risk identification, exceptions, remediation, reporting and, ultimately, risk decisions.
Compliance automation is a component of GRCops, not the end state. The objective isn’t to automate an audit. It’s to build a continuously operating risk feedback loop, and to change how GRC, engineering and risk owners work together.
Just as DevOps was never just a CI/CD tool, GRCops is an operating model, not a product you buy.
Five Principles of GRCops
1. Controls as code. Wherever practical, controls should be machine-readable, testable and enforceable. Not every requirement reduces to code, since many involve judgment, context or human behavior. But if a person can objectively test a requirement by reviewing a configuration, we should ask whether a machine could test it continuously.
2. Evidence as telemetry. One of the least valuable uses of skilled risk professionals is manually gathering evidence that already exists in the environment. Cloud platforms, identity systems, security tools and pipelines generate enormous amounts of telemetry. GRCops treats that telemetry as assurance evidence, moving us from evidence collection to evidence generation.
3. Continuous assurance. A control isn’t effective just because it passed a test six months ago. Where technology allows, critical controls should be evaluated continuously. The question changes from “Was this control effective when we tested it?” to “Is this control effective right now?”
4. Risk as a living signal. Risk registers are valuable, but they can create an illusion of precision when the environment changes faster than the register. A newly exposed critical asset, a new privileged account or a failed control should inform the organization’s view of risk without waiting for the next assessment cycle. The goal isn’t a dashboard that flickers red all day. It’s a current understanding of the conditions that materially affect the business.
5. Humans make risk decisions; machines maintain the evidence. This is the most important principle. Risk involves context, materiality requires judgment, regulations contain ambiguity, and risk acceptance belongs to accountable leaders. Machines excel at measurement, correlation, validation and detecting change. People are better at weighing consequences, tradeoffs and accountability.
Automate the mechanics of assurance so people can focus on the judgment of risk.
The Market Is Already Moving
This isn’t theoretical. Some of the most demanding authorization regimes are already moving toward more current, structured and machine-readable evidence.
FedRAMP’s Consolidated Rules for 2026 are a particularly interesting example. The program began allowing adoption of the consolidated rules in July 2026, with transition milestones continuing through 2027 and into 2028. FedRAMP 20x introduces Key Security Indicators and emphasizes structured, machine-readable evidence. Its approach reflects a broader movement toward demonstrating security outcomes through evidence that can be validated and updated more efficiently.
That matters because the underlying model is changing. Assurance is moving away from relying primarily on static narratives toward evidence that can be structured, validated, shared and increasingly generated from authoritative sources.
The Department of Defense is moving in a similar direction. Its Cybersecurity Risk Management Construct, announced in September 2025 as a successor to the traditional Risk Management Framework approach, emphasizes dynamic, automated and continuous risk management. Among its foundational objectives are automation, continuous monitoring and maintaining a more constant authorization posture.
When some of the government’s most rigorous assurance programs begin moving toward machine-readable, continuous evidence, commercial organizations should take note.
Regulators, auditors, boards and customers will increasingly expect proof that is current, not simply proof that is complete.
AI Changes the Equation
The volume of information available to security and risk teams already exceeds what people can correlate by hand. Asset criticality, configuration state, vulnerabilities, identity and privilege, threat intelligence, data sensitivity, third-party exposure, regulatory obligations and business impact usually live in separate systems owned by separate teams.
AI makes it possible to connect them.
Instead of telling a CISO, “Control AC-2 failed,” a GRCops capability might explain:
“Privileged-access drift has affected three production systems supporting a critical business service. This increases exposure against these control objectives and regulatory requirements. Here is the evidence, the likely business impact and the recommended remediation.”
That moves GRC from documenting compliance to delivering decision intelligence about risk.
Of course, AI-generated assessments must themselves be governed. A model that misinterprets a control, relies on incomplete telemetry or produces an unsupported risk conclusion can create false confidence. Evidence provenance, explainability, validation and human accountability remain essential.
The goal isn’t to replace one imperfect manual process with an opaque automated one. It’s to make assurance faster, more reliable and more transparent.
Extending GRCops Beyond Your Walls
Everything so far assumes you own the telemetry.
But much of an organization’s risk now lives in systems it doesn’t control: vendors, suppliers, cloud providers, partners and the long tail of SaaS that touches its data.
This is where traditional GRC is often most periodic. Third-party risk programs still lean heavily on questionnaires, attestations and point-in-time reports. A vendor’s answers may be accurate the day they’re submitted and stale weeks later.
GRCops needs an outside-in signal.
Continuous external monitoring can provide one by observing internet-facing conditions such as exposed services, configuration weaknesses and other externally visible security issues. It cannot replace everything a questionnaire, audit or direct assessment can reveal. What it adds is something those approaches struggle to provide: a frequently refreshed view of conditions an attacker can actually observe.
The flow mirrors the internal model:
External observation → Evidence → Third-party risk posture → Decision → Remediation
Mastercard’s RiskRecon is one example of this approach. External risk telemetry can supplement traditional third-party assessments so that a meaningful change in a critical vendor’s exposure does not have to wait for the next annual questionnaire to influence a risk decision.
That is also why outside-in and inside-out evidence work best together. Self-reported assessments provide context about how a vendor manages risk. External observation provides another signal about what can be observed now.
GRCops connects those signals into a more current view.
Agentic Systems Make This Urgent
In my previous post, Managing Risk at Agent Scale, I wrote about AI agents that move beyond generating information to taking action: writing code, provisioning resources, calling APIs and executing transactions within defined boundaries.
An agent can take thousands of actions before a quarterly control review ever happens.
That doesn’t mean governance disappears. It means governance needs its own automation layer, with the ability to set policy, observe behavior, validate controls, detect deviations, preserve evidence and escalate meaningful risk at roughly the speed technology now operates.
There’s a recursion here.
Agents will help make GRCops practical at scale, and agents are also a new risk class that GRCops must govern.
In an agentic world, GRCops becomes less an efficiency gain and more an architectural requirement.
This Isn’t About Eliminating GRC Professionals
Most risk professionals didn’t enter the field to chase screenshots.
They came to understand risk, interpret complex requirements, challenge assumptions and help leaders make better decisions. Yet much of their time goes to administrative work around those decisions: collecting evidence, reconciling control mappings, updating spreadsheets, preparing audit artifacts and chasing control owners.
GRCops moves risk professionals up the value chain.
They spend less time managing evidence and more time managing risk.
It also changes the role of independent assessors. Their work can increasingly shift from sampling artifacts toward validating the systems, pipelines and data that produce the evidence.
That’s a harder and more valuable job.
From Systems of Record to Systems of Action
For years, many GRC platforms have served primarily as systems of record.
They store policies, controls, findings, risk assessments and audit evidence. That still matters.
The next generation must become systems of action.
Rather than simply recording what the organization believed its risk posture was at the last assessment, these systems should help leaders understand how risk is changing now, why it’s changing and what should happen next.
And perhaps one of the most important metrics in that world will be how much risk latency the organization has eliminated.
Consider what that measurement could look like.
How long does it take to detect a material control failure?
How long before that failure is reflected in the organization’s risk posture?
How long before the accountable risk owner knows?
And how long before someone makes a decision or takes corrective action?
Those are operational questions with measurable answers.
Organizations already measure deployment frequency, lead time, change failure rates and recovery time. We should begin applying the same discipline to risk and assurance.
Not because every risk can be reduced to a metric, but because the time it takes to recognize and respond to risk is itself a meaningful measure of organizational resilience.
Where to Start
You don’t need a transformation program to begin. A practical first quarter could look like this:
- Pick one system and five controls. Choose controls whose evidence already lives in telemetry, such as MFA enforcement, encryption at rest, logging coverage, patch currency and privileged access.
- Wire evidence directly from the source. Replace the screenshot with a query or API call that runs on a schedule and preserves the result with appropriate timestamps, integrity and traceability.
- Treat a control failure like a bug. Route drift into the same workflow engineering already uses, with an owner and a due date.
- Put a GRC analyst on the engineering team’s cadence. Join sprint reviews. A shared rhythm does more than any tool.
- Show the risk owner a trend line. Give the accountable executive a view of posture over time, and ask what they’d decide differently with it.
- Add an outside-in view of critical vendors. Compare current external signals for the organization’s most important third parties with what their most recent assessments say. The gaps may reveal the first third-party GRCops use case.
Then expand control by control, system by system and vendor by vendor, the same way DevOps teams scaled one pipeline at a time.
And measure the result.
If it previously took 90 days to discover that a critical control had failed, and the organization can now detect it in minutes, that’s meaningful progress.
If the control failure still sits in a queue for another 90 days before anyone acts, the work isn’t finished.
GRCops must shorten the entire risk feedback loop, not just the time it takes to collect evidence.
The Next Pipeline
DevOps optimized how quickly organizations could change technology.
DevSecOps made security part of that change.
GRCops gives governance and risk a way to keep pace.
The destination isn’t perfect automation. Risk will always require human judgment, and governance will always require accountability.
The destination is more practical: assurance that happens alongside technology instead of months behind it.
Controls generate their own evidence. Risk reflects current conditions both inside and outside the organization. Failures trigger remediation instead of another spreadsheet. GRC professionals spend less time proving controls existed and more time understanding whether the organization is actually safe.
Technology has accelerated.
Security has accelerated.
Risk and assurance must do the same.
DevOps optimized how fast we change technology. GRCops can optimize how fast we understand the risk created by that change.
I’d like to hear where you draw the line: Which control in your environment would you trust a pipeline to assess continuously, with no human in the loop? And which one would you never hand over?
Disclosure: I’m a Field CISO at Mastercard, which offers RiskRecon. The views expressed here are my own and do not necessarily represent those of Mastercard.
Further Reading
