IN PARTNERSHIP WITH

Certify the best and empower who certifies the rest

Mastermind is the certification body trusted by the world’s most innovative organizations, including Google, Microsoft, Superhuman, Honeywell, Dataminr, Anecdotes, Thoropass, and many more.

Our auditors are fluent in modern tooling stacks, and, of course, automating everything. ISO audits aren’t just a side hustle; they’re the only thing we do.

But, that’s only part of the story.

In 2025, more than 40,000 auditors across 191 countries enrolled in Mastermind’s Lead Auditor courses, learning from the same team who assess the leaders in tech.

We certify the best and empower the auditors who certify the rest.

November 2025 has been the most intense month of my career! VantaCon in San Francisco last week. FAIRCon three weeks ago. Two trips between New York and San Francisco. Conversations with ~200 GRC practitioners across both conferences. Presenting to close to a thousand of y’all across live and online!

The kind words, the excitement about GRC Engineering, the stories about how this content has changed careers and programmes. It's been overwhelming in the best way.

Here's what struck me: I'm probably one of the only people who can meet with 10 competing GRC vendors in the same week, and they're all genuinely excited to see me. Not because I'm buying anything. Not because I'm selling anything. But because we're all building something bigger together.

That's what Thanksgiving means in GRC: a community genuinely trying to make this discipline better. Not just for certifications, not just for compliance, but for actual security outcomes.

But across all these conversations, when I asked people what they're most grateful for in their programmes, the answers were never what gets celebrated publicly. Nobody said "our governance framework." Everyone talked about a specific person, a reliable process, or a tool that just works.

So this Thanksgiving, let's be honest about what we're actually grateful for, and more importantly, how to protect and scale it.

Why It Matters 🔍

The why: the core problem this solves and why you should care

The Gratitude Gap in GRC

We celebrate the wrong things. Not maliciously, just structurally. The things that make board presentations (top 10 risk dashboard, clean audits, strategic initiatives) aren't the things that make Tuesday afternoon work (reliable scripts, responsive colleagues, tools that don't break).

This creates three problems:

We Don't Protect What Actually Works

That Python script pulling evidence daily? No documentation, no backup, one person knows how it works. That helpful security engineer? Could leave tomorrow. That vendor integration? Could break with the next platform update. We don't protect these things because we won't formally acknowledge they're critical.

We Can't Scale Operational Excellence

You can't systematise what you won't admit depends on. If success requires "that one person who just gets it," you can't hire five more of them. If your programme runs on undocumented workarounds, you can't expand to new regions. Operational excellence stays stuck because we won't acknowledge what makes it work.

We Burn Out the Wrong People

The person maintaining that critical integration gets no recognition while the framework architect gets the keynote slot. The engineer who responds to every Slack message gets no career progression while the person who created the ignored policy gets promoted. We reward visibility over reliability.

The fundamental shift: Celebration vs Dependency

We celebrate innovation and strategy. We depend on maintenance and relationships.

The GRC Engineering implication: Until we're grateful for what actually works (and protect it, document it, scale it), we're building programmes on hope rather than systems.

🤝 People: Building Empathy in GRC

What I'm most grateful for this year is watching GRC practitioners shift from adversarial to collaborative relationships with their stakeholders.

The Empathy Breakthrough

GRC teams are finally thinking about the world through their stakeholders' lenses. Understanding why engineers resist compliance requests. Recognising why security teams don't engage with GRC. Seeing why product teams avoid early involvement.

This is net new in our field. We've historically been isolated, adversarial, and compliance-focused.

Building Shared Fate

The best GRC teams I met aren't positioning themselves as compliance cops. They're positioning themselves as security enablers. When engineering ships vulnerable code, it's not just engineering's problem, it's GRC's problem too.

This builds on the Human API concept: GRC as the translation layer between different stakeholder languages.

What This Looks Like

Instead of: "We need evidence of your access reviews for SOC 2 by Friday"

We're seeing: "We've noticed credential-based attacks are up 40% in our sector. Our access review control is key to reducing this risk. Can we review the current process together?"

The Results

• GRC teams invited to architecture reviews from day one

• Security engineers voluntarily sharing documentation

• Product managers asking "what are the GRC implications?" before building

• Cross-functional working groups where GRC coordinates rather than dictates

When stakeholders see GRC as partners rather than blockers, adoption happens voluntarily. You don't need governance mandates when people genuinely want to work with you.

