This week, I attended Drata's final Drataverse city tour stop in London, held at the top of the Gherkin with appropriately gloomy British weather.

I had the privilege of doing a fireside chat with Drata’s CISO Matt Hillary about the future of GRC, how GRC Engineering is transforming the discipline, and practical approaches to scaling programmes.

Very well put together, GRC Engineering was front and centre and Adam (Drata CEO), noted the phrase “think about GRC as a Product” as one of the key takeaways from the event!

The most rewarding moment? A head of GRC from a $3B company told me they pulled every GRC Engineer newsletter issue into an LLM to draft their programme roadmap. Seeing the content impact enterprise GRC leaders in such tangible ways makes every hour spent writing worthwhile.

The Drata team really loves what the GRC Engineering manifesto team and GRC Engineer are championing so very excited to see what will come out of that! Amazing event all around 😀 

And now, on with today’s newsletter!

A LinkedIn post about no-code GRC solutions from my good friend Ahmed went viral last week. Staff-level practitioner sharing that he built effective tools with Power Automate and Appsheets. Simple, practical, working solutions.

It gave me the inspiration for today’s entry as I’ve spoken to many people about the philosophy behind GRC Engineering as I’ve gotten questions from numerous folks in the industry.

One camp sees GRC Engineering narrowing into a technical discipline. Python required. Cloud-native skills mandatory. Entry barriers rising. "When do you stop being GRC and become a security engineer?" 

The subtext: GRC Engineering means coding, means specific tools, means fewer people belong.

The movement gets reduced to one of its subcomponents ("GRC Engineering equals compliance automation"), and then to one subskill inside it ("you need Python/Cloud").

The way the manifesto describes it - GRC Engineering is a capability anyone can develop. A mindset, not a checklist. Engineering thinking applied to GRC problems, whether through spreadsheets or code.

My goal in this entry is to showcase the stack that underpins GRC Engineering ⬇️ 

Why It Matters 🔍

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

This isn't an academic debate about terminology. The GRC Engineering movement is at a critical inflection point, and three things are happening simultaneously that you should think about.

1. You still work in GRC

The biggest risk isn't that the movement gets commercialised. It's that we forget what we're actually here to do: advance GRC objectives. Improve governance. Reduce risk. Enable compliance. Build trust and assurance. The Technical Foundations piece explored the critical distinction between technical literacy (understanding systems, decomposing problems, evaluating solutions) and technical depth in specific tools.

But the market is conflating them. We're seeing practitioners pivot to becoming developers, learning Python and Kubernetes, whilst forgetting that their value comes from solving GRC problems, not just building pipelines.

Your objective isn't to become a software engineer who happens to work in compliance. It's to be a more effective GRC practitioner who can leverage engineering thinking to achieve better outcomes. Systems thinking helps you understand how controls interact. Design thinking helps you build solutions stakeholders actually use. Structured problem-solving helps you find root causes. These mental models advance GRC objectives whether you're using spreadsheets or custom applications.

2. Entry Barrier Confusion

Junior GRC professionals are receiving contradictory signals. They think they need "Python, AWS, Kubernetes experience" for entry-level GRC analyst roles. LinkedIn discourse suggests you need cloud-native skills before you can contribute. We're creating a generation of aspiring GRC professionals who think they need to master specific tools before they're allowed to participate.

The result? People who could bring valuable engineering thinking to GRC problems are being excluded because they don't have the "right" technical credentials. Entry-level individuals don’t know what they should focus on to stand out.

3. Role Boundary Blur

The line between "GRC Engineer" as a role versus "GRC Engineering" as a capability is disappearing in real-time discussions. I built a framework to separate these concepts in GRC Engineer vs. GRC Engineering, but Ahmed's post proves the confusion persists. People genuinely don't know if they're talking about hiring decisions, skill development, or programme maturity.

When organisations treat "GRC Engineer" as an entry-level role requiring specific technical skills, they've missed the point entirely. GRC Engineering is a capability your programme develops progressively. It's not a starting state you hire for.

Here's what I've learned from 150+ conversations with GRC leaders, from implementing GRC Engineering at GitLab, and from helping write the manifesto: GRC Engineering is a stack. A conceptual architecture where each layer builds on the previous one.

Miss a layer, and the whole thing collapses into either cargo cult automation or impossible job requirements.

Let me walk you through each layer and show you how they connect to both the manifesto and the practical work happening in the field.

