- GRC Engineer
- Posts
- ⚙️ GRC Team Topologies: When to Centralise, Distribute, or Build Platform Models
⚙️ GRC Team Topologies: When to Centralise, Distribute, or Build Platform Models
The Decision Framework from 150+ GRC Leader Conversations + Step-by-Step Implementation Roadmap for Building Teams That Scale
Ayoub Fandi
July 03, 2025
Your GRC team is either the bottleneck everyone complains about or the scattered group that can't agree on what "high risk" means.
Sarah runs a centralised GRC team at a 2,000-person fintech. Every compliance request flows through her team of 8 people. Engineering teams wait weeks for approvals. Her inbox has 247 unread messages, all marked "urgent."
Across town, Maria embedded GRC specialists directly into each business unit. Fast decisions, happy stakeholders, but three different teams rated the same vulnerability as "critical," "medium," and "not applicable." Her board presentation looks like it came from three different companies.
Both failed for the same reason: they picked an architecture by accident, not design.
Just like engineering teams learned that you don't choose microservices OR monoliths, you choose the right pattern for each situation.
IN PARTNERSHIP WITH
Supply Chain Detection and Response tackles your core GRC challenge
Maintaining continuous visibility across hundreds of vendors. We provide factor-based security ratings, automated assessments based on threat intelligence, and response capabilities to address vulnerabilities before they trigger findings.
Our platform eliminates manual collection processes while delivering the documentation required for audit evidence. Explore how we can help your enterprise.
Why It Matters 🔍
The why: the core problem this solves and why you should care
This isn't just about org charts. Poor GRC architecture is actively undermining your security posture.
When GRC teams are organised wrong, critical things break:
The Ivory Tower Problem creates disconnect between policy and practice. Engineering teams route around GRC processes to meet deadlines, treating compliance as a tax on innovation. Your documented controls exist primarily in slides whilst actual systems remain vulnerable.
The Scattered Chaos Problem generates opposite failures. Risk assessments for identical scenarios produce wildly different conclusions. Audit evidence tells contradictory stories across business units. Remediation efforts either duplicate work or leave dangerous gaps.
Organisations with poor GRC architecture spend significantly more time on compliance whilst achieving worse security outcomes. Companies that architect intentionally achieve faster response times and reduced audit preparation time.
The difference between success and failure isn't your GRC platform or your control framework. It's how you organise your people and processes.
# Most GRC team architecture decisions
def organize_grc_team():
if "we're growing fast":
return add_more_people_to_central_team()
elif "central team is overwhelmed":
return scatter_people_everywhere()
else:
return pray_current_setup_scales()
# What actually works
def architect_grc_function(context):
reporting_structure = assess_organisational_dynamics()
program_drivers = identify_compliance_vs_risk_focus()
maturity_level = evaluate_current_capabilities()
return design_hybrid_model(
central_platform=reporting_structure,
embedded_specialists=program_drivers,
clear_interfaces=maturity_level
)
Strategic Framework 🧩
The what: The conceptual approach broken down into 3 main principles
Your Reporting Structure Determines Your Architecture Options
Where your GRC team sits in the organisation fundamentally changes what architectural patterns are even possible. If you report to Legal but try to implement distributed GRC specialists embedded in engineering teams, you'll create irreconcilable conflicts between reporting relationships and operational needs. Your architecture must work with your organisational reality, not against it.
The most successful GRC functions under CISOs use what I call the Platform Pattern. They maintain central shared services for policy development and framework management while embedding specialists who have clear reporting lines to security leadership. These embedded specialists work closely with their host teams but maintain consistency through standardised interfaces and regular coordination with the central platform.
Your Program Driver Shapes Your Coordination Requirements
Understanding what's actually driving your GRC program determines how much flexibility you have in organisational design. Most organisations think they're compliance-driven when they're actually trying to be risk-driven, and this mismatch creates architectural confusion that explains why so many GRC teams feel stuck between conflicting requirements.
If your program is genuinely compliance-driven, your primary goal is passing audits and maintaining certifications. This requires following prescribed frameworks consistently, which naturally favors centralised architectures where standardization is easier to maintain. You need everyone interpreting requirements the same way, which is much simpler when everyone reports to the same team with the same training.
Control coverage programs focus on comprehensive security control implementation across all systems and processes. This approach requires both breadth and depth, making hybrid platform models most effective. You need central coordination to ensure nothing falls through the cracks, but you also need embedded expertise to handle the technical complexity of different domains.
Risk-driven programs exist to enable informed business decisions, which means they must be close to actual decision makers. This naturally favors distributed models where GRC specialists understand the specific context and constraints of their host teams. However, this only works if you can maintain consistency in risk assessment methodologies across distributed teams.
The Platform Pattern: Central Services + Embedded Specialists
The Platform Pattern combines centralisation's consistency with distribution's responsiveness. Central Platform Services handle policy development, tool evaluation, and executive reporting. Embedded Specialists manage domain-specific risk assessments, stakeholder relationships, and real-time monitoring. Clear Interfaces include standardized communication protocols and shared data models that prevent coordination chaos.
This isn't just theory. It's how the most successful GRC programs build on previous architecture work from "From Silos to Systems" while implementing the Human API concepts we've discussed.
Automate your SDLC Governance with Kosli
Are you delivering software in a regulated industry? Know the pains of ensuring supply chain security, change management, and runtime monitoring? Kosli automates all of the governance tasks in your software delivery process, giving you speed, security, and audit-ready proof—at scale.
Execution Blueprint 🛠️
The how: 3 practical steps to put this strategy into action at your organisation
Step 1: Diagnose Your Current Architecture Reality
Understanding your architecture reality requires honest assessment of constraints and pain points. Your organisational context sets boundaries: fewer than 3 GRC FTEs makes distributed models impossible, reporting to Legal creates embedding conflicts, and Three Lines of Defence requirements limit distribution options.
Your current pain points reveal which direction to move. Centralised bottlenecks need distributed capabilities. Distributed inconsistency needs central coordination. Interface problems need embedded relationships.
Architecture Readiness Score:
Rate your organisation (1-5 scale):
Technical maturity for automation/integration
Management support for organisational change
Current GRC team capability and bandwidth
Stakeholder relationship quality across teams
Existing tooling and process standardisation
Scores 3 or below indicate you should start with simpler patterns and evolve gradually.
Step 2: Choose Your Architecture Pattern Using Decision Framework
Choosing the right pattern requires understanding constraints and desired outcomes. Size and complexity form the foundation: organisations under 500 employees typically lack resources for distributed models, while 500-2,000 employee companies hit the sweet spot for hybrid platforms.
Organisational maturity determines feasibility. Low technical maturity should start with centralised patterns and evolve gradually. Program drivers shape sustainability: highly regulated industries with strict independence requirements struggle with distributed models because you can't have the same person implementing and testing controls.
Step 3: Implement Your Architecture Transition
Your Implementation Progress:
┌─ PHASE 1: FOUNDATION ─────────────────────────────────────────┐
│ ████████████████████████████████████████████████████████████ │ 100%
│ ✅ Policies standardised ✅ Tools consolidated ✅ Protocols defined │
└───────────────────────────────────────────────────────────────┘
┌─ PHASE 2: EMBEDDING ──────────────────────────────────────────┐
│ ████████████████████████████████████████░░░░░░░░░░░░░░░░░░░░ │ 75%
│ ✅ Specialists selected ✅ Pilot teams chosen 🔄 Dual reporting │
└───────────────────────────────────────────────────────────────┘
┌─ PHASE 3: SCALING ────────────────────────────────────────────┐
│ ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │ 25%
│ 🔄 Automation building ⏳ Feedback loops ⏳ Full deployment │
└───────────────────────────────────────────────────────────────┘Implementation requires phased approach building capabilities gradually. Phase 1 establishes platform foundation: standardise policies, implement shared tooling, create communication protocols. Success means 80% stakeholder understanding and 50% tool consolidation.
Phase 2 involves strategic embedding in 2-3 high-value teams with dual reporting relationships. Avoid micromanaging embedded specialists since the point is faster, contextual decision-making. Target 50% response time improvement and 90% decision consistency.
Phase 3 scales based on pilot learnings while implementing automated workflows and feedback loops. Aim for 70% organisation-wide response time improvement and 60% audit preparation reduction.
Common Implementation Pitfalls:
Anti-Pattern | Warning Signs | Prevention Strategy |
|---|---|---|
"Shadow GRC" | Teams creating their own compliance processes | Clear decision authority, regular audits |
"Coordination Hell" | More meetings than actual work | Async communication, automated coordination |
"Platform Bloat" | Central team trying to control everything | Regular service value assessment, ruthless prioritisation |
This builds directly on the Central Data Layer concepts we discussed. Your organisational architecture must support your data architecture, and both must serve your stakeholder needs efficiently.
Did you enjoy this week's entry? |
Content Queue 📖
The learn: This week's resource to dive deeper on the topic
"Team Topologies" by Matthew Skelton and Manuel Pais
This book revolutionised how technical organisations think about team design. Their four fundamental team types map perfectly to GRC organisational patterns:
Stream-aligned teams (Product/Engineering) need compliance support, not compliance overhead
Platform teams (Central GRC) should reduce cognitive load for stream-aligned teams
Enabling teams (Embedded GRC specialists) help other teams adopt new capabilities
Complicated-subsystem teams handle specialized domains requiring deep expertise
Key insight for GRC: Your compliance architecture should mirror your communication structure. If your GRC team doesn't talk to engineering regularly, your controls won't work in practice.
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 Engineering Podcast
See you next week!
Reply