IN PARTNERSHIP WITH

Traditional DLP isn’t build for AI.

While legacy tools focus on email, file transfers, and endpoints, AI platforms like ChatGPT introduce new risks that demand smarter safeguards.

Learn how leading enterprises are evolving their DLP strategies to embrace AI securely – without compromising compliance or control.

A Quick Note from FAIR Conference 2025 📣

What an incredible week at #FAIRCon25! The energy, the insights, and the conversations were outstanding. Saket Modi’s keynote on the state of CRQ and which role SAFE wants to play in its future was pretty sharp!

His core message resonated deeply: 93% of CISOs want the outcomes CRQ delivers, yet only 7% say yes to the methodology.

The solution? Lead with outcomes ("Cyber Decision Intelligence") rather than terminology, automate the heavy lifting, and extend FAIR principles beyond first-party risk to TPRM and AI. Saket's vision for automated inputs, robust models, and automated outputs aligns pretty well with what we are championing in GRC Engineering.

Overall, two sessions stood out for me. Tony Martin-Vegue's "The Six Levers That Actually Move Risk" went beyond controls to showcase external forces impacting risk, blending brilliant anecdotes with actionable insights. Then Adrienne Allen's "From Checkbox to Chess Move: Building a Risk-Driven GRC Program" delivered an amazing blueprint on gradually building a threat-driven GRC programme vs an audit-focused practice. I had the privilege of emceeing Adrienne's session, and her amazing insights inspired this week's newsletter.

Already looking forward to next year, it was really nice to meet so many readers of the newsletter in real-life 🙂 

Are You Building for Auditors or Attackers?

Adrienne's session laid out why organisations must shift from audit-driven to threat-driven security. Most security programmes are built to pass audits, not stop attackers.

Here's the GRC Engineering question: What actually changes when you make this shift?

It's not just philosophy. Your systems shift from annual evidence collection to continuous threat monitoring. Your stakeholder relationships move from adversarial compliance requests to collaborative threat response. The value you deliver changes from "we passed the audit" to "we reduced our threat exposure."

This is the practical implementation challenge Adrienne described, through the GRC Engineering lens.

Why It Matters 🔍

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

Most GRC programmes operate in an annual cycle: controls tested once yearly, evidence collected when auditors arrive, relief when the certificate/report arrives, then nothing for 11 months.

This creates three critical problems:

• a partial sense of accomplishment

• implementing suboptimal controls

• 364 days of control drift

Here's the fundamental distinction between compliance theatre and risk-driven approaches:

Audit-driven programmes are inward-facing: they focus on what compliance frameworks require, where success means meeting auditor expectations.

Threat-driven programmes are outward-facing: they focus on what actually threatens your organisation, where success means reducing susceptibility to real attacks through alignment with the actual threat landscape.

The GRC Engineering implication: you're currently building systems to pass audits. When the goal changes to reducing threat exposure, your entire technical stack needs rethinking. Evidence collection becomes continuous monitoring, control testing shifts to effectiveness measurement, and your stakeholder relationships completely transform. Your company needs protection, not just certificates.

Strategic Framework 🧩

The what: The conceptual approach broken down into 3 main principles

1. Threat-Risk Integration Through GRC Engineering

In a threat-driven model, you become the orchestration layer between threat intelligence teams and control implementation. Think of yourself as the Human API that translates threat context into control requirements.

Frameworks like MITRE ATT&CK and STRIDE become your translation tools. When threat intelligence identifies a new attack pattern, you map it to which controls should prevent it, which assets are susceptible, what evidence demonstrates effectiveness, and how to measure risk reduction.

Similarly, FAIR terminology (Threat Event Frequency → Vulnerability/Susceptibility → Primary/Secondary Loss) helps you quantify impact. Instead of asking "does SOC 2 CC6.1 require this?" you ask "does this reduce our susceptibility to credential-based attacks?"

2. Building Systems for Contextual Controls

Threat modelling creates your requirements; GRC Engineering delivers the automation to execute them continuously.

Build dashboards that map controls to active threats. Instead of "MFA Implementation: 95% complete," show the threat (credential attacks via T1078), current exposure (5% of privileged accounts lack MFA on financial systems), control effectiveness (preventing 98% of attempts, up from 92%), and risk level (high). This requires control orchestration beyond documenting controls exist. You're instrumenting controls for continuous feedback about effectiveness against specific threats. This approach builds on designing controls where compliance is an afterthought to actual security outcomes.

3. The Systems Thinking Shift

When you move to threat-driven GRC Engineering, your entire stakeholder relationship model changes.

In audit-driven models, your primary partnerships are with Audit and Compliance teams, working with control owners in a transactional basis, you contact Engineering only for evidence collection, and dynamics are adversarial. In threat-driven models, your primary partnerships shift to Security Engineering and Threat Intelligence, you collaborate continuously with Infrastructure and Product, and dynamics become collaborative with joint threat-response planning.

