GaugeSeal
Security & privacy brief
GaugeSeal watches the reports in a Power BI or Tableau estate, holds each to a contract you set, and says which ones need a decision. It reads metadata and activity. It does not read what is inside a report.
https://api.gaugeseal.com/brief · Revised 9 August 2026 · security@gaugeseal.com
Where it runs
One process on one server in the European Union, rented from an EU company with no US parent. No cross-region replication and no second copy elsewhere. Connections are TLS, terminated by the proxy in front of the application; the application binds the loopback interface.
Sub-processors: OVHcloud (European Union) — the virtual server the application runs on, its disk, and the daily backup snapshots on it; Scaleway (European Union — France) — delivers sign-in links and the weekly digest. There are no others.
What we can read in your tenant
You grant read-only access in your own platform: an Entra service principal for Power BI, a personal access token for Tableau Cloud. The same list is shown to whoever enters the credential.
Power BI. We read: Report and dataset inventory, owners, and workspace membership. Who viewed which report, and when — the same activity log your tenant already keeps for 28 days. Whether each dataset refresh succeeded or failed. We never read: Nothing inside your data: no rows, no columns, no queries, no dataset contents or schema. Nothing outside this workspace — the credentials are used against the one workspace id you give us. Nothing writable: every call we make is a read. The workspace role we ask for could write, because Power BI has no read-only role that can read refresh history — the grant is wider than our use of it, and that is worth knowing.
Tableau Cloud. We read: Workbook and view inventory, and each workbook's owner. Who opened which view, and when — from the Admin Insights view history your site already keeps. We never read: Nothing inside your data: no marks, no rows, no columns, no extract or published-data-source contents. Nothing outside this site — the token is used against the one site URL you give us. Nothing writable: every call we make is a read. The token carries a site administrator's permissions because listing a whole site needs them — the grant is wider than our use of it, and that is worth knowing.
What we store about people
Four kinds, each because a rule cannot run without it. We are the processor; you are the controller. Retention is a number on your account enforced by a daily job — not a sentence in a policy — and unbounded retention is not a value the system can hold.
| Personal data | Why we hold it | How long | Erasure |
|---|---|---|---|
| Who viewed which report, and when | Usage cannot be judged without it — an anonymised count could never say five different people read this | 24 months by default, set per account | One request rewrites that person's identity across every event, leaving the events themselves intact |
| Report and workbook owners | The ownership rule, and the 'who do I talk to' column on the board | Life of the tracked report | The same rewrite |
| Your colleagues' sign-in addresses | Magic-link sign-in, invites, and the weekly digest | Life of the membership | Removing the member deletes the row, and their sign-in tokens and sessions with it |
| Rejected deliveries, as they arrived | Malformed telemetry is kept for inspection rather than dropped, so nothing is lost silently | 6 months by default, set per account | The same rewrite reaches inside them |
Nothing else we store is personal data: health verdicts, state transitions, contracts, aliases and cursors carry no identities. An erasure request rewrites the identity in the live store immediately and reaches the last backup copy within 7 days.
How it is protected
The measures, each a property of the running system rather than an intention — encryption in transit; credentials sealed at rest; secrets stay out of everything else; keys we issue are held as digests; tenant isolation is structural; authentication without passwords; backups and a rehearsed restore; retention and erasure are enforced jobs; we watch our own instance; data minimisation is a review gate. Each is written out in Annex II of the DPA, which is the version to quote in a questionnaire.
How you switch us off
Access is granted in your tenant, so it is withdrawn in your tenant: nothing we run can keep reading after you close the door.
- Power BI — you can revoke them at any time by deleting the secret in Entra ID — that is your kill switch, not ours.
- Tableau Cloud — you can revoke it at any time by deleting the token under My Account Settings — that is your kill switch, not ours.
Push keys for the embed collector are revoked inside the product and stop working on the next request. A workspace can be deleted outright: every row it owns goes in one operation, not a queue of jobs you have to trust.
What we do not have
- No SOC 2 report. The hygiene it asks for is how the system is built; the audit itself waits until a customer's process needs it.
- No public status page yet.
- No SSO, SAML or SCIM, and one role: member of an account. If your procurement requires more, tell us — that is a conversation we want to have.
- No high availability: one instance, one region. A restore from the last daily snapshot is the recovery path, not a failover.
Next: the data processing agreement carries the categories, the measures and the sub-processors as annexes, the security page is the long form of this one, and anything neither answers has an address — security@gaugeseal.com.