u/stinenwrit

Been going down a rabbit hole on this lately after the 2026 DTEX Insider Threat Report dropped, showing average insider incident costs hitting $19.5M. The negligence piece is what gets me - shadow AI and accidental misuse are, consistently showing up as the dominant risk drivers, outpacing malicious actors as the primary vector. From a GRC angle that's a real problem because your traditional rule-based controls just aren't built to catch that kind of drift. You can't write a policy rule for "employee pasted sensitive data into a gen AI tool they found on Product, Hunt." We've been looking at a few platforms and the behavioral analytics side is genuinely impressive when it's tuned properly. The anomaly correlation across identity and data access signals has actually reduced the triage noise our team deals with. But I keep hitting the same wall - only 37% of orgs apparently have formal AI governance policies despite the majority already deploying gen AI in, security contexts, and without that integration into your broader Zero Trust and access governance model it really does just become another monitoring layer that nobody acts on. The part I'm still working through is the cost justification. For mid-size environments the subscription costs can get uncomfortable fast, and if your SOC doesn't have the capacity, to action the alerts properly you've basically paid a lot of money to document problems you can't fix. The newer predictive capabilities are interesting though - early intervention weeks before a breach actually occurs is a different ROI conversation than pure detection and reporting. Microsoft Purview extending DLP to AI agents is worth watching from a compliance standpoint since it at least fits into frameworks we're already operating in. But I'm curious whether teams are finding these platforms actually move the needle on prevention, or if most of the value is still sitting on the detection and reporting side. Anyone here deployed something like this and actually got it to the point where it's reducing incident costs rather than just surfacing them?

Something I keep running into is orgs that have a solid GRC platform running, dashboards look great, evidence is auto-collected, frameworks are mapped. And then an auditor starts asking whether the controls actually work and it all kind of falls apart. The tool documented everything but nobody verified anything. That's what I'd call compliance theater and it's more common than people admit, even as platforms get more sophisticated. The way I think about it now is that a GRC tool is infrastructure. It gives you a place to centralise risk, automate evidence collection, map controls across frameworks, report upward. All genuinely useful stuff, and with the current wave of AI and continuous control monitoring being baked into more platforms, that infrastructure is getting genuinely powerful. But a compliance program is the operating model that sits around it. Who owns each control? Who's verifying it's functioning, not just documented? What happens when a control fails? A tool can't answer those questions on its own, and most still can't enforce ownership accountability without a human process behind them. Regulators right now are increasingly focused on outcomes and actual control effectiveness rather than documentation completeness, which is pushing this conversation harder than ever. It forces the question past "we have a platform" into "here's proof it works." The gap shows up most obviously during access reviews. You can have a tool generating the review campaigns automatically, but if business owners are, rubber-stamping everything without actually looking, the tool just made your rubber-stamping faster and more organised. The program is the part where someone is accountable for the quality of those decisions, not just the existence of them. So what does your setup look like - do you feel like your tool and your program are genuinely aligned, or is one carrying the other?

The dbt Labs 2026 State of Analytics Engineering report dropped recently and one finding stuck, with me: AI adoption in analytics is outpacing the trust and governance infrastructure underneath it. That's not a new observation, but seeing it quantified across that many practitioners makes it harder to dismiss as a niche concern. The report puts AI-assisted coding at 72% while only about a quarter of teams are prioritizing AI for, pipeline management and governance, which is a pretty stark gap when you see it laid out like that.

From a blue team perspective this isn't just a data quality problem. When AI pipelines are ingesting, transforming, and serving data at speed, the question of whether sensitive, data is even supposed to be in that pipeline often doesn't get asked until something goes wrong. The governance layer, knowing what data exists, where it lives, and who can touch it, is being treated as a post-hoc audit exercise rather than a prerequisite. That gap is where your exposure lives.

I've been thinking about this partly because we've been evaluating tooling in this space, including Netwrix Data Discovery & Classification, and, what's clear is that most teams don't have a reliable baseline inventory of their regulated data before AI tooling starts touching it. You can't govern what you haven't mapped.

The dbt report framing is interesting because it comes from the analytics engineering side, not security. These are people who care about pipeline reliability and model trust, and even they're flagging this. That suggests the problem is visible across disciplines now, not just compliance teams doing annual audits.

Not sure what the right operational response looks like at scale. Classification before ingestion seems obvious but the tooling to do that continuously in hybrid environments is still pretty immature.