Layer 1: Foundation - What It Fundamentally Is 🏗️

Context-specific, not tool-specific

Why it matters: What works at GitLab fails at the NHS; startup solutions create enterprise debt

Foundation: Manifesto critiques "excessive focus on frameworks & standards" - applies equally to tools (From Silos to Systems)

Action: Document your org's actual constraints before evaluating any tool

G, R and C, not just evidence collection

Why it matters: Real GRC means governance orchestration, risk quantification, and compliance automation - not screenshot collection

Foundation: "Measurable and meaningful risk outcomes over checkbox compliance outputs" (Signal vs. Noise)

Action: Replace one evidence collection metric with one control effectiveness metric this week

A mindset, not a checklist

Why it matters: Systems thinking + design thinking + root cause analysis transfers across any context

Foundation: "Systems thinking allows us to understand problems in holistic context" (Three Lines of Defence)

Action: For your next problem, ask "why" five times before proposing a solution

A set of practices, not an entry-level job title

Why it matters: GRC Engineering capabilities emerge progressively as programmes mature, not as a hiring checkbox

Foundation: Capabilities develop over time, not overnight (Maturity Model)

Action: Assess your current maturity level before writing your next job description

```python
# Understanding_what_grc_engineering_is.py
# Run this before your next "GRC Engineer" job posting

class GRCEngineeringReality:
    def __init__(self):
        self.is_job_title = False
        self.is_capability = True
        self.requires_phd = False
        self.requires_thinking = True
        
    def can_contribute(self, person):
        """Who can do GRC Engineering? More people than you think."""
        if person.solves_problems_systematically():
            return True
        if person.thinks_about_root_causes():
            return True
        if person.considers_stakeholder_experience():
            return True
        if person.measures_outcomes_not_activity():
            return True
        if person.can_write_python():
            return True  # Nice to have, not required
        if person.can_use_spreadsheets_well():
            return True  # Also valid!
        if person.has_kubernetes_certification():
            return "Maybe, but that's not why"
            
    def hiring_antipattern(self, job_description):
        red_flags = []
        if "entry-level GRC Engineer" in job_description:
            red_flags.append("Contradictory expectations")
        if "must know Python, AWS, Kubernetes" in job_description:
            red_flags.append("Confusing engineer with GRC Engineering")
        if "3 years GRC Engineering experience required" in job_description:
            red_flags.append("The discipline is 2 years old")
        return red_flags
```

Layer 2: Scope - Who and Where It Applies 🌍

For everyone, not just for engineers

Why it matters: Power Automate workflows and systematic spreadsheets are valid GRC Engineering

Foundation: "Shift, and start, GRC left" only works if accessible to everyone touching the system

Action: Identify one GRC process that non-technical staff could systematise this week

For cloud, and for non-cloud

Why it matters: Principles work in air-gapped environments and legacy infrastructure too

Foundation: GRC Engineering in public sector air-gapped contexts (Dr. Ibrahim Waziri)

Action: Apply one GRC Engineering principle to your most legacy system

For B2B SaaS, and for the public sector

Why it matters: Principles transfer across sectors; specific implementations don't

Foundation: Cross-sector portability from AWS to retail to transport (Ange Ferrari)

Action: Read one case study from a different sector than yours

Extremely specific to your organisation

Why it matters: No one-size-fits-all; your context determines your path

Foundation: Level 5 solutions overwhelm Level 2 orgs (Maturity Model)

Action: Stop copying solutions from different-sized orgs; assess your actual starting point

Layer 3: Philosophy - How to Think About Problems 🧠

About solving problems, not just implementing solutions

Why it matters: Building shadow GRC infrastructure wastes resources and alienates teams

