Notifications
Clear all
Topic starter
11/07/2026 8:31 pm
TL;DR: Modern GRC is shifting from screenshot-driven audits and annual evidence collection toward continuous, engineering-led assurance, according to Drata’s conversation with Ayoub Fandi. That change matters because AI, automation, and trust centers only work when underlying workflows and data quality are already disciplined, not as a substitute for them.
NHIMG editorial — based on content published by Drata: GRC engineering, AI, and the future of assurance from Drataverse London 2025
Questions worth separating out
Q: How should security teams build GRC processes that stay current with engineering change?
A: They should instrument controls so evidence is generated by the systems that run them, not assembled manually after the fact.
Q: Why do AI tools fail in GRC when the underlying workflow is inconsistent?
A: AI fails when it is asked to summarise unstructured evidence, inconsistent exceptions, or unclear approval logic.
Q: What breaks when assurance is still based on annual evidence collection?
A: Annual collection creates stale proof, stale accountability, and stale risk decisions.
Practitioner guidance
- Instrument controls for continuous evidence Map high-value controls to systems that emit durable evidence automatically, then define who owns remediation when the evidence shows drift.
- Standardise AI review inputs before scaling automation Normalize report formats, exception categories, and approval paths so AI can support review without inventing structure.
- Tie identity lifecycle signals to assurance reporting Feed account provisioning, privilege changes, offboarding, and secret rotation into the same governance view so access truth stays current.
What's in the full article
Drata's full post covers the operational detail this post intentionally leaves for the source:
- How the team frames assurance as a daily operating model rather than a quarterly evidence chase.
- The workflow patterns used to turn engineering activity into governance-ready evidence without constant manual collection.
- Specific examples of how AI is being applied to third-party risk management and report review.
- The trust-centre direction the conversation points toward for external assurance and vendor risk workflows.
👉 Read Drata’s conversation on GRC engineering, AI, and continuous assurance →
GRC engineering and continuous assurance: what changes for teams?
Explore further
11/07/2026 9:01 pm
GRC engineering is becoming the control plane for assurance, not a back-office reporting function. The article shows a shift away from annual evidence production toward continuous control visibility, which is the only model that can keep pace with modern engineering teams. That matters because trust is no longer created at audit time, it is earned through current, machine-readable control state. For practitioners, the implication is that GRC has to speak the language of operations, not just compliance.
A question worth separating out:
Q: How should identity teams connect access governance to continuous assurance?
A: They should use live lifecycle signals for provisioning, privilege changes, revocation, and secret rotation as part of the assurance model. When those signals are separate from governance reporting, the organisation can prove a control exists without being able to prove it is working.
👉 Read our full editorial: GRC engineering is turning compliance into continuous assurance
