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.

CARD 002: SECURITY ENGINEER

Card 001 covered Product Managers - the people who decide what gets built. Now we're diving into Security Engineers - the people who want to reduce threats, not satisfy auditors.

This is the relationship that defines whether your GRC programme is compliance theatre or actual risk reduction.

Let's collect Card 002. 🎴

Table of Contents

• 🪪 Core Identity

• 💭 What They Actually Care About

• ⚡ How GRC Intersects Their World

• 📅 Key Milestones in Their Calendar

• 🤝 Critical Meetings They Run

• 🌐 Their Key Stakeholders

• 🏆 What Success Looks Like to Them

• 💬 How to Start the Conversation

• 🚩 Red Flags (When They'll Resist GRC)

• 🧠 Their Mindset & Philosophy

• 🗣️ The Language They Speak

• 🎴 Key Takeaways

🪪 Core Identity

Role: Security Engineer
Department: Security / InfoSec / Engineering (varies by organisation)
Reports To: Security Lead / CISO / VP Engineering (organisation-dependent)
Key Metric: Vulnerability remediation time, incident response effectiveness, mean time to detect (MTTD), mean time to respond (MTTR), security posture improvements

💭 What They Actually Care About

• Reducing attack surface through threat-driven priorities - Fix vulnerabilities attackers actually exploit (based on threat intel), not what frameworks list alphabetically. Question: "Does this reduce exposure to real threats?"

• Preventing incidents that impact business and customer trust - Measured in incidents prevented, MTTR reduced, vulnerabilities eliminated before exploitation. Audit findings closed doesn't motivate them.

• Continuous security improvement vs annual audit snapshots - Threat landscape evolves daily. Annual control testing misses 364 days of reality whilst attackers operate continuously.

• Building defences based on threat landscape, not audit requirements - MITRE ATT&CK and threat intelligence drive roadmap. Compliance frameworks don't. When credential attacks (T1078) spike in their sector, that's priority #1.

• Automation of security tasks - Manual security work doesn't scale. Automate scanners, SIEM rules, detection, response. If done manually twice, automate it.

• Not being treated as audit evidence generator - Hired to secure systems, not produce screenshots for auditors. Want to fix real problems, not fill compliance spreadsheets.

⚡ How GRC Intersects Their World

GRC enters when compliance demands technical expertise, when audit evidence needs their security systems, or when GRC treats them as "evidence generation service." For most Security Engineers, GRC work feels like distraction from actual security.

When GRC Becomes Their Problem

Scenario 1: Audit questions disconnected from cloud security reality

Preparing for audit, GRC asked for IP addresses and network perimeter details. Security's response: "Infrastructure changes constantly. IP addresses are dynamic. This makes no sense for cloud security."

Security custom-created static lists of dynamic infrastructure to satisfy audit questions designed for on-premise data centres. Their reaction: "We can get you the evidence. It's useless. It doesn't help security because that's not how you do network security in the cloud. But if you want it, you have it."

Lesson: Audit frameworks designed for traditional infrastructure don't translate to cloud-native security. When GRC asks Security for evidence that makes no technical sense, you create compliance theatre whilst consuming their limited time.

Scenario 2: GRC absent when Security needs advocacy

Security Engineer identified critical security gap requiring new controls that would provide meaningful risk reduction. Not tied to any compliance requirement. When they requested GRC support to advocate with leadership for resources and priority, GRC declined involvement: "This isn't a compliance requirement. We can't help."

Security had to fight the battle alone, without GRC's weight in conversations with control owners and executives. Their proposal got deprioritized because it had no audit deadline attached. Security's reaction: "We're supposedly part of the same security organisation, but GRC only shows up when they need something from us for audits."

The resentment: GRC constantly asks Security for evidence and support, but when Security needs GRC's organizational weight to get threat-reducing controls approved, GRC is absent.

Lesson: The relationship can't be one-way. If GRC only engages Security for compliance needs but doesn't advocate for Security's threat-driven priorities, you're not partners. Use your influence with executives to help Security get funded for controls that reduce real risk, even when no audit requires them. That's how you build trust.

Scenario 3: Annual pen testing theatre

Annual pen test required weeks of Security involvement: AppSec designs scope, coordinates with testers, reviews findings. Testers used automated tooling in black-box mode, finding mostly low-hanging fruit.

With active bug bounty programme running, pen test value-add was minimal. But toil was substantial: false positives, findings rated High/Medium that Security scoped to Low/Not Applicable, every vulnerability requiring AppSec review.

Result: Weeks of Security time consumed. Security value: nearly zero beyond providing report to customers for sales.

Lesson: Annual compliance-driven pen testing provides minimal security value when continuous testing already exists. If pen tests exist purely for compliance, acknowledge this honestly and minimise Security burden.

Common Conflicts

• GRC building parallel threat/risk infrastructure - Security already has threat intelligence platforms, vulnerability prioritization systems, attack surface mapping, and incident metrics. When GRC builds separate risk registers or compliance tracking without connecting to Security's data, you create competing systems. (See our GRC Running Behind Security newsletter)

• Annual compliance cycles vs continuous threat reality - Auditors arrive annually. Attackers operate daily. When GRC uses annual cycles (yearly evidence, quarterly testing) whilst Security monitors continuously (daily scans, real-time SIEM), the mismatch creates friction. (Related: See our Auditors or Attackers newsletter on this critical shift)

• Audit-driven vs threat-driven priorities - "SOC 2 requires this" feels arbitrary. "Credential attacks up 40% in our sector, this prevents them" makes security sense. Framework requirements don't motivate. Threat reduction does.

• Documentation over remediation - GRC wants proof controls exist. Security wants to fix vulnerabilities. When compliance says "document your process," Security hears "paperwork instead of working on top attack vectors."

• Becoming audit support instead of security professionals - Pulled into compliance meetings, evidence generation, auditor discussions instead of securing systems and responding to threats.

📅 Key Milestones in Their Calendar

• Q1: Post-holiday backlog, annual planning. GRC insight: Embed in planning now, don't wait for Q4 audit prep.

• Q2: Security improvements execution. GRC insight: Good window for evidence automation projects.

• Q3: Proactive security work (ideal). GRC insight: Best time for collaborative projects if you've built trust.

• Q4: Year-end audit prep, 2026 planning. GRC insight: If asking for audit help in Q4, you've planned poorly. This should be automated.

IN PARTNERSHIP WITH

Leave Compliance Firefighting in 2025 🔥

Make 2026 the year of continuous trust. 

Drata automates the manual chaos so you can spend your time engineering—not extinguishing audit emergencies. Discover the power of continuous, automated control monitoring, real-time risk insights, and an AI-powered trust management platform that scales with your architecture.

🤝 Critical Meetings They Run

Weekly: Security team sync, incident postmortem, vulnerability triage, on-call handoff

Monthly: Security metrics review (MTTD/MTTR), tool evaluation, architecture review board, threat intelligence briefings

Quarterly: Security roadmap planning, OKRs review, compliance prep (reluctantly), infrastructure security planning

GRC insight: Don't create new meetings. Embed in existing ones or ask for async input.

🌐 Their Key Stakeholders

Upstream: CISO, VP Engineering, CTO
Downstream: Development, Infrastructure, DevOps teams
Peers: GRC/Compliance (often tense), IT, SRE

Note: Security Engineers may report to Engineering or CISO. Engineering-reporting optimises for velocity + security. CISO-reporting optimises for risk + compliance.

🏆 What Success Looks Like to Them

Short-term

Close critical vulnerabilities before exploitation. Improve detection coverage. Ship security tooling. Reduce MTTR. Minimise 3am pages.

Medium-term

Significantly reduce MTTR through automation. Build security tooling that shifts left. Measurable security improvements (fewer criticals, better detection, faster response). Recognised for preventing incidents.

Long-term

Security architecture recognised as enabling velocity. Promoted to Senior/Staff/Principal. Build elegant solutions. Maybe Security Architect, Lead, or CISO.

💬 How to Start the Conversation

The ideal GRC-Security partnership: Security owns threats, GRC translates to business impact, funding flows to threat reduction, compliance happens automatically.

Opening That Works:

"I want to translate your threat intelligence into risk language that gets you funded. Can we map your top threats to business impact? You focus on threat reduction, I'll handle executive translation and get you resources."

Frame GRC As:

• Threat-to-business translator: "Credential attacks (T1078) are your #1 threat. Let me translate to business risk language that funds zero-trust implementation."

• Risk-driven prioritization partner: "Instead of annual SOC 2 testing, let's build continuous monitoring of control effectiveness against active threats." (See our Risk Registers Reimagined newsletter)

• Security investment amplifier: "You've identified 3 critical gaps. I'll build the business case showing threat reduction value AND compliance coverage. Get you funded."

• Integration with existing systems: "Use your vulnerability scanner, SIEM, threat intel platform. I'll transform your security data into risk language executives understand."

Avoid Saying:

• ❌ "Can you fill this spreadsheet for audit?"

• ❌ "We need documentation for this control"

• ❌ "Compliance requires this" (without threat context)

• ❌ "Can you attend this 2-hour audit meeting?"

🚩 Red Flags (When They'll Resist GRC)

Trigger #1

Treated as evidence generation service instead of threat reducer.
Defuse: Automate evidence from their existing stack. Dashboards serve ops AND audit.

Trigger #2

Pulled into compliance meetings instead of security work.
Defuse: Async input only. Respect their time ruthlessly. Technical decisions only.

Trigger #3

Manual toil requirements instead of automation.
Defuse: Never ask for recurring manual work. Always propose automation.

Security Engineers operate on continuous cycles. GRC operating on annual cycles creates fundamental misalignment.

🧠 Their Mindset & Philosophy

Core Beliefs

• Threat-driven prioritization beats framework-driven compliance

• Incidents prevented > audits passed

• Continuous monitoring not annual snapshots

• Built-in security, automation always

Motivations

• Preventing breaches

• Elegant solutions

• Modern tech

• Being enablers not blockers

• Deployed improvements making measurable impact

Daily Frustrations

• Compliance busywork providing zero security value

• Blamed without empowerment

• Auditors missing cloud reality

• Screenshot requests

• Pulled from threat work for compliance meetings

🗣️ The Language They Speak

Phrases They Use:

• "How can we automate this?"

• "What's the actual attack surface?"

• "Can we shift this left?"

• "What's the real risk?" (business impact, not framework severity)

• "How does this integrate with our stack?"

• "Is this exploitable or just scanner noise?"

Translation Guide:

❌ "We need AC-2.17 for annual audit"
✅ "Credential attacks (MITRE ATT&CK T1078) are your #1 threat. Can we map MFA effectiveness to business risk reduction? Auto-generates audit evidence whilst measuring threat prevention."

❌ "Annual penetration testing for SOC 2"
✅ "Shift from annual pen tests to continuous threat validation using your bug bounty and SAST/DAST. Real-time feedback, continuous assurance, less toil."

❌ "Audit wants screenshots of security tools"
✅ "Build dashboard from your SIEM/scanner showing control effectiveness against active threats. Better ops visibility, real-time audit evidence, zero screenshots."

❌ "Document threat model for risk assessment"
✅ "Your threat model is what our risk register needs. Transform your MITRE ATT&CK mappings into business risk language. Get you funded."

❌ "Quarterly vulnerability compliance review meeting"
✅ "Pull vulnerability metrics from scanner API automatically. Dashboard shows: threats → impact → remediation → risk reduction. Replaces meetings."

🎴 Key Takeaways

• Security Engineers prioritize threat reduction, not compliance satisfaction - frame GRC in threat landscape language (MITRE ATT&CK, active exploits, incidents prevented) not framework requirements (AC-2.17, annual testing)

• Use Security's existing threat intelligence and vulnerability data - they already track threats, prioritize vulnerabilities, map attack surface. Connect to their systems, don't duplicate their work

• Shift from annual compliance snapshots to continuous threat-driven monitoring - Security operates continuously (daily scans, real-time SIEM). GRC must match this cadence to stay relevant

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!