GRC Engineering: From After-the-Fact Verification to Engineered Assurance
Featuring my collected insights combined with thoughts from the most recent Risk Is Our Business Podcast with Ayoub Fandi, Security Assurance Automation Team Lead at GitLab and founder of the GRC Engineer Podcast & Newsletter
In the most recent transmission of the Risk Is Our Business Podcast, I beam aboard Ayoub Fandi — Security Assurance Automation Team Lead at GitLab and the founder of the GRC Engineer Podcast and newsletter — to explore what is a next frontier for governance, risk management, and compliance: GRC engineering and how it related to GRC 7.0 – GRC Orchestrate. Our conversation ranged from first principles to hard-won lessons in automation and architecture, and from the current cyber-heavy use of the term to a broader, enterprise-wide discipline that touches objectives, risk, integrity, and assurance across the business.
Ayoub’s professional arc mirrors the transformation underway in the field. He moved from Big Four consulting in France to roles in high-growth technology environments at Salesforce and GitLab, where the cadence of change is measured not in quarters but in deployments per hour. That pace renders traditional GRC practices — annual control checks, screenshots, manual evidence packs, after-the-fact testing — increasingly unfit for purpose. As Ayoub put it, the gap between how fast the business operates and how slowly GRC verifies has become untenable. The solution, he argues, is not more checklists; it’s a structural shift: treat risk, compliance, and assurance as engineered capabilities built directly into systems, processes, and workflows.
Ayoub Fandi: “Some companies push a hundred thousand deployments a year. You can’t meet that speed with yearly tests and screenshots. GRC has to move earlier into design and become machine-readable in how we test, monitor, and gather evidence.”
What follows is a detailed exploration — narrative and pragmatic — of what GRC engineering is, why it matters, and how to make it real.
First Principles: Defining GRC Engineering against OCEG’s Core
We ground this in the OCEG definition of GRC as a capability to reliably achieve objectives (governance), address uncertainty (risk), and act with integrity (compliance). Against that backdrop, GRC engineering is not a new “flavor” of risk, compliance, or control; it is the technical discipline that embeds those principles into the fabric of the organization.
Here’s the definition we refined together:
Michael Rasmussen (validated by Ayoub): “GRC engineering is the discipline of embedding governance, risk management, and compliance into the technical fabric of the organization through systems architecture, automation, and data engineering — so that GRC is not just a policy function, but an operationalized, engineered capability.”
Ayoub’s verdict: “9.999 out of 10 — the data engineering part is critical. Get the data wrong and everything else collapses.”
That last sentence is a constant refrain in our discussion. The most sophisticated automation fails without coherent data models, clean pipelines, and consistent semantics. In other words, data engineering is table stakes.
The Manifesto Mindset: Shift-Left, Treat GRC as a Product, and Be Practitioner-Led
Ayoub has articulated a simple, powerful set of principles in what he calls the GRC Engineer Manifesto. Three ideas stand out:
- Shift Left: Move risk management and compliance considerations into the design phase so that GRC influences how systems are built, not just how they’re verified.Ayoub: “We want GRC present when the product manager makes trade-offs, not arriving at the end asking for screenshots.”
- Treat GRC as a Product: Manage GRC iteratively, with a roadmap, telemetry, and a user experience orientation toward control owners and contributors. Reduce toil by sourcing data from native systems rather than forcing duplicate entry into GRC tools.
- Practitioner-Led: Ensure those who live the problems shape the solutions. Partner with vendors, yes, but be clear-eyed about what good looks like, and build lightweight internal capabilities where necessary to bridge gaps.
Together, these principles convert GRC from a project (checklist, deadline, binder) into a product (ongoing capability, measured outcomes, engineered UX).
Architect vs. Engineer: Two Sides of the Capability
We also distinguished GRC architects from GRC engineers. The engineer writes the scripts, wires the webhooks, builds the workflows, and automates the evidence gathering. The architect designs the overarching decision and data architecture: how risk, control, obligation, and assurance flows traverse systems; where the source of truth sits; how to align GRC telemetry with business objectives and reporting.
Ayoub: “Software engineering skills may increasingly be commoditized with AI, but architecture endures— orchestrating systems, data, and stakeholders so the whole actually works.”
I shared an example of a Nordic telecom whose first GRC implementation faltered; their second succeeded only after they restarted with data models and enterprise architecture first. Ayoub agreed: many failures stem from starting with vendor feature lists instead of a clear picture of inputs, outputs, and flows (e.g., how a third-party risk assessment creates obligations, exceptions, and control tests downstream).
Beyond Cyber: Expanding the Scope to Enterprise GRC
Today, most visible “GRC engineering” examples sit inside digital and cyber programs — policy-as-code, cloud configuration monitoring, continuous compliance for SOC 2 / ISO 27001 / PCI / FedRAMP. That’s understandable; the technical acumen and tooling maturity in security are ahead of many business functions. But both of us argue that the same engineering principles must extend beyond IT to the full enterprise:
- Performance & Objectives: connecting KPIs/KRIs/KCIs to objectives so that performance is always viewed with its uncertainty and control posture.
- Enterprise & Operational Risk: scenario modeling, risk quantification, and control telemetry tied to processes, people, and assets.
- Compliance & Ethics: obligation parsing and mapping, policy lifecycle automation, training triggers, and case management that integrates HR, Legal, and Compliance.
- Internal Control & Audit: continuous controls testing, automated evidence pipelines, exception governance, and analytics-driven assurance.
Ayoub: “We started in tech because that’s where the engineers were, but the benefits are even greater as you move into functions with legacy process debt. The evangelism and some pre-built patterns just need to catch up.”
What GRC Engineering Looks Like in Practice (Across GRC 7.0 – GRC Orchestrate)
To make this concrete, here is a cross-section of engineered capabilities aligned to the GRC 7.0 – Orchestrate domains. Note how they move from workflow lists to data-centric, automation-ready architectures.
Strategy & Decision Management
- Problem: Strategy reviews lack risk-adjusted intelligence.
- Build: A decision architecture that links objectives to risk and control telemetry; simulation models surface trade-offs (“If we accelerate Region X, supply risk and ESG non-compliance increase by Y”).
- Result: Decisions show the path to target and the cost of uncertainty.
Performance & Objective Management
- Problem: KPIs are blind to risk and control efficacy.
- Build: Data models that bind KPIs ↔ KRIs ↔ KCIs with lineage back to source systems (ERP, CRM, HRIS, cloud).
- Result: Performance dashboards that surface early warning signals and control degradation.
Enterprise & Operational Risk & Resilience
- Problem: Paper scenarios and tabletop exercises don’t translate into action.
- Build: Digital twins of critical processes and assets; stress-test scenarios (workforce, vendor, facility, cyber, regulatory).
- Result: Playbooks driven by telemetry, not static documents; alignment to DORA, CPS 230, UK Operational Resilience.
Digital Risk & Resilience
- Problem: Cyber posture is siloed from business risk.
- Build: Continuous configuration and vulnerability telemetry mapped to business services and obligations (NIST CSF, PCI, GDPR).
- Result: Cyber metrics contextualized by business impact and regulatory exposure.
Compliance, Ethics & Obligation Management
- Problem: Obligations live in PDFs and spreadsheets.
- Build: Obligation parsing (human + AI), normalized into a graph that links to processes, policies, controls, owners, and evidence sources.
- Result: Machine-actionable compliance with automated attestations and evidence collection.
Third-Party GRC
- Problem: Onboarding is front-loaded; monitoring and offboarding are weak.
- Build: End-to-end orchestration — intake → segmentation → KYC/AML/sanctions → ESG → contract → performance/risk telemetry → offboarding controls.
- Result: Governance of the entire third-party lifecycle, not just initial risk scoring.
Policy & Training
- Problem: Policies aren’t adopted or understood at the point of work.
- Build: Version-controlled policies linked to obligations and roles; contextual policy guidance APIs and Q&A assistants embedded where employees work.
- Result: Reduced policy-toil and higher adherence.
Internal Control Management
- Problem: Point-in-time testing misses drift.
- Build: Continuous control monitoring (CCM) via APIs, event streams, and rules engines; exception management with risk-based SLAs.
- Result: Early detection, lower audit fatigue, clearer lines of accountability.
Issue & Case Management
- Problem: Fragmented hotlines and incident trackers.
- Build: A unified case platform with routing, confidentiality tiers, evidence management, and disclosure workflows.
- Result: Integrity becomes operationalized and reportable.
Audit & Assurance
- Problem: Audits recreate the past instead of validating the present.
- Build: Evidence pipelines and data lineage, enabling continuous auditing; risk-based sampling and automated test scripts.
- Result: Assurance at the speed of change.
ESG & Sustainability
- Problem: CSRD/ESG data is manually wrangled and error-prone.
- Build: Instrumentation and vendor data feeds (energy, scope data, workforce) normalized to reporting taxonomies with provable lineage.
- Result: Timely, defensible disclosures tied to objectives and risk.
Integrated Reporting & Analytics
- Problem: Reports are static and backward-looking.
- Build: A GRC command center that unifies objectives, risks, controls, obligations, third-party and ESG metrics; layered with digital twins and agentic AI to surface weak signals and recommend actions.
- Result: A living system of governance, not a stack of PDFs.
Agentic AI: Promise, Pragmatism, and the Data Imperative
Both of us see agentic AI as a transformative accelerant — but only when the data substrate is ready.
Ayoub: “A lot of ‘agentic’ workflows today are still step-by-step automations. Without coherent, consistent data, the agent will just go faster in the wrong direction. Fix the data, and even a modest tool delivers outsized value.”
The horizon he sketches is compelling: AI that becomes technology-agnostic, generating custom integrations and workflows to meet business objectives regardless of the underlying cloud or tool stack. In that world, engineering gives way to architecture as the enduring discipline — because the agent writes scripts, but humans still design the goals, constraints, and governance.
Pathways into GRC Engineering (From Both Sides of the Aisle)
One of the most practical sections of our conversation was Ayoub’s guidance on how to enter and grow in the discipline:
- If you’re a GRC practitioner:
- Learn the basics of Python or similar.
- Pick a single, painful, repetitive task — e.g., quarterly evidence collection from a handful of systems — and automate it end-to-end (even with AI-assisted coding).
- Measure toil reduction and error rate improvements; socialize the win and repeat.
- If you’re a software engineer:
- Study GRC objectives and frameworks (OCEG, ISO 31000, internal control principles, sector regulations).
- Shadow a control owner or an auditor for a sprint.
- Apply your skills to build reliable evidence pipelines, clean data models, and simple but robust automations that survive audits.
For ongoing learning, Ayoub points to the GRC Engineer Manifesto and his newsletter and podcast — where he features practitioners from Netflix, Zoom, IKEA, and beyond. The pattern across episodes is the same: start where the data already lives, automate one real bottleneck, and focus on fit-for-purpose outcomes rather than flashy demos.
From Workflow to Architecture: The Operating Model Changes
A recurring theme in our exchange is that GRC engineering is not merely “doing workflows in a tool.” It is adopting an architectural operating model:
- From forms to pipelines: Inputs flow from source systems; validations and transformations are explicit.
- From controls to telemetry: Tests run continuously; drift is detected early.
- From evidence packs to lineage: Data is traceable from report back to system of record.
- From one-off projects to product roadmaps: Backlogs, usage metrics, SLAs, and success criteria exist.
- From isolated teams to orchestration: Risk, compliance, audit, security, and the business share a common data model and glossary.
This is precisely where GRC architects and engineers collaborate: decide what must be true in the data and the flows, then implement it with the right blend of vendor capabilities and custom glue.
Why Now: Regulation, Complexity, and Tooling Maturity
The timing is not accidental. Three forces converge:
- Regulatory pressure (e.g., UK Corporate Governance Code Provision 29, EU DORA, CSRD, NIS2) demands not just policies but evidence of effectiveness and ongoing assurance.
- Business complexity — global supply chains, hybrid work, digitized operations — creates a volume and velocity of change that manual GRC cannot handle.
- Technology maturity — APIs everywhere, event streams, cloud data platforms, rules engines, LLMs, and early digital twin practices — makes engineering the practical path to sustainable GRC.
Making It Real: A Practical Starter Blueprint
If you’re ready to move from concept to capability, here’s a pragmatic starter plan that works in organizations large and small:
- Choose one value stream (e.g., third-party onboarding, change management, or financial close).
- Map the GRC flows: objectives → risks → obligations/policies → controls → telemetry/evidence → exceptions → attestations → reporting.
- Define the minimum data model (entities, relationships, owners, sources of truth, lineage requirements).
- Automate one control test end-to-end (trigger → gather → evaluate → log → notify → escalate).
- Stand up a tiny “command center” view for that stream — objectives, risk indicators, control status, exceptions — in a single page.
- Measure toil removed and assurance gained; capture lessons; expand by one adjacent control or obligation each sprint.
- Institutionalize the operating model: backlog, product ownership, SLAs, data standards, change management, and documentation that auditors can love.
The Road Ahead: GRC 7.0 – Orchestrate
We closed by situating GRC engineering inside the broader evolution I call GRC 7.0 – GRC Orchestrate. This next era blends agentic AI with digital twins and business-integrated architectures so organizations can reliably achieve objectives, address uncertainty, and act with integrity — continuously, and at scale. GRC engineering is how we get there: by making assurance native to the way the enterprise plans, builds, buys, changes, and learns.
Ayoub: “Fix the data, build the flows, and the rest follows. Start small, automate what hurts, and keep the human judgment where it matters.”
Risk isn’t the enemy; it’s the mission. GRC engineering gives us the instrumentation, the telemetry, and the control surfaces to navigate that mission with speed and integrity — not just in cyber, but across the entire enterprise. If you want to dive deeper into practitioner stories and the manifesto, check out Ayoub’s GRC Engineer newsletter and podcast — and expect to hear more from both of us as this discipline matures from pockets of automation into a coherent, engineered operating model for GRC.