What we hold, what we can read, and how you switch us off
Written for the person who has to approve this. If something you need is not here, ask us and we will write it down: security@gaugeseal.com.
Take it to your reviewer: the two-page brief, and the data processing agreement with its annexes. Both print to PDF from your browser, and both are generated from this system rather than kept in a folder beside it.
One process, one machine, one EU region
GaugeSeal runs on a single server in the European Union, rented from an EU company with no US parent. There is no cross-region replication and no second copy elsewhere: residency is a sentence, not a roadmap item.
Every connection is TLS, terminated by the proxy in front of the application; the application itself binds the loopback interface and is not reachable from the internet by any other route. This site sets no cookie and loads nothing from anyone else's servers — no fonts, no analytics, no trackers.
What each connector can see
These are the same words the connect page shows the person entering the credential, because they are the same list.
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.
The credentials are encrypted before they are stored, and you can revoke them at any time by deleting the secret in Entra ID — that is your kill switch, not ours.
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.
The credentials are encrypted before they are stored, and you can revoke it at any time by deleting the token under My Account Settings — that is your kill switch, not ours.
Sealed before they are stored, and never on their way out
At rest
Connector credentials are encrypted (AES-256-GCM) before they reach the database. The master key lives outside the database and reaches the process through its environment at start, so a copy of our storage is not a copy of your credentials. Rotation is supported and has been exercised in production.
In use
They are decrypted only in the worker making the call, and they never appear in a log line, an error message, or a URL — which is enforced by tests, not by convention. They enter the system through exactly two doors: the connect form's request body, and an operator prompt.
Keys we issue
The embed collector's push keys are ours to mint. You see one exactly once, on the screen that created it; we keep only a digest, so we cannot show it to you again and neither can anyone who reads our database. Revoking one takes effect on the next request.
You can end this without talking to us
Access is granted in your tenant, so it is withdrawn in your tenant. We are not in that loop, and 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 are revoked from inside the product, and a workspace can be deleted outright: every row it owns goes in one operation, not a queue of jobs you have to trust.
We are a processor, and the inventory is short
Four kinds of personal data, each because a rule cannot run without it. Retention is a number on your account, enforced by a job — not a sentence in a policy — and unbounded retention is not a value the system can hold.
| What | Why | How long | How it is erased |
|---|---|---|---|
| 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, transitions, contracts and cursors carry no identities, and the demo estate is synthetic throughout.
The boring half, stated plainly
Backups
Both stores, daily, integrity-checked, seven snapshots kept, and a restore procedure that has been rehearsed end to end rather than documented. Backups hold the same personal data under the same bounds — which means an erasure reaches the last copy within a week, and we would rather say so than let you assume it is instant.
Sign-in
A link in an email. We store no passwords because we never receive one; sessions are server-side rows that expire, and signing out deletes the row rather than the cookie. One role: member of an account. SSO and SAML are not built — if your procurement requires them, tell us, because that is a conversation we want to have.
When something breaks
We are our own first monitoring customer: failed jobs, connector outages and rejected telemetry raise operator alerts, and an external check watches for the whole instance going quiet. A reliability product that degrades silently refutes itself.
What we do not have
Stated here rather than discovered in a questionnaire.
- 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.
Sub-processors
- OVHcloud (European Union) — The virtual server the application runs on, its disk, and the daily backup snapshots on it. All stored data is here.
- Scaleway (European Union — France) — Delivers sign-in links and the weekly digest. It sees the recipient's address and the message, which names that account's own reports, owners and verdicts.
There are no other sub-processors, and nothing leaves the European Union. Annex III of the DPA carries the same list with the notice period for changing it.
Look before you decide
The demo estate is synthetic and read-only, and it will show you exactly what a connected workspace looks like from the inside.