Privacy Policy
Last updated August 2026
iDash is a conversational business intelligence product operated by Gateway Group. This policy explains what information we collect when you use iDash, why we collect it, who we share it with, and the choices you have.
It is written for the people who will actually be asked to approve it: the person signing up, and the person in security or legal who has to read it afterwards. Where a section describes something technical, it describes what the product does rather than what the category usually does.
1. Who we are
iDash is built and operated by Gateway Group, a software engineering company. In this policy, Gateway Group is referred to as we, us and our, and iDash is referred to as the service.
If you use iDash through an account created by your employer, your employer controls that workspace. We process workspace content on their instructions, and questions about how that workspace is run should go to them first. You can still contact us directly at any time using the address at the end of this policy.
2. What this policy covers
This policy covers our website, the iDash application, and the systems that run behind it. It does not cover the databases and warehouses you connect to iDash, which remain yours and stay under your control, and it does not cover third party sites we link to.
3. Information we collect
We collect information in three ways: you give it to us, the service generates it as you use it, and a small amount arrives automatically from your browser.
- Account details. Your name, email address, password (stored only as a hash), and email verification state.
- Workspace and project details. The names of your workspaces and projects, the members you invite, and the role each member holds.
- Data source connection details. Host, port, database name, username, credentials and any connection options you enter. These are encrypted field by field before storage.
- Schema metadata. Table names, column names, data types, primary keys and foreign keys read during introspection, and any curation you apply on top of them.
- Workspace content. The questions you ask, the queries generated to answer them, the charts you pin, and the rows a pinned chart needs in order to render.
- Usage and diagnostic data. Log records of requests to the service, error traces, and performance timings, used to keep it running and to fix faults.
- Communications. Messages you send us for support, and the details you submit in a demo request form.
- Billing details. On paid plans, the billing contact, address and tax identifiers. Card details are handled by our payment processor and are not stored by us.
4. Your database and its contents
This is the section most people are here for, so it is the most specific one.
iDash connects to your data source using a credential you supply, and the connection is opened read-only. Statements are restricted to a single SELECT and run under a statement timeout. There is no write path in the product.
We do not copy, replicate or warehouse your tables. Queries run on demand against your source, and the rows come back only for the question being answered. When you pin a chart to a dashboard, we store the rows that chart needs in order to draw itself, so that opening a dashboard does not silently re-query your production systems. Refreshing a pinned tile re-runs the stored query and replaces those rows.
Connection details are encrypted field by field with AES-256-GCM at rest, and are decrypted only at the moment a connection is opened. They are never sent to a language model, never written to logs, and never made available to the code sandbox described below.
If you delete a data source, its connection details are deleted with it. If you delete a project or a workspace, the questions, charts and pinned rows belonging to it are deleted as described in the retention section.
5. How we use information
We use the information above to provide the service, and for a short list of things that keep it viable.
- To run the product: authenticating you, resolving your workspace role, connecting to your data source, answering your questions and rendering your dashboards.
- To keep it working: monitoring, debugging, capacity planning and abuse prevention.
- To keep it secure: detecting unusual access patterns, investigating incidents and enforcing our terms.
- To support you: replying to requests, and following up on demo enquiries you sent us.
- To bill you: invoicing, collecting payment and meeting tax obligations on paid plans.
- To tell you about the product: service notices, security notices, and product updates you can unsubscribe from at any time. We do not sell your information, and we do not share it for advertising.
6. Language model providers
Answering a question involves sending the question, relevant schema metadata, and where necessary the rows returned by a query, to the language model provider configured for your deployment. This is what allows the service to understand what you asked and choose the right metrics and dimensions.
We do not train models on your data, and we do not permit our providers to train on it under our agreements with them. Retention at the provider is governed by the provider you use. On Enterprise plans you can configure your own provider and your own keys, in which case that relationship is directly yours.
Query results may also be passed to the sandboxed code environment when a question requires computation beyond a query. That environment runs in a disposable container, receives the result set as a file, has no network access unless enabled for your deployment, and never receives a database credential.
9. Security
Security in a product that connects to customer databases has to be structural rather than procedural, so most of our controls are properties of how the system is built.
- Read-only connections, enforced at the database session level where the engine supports it, with a guard that rejects anything that is not a single SELECT.
- Statement timeouts on every query, so a runaway question is cancelled rather than left running against your source.
- Per-field AES-256-GCM encryption of connection credentials at rest, with keys held outside the application database.
- Transport encryption for traffic between you and the service, and between the service and your data source where your engine supports it.
- Tenant isolation at the API boundary. Workspace membership is resolved on every request from your authenticated session, never from anything a user or a model can type.
- A sandboxed code environment with no credential access, no persistent state between sessions, and resource limits applied at the container level.
- Passwords stored only as hashes, and session tokens that your browser cannot read from script.
- Access to production systems limited to the engineers who need it, with individual accounts and audit records.
- No security programme is perfect. If you believe you have found a vulnerability, please contact us at the address below and we will respond promptly.
10. How long we keep information
Account and workspace information is kept while your account is active. Chat history is kept according to the retention window of your plan, after which older sessions are removed. Pinned dashboards and the rows they carry are kept until you delete them, or until the project or workspace is deleted.
When a workspace is deleted, we delete its content within 30 days, other than backups that expire on their own cycle and records we are required to keep for tax, accounting or legal reasons. Deleting a data source removes its encrypted connection details immediately.
Logs and diagnostic records are kept for a limited period appropriate to their purpose and are then discarded.
11. Your choices and rights
You can update your account details in the application, delete a data source at any time, export your dashboards and definitions, and delete your workspace. Product emails carry an unsubscribe link, and service and security notices are sent regardless because they are part of operating the account.
Depending on where you live, you may also have the right to request a copy of the personal information we hold about you, to have it corrected, to have it deleted, to object to or restrict certain processing, and to complain to your local data protection authority. Contact us at the address below and we will respond within the period the applicable law requires.
If your workspace is administered by your employer, we may direct your request to them where they control the information involved.
12. Where information is processed
We and our service providers may process information in countries other than the one you live in. Where information moves across borders, we use the contractual protections available to us with each provider, and we choose hosting regions to fit customer requirements where a plan supports it.
13. Children
iDash is a business product. It is not directed at children, and we do not knowingly collect information from anyone under 16. If you believe a child has provided us with information, contact us and we will delete it.
14. Changes to this policy
We update this policy when the product changes or when the law requires it. The date at the top always reflects the current version. If a change materially affects how we handle your information, we will tell you in the application or by email before it takes effect.
15. Contact us
Write to us at idash@thegatewaycorp.com with anything about this policy, a data request, or a security concern. We read every message that arrives there.