Entitlements drifted across tools; Okta–Snowflake roles, row policies, and masking governed finance data access

Overview

A financial services firm lacked consistent control over who could access sensitive finance data because entitlements were managed differently in each tool. Analysts pulled detailed extracts from the data warehouse and BI, ad hoc groups in the identity provider drifted, and approvals lived in email. Intelligex implemented fine?grained permissions using Okta for identity and Snowflake for role?based and policy?based access, added field?level masking for personally identifiable information (PII), and stood up auditor?friendly monitoring with finance approvals for exceptions. Access requests became faster to adjudicate, exceptions decreased, and auditors saw clear governance—while the ERP, BI, identity provider, and data warehouse remained in place.

Client Profile

• Industry: Financial services (asset management and lending)
• Company size (range): Multi?entity, multi?region operations with centralized Finance
• Stage: Okta as identity provider; Snowflake as the finance data platform; NetSuite and subledgers as sources; Tableau and Power BI for analytics; access approvals and certifications handled via email and spreadsheets
• Department owner: Finance & Accounting (Controllership and Finance Operations)
• Other stakeholders: FP&A, Treasury, Risk, Internal Audit, IT/Security, Data Engineering, Legal/Privacy, External Auditors

The Challenge

Access to finance data was inconsistent across tools. In Snowflake, broad roles exposed detailed tables to users who only needed aggregates. In BI, embedded credentials bypassed table?level controls, and extracts circulated by email. ERP and subledger data arrived with PII fields intact, and masking was applied unevenly in transformation jobs. Ad hoc Okta groups were created to meet deadlines, then never pruned. When teams needed temporary access to close data or board materials, approvals were captured in threads with attachments rather than in a repeatable workflow.

Audit and privacy pressures mounted. Internal Audit needed evidence that only approved users could see sensitive data and that access changes were reviewed by Finance. Privacy partners asked for clear treatment of bank accounts, taxpayer IDs, and employee details. Access certifications were run as one?off campaigns that did not line up with organizational changes, and revokes lagged transfers and departures. Investigating an incident required stitching together logs across Okta, Snowflake, and BI.

Why It Was Happening

Root causes were fragmented entitlements and no canonical policy model. Okta groups mirrored historical reporting lines rather than data domains, and Snowflake roles grew organically around projects. BI tools cached datasets without inheriting warehouse controls. There was no jointly owned registry that defined which roles could see which finance domains, what masking applied to which fields, and how exceptions flowed for review. Email approvals and spreadsheets carried the burden of governance.

Timing and ownership were misaligned. IT provisioned accounts, Data Engineering granted warehouse access, Finance defined what was sensitive, and Audit assessed after the fact. Without a shared access workflow and evidence trail, fast answers to “who can see this?” or “who approved that?” were hard to provide, and exceptions accumulated.

The Solution

Intelligex delivered a governed access model that centralized identity in Okta, enforced fine?grained controls in Snowflake, and added review and monitoring tailored to Finance. Okta groups were aligned to finance data domains, with lifecycle automation and break?glass rules. In Snowflake, role?based access control (RBAC) defined which roles could view schemas and tables, row access policies limited data by entity and region, and dynamic masking protected sensitive fields. Access requests and exceptions flowed through a Finance?owned workflow with maker?checker approvals. Monitoring pulled from Snowflake Access History and Okta audit logs to produce auditor?friendly reports. The design leveraged Okta Identity Governance concepts (Okta Identity Governance) and Snowflake features including column?level security and dynamic data masking (Snowflake Dynamic Data Masking) and access history (Snowflake Access History).

• Integrations: Okta for identity and group membership; Snowflake for RBAC, row policies, and masking; ERP and subledgers as sources; BI tools configured to use Snowflake roles; notifications to collaboration tools for approvals and alerts.
• Role and group model: Finance?owned roles mapped to domains (general ledger, subledger, payroll, treasury) with legal entity and region attributes; Okta groups synchronized to Snowflake roles and databases.
• Row and field controls: Row access policies applied by entity and region; dynamic masking for PII and confidential finance attributes; clear separation of duties for administrators and approvers.
• Access request workflow: Standard catalog of access packages; maker?checker approvals routed to Finance owners; expirations for temporary access; exception reason codes captured.
• Monitoring and reporting: Scheduled extracts from Okta and Snowflake audit logs; dashboards showing who has access to what, recent changes, and high?risk queries; evidence packs curated for Internal Audit.
• Data tagging and lineage: Object tags in Snowflake marking sensitivity and ownership; BI connections updated to inherit warehouse roles; lineage from user to query to dataset tracked.
• Security and privacy: Role?based access enforced end?to?end; least privilege defaults; break?glass with time?bound tokens and post?use review.

Implementation

