How I Built a SIEM for Auditors. And What I Learned About Moving Across Silos

When I started working at my current place of work, I inherited
a problem: how do you efficiently conduct access control reviews?
The answer was: we didn't have one.
Every quarter, the audit team manually requests for access reports from Active
Directory, waded through spreadsheets in Excel looking for orphaned accounts,
excessive permissions, stale access. It was slow, error-prone, and it treated
security and audit like separate worlds.That's when I realized I have the tools to solve this.

I've spent five years in cybersecurity—threat detection, SIEM engineering,
log analysis. I'm comfortable deploying and building detection systems in Elasticsearch,hunting anomalies across millions of events.
But access control audits? That's a different language. Different frameworks and standards(ISO,COSO, internal policies), different stakeholders, different success metrics.The security team thinks about threats. The audit team thinks about controls.They rarely speak to each other So I decided to build a bridge.

I integrated Active Directory with Elasticsearch and built detection rules:
- Accounts with no recent logons (orphaned accounts)
- Users with excessive permissions across systems
- Rapid permission grants (possible misconfigurations)
- Group membership changes that didn't match workflows

Then I created dashboards to translate it into audit language:Access Review
Summary,User Access Lifecycle,Permission Trend Analysis.

For the first time, audit could see what security saw.
Here's what I didn't expect:building the system was easy. Getting people to
use it was hard.

I presented the dashboards to the audit team. I was proud of the Elasticsearch configuration, the ML anomaly detection, the real-time data ingestion and One of the audit managers asked:Can you just tell me which accounts are risky?

That question broke something open for me. She didn't want to understand
the SIEM. She wanted to understand the risk.And I was speaking a different language So I rebuilt it—not the system,but how I presented it.

Instead of "Elasticsearch ingest pipeline with anomaly detection,"I said:
"Automatic flagging of high-risk access patterns you should review."

Instead of technical depth, I provided business context: "This matters because control gaps lead to compliance failures.When I presented to my manager—who does have the technical background—he understood the dashboards immediately.But even he appreciated it when I framed it around business impact,not engineering details.

That's when I realized the real lesson: being excellent at solving the problem isn't the same as being effective at solving itbecause Six years in security made me a good engineer but that wasn’t enough.

I was so focused on building the perfect system, I didn't ask:Who am I building this for? What do they need? How do they think?

That's not a security lesson. That's a leadership lesson.
And I suspect a lot of us in technical roles miss it. We assume technical
excellence speaks for itself,We assume smart people will understand complexity,We assume our way of thinking is the right way.

If you're a SIEM engineer, threat hunter, or security analyst: your technical
skills matter. But they're not enough