GRC Engineering in 2026
Hopes and dreams for the future of GRC in the new year
New year, new us! With a new year upon us, I’ve been thinking a lot about what I expect - or maybe just hope - GRC will look like by the end of 2026.
In 2025, the excitement and momentum around GRC Engineering exploded among practitioners and vendors alike.
In 2026, I’m optimistic we will see big leaps forward in how GRC programs, platforms, and tools are designed with GRC Engineering principles and values in mind.
Here’s what I’m hoping this future will look like.
Autonomous GRC
AI will have transitioned from being just a copilot or use case-specific assistant and will instead operate as full fledged agentic extensions of GRC teams.
GRC platforms will provide AI agents that aren’t just confined to work within the platforms they are built in but also will be able to operate outside those platforms too - just like their human counterparts can. Autonomous Security Risk Analysts, Compliance Analysts, Trust Analysts, etc. will exist more and more as agentic AI team members executing core GRC program operations and functions.
Security, safety, and alignment controls and mechanisms will be incredibly important, of course. We’ll see more investment in prompt injection mitigations, tried-and-true human-in-the-loop (HITL) patterns, and AI-native least-privilege access management. It won’t be perfect, but it will be better than it is today and will allow pioneering GRC teams to feel comfortable enough with incorporating autonomous GRC agents into their programs.
I also expect to see more AI agent providers, including GRC platform vendors, obtain AIUC-1 certification and insurance coverage as a way to rapidly build strong assurance for customers (and to better tolerate AI-related risks for themselves) around the safety and security of their AI agents.
Governance
GRC teams will stop treating policies, standards, and procedures as documents to publish and review on an annual basis and instead start treating them as what they were always meant to be: the foundational principles/requirements that security programs are built on and that get systematically integrated into processes and systems.
This means GRC teams will collaborate more with Platform Engineering, Security Engineering, IT Engineering, etc. teams to have 1:1 mappings between security policy/standard requirements and policy-as-code guardrails baked into version control systems, CI/CD pipelines, endpoint/fleet management systems, and runtime monitoring systems.
This also means that de facto policies/standards that non-GRC teams have already implemented in practice will be added to the “law of the land” documentation that GRC teams own. Policies, standards, and controls-in-practice will fully align 1:1 without any disconnects. Furthermore, security awareness training will map 1:1 with security policies, standards, and procedures to ensure workforce personnel are fully aligned on what’s expected of them to uphold their organization’s security program, on day 1 and regularly thereafter.
Risk
Cyber risk quantification (CRQ) becomes a must-have capability for GRC programs. CRQ capabilities will become more prominent in GRC platforms, both for first-party risk and third-party risk management.
We’ll see a convergence and integration between CRQ as a strategic lens for prioritizing security investments, and related tactical security tools/programs, such as full-stack vulnerability risk management (i.e. CTEM, CNAPP, etc.), threat detection & response, cloud security, application security, etc., resulting in a noticeable increase in organizations standing up Risk Operations Centers (ROCs) as the gold standard model for how Risk teams function.
GRC teams will also start to focus much more on first-party risk mitigations in the context of their third-party risk management programs, recognizing they have limited leverage to effect changes within their vendors’ control environments and are better off mitigating third-party risk by implementing first-party controls.
All of these shifts will also drive GRC teams to find automated ways to monitor how their third-party vendor use cases are changing over time to ensure third-party risk exposure is continuously monitored and managed, as opposed to quarterly, semi-annual, or annual reassessments. For example:
New OAuth-based app integrations setup with an existing third-party system
New user accounts created in a third-party system using email addresses outside of your organization’s domain
New IP addresses showing up in third-party system logs that are well-known egress IPs for a widely used SaaS platform
New sensitive data types being exposed to/accessed by a third-party system that was originally only approved for use with low sensitivity data types
All of these kinds of “use case drift” concerns will be much more easily addressed by GRC teams, in part thanks to new capabilities being introduced in modern GRC/TPRM platforms.
Finally, we will begin moving away from third-party compliance management to a future state of true third-party risk management.
Compliance
“Security Compliance” in the sense of continuous control monitoring and audit operations will hopefully see some additional changes not too different from how much this space has been transforming over the past few years. Rigid control monitoring workflows will be much more customized by GRC teams, whether or not their GRC platforms become much more customizable themselves.
Control monitoring evidence will be fully composable, so that multi-component controls can finally be comprehensively and consistently monitored for operating effectiveness over time. For example: a WAF control must be understood as a combination of proper DNS record configurations, WAF rule configurations, and network/host-based firewall rule configurations in order for it to be properly monitored for operating effectiveness. If a WAF product is implemented, DNS records are properly configured, and WAF rules are configured in blocking mode, but network/host-based firewall rules allow ingress traffic from non-WAF sources, the WAF can be trivially bypassed and thus this control cannot be considered to be designed effectively nor operating effectively.
Trust & Assurance
Similar to how we will see the emergence of the ROC as a new standard for how Risk programs function, we will see the emergence of the Trust Operations Centers (TOCs) as an emerging standard for how Trust programs are designed and function.
Trust programs will be much more tightly integrated with the end-to-end customer experience (i.e. “CX 360”). For example: customer security requirements expressed in the form of contract stipulations will be mapped and tracked by Trust teams with their Sales and Product partners to ensure that these requirements are treated like customer feature/use case requests. Likewise, tracking similar and identical customer security requirements across all customers will reveal a need to change underlying policies and standards across the board, instead of fooling ourselves into thinking we can and should try to commit to e.g. 8 different security incident notification timeframe requirements.
Additionally, Trust Centers will become much more self-service than they are today. Customers won’t have to talk to a human at your organization if they don’t want to. Whatever security questionnaire they have, in whatever format they have it in, can be easily uploaded by a customer into your Trust Center, and then within a few hours or days they will get an email with a secure link to download their filled out questionnaire. Behind the scenes, Trust teams will utilize agentic AI to automatically answer as many questions as they can in these questionnaires (like they are doing today with AI-powered security questionnaire automation tools). HITL will be necessary to answer trickier questions without well-known responses already documented for them. Even if questionnaires live inside TPRM web portals, customers can submit the link to their questionnaire and be instructed to add a specific user account to their TPRM portal all through your Trust Center. Whether through traditional headless browser automation or computer use AI agents, these web portal-based questionnaires can be automatically filled out with high confidence answers with HITL being needed before submitting them back to the customer. In any case, cumbersome email threads, Zoom calls, etc. will become a rarity in this future state, driving better customer Trust Center experiences and more efficiencies for Trust teams.
Lastly, I’m naively hopeful that we will finally start to see some organizations dabble in the world of sharing real(ish)-time control monitoring metrics with their customers to drive stronger continuous assurance with them. This will likely start out as a private sharing mechanism through Trust Center APIs, but will help provide better confidence about a vendor’s controls and also pressure vendors to shore up their control posture between annual/semi-annual SOC 2/ISO audits, thus resulting in stronger control environments that create a rising tide that lifts all boats.