TL;DR: Opal Security says its Databricks integration turns access, ownership, approval and entitlement data into notebooks and Delta tables so teams can correlate identities, detect drift and feed recommendations back into governance workflows. The shift is from reporting on access to operationalising identity intelligence as a closed-loop control.
Editorial analysis by NHI Mgmt Group, based on content published by Opal Security: “Supercharging Identity with Opal and Databricks”.
Key questions
Q: How do IAM teams know whether access governance is working?
A: IAM teams should look for fast revocation after role change or departure, accurate entitlement data, and low numbers of orphaned or over-provisioned accounts.
Q: What is the risk of analysing access data without joining business context?
A: You get partial answers that can misclassify justified access as drift or miss redundant entitlements that only become obvious when usage, HR and cost data are combined.
Q: How can teams tell whether behavioural access analytics is actually working?
A: Look for fewer false positives on normal administrative work, more consistent escalation signals on unusual request patterns, and better reviewer confidence in high-risk cases.
Practitioner guidance
- Map access data into a governed analytics model Ingest events, user attributes, group hierarchies and owner relationships into a consistent schema so the same identity can be analysed across systems.
- Define write-back rules for governance actions Decide which outputs, such as risk scores or utilisation metrics, are allowed to trigger approval changes, reviews or entitlement updates.
- Join identity data with business context Combine access records with HR, security and cost data so teams can separate justified access from redundant or underused entitlement.
Bottom line: The core problem is not a lack of access data, but the difficulty of converting that data into governed decisions inside IAM and IGA workflows.
What's in the full article
Opal Security's full article covers the operational detail this post intentionally leaves for the source:
- Notebook-by-notebook breakdown of the Databricks accelerator and what each export job produces
- Example Delta table structures for access events, users, groups and owner objects
- Practical guidance for using Opal API and CLI outputs inside Databricks workflows
- Illustrative use cases for predictive risk scoring and licence optimisation
👉 Read Opal Security's analysis of access intelligence with Databricks →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Access intelligence becomes governance only when analysis can change control state. The article’s central value is not that access data is now visible in a notebook, but that analytic outputs can be fed back into the governance plane. That is the point where reporting stops being passive and starts influencing approvals, ownership and remediation. For IAM programmes, the architectural test is whether insight can alter the next access decision.
A question worth separating out:
Q: How should organisations separate analytics from enforcement in identity governance?
A: Use analytics to surface risk, prioritise remediation and propose actions, but keep policy intent, approval authority and final enforcement in the governance layer. That separation prevents decision drift and keeps automation aligned to accountable access policy.
👉 Read our full editorial: Opal and Databricks turn access data into governance analytics