By Hani Mebar | Äctvli Responsible Consulting
A colleague came to me recently with a frustration. Not a complaint, exactly — more of a “this can’t be right” kind of observation. They work in a large organisation, and during the project they wanted to get clarity on who had access to the company’s analytics environment, just because someone had the reasonable idea that maybe they should know.
What they found was a patchwork. Some tools had records. Some didn’t. A few showed users who hadn’t worked at the company for over a year. Nobody was sure who had approved the original access, or whether it was still appropriate, or whose job it was to check. (I have seen this in most of my life at every corporate environment, only one client I’ve worked with is very dilligent about clearing this out).
This is quite ‘normal’. This isn’t a story about negligence but about a gap that almost every growing company falls into, and nobody talks about until an auditor finds it.
The Problem
Let me describe the situation as precisely as I can, because I think it often gets obscured behind jargon like “IAM” or “access governance” (terms that either feel too technical or too enterprise to land with the people who are actually living with the problem).
In practice:
A new analyst (or whatever, employee) joins. Someone in IT creates their account in the data warehouse. The BI tool admin adds them to the right dashboards. The AI pipeline team gives them an API key. Over time they accumulate access to eight or ten different systems — Power BI, Snowflake, dbt Cloud, Looker, Databricks, whatever stack the company runs.
Then they leave, or move to a different team, or their role changes, etc.
HR updates the headcount. IT disables the laptop. The exit interview happens. But nobody has a process — or a system, or even a list — that connects “this person left” to “these twelve places still have their credentials.” The BI tool admin doesn’t get a notification. The data warehouse access doesn’t auto-expire. The AI API key just keeps working.
Multiply this by twenty analytical teams. By four years of growth. By every contractor, intern, and agency freelancer who ever touched the data environment.
The result is that most mid-market companies cannot answer a simple question: who has access to your data right now, and why?
And when I say most, I mean it. We have yet to meet a company of more than 200 people with a mixed analytics and AI stack that has clean, current, auditable access records. It is the norm, not the exception.
This is no good
This problem isn’t new and it has become more acute in the last two to three years for a specific reason: the AI tool explosion.
For most of the last decade, “the analytics stack” was relatively stable. Companies had a data warehouse, maybe a BI layer, a few SQL tools. The number of things to provision access to was manageable. The problem existed, but it was small enough to handle with spreadsheets and goodwill.
Things have changed though. The average data-mature mid-market company now runs somewhere between ten and thirty different tools with their own user management systems. Like the ones I mentioned above (the Databricks, dbt, Looker, Metabase, Power BI, Tableau, Hex, Mode, Notion, OpenAI API keys, Azure OpenAI deployments, internal RAG systems, custom analytics applications). Each one has its own admin, its own permission model, its own user table.
And each one is typically governed by the team that introduced it — which means there are fifteen different access policies, none of them connected, and none of them talking to HR.
Every new tool that gets added is another place where access can linger after someone leaves.
This is also, increasingly, a compliance problem. If your company is in scope for NIS2 — and if you’re a mid-sized European company, there’s a good chance you are — then having documented, reviewable access controls isn’t optional. It’s a requirement. An auditor asking “show me your access control policy and evidence it’s being enforced” is not a hypothetical. It’s a scheduled event.
How We Thought About It
After that initial conversation, and reminiscing on how I’ve seen this everywhere Ive worked (mind you, not in ICT but even just in regular operational roles) so I spent some time thinking about whether this was a solved problem that people just weren’t implementing, or a genuinely unserved gap.
I think it really depends on the size of the company.
For large enterprises — banks, telcos, major manufacturers — this problem is handled by Identity Governance and Administration (IGA) platforms. Products like SailPoint, Saviynt, and Omada exist specifically for this. They are comprehensive, deeply configurable, and genuinely effective.
They are also enormously expensive, require dedicated implementation teams, take six to eighteen months to deploy, and are designed for IT estates of thousands of systems, not the analytics-and-AI-focused stack of a 200–800 person company.
The mid-market company trying to govern access to twelve BI and AI tools is left with a gap. Too big for spreadsheets. Too small for SailPoint.
I also looked at the HR software direction (platforms like Rippling and BetterCloud) that do automated provisioning for SaaS tools. By the way, to be clear whne I say ‘I looked into’, I mean I grabbed my AI machine, and used a bunch of my agents to find exactly what I needed, and then broke it down to the lower level problems and issues that could be resolved, and sparred etc.. ).
Back to the point, those HR softwares solve part of the problem well: connecting HR events to common SaaS apps like Slack, Google Workspace, and Salesforce. But they are built around general SaaS tools, not around the data and analytics layer specifically. They don’t “natively” speak Metabase, dbt Cloud, Databricks, or Snowflake role-based access. The connector gap is significant.
Nobody has built a purpose-fit governance layer for the modern analytics and AI stack, designed for mid-market price points and timelines.
That’s what I kept coming back to, and I just thought “hmmm, is there a market for this?”
The Brainstorm: What Would Actually Solve This?
We (I say ‘we’ because now I am speaking as Äctvli, which is me and my 12 agents and tools) started sketching what a real solution would look like — not an enterprise IGA platform, not a general SaaS provisioning tool, but something designed specifically for this problem.
The core idea is simple. The HR system should be the source of truth for access. When someone joins, the access they’re entitled to — based on their role and team — gets provisioned automatically across every connected tool. When they change role, their access updates. When they leave, it’s revoked. Not eventually. Not manually. Automatically, with a full audit trail.
The key design decisions we kept landing on:
Define once, enforce everywhere. An “analyst” role shouldn’t have to be configured in Tableau and Power BI and Metabase and dbt Cloud separately. You define what an analyst gets access to — across all tools, at the right permission level for each — in one place. The system handles the rest.
Don’t abstract the permissions model. One of the failure modes of generic IAM tools is that they try to map “viewer” in one tool to “viewer” in another, as if they’re the same thing. They’re not. A Tableau Creator is a completely different thing from a Metabase admin. We’d want the policy editor to show you each tool’s native access levels — not a false abstraction that causes silent misconfiguration.
Treat the audit trail as a first-class feature. Every provisioning action, every deprovisioning event, every access change — logged, searchable, exportable. Not as an afterthought, but as one of the primary outputs of the system. Because when an auditor asks, you want to be able to show exactly what happened, when, and why.
Built for the modern data stack first. Metabase, Looker, Power BI, Tableau, dbt Cloud, Notion — not just the generic SaaS tools. This is where the access governance gap is widest.
We also thought carefully about what the right entry point would be. Not a six-month implementation project. Something you could install, connect to your HR system, connect to your first two or three tools, and see value from within a week or two. A governance tool should be fast to demonstrate, not slow to justify.
What We’re Not Doing (Yet)
In the spirit of being honest about where we are: we’re not building a full enterprise IAM platform. That’s not the problem we’re trying to solve, and the companies that need that already have options.
We’re also not pretending that this is a technology problem first and foremost. In our consulting work — through Custodia, our ISMS and security practice — we’ve seen plenty of companies that have the tooling and still have chaos, because the governance model underneath is broken. The roles aren’t defined. Nobody owns the process. Access reviews don’t happen because nobody is accountable for them.
Any solution to this has to be a governance design problem and a tooling problem solved together. That’s the combination we’re interested in.
We Think We Can Build This. But We Need You First.
This is where it all kinda sorta get tricky for us.
We have a clear picture of the problem. We have a technical architecture we’re confident in. We have a consulting methodology — the service design piece — that we know works, because we’ve delivered versions of it as standalone ISMS engagements.
What we don’t have yet is a live customer running the full end-to-end product in a real environment.
That’s what we’re looking for.
If you’re running a mid-market company — roughly 50 to 500 people, with more than ten BI or AI tools in your stack — and you’ve never done a formal access review, or you have and it was painful, I’d genuinely love to talk.
We’re not asking for a long commitment. What we’re proposing is a Rapid Scan — five days, a structured look at your current access landscape, a report on what we find, and a conversation about what fixing it would look like. If we can help, we’ll be honest about it. If we can’t, we’ll tell you that too, and you’ll have a clearer picture of your exposure regardless.
This is how we build things at Äctvli. Not in the abstract. In the real.
A Note on the Bigger Picture
This is, in one sense, a very specific and technical problem. But I think it connects to something broader that runs through most of the work we do here.
Governance problems — whether they’re about ESG reporting, OKR execution, or information security — almost always share the same root structure. Something important is happening without a defined owner, a clear process, or a way to verify it’s working. The organisation grows, the complexity compounds, and eventually someone asks a question that should have a simple answer and discovers that it doesn’t.
Data access governance is one instance of that pattern. HR and IT are two different systems with two different owners, and nobody was ever explicitly tasked with keeping them in sync as the analytics stack grew. That’s not a failure. It’s just what happens when companies scale faster than their processes.
What matters is recognising it — and deciding to fix it intentionally, rather than waiting for the auditor.
Hani Mebar is the founder of Äctvli Responsible Consulting. Äctvli works with mid-market organisations on security governance (Custodia), supply chain integrity (Tryggvi), transformation and execution (Praeceptor), and ESG strategy (Vigilantia). If any of these feel relevant to your organisation, start here.