This connects directly to winning over key stakeholders through demonstrated value rather than mandated compliance.

IN PARTNERSHIP WITH

Lessons from achieving the ISO Trifecta

Only around 30 companies in the world hold the ISO Trifecta: ISO 27001, ISO 27701 and ISO 42001.

Join us Thursday, December 4th as Jake Bernardes and Adeel Bakht demo how they consolidated and automated the entire process using the Anecdotes platform.

⚙️ Process: Thinking in Layers

What genuinely excites me is watching GRC practitioners finally think systematically about their processes, breaking them down into atomic components that can actually be automated.

The Hard Prerequisite for Automation

You can't automate chaos. Before automation, you need consistency. And before consistency, you need to understand your process at the most granular level.

The Three-Layer Model

People are finally understanding process architecture:

Input Layer: What data comes in? Where from? In what format? Can we trust it?

Processing Layer: What transformations happen? What decisions get made? Where does human judgment remain necessary?

Output Layer: What gets produced? For whom? What triggers the next step?

When everyone on your team does the process the same way, you can automate it. When everyone does it differently, you can't.

Examples in Practice

Access Reviews becoming systematic: Instead of "please review this spreadsheet of 10,000 users," we're seeing risk-scored, prioritised review lists with context. This builds on automating quarterly access reviews through proper process design.

Vendor Assessments becoming repeatable: Instead of "every vendor gets the same 300-question assessment," we're seeing risk tiering based on actual data access and criticality.

Control Testing becoming continuous: Instead of "we test everything once per year during audit prep," we're seeing real-time effectiveness measurement against specific threats, as discussed in building for attackers rather than auditors.

The Result

When your processes are consistent and well-documented, they're scalable. You can train new team members. You can automate incrementally. You can measure effectiveness objectively.

This is the shift from GRC as a project to GRC as a product: treating processes as engineering systems requiring continuous improvement.

🛠️ Technology: The Stack That Changed Everything

The tools we have available now compared to two years ago? Night and day. I'm genuinely grateful for the engineering talent and product expertise invested in making the GRC experience better.

The Transformation

Evidence Collection: From Manual to Automatic

Two years ago: screenshots taken manually, documents uploaded individually, emails requesting information.

Now: APIs pulling evidence continuously, automated validation, integration with every major security tool.

Result: GRC teams can focus on risk analysis instead of evidence hunting.

Data Integration: From Silos to Systems

Two years ago: your GRC platform was an island, data lived everywhere, manual aggregation.

Now: 100+ native integrations, reliable APIs, unified dashboards pulling from multiple sources.

This builds on building a central data layer as the foundation of modern GRC.

AI Capabilities: From Ideas to Implementation

This is the newest shift: evidence analysis catching gaps automatically, control mapping suggesting frameworks, documentation generation that's actually useful.

But more importantly: AI tools letting GRC practitioners build solutions themselves.

With Claude Projects, Claude Code, and similar tools, GRC practitioners who aren't software engineers can now build automations, create integrations, and prototype solutions. As covered in vibe coding for GRC Engineering, the barrier between "I wish this existed" and "I built this myself" has collapsed.

Why I'm Grateful

These improvements didn't happen by accident. Vendors invested in understanding practitioner pain. Product teams prioritised infrastructure over flashy features. Engineers built reliable APIs.

The Honest Assessment

Are we done? No. There are still gaps, frustrations, platforms that overpromise.

But compare where we are to 24 months ago? The progress is undeniable. The experience is measurably better. The possibilities are exponentially broader.

measurably better. The possibilities are exponentially broader.

Conclusion

This Thanksgiving, I'm grateful for a GRC community that's evolving beyond compliance theatre. We're building empathy with stakeholders, designing systematic processes, and leveraging technology that actually works.

But gratitude without action is just sentiment.

Your challenge next week:

Protect one reliable process - Document that script, backup that workflow, cross-train that knowledge

Thank one helpful person - The engineer who responds quickly, the auditor who provides useful feedback, the colleague who makes your job easier

Acknowledge one tool that works - And make sure you have monitoring, backup, or redundancy so it keeps working

Because what we're grateful for today becomes what we depend on tomorrow. And dependencies without protection become single points of failure.

The question isn't just "what are you grateful for?"

The question is: "What are you doing to protect it?"

Enjoy your time, see you next week :)

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!