👷🏻‍♂️ Is GRC Engineering the next DevSecOps?

"Your security risk management function is ineffective." That single line in an audit report didn't just sting - it sparked a revolution.

But here's the twist: this frustration back then sparked his involvement years later getting the GRC Engineering movement kickstarted.

Why This Episode Matters

Justin isn't just another security leader - he's been instrumental in spearheading the GRC Engineering movement and co-authored the GRC Engineering Manifesto. When someone who's experienced GRC from every angle (software engineer, security practitioner, and GRC leader) says we need to fundamentally rethink our approach, it's worth paying attention.

The Problem with Traditional GRC

The conversation with Justin revealed several key challenges that plague traditional GRC approaches:

• Being multiple degrees removed from actual security problems

• Spending excessive time on manual documentation

• Struggling to demonstrate tangible value and impact

• Getting caught in the "meta-work" trap without driving real change

This disconnect between GRC activities and actual risk reduction creates a situation where teams can be incredibly busy without moving the needle on security outcomes.

The Build vs. Buy Dilemma: A Fresh Perspective

One of the most interesting insights from Justin challenges the traditional build vs. buy dichotomy. He introduces a third way: strategic partnerships with nimble vendors who can build solutions aligned with your vision. This approach is particularly relevant for areas like Third-Party Risk Management (TPRM), where:

• Traditional solutions often fall short

• Building in-house requires significant resources

• Smaller, innovative vendors can offer customised solutions

• Design partnerships can shape product development

This perspective shifts the conversation from a binary choice to a spectrum of options that organisations can leverage based on their specific context and needs.

The Future of GRC: Making Time for What Matters

Justin's vision for GRC Engineering isn't just about automation - it's about freeing up time for high-value activities:

• Building deeper relationships with stakeholders

• Understanding business context more thoroughly

• Addressing complex, nuanced risk scenarios

• Focusing on areas where human judgment is irreplaceable

By automating routine tasks and streamlining processes, GRC teams can focus on work that machines can't do - building trust, understanding organizational context, and driving strategic risk decisions.

Key Success Metrics for GRC Engineering

The conversation highlighted several ways to measure success in GRC Engineering initiatives:

Key Performance Indicators (KPIs) ⚡️

• Process efficiency improvements

• Time saved on routine tasks

• Coverage of automated vs. manual processes

Key Risk Indicators (KRIs) 🎯

• Ability to measure risk magnitude

• Effectiveness of risk management strategies

• Real-time risk monitoring capabilities

Key Control Indicators (KCIs) 🛡️

• Control effectiveness measurements

• Coverage across the organisation

• Automation of control testing

The Real Value of GRC Engineering

Perhaps the most powerful insight from Justin is how GRC Engineering can transform the perception and impact of GRC teams:

• Moving from document creators to strategic partners

• Shifting from periodic assessments to continuous monitoring

• Evolving from checkbox compliance to real risk reduction

• Transforming from cost center to value driver

Want More? We've Got You Covered 🎧

Full episode available on:

• Spotify

• YouTube

Keep The Conversation Going

Think we're onto something? Here's what you can do:

• Join the GRC Engineering community on LinkedIn

• Check out grc.engineering, pull requests welcome!

• Connect with Justin

Share it with that third-party risk team still sending endless questionnaires. 📋 ➡️ 🚀