To set up BI dashboard software for permissioned reporting in a controller office, focus on three things: data governance, role-based access, and auditability. Here’s a practical setup approach.

1) Define the reporting model

Start by listing:

• What reports the controller office needs
  • P&L, balance sheet, cash flow
  • budget vs actual
  • close status
  • journal entries
  • aging / AP / AR
  • compliance or variance reports
• Who uses them
  • Controller
  • Assistant controller
  • FP&A
  • Accounting managers
  • Audit/compliance
  • Executive leadership
• Which data each role may see
  • Entity, region, department, cost center, project, vendor, customer, payroll, etc.

This becomes your permission model.

2) Choose BI software with enterprise security features

Pick a tool that supports:

• Role-based access control (RBAC)
• Row-level security
• Column-level security or data masking
• Single sign-on (SSO) with your identity provider
• Audit logs
• Scheduled report delivery
• Approval / certification of dashboards if available

Common options:

• Power BI
• Tableau
• Looker
• Qlik
• Sigma
• SAP Analytics Cloud

For a controller office, Power BI or Tableau are common if you already use Microsoft/enterprise systems.

3) Set up identity and access management

Integrate with:

• Azure AD / Entra ID
• Okta
• Google Workspace or your corporate IdP

Create groups such as:

• Controller_Office_Admin
• Controller_Office_Analysts
• Department_Leaders_ReadOnly
• Executive_ReadOnly
• Audit_ReadOnly

Then assign permissions to groups, not individuals, whenever possible.

4) Build a security model around the data

Use security at the dataset or semantic layer, not just at the dashboard front end.

Row-level security examples

Users only see:

• Their business unit
• Their legal entity
• Their department
• Their region

Example:

• Region managers can see only their region
• Corporate controller can see all entities
• Auditors can see historical closed periods only

Column-level security examples

Hide sensitive fields:

• Employee names
• Salary details
• Bank account numbers
• Vendor tax IDs
• Customer PII

Data masking

Use masked values like:

• XXX-XX-1234
• truncated account numbers
• generalized personnel categories

5) Separate development, test, and production

Set up three environments:

• Dev: build and test dashboards
• Test/UAT: validate access and numbers with business users
• Prod: controlled, approved release

Only a small admin group should publish to production.

6) Govern the source of truth

Controller office reporting should pull from controlled sources:

• ERP
• GL
• AP/AR
• payroll
• budgeting system
• data warehouse / lakehouse

Best practice:

• Use a single curated finance data model
• Standardize chart of accounts mappings
• Lock down transformation logic
• Reconcile to the GL before publishing

7) Design permissioned dashboards by audience

Don’t build one giant dashboard for everyone.

Create separate dashboards or views for:

• Executive summary
• Controller close package
• Department performance
• Audit/compliance
• Operational finance

Each should expose only the metrics needed for that audience.

8) Add approval and certification workflows

For controller reporting, establish:

• Report owner
• Data owner
• Approver
• Change log
• Versioning

If the software supports it, mark certain reports as:

• “Certified”
• “Official close report”
• “Board-ready”

This reduces confusion about which numbers are authoritative.

9) Schedule and control distribution

Use:

• scheduled refreshes
• email subscriptions
• PDF exports only for approved users
• secure links instead of attachments when possible

Avoid sending sensitive reports broadly by email without access controls.

10) Log and monitor access

Enable audit logging for:

• dashboard views
• exports
• permission changes
• refresh failures
• admin actions

Review:

• who accessed sensitive reports
• who exported data
• unusual access patterns

11) Test security thoroughly

Before launch, verify:

• Users cannot see unauthorized entities
• Managers cannot see peer departments
• Restricted columns are hidden
• Exported files respect permissions
• SSO and MFA work correctly
• Audit logs capture access

Use test accounts for each role.

12) Create operating procedures

Document:

• how new users are added
• how access is removed when roles change
• who approves new dashboards
• how data issues are escalated
• how close-period changes are handled

This is especially important in finance.

---

A simple implementation pattern

A good controller-office setup often looks like this:

ERP/GL source systems
→ Finance data warehouse / semantic layer
→ BI tool with RBAC and row-level security
→ Role-specific dashboards
→ Audit logs + scheduled distribution

---

Recommended minimum controls

If you want the shortest checklist:

1. SSO + MFA
2. Role-based access groups
3. Row-level security
4. Column masking for sensitive fields
5. Certified source data model
6. Separate dev/test/prod
7. Audit logging
8. Scheduled reviews of permissions

---

If you want, I can also give you:

• a sample permission matrix for a controller office,
• a Power BI setup example,
• or a Tableau/Looker security design.