Introduction
I spent years writing code. Then I sold things. Now I'm pivoting to GRC (Governance, Risk, and Compliance) in cybersecurity. Here's what I learned about Detection and Incident Response that most people don't talk about.
The Reality Most Miss
Detection isn't just logs and alerts.
Most developer documentation treats detection as "set up your SIEM and you're done." That's wrong. Real detection requires understanding three layers:
- Technical signals (what your tools see)
- Behavioral patterns (what normal looks like for YOUR environment)
- Business context (why something matters beyond the alert)
You can have the best log aggregation in the world. If you don't understand which assets actually matter to your business, you're drowning in noise.
Incident Response: The Uncomfortable Truth
When I was a programmer, I thought IR was about containment and fixing the bug. In GRC terms, it's messier:
| Technical View | GRC Reality |
|---|
| Patch the vulnerability | Document who knew what when, regulatory notifications needed, board-level communication |
| Block the malicious IP | Preserve chain of custody for potential litigation, customer impact assessment |
| Restore from backup | Legal review before restoration (could destroy evidence), privacy considerations |
Your playbook needs to account for both. A purely technical response without compliance awareness can expose your organization to legal risk. Just as a purely compliance-first approach can let an attacker maintain persistence.
What Developers Bring to GRC That Lawyers Don't Understand
Coming from a coding background into GRC, here's where I see gaps:
- Automation culture: We document manually when we should script our governance checks. Why write a quarterly audit report you'll rewrite next quarter? Automate it.
- API-driven thinking: Your controls can be tested programmatically. Infrastructure as Code meets Control as Code.
- Debugging mindset: When a control fails, treat it like a bug. Root cause analysis, fix, prevent recurrence. Not "someone didn't check the box."
The Detection Stack Every Dev Team Should Know
For teams building detection capabilities, keep it practical:
- Baseline first: Define normal before looking for abnormal
- Correlation over volume: 10 relevant logs beat 10,000 irrelevant ones
- Playbook readiness: Can your team execute the response without stopping to figure out who has authorization?
- Feedback loops: Post-incident reviews that actually change behavior
My Personal Pivot
At 53, making a career shift to GRC wasn't easy. The temptation is to position yourself as someone who "understands tech better than compliance people." Wrong game. The value is being a bridge—translating between engineering reality and governance requirements.
Both sides speak different languages. Both are right from their perspective. Your job is making sure neither gets ignored when lives depend on it.
The Bottom Line
Detection and Incident Response aren't separate domains. They're part of the same system. If you're a developer moving into security or compliance work, you have a unique advantage: you know how systems actually work under the hood. Use that knowledge wisely.
And if you're in traditional GRC reading this: talk to your engineers. They won't tell you everything upfront, but they'll answer your questions if you ask the right way.