Here's what's critical: threat-driven GRC Engineering is still about orchestration, not ownership. You own control framework design, evidence automation, effectiveness measurement, and risk quantification. You orchestrate control implementation, security tooling integration, and remediation workflows. But you don't own threat detection systems, incident response, or security operations. Security Engineering detects threats; you ensure those detections flow into control effectiveness measurements and drive systematic improvements. This builds on the systems thinking approach where GRC operates as a product with continuous improvement cycles.

IN PARTNERSHIP WITH

The Compliance OS for Modern GRC Leaders

Audits are no longer one-off, they’re constant, complex, and costly. Legacy tools add chaos, but Sprinto is the Compliance OS built for modern GRC leaders. It automates evidence collection, reuses proof across frameworks, and keeps compliance always-on.

The impact: 60% faster audit readiness, 100% risk oversight, and confidence for boards and regulators, all without scaling headcount. Compliance stops being a firefight and becomes a predictable business function.

Execution Blueprint 🛠️

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

Step 1: Automate Threat-to-Control Mapping

Start with your five most critical assets on Monday morning. For each one, identify what threats target this asset type using MITRE ATT&CK, which controls should prevent these threats, and how you know if these controls are effective.

Build the mapping in your first two weeks. Select your framework (MITRE ATT&CK for technical threats, STRIDE for application threats), list relevant techniques for each critical asset, map existing controls to these techniques, and identify gaps. In weeks three and four, connect to threat intelligence by creating a simple spreadsheet mapping threats to technique IDs to controls to owners, and schedule monthly reviews where threat intelligence updates drive control assessments.

You don't need expensive tools. Start with MITRE ATT&CK Navigator (free) for threat mapping, your existing GRC platform for control tracking, and simple dashboards. The goal is creating the feedback loop between "what threatens us" and "what protects us."

This mapping shows how a single threat (T1078: Valid Accounts) connects to multiple preventive controls (stopping attacks before they succeed) and detective controls (identifying attacks in progress). Each control displays its current status and risk level, enabling you to prioritise improvements based on threat exposure rather than compliance requirements.

Step 2: Build Continuous Monitoring Systems

Move from annual evidence collection to real-time effectiveness measurement. Transform from "please provide screenshots showing MFA is enabled" (once per year) to "MFA effectiveness dashboard showing coverage, bypass attempts, and risk reduction" (updated continuously).

Identify high-value automation candidates where evidence collection is currently manual, underlying data already exists in security tools, changes happen frequently, and effectiveness can be measured quantitatively. Examples include access review data from identity providers, vulnerability scan results, configuration compliance from cloud providers, and encryption status from data stores.

Leverage existing integrations. Pull real-time user access state from Okta or Azure AD via API, vulnerability posture from Tenable or Qualys, configuration compliance from AWS Config or Azure Policy, and detection coverage from your SIEM. If you're working with an existing GRC platform, unlock its hidden value through these integrations rather than replacing it.

Create effectiveness dashboards answering "is this control reducing our threat exposure?" Show coverage metrics, threat reduction (attacks prevented, estimated loss prevention), and risk areas (remaining vulnerabilities). This requires connecting your central data layer to security tooling for continuous visibility.

Step 3: Redesign Your Stakeholder Model

Shifting to threat-driven GRC Engineering requires changing who you work with and how you engage them. It’s one of the key tenets of the grc.engineering manifesto.

Schedule regular threat review sessions: weekly 30-minute syncs with Security Engineering on emerging threats, bi-weekly control effectiveness reviews with Infrastructure teams, monthly joint assessments with Threat Intelligence on attack trends, and quarterly executive briefings connecting threats to risk exposure.

Reframe your communication. Instead of "we need evidence of your access reviews for the SOC 2 audit by Friday," say "we've seen a 40% increase in credential-based attacks in our sector. Our access review control is key to reducing this risk. Can we review the current process and identify any gaps?" This positions you as a security partner, not a compliance taskmaster.

Build cross-functional working groups for weekly threat assessments (mapping emerging threats to control gaps), bi-weekly control effectiveness reviews, monthly architecture reviews, and quarterly risk committees. Measure relationship quality through response times, engagement quality, proactive partner input, and implementation success rates.

You've successfully transitioned when Security Engineering invites you to threat modelling sessions, Product teams seek your design input, control owners proactively suggest improvements, and leadership references your threat analysis in business decisions.

Conclusion

The choice between audit-driven and threat-driven security isn't just philosophical. It fundamentally shapes how you build your entire GRC Engineering practice, the systems you design, the relationships you cultivate, and the value you deliver.

For a more holistic vision on this topic, I would really recommend you check out Adrienne’s presentation at FAIRCon25 when it drops on the FAIR Institute website. She showed us why organisations need to make this shift. GRC Engineering can help with the “how”: building the automation, creating the measurement systems, and orchestrating the cross-functional collaboration that makes threat-driven security possible at scale.

Your challenge: Assess which approach currently drives your systems and relationships. Are you building to pass audits or to reduce threats?

The answer determines whether you're a compliance coordinator or a strategic security enabler.

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!