- GRC Engineer
- Posts
- ⚙️ Designing Controls Where Compliance is an Afterthought
⚙️ Designing Controls Where Compliance is an Afterthought
Transform compliance-driven GRC programs into security-first systems that reduce business risk, automate evidence collection, and earn executive trust
Ayoub Fandi
June 19, 2025
Most controls are designed to satisfy auditors first, and protect against real risks second. This backwards approach is why your GRC program feels like security theatre.
The best GRC programs design controls that happen to satisfy compliance requirements, not controls that exist to satisfy compliance requirements.
What's the difference?
Compliance-driven controls ask: "What does the framework require?" Risk & security-driven controls ask: "What threats and business risks does this actually mitigate?"
The magic happens when you flip this priority. When you design controls to address real security threats and business risks, compliance becomes a natural byproduct instead of the primary objective.
Your organization rewards compliance theater because that's what you've optimized your controls to deliver.
Ready to build controls that actually defend and protect?
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
Most GRC professionals are trapped in what I call the "Compliance-First Control Design Trap."
You're excellent at creating controls that pass audits: policies that check boxes, procedures that generate evidence, and monitoring that produces screenshots. But your controls optimize for audit satisfaction, not threat prevention and business risk reduction.
The Control Design Crisis
Control Example | Compliance Theater | Actual Impact |
|---|---|---|
MFA Implementation | "Enabled" in SSO settings | Reality: VPN, legacy systems, and service accounts bypass it entirely |
Access Reviews | Quarterly sign-offs completed | Reality: Critical privileged access unreviewed for 8+ months |
Vulnerability Management | Weekly scans running | Reality: 47 critical vulnerabilities "accepted" due to "business justification" |
Application Security | WAF deployed and "monitoring" | Reality: Monitor-only mode prevents zero attacks |
Code Security | SAST in CI/CD pipeline | Reality: 127 critical findings marked "will not fix" |
The strategic problem: When compliance drives your control design, you optimize for audit evidence instead of threat prevention.
This isn't about abandoning compliance - it's about building integrated GRC systems that naturally produce compliance while actually defending against real threats and business risks.
# Traditional compliance-driven approach
def design_control_for_audit():
requirement = parse_framework_requirement("SOC 2 CC6.1")
control = create_policy_document(requirement)
evidence = generate_screenshot_collection()
return control_that_satisfies_auditor()
# Integrated GRC approach
def design_control_for_security_and_risk():
threats = analyze_threat_landscape()
business_risks = assess_material_business_risks()
for risk_or_threat in combine(threats, business_risks):
preventive_control = engineer_threat_prevention(risk_or_threat)
detective_control = implement_risk_monitoring(risk_or_threat)
governance_control = establish_decision_framework(risk_or_threat)
# Compliance alignment happens automatically
compliance_mapping = verify_framework_coverage(preventive_control)
return control_that_mitigates_threats_and_risks()
Strategic Framework 🧩
The what: The conceptual approach broken down into 3 main principles
1. Threat & Risk-Informed Control Architecture
The Philosophy Shift: Design controls based on what actually threatens your business, not what frameworks require.
Traditional approach: Read SOC 2 requirement → Design Controls → Hope it helps → Generate audit evidence.
Integrated GRC approach: Analyze real threats → Design protective capabilities → Validate effectiveness → Compliance naturally follows.
The insight that changes everything: Attackers don't read your compliance framework. They exploit gaps in your actual defences.
2. The Control Design Hierarchy
Stop building controls that optimize for the wrong outcome:
Control Purpose | Effort to Build | Effort to Evidence | Business Protection |
|---|---|---|---|
Threat Prevention | High | Low | Maximum |
Risk Reduction | Medium | Low | High |
Risk Visibility | Medium | High | Medium |
Compliance Theatre | Low | High | Minimal |
The best programs invest in threat prevention and risk reduction controls that naturally generate evidence, not compliance documentation that hopes to prevent threats.
3. Common Controls Framework (CCF) Implementation
Instead of implementing "SOC 2 controls" and "ISO 27001 controls," implement "our security baseline" that maps to whatever frameworks you need.
The breakthrough: Your evidence comes from security systems (SIEM, vulnerability scanners, identity platforms) that serve operational decisions AND compliance requirements. One control design, multiple framework satisfaction.
GRC pros don’t have time to play document detective.
Vendict’s AI mines your source materials to auto-generate precise, policy-aligned answers, without hallucinations.
Security reviews go from blocker to enabler.
Execution Blueprint 🛠️
The how: 3 practical steps to put this strategy into action at your organisation
Step 1: Conduct a Control Security & Risk-Alignment Audit
Before redesigning controls, understand whether your current controls actually prevent threats and reduce business risks, or just satisfy audit requirements.
The Integrated GRC Effectiveness Assessment:
Assessment Question | Compliance-Driven | Security & Risk-Driven | Your Score |
|---|---|---|---|
Primary design driver? | Framework requirement | Threat prevention + business risk reduction | ___ |
Success measurement? | Audit finding closure | Security incidents prevented + risk impact reduced | ___ |
Evidence collection focus? | Documentation completeness | Security effectiveness + risk reduction validation | ___ |
Control owner motivation? | Avoid audit findings | Prevent threats + reduce business exposure | ___ |
Implementation priority? | Auditor satisfaction | Threat elimination + risk governance | ___ |
Scoring: 0-2 responses means your controls optimize for auditors, 3-4 means you're transitioning to integrated GRC design, and 5 means your controls naturally defend, govern risk, and enable compliance.
Step 2: Implement the Integrated Threat & Risk-to-Control Design Process
Transform your control design methodology from compliance-driven to security and risk-driven through three phases.
Phase 1 focuses on threat and risk assessment by documenting realistic security threats and material business risks, mapping likely scenarios with potential impact, and analyzing threat-risk interdependencies and cascade effects.
Phase 2 centers on integrated security and risk control engineering. For each threat and material business risk, you design controls that prevent threats from materializing, implement controls that reduce business risk exposure, create monitoring capabilities that provide early warning and decision support, and validate effectiveness through security testing and business impact measurement.
Phase 3 ensures compliance alignment through a Common Controls Framework (CCF) approach. Instead of designing controls to meet specific requirements like SOC 2 CC6.1 or ISO 27001 A.9.1.1, you map your security and risk controls to whatever frameworks your business requires. The real power here is that your data sources become security and risk-driven rather than compliance-driven - you're pulling real-time security metrics from your SIEM, vulnerability scanners, and identity management systems that serve both operational security decisions AND compliance evidence generation.
Step 3: Build Integrated Security & Risk-Informed Control Testing
Traditional control testing asks "Does this control exist?" while integrated GRC testing asks "Does this control prevent threats AND reduce business risks it's designed to address?"
The Testing Transformation:
Control Category | Compliance Testing | Security & Risk-Driven Testing |
|---|---|---|
Access Control | "MFA is enabled" | "Does our access management prevent unauthorized access AND reduce insider risk?" |
Vulnerability Management | "Scanning runs weekly" | "Are we preventing exploitable attacks AND reducing operational risk?" |
Data Protection | "Encryption policy exists" | "Is sensitive data protected from threats AND breach-related business risks?" |
Business Continuity | "DR plan documented" | "Can we maintain operations during attacks AND business disruptions?" |
Monitoring & Detection | "Logs are collected" | "Do we detect security threats AND identify business risk indicators?" |
Your turn: Look at your three most critical controls right now. If an attacker wanted to compromise your organization, would these controls actually stop them, or would they just generate good audit evidence while the attack succeeds?
Did you enjoy this week's entry? |
Content Queue 📖
The learn: This week's resource to dive deeper on the topic
In this great conversation with Justin Pagano, we’ve discussed in-depth how to get above and beyond compliance and use actual security as the baseline for building your controls catalogue.
Justin is very sharp and has been one of the key (I argue the key) contributor to the grc.engineering manifesto so you should definitely have a listen!
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