• Discovery: Cataloged current Okta groups, Snowflake roles, and BI connections; inventoried sensitive fields and privacy obligations; reviewed recent access approvals and incidents; gathered audit requirements and finance ownership for data domains.
• Design: Defined the finance domain role model and attribute rules; mapped Okta groups to Snowflake roles and databases; authored row policies and masking rules with effective dating; specified approval paths and exception codes; designed monitoring dashboards and evidence packs.
• Build: Implemented Okta group restructuring and lifecycle automation; configured Snowflake RBAC, row access policies, dynamic masking, and object tags; updated BI connections to use role?based credentials; built the access request workflow with approvals and expirations; assembled monitoring using Okta and Snowflake logs.
• Testing/QA: Ran in shadow mode: applied policies in a non?production environment with mirrored data; validated that BI dashboards rendered as expected under new roles; tested masking, row filters, and exception handling; piloted access requests with Finance owners and Internal Audit.
• Rollout: Migrated user groups by domain in waves; enabled masking and row policies first, then tightened table access; moved BI connections to role?based credentials; enforced maker?checker approvals for new access requests after training.
• Training/hand?off: Delivered sessions for Finance, Data Engineering, and IT on the new role model, request catalog, and monitoring; updated SOPs for onboarding, offboarding, temporary access, and exception handling; transferred ownership of roles, policies, and dashboards to Finance and Security under change control.
• Human?in?the?loop review: Established periodic certifications for high?sensitivity roles; scheduled reviews of exceptions and break?glass usage; decisions recorded with rationale and effective dates.

Results

Access decisions became consistent and quick to justify. Users requested predefined access packages aligned to finance domains, approvers saw exactly which tables and fields were in scope, and temporary access expired automatically. Sensitive fields were masked by default, and row policies limited access by entity and region, so teams could share dashboards without exporting raw data.

Governance grew stronger and more transparent. Audit requests were answered with reports showing who had access, who approved changes, and which queries touched PII. BI tools honored Snowflake roles, reducing data sprawl. Exceptions decreased because workflows captured the context and duration of non?standard access, and Finance controlled which cases required additional review. Okta, Snowflake, the ERP, and BI remained; the difference was a finance?aware access model with clear approvals and monitoring.

What Changed for the Team

• Before: Broad warehouse roles and ad hoc groups granted more than needed. After: Domain roles and row policies enforced least privilege by entity and region.
• Before: PII masking was handled in ETL jobs inconsistently. After: Dynamic masking protected sensitive columns at query time across tools.
• Before: Access requests and approvals lived in email. After: A request catalog with maker?checker approvals and expirations governed exceptions.
• Before: BI caches bypassed warehouse controls. After: BI connections used Snowflake roles, inheriting row and column policies.
• Before: Audit trails were reconstructed. After: Okta and Snowflake logs fed dashboards and evidence packs with clear lineage.
• Before: Revokes lagged transfers and departures. After: Lifecycle automation aligned group membership to roles with periodic certifications.

Key Takeaways

• Center identity and access on data domains; align Okta groups and Snowflake roles to how Finance uses data.
• Protect at the warehouse; use row policies and dynamic masking to enforce least privilege across downstream tools.
• Make exceptions explicit; route non?standard access through maker?checker approvals with expiration and rationale.
• Tie BI to the warehouse; require role?based connections so dashboards inherit policies rather than duplicate them.
• Monitor continuously; combine Okta and Snowflake logs into auditor?friendly reports with Finance ownership.
• Integrate, don’t replace; keep existing ERP, BI, and identity platforms, and add a governed access layer and workflow.

FAQ

What tools did this integrate with? Identity and group membership remained in Okta, with groups synchronized to Snowflake roles. Snowflake enforced role?based access, row access policies, and dynamic data masking, and delivered monitoring via Access History. BI tools (Tableau and Power BI) were configured to use role?based connections so policies applied at query time. Reference material included Okta Identity Governance and Snowflake Dynamic Data Masking.

How did you handle quality control and governance? Finance owned the role model, masking rules, and row policies under change control with effective dates and rationale. Access requests followed maker?checker approvals, with expirations for temporary access. Monitoring used Snowflake Access History and Okta logs to produce reports on entitlements and query activity. Periodic certifications reviewed high?sensitivity roles, and all changes were immutably logged.

How did you roll this out without disruption? Policies were tested in a non?production environment first. User migrations occurred in waves by data domain. Masking and row policies were enabled before tightening table permissions. BI connections were switched to role?based credentials with validation against current dashboards. Legacy emails for approvals remained as a controlled fallback during early cycles.

How were PII and sensitive finance fields masked? Sensitive columns were tagged in Snowflake and protected with dynamic masking policies at query time. Authorized roles saw full values; others saw partially redacted or null representations. Masking applied consistently across SQL, BI, and ad hoc tools because enforcement lived in the warehouse rather than in ETL.

How were exceptions and break?glass access handled? Non?standard access requests included reason codes, approvals from Finance owners, and time?bound expiration. Break?glass access used short?lived tokens with alerting and post?use review. All exceptions were reported in dashboards with who, what, when, and why, and were included in periodic certifications.

What changes were made to BI tools? Connections were updated to use Snowflake roles tied to Okta groups, and embedded credentials that bypassed warehouse policies were retired. Dashboards were validated under role contexts to confirm that row filters and masking applied as expected.