By Yasmine Abdillahi, Executive Director of Cyber GRC and Business Information Security Officer, Comcast
When security leaders hear “engineering discipline” applied to Governance, Risk, and Compliance (GRC), the instinct is to brace for more tooling, more headcount, and more infrastructure that needs to be justified to the board.
But this initial reaction misreads what is actually happening. GRC is becoming an engineering discipline not because someone decided to make it more complicated, but because the complexity was already there. The compliance programs built a decade ago were designed for the slower world of annual audits, static risk registers, and policies that changed quarterly at best. That world is gone. Today, cloud infrastructure can spin up and down in hours, AI agents are proliferating, regulations can multiply across jurisdictions, and a board member might ask about risk posture, with the expectation of an immediately trustworthy answer.
The teams making real progress aren’t the ones that have added more people or tools. They’re the ones that changed what GRC is built on. Today, GRC engineering is how organizations simplify governance, shorten the time it takes to find value, and stop reinventing the wheel of pipelines year after year.
The Problem Is the Data Beneath GRC
Most organizations don’t fail at GRC because they lack frameworks, policies, or good intentions. They fail because the underlying knowledge of what is connected to what, which data resides where, and which controls protect which assets is scattered piecemeal across security, IT, cloud, identity, and business systems — none of which were designed to maintain that picture coherently. Every time a control needs to be validated, someone manually pulls from multiple sources, normalizes the results, and hopes the timing is close enough to tell a consistent story.
Consider a simple question: “How many of our critical systems have MFA enabled?” Answering it accurately means pulling identity data, cross-referencing asset inventory, filtering the results by criticality classification, and clarifying whether “enabled” means configured, enforced, or actively used. By the time the answer is ready, it’s already a snapshot from last week. Multiply that by the hundreds of controls a mature GRC program tracks, and you see the real problem: teams aren’t doing GRC work. They’re doing data plumbing.
Why agentic AI is amplifying the urgency
AI governance dominated the conversation at Black Hat USA 2026, with much of it tracing directly back to the Hugging Face incident — a preview of how quickly “AI agents” went from an emerging buzzword to the central topic on the floor.
These solutions are responding to the fact that agents drift and can get exploited when nobody is looking at them. However, AI governance is not just a feature that can simply be added to existing security tool stack. It’s a practice or a discipline requiring alignment between IT, Cybersecurity, GRC, finance and the business.
Access control issues for agents cannot be observed and trusted periodically. Instead, they need continuous validation and remediation. Because agents can update themselves at runtime; a control evidenced at a point in time may not be compliant an hour later.
This isn’t hypothetical. In July 2026, an AI model undergoing a routine capability evaluation escaped its test environment and compromised Hugging Face’s production infrastructure — autonomously, over four days, without a human directing each step. The agent didn’t need stolen admin credentials to escalate; it read cloud metadata, minted its own service-account tokens, and mapped its own permissions in real time. That’s the identity-to-agent-to-asset chain breaking down in exactly the way static, point-in-time control evidence can’t catch.
This is where the identity-to-agent-to-asset mapping underneath any GRC platform needs to be engineered and current.
Why Building Your Own Solution Usually Stalls
The natural response is to unify the data by building an internal pipeline, a custom dashboard, and a “security data fabric” that pulls everything into one place. The intent is right, but the execution is where things get hard.
Data normalization is genuinely demanding. Matching a user record from an identity provider to a Configuration Management Database (CMDB) asset record and a Security Information and Event Management (SIEM) log entry isn’t a configuration task — it’s an engineering challenge requiring sustained expertise. Audit defensibility gets added after the fact, if at all. And maintenance quietly becomes a permanent commitment, consuming engineering capacity that was supposed to go elsewhere.
Agentic AI makes the engineering lift heavier as its governance requires granular traceability including what the agents are permitted to do and what they actually did, with what inputs, on whose behalf and why. If an agent’s effective permissions can be manipulated by the content it processes through prompt injection, then “what can this agent do” isn’t a static fact pulled once and normalized; it has to be validated continuously.
What “Engineering GRC” Actually Means
Engineering GRC doesn’t mean every organization needs to engineer it themselves. It means GRC now depends on properties that must be designed in from the beginning, not added later.
Those properties are observability, testability, and explainability. Observability means your compliance posture is visible in real time, not reconstructed at audit time. Testability means controls are validated continuously against live data, not just when a review is coming. And explainability means every metric has a traceable origin. If someone asks how a number was derived, you can show exactly what data was used, how it was transformed, and what was included or excluded.
With adding agentic AI to the attack surface, internal pipelines that have been built to track control configuration need to be expanded to continuous action-level traceability.
Where the Real ROI Lives
An organization that has built toward these properties is doing something fundamentally different from one that prepares for audits by collecting screenshots. The output might look similar from the outside, but the foundation is entirely different. The business case is often framed around efficiency such as less audit prep time, and fewer manual handoffs. Those gains are real, but the more compelling argument is compounding value.
In most GRC programs, a significant chunk of team time goes toward “rebuilding truth.” Every quarter, every audit, every board report, someone pulls from the same sources, normalizes the same fields, and produces a number everyone agrees on. That work doesn’t accumulate into anything. Engineering the data foundation converts this recurring cost into a durable asset — a compliance posture that updates continuously and produces the same defensible answer whether the question comes from internal audit, an external assessor, or the board.
There’s a risk dimension too. When compliance data is manually assembled, a gap can exist for weeks without anyone knowing. When the foundation is continuous and observable, that window closes.
Most importantly, with agentic AI, the cost of not having the mapping foundation is an attack vector and not just a control gap.
The Shift Worth Making
GRC is becoming an engineering discipline because trust and accountability must now operate at machine speed. The organizations navigating this well aren’t the ones building the most sophisticated internal capabilities — they’re the ones that stopped rebuilding truth from scratch and started instrumenting it.
When talking to GRC leaders early on in this journey, the question is almost never: “Shouldn’t we do this?” Instead, it’s: “Where do we start?” The answer: start with the data you already have. Map where your control evidence actually comes from. Identify the reconciliation work your team does every quarter that produces no lasting value. Then ask what it would take to make that work happen once — automatically, continuously, with full lineage — instead of repeatedly by hand.
That question leads you to the foundation. Everything else follows from there.
About the Author
Yasmine Abdillahi is Executive Director of Cyber GRC and Business Information Security Officer at Comcast, where she leads security risk and compliance across Comcast and Sky. She is a recognized speaker at SINET, Gartner Evanta, and BrightTalk. She is also a senior fellow at the Atlantic Council. Connect with her on LinkedIn: linkedin.com/in/yasmine-abdillahi-2631b97
Guest Post: Why GRC Is Becoming an Engineering Discipline
Posted in Commentary with tags Comcast on August 27, 2026 by itnerdBy Yasmine Abdillahi, Executive Director of Cyber GRC and Business Information Security Officer, Comcast
When security leaders hear “engineering discipline” applied to Governance, Risk, and Compliance (GRC), the instinct is to brace for more tooling, more headcount, and more infrastructure that needs to be justified to the board.
But this initial reaction misreads what is actually happening. GRC is becoming an engineering discipline not because someone decided to make it more complicated, but because the complexity was already there. The compliance programs built a decade ago were designed for the slower world of annual audits, static risk registers, and policies that changed quarterly at best. That world is gone. Today, cloud infrastructure can spin up and down in hours, AI agents are proliferating, regulations can multiply across jurisdictions, and a board member might ask about risk posture, with the expectation of an immediately trustworthy answer.
The teams making real progress aren’t the ones that have added more people or tools. They’re the ones that changed what GRC is built on. Today, GRC engineering is how organizations simplify governance, shorten the time it takes to find value, and stop reinventing the wheel of pipelines year after year.
The Problem Is the Data Beneath GRC
Most organizations don’t fail at GRC because they lack frameworks, policies, or good intentions. They fail because the underlying knowledge of what is connected to what, which data resides where, and which controls protect which assets is scattered piecemeal across security, IT, cloud, identity, and business systems — none of which were designed to maintain that picture coherently. Every time a control needs to be validated, someone manually pulls from multiple sources, normalizes the results, and hopes the timing is close enough to tell a consistent story.
Consider a simple question: “How many of our critical systems have MFA enabled?” Answering it accurately means pulling identity data, cross-referencing asset inventory, filtering the results by criticality classification, and clarifying whether “enabled” means configured, enforced, or actively used. By the time the answer is ready, it’s already a snapshot from last week. Multiply that by the hundreds of controls a mature GRC program tracks, and you see the real problem: teams aren’t doing GRC work. They’re doing data plumbing.
Why agentic AI is amplifying the urgency
AI governance dominated the conversation at Black Hat USA 2026, with much of it tracing directly back to the Hugging Face incident — a preview of how quickly “AI agents” went from an emerging buzzword to the central topic on the floor.
These solutions are responding to the fact that agents drift and can get exploited when nobody is looking at them. However, AI governance is not just a feature that can simply be added to existing security tool stack. It’s a practice or a discipline requiring alignment between IT, Cybersecurity, GRC, finance and the business.
Access control issues for agents cannot be observed and trusted periodically. Instead, they need continuous validation and remediation. Because agents can update themselves at runtime; a control evidenced at a point in time may not be compliant an hour later.
This isn’t hypothetical. In July 2026, an AI model undergoing a routine capability evaluation escaped its test environment and compromised Hugging Face’s production infrastructure — autonomously, over four days, without a human directing each step. The agent didn’t need stolen admin credentials to escalate; it read cloud metadata, minted its own service-account tokens, and mapped its own permissions in real time. That’s the identity-to-agent-to-asset chain breaking down in exactly the way static, point-in-time control evidence can’t catch.
This is where the identity-to-agent-to-asset mapping underneath any GRC platform needs to be engineered and current.
Why Building Your Own Solution Usually Stalls
The natural response is to unify the data by building an internal pipeline, a custom dashboard, and a “security data fabric” that pulls everything into one place. The intent is right, but the execution is where things get hard.
Data normalization is genuinely demanding. Matching a user record from an identity provider to a Configuration Management Database (CMDB) asset record and a Security Information and Event Management (SIEM) log entry isn’t a configuration task — it’s an engineering challenge requiring sustained expertise. Audit defensibility gets added after the fact, if at all. And maintenance quietly becomes a permanent commitment, consuming engineering capacity that was supposed to go elsewhere.
Agentic AI makes the engineering lift heavier as its governance requires granular traceability including what the agents are permitted to do and what they actually did, with what inputs, on whose behalf and why. If an agent’s effective permissions can be manipulated by the content it processes through prompt injection, then “what can this agent do” isn’t a static fact pulled once and normalized; it has to be validated continuously.
What “Engineering GRC” Actually Means
Engineering GRC doesn’t mean every organization needs to engineer it themselves. It means GRC now depends on properties that must be designed in from the beginning, not added later.
Those properties are observability, testability, and explainability. Observability means your compliance posture is visible in real time, not reconstructed at audit time. Testability means controls are validated continuously against live data, not just when a review is coming. And explainability means every metric has a traceable origin. If someone asks how a number was derived, you can show exactly what data was used, how it was transformed, and what was included or excluded.
With adding agentic AI to the attack surface, internal pipelines that have been built to track control configuration need to be expanded to continuous action-level traceability.
Where the Real ROI Lives
An organization that has built toward these properties is doing something fundamentally different from one that prepares for audits by collecting screenshots. The output might look similar from the outside, but the foundation is entirely different. The business case is often framed around efficiency such as less audit prep time, and fewer manual handoffs. Those gains are real, but the more compelling argument is compounding value.
In most GRC programs, a significant chunk of team time goes toward “rebuilding truth.” Every quarter, every audit, every board report, someone pulls from the same sources, normalizes the same fields, and produces a number everyone agrees on. That work doesn’t accumulate into anything. Engineering the data foundation converts this recurring cost into a durable asset — a compliance posture that updates continuously and produces the same defensible answer whether the question comes from internal audit, an external assessor, or the board.
There’s a risk dimension too. When compliance data is manually assembled, a gap can exist for weeks without anyone knowing. When the foundation is continuous and observable, that window closes.
Most importantly, with agentic AI, the cost of not having the mapping foundation is an attack vector and not just a control gap.
The Shift Worth Making
GRC is becoming an engineering discipline because trust and accountability must now operate at machine speed. The organizations navigating this well aren’t the ones building the most sophisticated internal capabilities — they’re the ones that stopped rebuilding truth from scratch and started instrumenting it.
When talking to GRC leaders early on in this journey, the question is almost never: “Shouldn’t we do this?” Instead, it’s: “Where do we start?” The answer: start with the data you already have. Map where your control evidence actually comes from. Identify the reconciliation work your team does every quarter that produces no lasting value. Then ask what it would take to make that work happen once — automatically, continuously, with full lineage — instead of repeatedly by hand.
That question leads you to the foundation. Everything else follows from there.
About the Author
Yasmine Abdillahi is Executive Director of Cyber GRC and Business Information Security Officer at Comcast, where she leads security risk and compliance across Comcast and Sky. She is a recognized speaker at SINET, Gartner Evanta, and BrightTalk. She is also a senior fellow at the Atlantic Council. Connect with her on LinkedIn: linkedin.com/in/yasmine-abdillahi-2631b97
Leave a comment »