Foundation: "Shallow & narrow problem solving" treats symptoms, not root causes (GRC isn't running parallel)

Action: Before buying/building, write down the actual problem you're solving (not the solution)

Brings engineering thinking to GRC, not GRC people into engineering

Why it matters: You're applying methodologies to GRC problems, not becoming a software engineer

Foundation: Product thinking over technical skills (Becoming a GRC Product Manager)

Action: Reframe one project from "implement control X" to "solve stakeholder problem Y"

Rational build vs. buy approach

Why it matters: Most orgs use <30% of platform capabilities before deciding to "build custom"

Foundation: "Open source over closed source" but note "over," not "instead of" (DIY Breaks, Platform Value)

Action: Audit what your current platform can already do before writing another line of code

Knows about opportunity costs

Why it matters: Every hour building is an hour not spent analysing risk or building relationships

Foundation: Time invested must create more value than time saved (Selling GRC Engineering)

Action: Calculate actual ROI of your last automation project (time saved vs. time invested)

Measures impact, not activity

Why it matters: Green dashboards mean nothing if underlying controls are ineffective

Foundation: "Measurable risk outcomes over compliance outputs" (Graduation Framework)

Action: Replace one vanity metric with one outcome metric in your next report

Layer 4: Capability - What You Actually Need 🛠️

The solution spectrum: Spreadsheets → Low-code → Code

Why it matters: Context determines complexity; your problem determines the solution layer

Foundation: Engineering is in design and integration, not sophisticated algorithms (Quarterly Access Reviews)

Action: Match your next solution to your actual maturity level, not your aspirations

Leverages AI where it's strongest

Why it matters: Use AI for demonstrated outcomes, not because it's trendy

Foundation: "Evidence, logic, maths, reason over fear, uncertainty, doubt" (Vibe Coding)

Action: Identify one repetitive task where AI actually saves time (not just looks impressive)

Can be implemented by non-technical folks

Why it matters: Most valuable implementations leverage existing infrastructure, not custom builds

Foundation: Framework designed for teams without engineers (Implementation Framework)

Action: Give one GRC analyst permission to systematise one process using tools they know

Wants to popularise engineering problem-solving, not just cloud-native skills

Why it matters: Mental models transfer; Kubernetes expertise doesn't

Foundation: Technical literacy enables GRC Engineering; technical depth is optional (Technical Foundations)

Action: Teach one person systems thinking this week; skip the Python tutorial

Layer 5: Outcome - What It Actually Achieves 🎯

Provides additional value to the business, not just operational efficiency

Why it matters: Control monitoring data can inform product decisions; access reviews prevent incidents

Foundation: "GRC as product provides outcomes beyond primary use cases" (GRC as a Product)

Action: Identify one way your GRC data could solve a non-GRC problem

Improves business outcomes, not just operational metrics

Why it matters: Strategic impact beats activity metrics every time

Foundation: Risk reduction over evidence collection rates (Risk Register Reimagined)

Action: Present one metric to leadership that shows business impact, not GRC activity

Wants stronger relationships with engineers, not just bothering them less

Why it matters: Goal is partnerships where engineering sees GRC as enabling, not constraining

Foundation: "Shared fate partnerships over transactional relationships" (Human API, Obstacles to Allies)

Action: Schedule one coffee chat with an engineer to understand their pain points

Supports control/risk owners, doesn't replace them

Why it matters: Taking over responsibilities violates independence required for effective governance

Foundation: When to centralise vs. distribute capabilities (Team Topologies)

Action: Build one tool that makes a control owner's job easier, not obsolete

Knows where friction is still required

Why it matters: Some friction prevents mistakes; some forces deliberate decisions

Foundation: "In-depth continuous assurance over shallow periodic monitoring" (Designing Controls)

Action: Identify one approval step that should stay manual despite automation pressure

Execution Blueprint 🛠️

The how: 3 practical steps to put this strategy into action at your organisation

Theory is interesting. Practice is valuable. Here's how to apply these principles starting this week.

Step 1: Assess Your Context (Not Your Tools)

Use the Maturity Model to honestly assess where you are today. Your maturity level doesn't determine your value - it determines your approach.

Level 1-2: Start with what you have. Make spreadsheets systematic. Document workflows. Create repeatable processes. Pierre-Paul at Coveo started here before investing in platforms.

Level 3-4: Focus on leveraging existing infrastructure. Low-code platforms, API integrations, workflow automation. My access review automation pulled from existing IAM systems.

Level 5: Custom development, GRC-as-Code, continuous monitoring. Git-based policies and control orchestration operate here.

A Level 2 organisation with systematic, well-documented processes provides more value than a Level 4 organisation with impressive automation nobody trusts.

Step 2: Pick One Principle, Apply It This Week

Don't transform everything. Pick one principle, apply it to one problem.

Struggling with stakeholders? Read The Human API, identify one pain point, design one interface that helps.

Drowning in manual work? Find the smallest repeatable task. Automate one thing. My automation started with one system, one control, one cycle.

Building for building's sake? Read Why DIY Breaks and Platform Value. Then honestly assess: buy or build?

Measuring wrong things? Replace one vanity metric with one outcome metric. Signal vs. Noise shows you how.

# Build_vs_buy_decision_tree.py
# Run this before your next "let's build it" meeting

class BuildVsBuyDecision:
    def __init__(self, problem_description):
        self.problem = problem_description
        self.should_build = False
        
    def evaluate(self):
        """The decision tree that saves you from expensive mistakes"""
        
        # Check 1: Does a solution already exist?
        if self.existing_platform_has_capability():
            return "USE WHAT YOU HAVE (seriously, check the docs first)"
            
        # Check 2: Is this truly unique to your organisation?
        if not self.is_unique_to_your_context():
            return "BUY (someone already solved this problem)"
            
        # Check 3: Can you maintain what you build?
        if not self.can_maintain_long_term():
            return "BUY (technical debt is expensive)"
            
        # Check 4: Is building actually faster?
        if self.time_to_build() > self.time_to_integrate_existing():
            return "BUY (opportunity cost matters)"
            
        # Check 5: Does this provide strategic advantage?
        if self.provides_competitive_advantage():
            self.should_build = True
            return "BUILD (but start small, iterate fast)"
            
        # Default case
        return "BUY or use existing tools (building should be the exception)"
    
    def red_flags_you_are_building_wrong_thing(self):
        """Stop immediately if any of these are true"""
        flags = []
        if "we can build it better" in self.justification:
            flags.append("Pride, not pragmatism")
        if "it'll only take two weeks" in self.estimate:
            flags.append("Famous last words (it'll take 6 months)")
        if "we're building our own GRC platform" in self.project_description:
            flags.append("You're about to learn expensive lessons")
        return flags

Step 3: Red Flags That You're Doing It Wrong

Building parallel infrastructure instead of leveraging existing systems? Stop. Read GRC isn't running parallel and redesign.

Cargo culting tools without understanding context? If you're copying solutions because "that's what [company] uses," you're setting up expensive failure.

Alienating stakeholders with "improved" processes that create friction? You've optimised the wrong thing. From Obstacles to Allies shows how to rebuild.

Creating science experiments that never ship? Implementation Framework exists because too many initiatives stay in perpetual POC mode.

Measuring activity instead of outcomes? If success is "automations built" not "risk reduced," you're optimising wrong. Signal vs. Noise covers this.

The Bottom Line

This isn't abstract theory. It's for you, right now, trying to figure out whether your Power Automate solution "counts" or whether you need Kubernetes before you're "real."

It counts.

You're doing GRC Engineering if you're solving problems systematically, thinking about root causes, considering stakeholder experience, measuring outcomes, and being pragmatic about build vs. buy. You don't need permission. You don't need a new job title. You don't need specific tools.

The movement wants to revolutionise GRC. But revolution needs practitioners building real solutions. People sharing what works. People contributing knowledge.

Join the Discord. Contribute to the GitHub. Reply to this email to be featured in a GRC Deep-Dive. Share your spreadsheet solutions alongside Kubernetes deployments. Both matter.

The manifesto was written by practitioners who learned through implementation. Real work. Real failures that taught us what doesn't work.

Your contributions matter just as much. The spreadsheet that solved your problem might solve someone else's. The low-code integration that improved your relationships might inspire someone else's approach. The decision framework that helped you avoid expensive mistakes might help someone else.

Until then: pick one principle. Apply it to one problem. See what happens.

Resource corner 📚

Resources I’ve been consuming which are relevant to GRC Engineering!

Emre is disrupting Security Awareness, for free

If anyone of you do not know Emre Ugurlu already, I don’t know what to say…

Part of the grc.engineering manifesto crew, he crushed it at Plaid before recently joining Docker alongside Chad as GRC Engineers (podcast with both of them dropping next week!)

As part of their work at Docker they revamped a lot of the GRC program from scratch including Security awareness.

Emre launched the Open Source Cybersecurity Training, a completely free and open-source way of doing security awareness. Integrates with LMS through SCORM as well.

I was in awe when he presented it to me a couple of weeks ago and so glad he made that available to the broader community.

I took the full training, it’s probably the best awareness training I’ve been through in my career and I’ve done a lot of them!

Check out the project on grc.engineering: Open Source Cybersecurity Training

PS: Please send lots of love to Emre, this guy is a GOAT and truly committed to creating an open-source GRC space for all of us.

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!