- GRC Engineer - Engineering the Future of GRC
- Posts
- ⚙️ The Three Lines of Defence, a systems-thinking approach
⚙️ The Three Lines of Defence, a systems-thinking approach
Why your defence lines need systems thinking and shared intelligence, not just functional independence and isolated processes, a GRC Engineering approach.
IN PARTNERSHIP WITH

Prove Security and Compliance Without Delays
Showcase your security posture with a self-serve Trust Center. Get a centralized, interactive single source of truth to manage documentation and respond to requests in real time, with answers fully traceable to their source. All without the repetitive back-and-forth or last-minute requests.

For this week

What’s going on? 🔊
This week, a pretty short newsletter on a topic I love, the three lines of defence. It’s a hotly debated topic and I wanted to give my perspective, leveraging systems thinking and experience from B2B SaaS where the 3LoD are a lot less rigid than traditional industries.
I believe security GRC is breaking the gap between 1st and 2nd line and I wanted to highlight some key cross-lines synergies everyone can benefit from!

Three Lines of Defence, the Systems Fix
From rigid silos that create operational gaps to adaptive systems that compound security effectiveness over time
Your Three Lines of Defence model is creating the problems it's supposed to solve. Modern security threats don't respect organisational charts and your CISO is asking you to be more operational. Why are we still pretending rigid functional boundaries make sense in GRC outside of heavily regulated industries?
Systems thinking insight: Linear processes create delays and errors. Feedback loops create intelligence.
The fix isn't abandoning the model—it's adding the missing feedback loops that turn three separate functions into one adaptive system.

The Disconnect That's Killing Security
Security teams (1st line) implement controls but can't verify them effectively GRC teams (2nd line) write policies they can't technically understand
Internal audit (3rd line) finds gaps that could have been prevented upstream
Everyone creates parallel processes to work around each other. Remediation moves at the speed of bureaucracy, not threats.
The systems problem: Linear handoffs break feedback loops. Each function succeeds individually whilst the system fails collectively.
This creates what systems thinkers call "local optimization" - each line hits their targets whilst overall risk management degrades.
Security teams optimize for uptime, GRC teams optimize for coverage, audit optimizes for findings. Nobody optimizes for the system outcome: reduced risk.
Missing feedback loops:
Security teams don't learn how their control decisions affect enterprise risk scores
GRC teams don't see how their requirements impact operational security effectiveness
Audit findings don't inform future control design decisions
The result? Repeated failures in the same areas, because the system can't learn from its own performance.
Three Systems Interventions
1. Unified Control Dashboards
Stop maintaining separate views of the same controls. Build shared dashboards where:
Security teams see risk impact of their design decisions (feedback loop to first line)
GRC teams see operational constraints and security effectiveness (feedback from operations)
Audit sees real-time control effectiveness, not quarterly snapshots (continuous loop)
Systems principle: When all functions see the same data from different analytical perspectives, the system develops collective intelligence about control effectiveness.
2. GRC as Technical Translation Layer
Instead of independence through isolation, create independence through methodology:
GRC actively participates in remediation planning whilst maintaining testing independence
Serves as translator between compliance requirements and engineering reality
Builds control frameworks directly integrated with security workflows
Maintains separate testing protocols from implementation responsibilities
Why this works: Shared understanding creates alignment loops. When GRC understands technical constraints and security teams understand compliance context, both functions improve.
3. System-Level Success Metrics
Replace functional KPIs with system outcomes:
Instead of: "95% of risk assessments completed on time"
Better: "Mean time to remediate high-risk findings: 14 days"
Focus: How fast the system responds to threats, not individual function performance
Systems principle: Shared metrics create alignment loops. When everyone's success depends on system performance, functions naturally collaborate instead of compete.
4. Dynamic Incident Response
During security incidents, defence line boundaries dissolve:
GRC teams join technical response calls where appropriate
Security teams lead updates to enterprise risk assessments
Everyone contributes expertise where needed, regardless of "line"
Systems principle: Adaptive systems reorganize their structure based on environmental demands. Rigid functional boundaries prevent this adaptation.
Why This Works
Feedback loops: Each line learns from downstream impacts of their decisions
Systems intelligence: Collective problem-solving emerges from shared information
Adaptive response: System adjusts faster than individual functions can handoff
Partnership over obstacles: Security teams view GRC as enablers, not bureaucratic barriers
Dramatically faster remediation cycles, controls designed for effectiveness (not just documentation), and a compliance function that security teams actually want to work with.
Start This Week
Pick one control family (access management, change control, vendor risk) Create shared visibility into how that control performs across all three lines Measure system outcome (time to remediate findings) instead of functional metrics (assessments completed)
Start small, but think systemically. One functioning feedback loop will demonstrate the value and create momentum for broader transformation.
Pro tip: Don't try to change the org chart. Just change the information flows. The collaboration will emerge naturally when people can see how their work affects the whole system.
The goal isn't eliminating independence, it's creating intelligent collaboration through properly designed feedback loops.

Do you prefer shorter weekly newsletters vs. the traditional ~2,500 words ones?I want to ensure you're reading through it every week so testing a shorter format. |

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
See you next week!
Reply