HighQ Visualisations Add-On Security Whitepaper

All Add-ons require the customer to provision and manage their own Azure resources. Customers are solely responsible for the security configuration, credential lifecycle management, and compliance posture of their Entra ID app registrations, Azure Maps Accounts, and Power BI workspaces.

Azure Maps

Authentication uses the OAuth2 client credentials grant flow via direct REST API calls to the Entra ID token endpoint. A registered Entra ID application authenticates using Client ID, Tenant ID, and Client Secret to obtain an access token scoped to

https://atlas.microsoft.com/.default

.

Every API request to the Azure Maps service carries this bearer token in the

Authorization: Bearer

header alongside the Maps Account Client ID in the

x-ms-client-id

header. The Maps Account Client ID is obtained from the Azure Maps Account resource's Authentication blade in the Azure Portal and is distinct from the Entra ID application's Client ID. Shared key authentication is not used.

The Entra ID application must be assigned the

Azure Maps Data Reader

IAM role on the Maps Account resource, the minimum permission required for geocoding and tile access. The backend service caches access tokens and refreshes them automatically before expiry (60-second buffer). Requests to Azure Maps REST endpoints (Search, etc.) are proxied through the backend to avoid exposing credentials to the browser.

Power BI Embedded

Authentication uses the OAuth2 client credentials grant flow against the customer's Azure Entra ID tenant. A registered service principal authenticates using Client ID, Tenant ID, and Client Secret to obtain an access token scoped to

https://analysis.windows.net/powerbi/api/.default

the Power BI service.

This token is used to call the Power BI REST API GenerateToken endpoint, which returns a short-lived, report-scoped embed token delivered to the end user's browser. Each customer tenant requires its own Entra ID application with appropriate Power BI workspace permissions.

The OData connector exposes selected HighQ iSheet views as OData feed URLs. Each feed is protected by HTTP Basic Authentication using a shared username and password scoped to the HighQ instance. Power BI Desktop authenticates against the feed using these credentials to import iSheet data as a dataset.

The feed credentials are instance-wide and consistent across all registered feeds on that instance. The username format is

{sanitized-instance-name}-{instance-id}

, and the password is a randomly generated 32-byte URL-safe token. Power BI Desktop and other OData clients authenticate against the feed using these credentials to import iSheet data as a dataset. Customers are responsible for managing access to these credentials and can regenerate them via the

System Settings

administration interface.

Meeting Planner

Authentication uses the OAuth2 client credentials grant flow to access Microsoft Graph API. A registered Entra ID application (service principal) authenticates using Client ID, Tenant ID, and Client Secret to obtain an access token scoped to

https://graph.microsoft.com/.default

.

The service principal accesses a designated Exchange mailbox (bot email) to manage calendar events on behalf of HighQ sites. Meeting Planner configuration is deployment-wide (single service principal and bot mailbox), with per-instance settings.

The following table summarises the Authentication methods, identity providers, access models, and key security controls for each integration.

Address data from HighQ iSheet columns is sent to the Azure Maps Geocoding and Search APIs through the HighQ backend as a proxy. The HighQ backend forwards search requests to Azure Maps REST endpoints and returns the results (coordinates, address suggestions) to the browser. Azure processes the address queries and returns results, no customer data is retained by Azure Maps.

Search and geocoding operations occur both during map configuration and at runtime as users interact with the map. Returned coordinates may be cached within HighQ iSheet metadata columns. Map tiles are delivered directly from Microsoft's Azure Maps CDN to the end user's browser using an access token issued by HighQ with no tile data is proxied through HighQ.

Report data is never proxied through HighQ or any intermediary. The embed token delivered to the browser is used directly by the Power BI JavaScript SDK to load report data from Microsoft's Power BI service. HighQ's role in the data flow is limited to access control validation and embed token coordination. The only data that passes through HighQ during a report load is the embed token itself, not the report data.

All report data resides within and is served from the customer's own Power BI tenant. All report data remains within the customer's own Power BI tenant and Azure subscription. The customer retains full ownership and control of their workspace, reports, datasets, and credentials.

When the OData connector is used, selected iSheet view data is made available as a feed endpoint hosted within HighQ. Power BI Desktop connects to this endpoint using the shared feed credentials and imports the iSheet data into a Power BI dataset. The imported dataset is published to the customer's own Power BI workspace and remains within the customer's tenant.

iSheet data does not leave the customer's environment to any third-party or TR-owned infrastructure, it flows from HighQ directly into the customer's own Power BI workspace. The OData feed is a read-only interface ,no data is written back to HighQ through this channel. iSheet data flows from HighQ directly into the customer's own Power BI workspace. Data does not transit through any TR-owned or third-party infrastructure. Customers retain full control over which iSheet views are exposed as feeds and which Power BI workspaces receive the data.

Calendar event data is stored exclusively in Microsoft Graph (Exchange Online) within the customer's own Microsoft 365 tenant. HighQ does not store calendar event data in its database, it acts solely as an orchestration layer that proxies requests between the end user's browser and Microsoft Graph API. When a user creates or views a meeting, HighQ authenticates to Microsoft Graph using OAuth2 client credentials and forwards the calendar operation to the designated Exchange mailbox (bot email).

Event data flows from the browser through HighQ's backend to Microsoft Graph, where it is persisted. Calendar queries flow in reverse: Microsoft Graph returns event data through HighQ to the browser. Each calendar event is tagged with a Microsoft Graph OpenTypeExtension containing the HighQ site ID. This extension metadata enables multi-tenant isolation, ensuring users only see events belonging to their HighQ site even though all events share a single Exchange mailbox.

The extension data resides within the calendar event in Microsoft Graph, not in HighQ. All calendar event data (subject, attendees, location, times, attachments) remains within the customer's Microsoft 365 tenant. HighQ proxies read and write operations but does not persist, cache, or retain any calendar event content. The only Meeting Planner data stored in HighQ's database is configuration settings (default time zone, meeting duration, buffer time), no event data.

The following table provides an overview of data flow patterns, trust boundaries, data storage locations, and key security considerations for each integration.

The following table summarises data ownership, systems of record, and customer control for each integration component.

Azure Maps data processing locations vary by Collaborate instance region. Thomson Reuters manages the Azure Maps subscription for all Collaborate instances. The following table shows the Azure Maps Account location and corresponding data processing geography for each instance.