Where your data is hosted
All inmydata services run on Amazon Web Services (AWS) in the Europe (Ireland) region. Your data is stored and processed within this region.
Data uploaded to inmydata is held in three places.
1. Upload staging (Amazon S3). On initial upload, your data is temporarily stored on Amazon S3 until the publish process is complete. Amazon S3 applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption.
2. The analytics database. The data is then loaded into the inmydata analytics database, hosted on an AWS EC2 instance which uses AES-256 (a LUKS-enhanced version of cryptsetup) for OS and storage disk encryption. Any data that is permanently deleted from the analytics database is removed using the Linux tool shred (7 iterations and a final zero overwrite to hide shredding).
3. The platform database (Amazon RDS for PostgreSQL). Your account configuration, users, dashboards, saved reports and other metadata are held in a PostgreSQL database on Amazon RDS. This does not include your operational data which is stored in the analytics database, and dashboard and report definitions do not contain data values. Storage, snapshots and automated backups are encrypted at rest with AES-256 using keys managed by AWS Key Management Service (KMS).
Network isolation of our databases
Our databases are not reachable from the public internet.
Platform database. Public access is disabled and the database sits in a private inmydata network (VPC) with no public address. Its firewall accepts connections only from a dedicated database-client security group that is attached solely to inmydata's own application components: the web application, authentication server, publishing and forecasting services, and API functions. There is no "allow from anywhere" rule, and every component that communicates with the platform database runs inside that private network.
Analytics database. The analytics database runs in its own private network, connected to the inmydata network by VPC peering, and has no public address. Its firewall likewise accepts connections only from inmydata's own application components.
Connection logging. Every connection to the platform database is logged with its source, and the logs are reviewed for unexpected clients.
How we control access to the databases
Applications. Each inmydata application connects to the platform database as its own dedicated database user, whose permissions are limited to the data that application needs; one application cannot read another application's data. Applications authenticate using AWS IAM database authentication: rather than a stored password, each connection presents a short-lived token (valid for 15 minutes) generated at runtime by the application's IAM role. There are no database passwords in application code, container images, configuration files or environment variables.
Our staff. inmydata engineers cannot connect to the databases directly over the internet. Access requires an individual, named AWS identity that has been explicitly granted membership of a dedicated database-access group, and each engineer authenticates to the platform database with their own short-lived IAM token rather than a shared password. Connections are established through AWS Systems Manager Session Manager to a relay inside the private network; the relay accepts no inbound network connections of any kind. Every session is authenticated by AWS IAM, recorded in AWS CloudTrail, and times out automatically. Database access is limited to the small number of engineers who need it to operate the service.
Access to the analytics database uses a service credential held in AWS Secrets Manager and available only to the inmydata services that publish and query data.
How we manage keys and secrets
No long-lived credentials. Applications obtain their AWS permissions from IAM roles assumed at runtime. Static access keys are not embedded in code, container images or configuration.
Secrets are held in AWS Secrets Manager, encrypted with KMS. Access is granted per application through IAM policy, so each service can read only the secrets it owns.
Encryption keys are managed by AWS KMS. inmydata staff never handle raw key material.
Key rotation. Credentials are rotated on a schedule and immediately if there is any suspicion of exposure.
TLS certificates for inmydata services are issued and renewed automatically through AWS Certificate Manager, removing the manual renewal steps that can lead to lapses.
Two-factor authentication (2FA) and passkeys
inmydata supports two-factor authentication for all user accounts. When enabled, signing in requires both your password and a one-time code, delivered either by an authenticator app on your phone (time-based one-time password, TOTP) or by SMS.
Any user can enable 2FA on their own account.
Administrators can require two-factor authentication for every user in their organisation from the authentication settings, so that no account can sign in with a password alone.
inmydata also supports passkeys (FIDO2 / WebAuthn), letting users sign in with a device-bound credential such as Windows Hello, Touch ID or a hardware security key instead of a password. Passkeys are bound to your organisation and cannot be used to sign in to another tenant.
Organisations using single sign-on continue to authenticate through their own identity provider, and that provider's MFA policy applies.
Authentication is handled by a dedicated inmydata authentication server using OAuth 2.0 / OpenID Connect. Passwords are never stored in plain text. Browser-based (cross-origin) interaction with the authentication server is restricted to inmydata's own domains — inmydata.com, inmydata.ai and some partner URLs — so a page on any other domain cannot drive a sign-in against our authentication server.
Data in motion
When data is transferred over a network, inmydata uses TLS encryption between all server-side and client-side processes. This includes traffic inside our own network: connections from inmydata applications to the platform database are encrypted with TLS and verify the server certificate. Public endpoints enforce HTTPS with HTTP Strict Transport Security (HSTS) and support TLS 1.2 or later.
AI features: how your data is shared with Claude and OpenAI
inmydata's AI features are designed so that models see only what is needed to answer the question in front of them, and so that no AI provider becomes a store of your data.
In every case the same principles apply:
Only what is needed is sent. The model receives your request, a description of your data model (field names, types and descriptions), and the aggregated results needed to answer the request. The raw underlying dataset is never sent to a model.
Stateless requests. Each call to a model is independent. The provider holds no persistent memory of your data between requests; conversation history is stored in inmydata's own database and is included only for the duration of a request.
Not used for training. Data sent to the model providers under their commercial terms is not used to train their models.
1. inmydata Copilot and AI descriptions
Copilot (the chat assistant inside inmydata) and the AI-generated descriptions of dimensions and metrics use OpenAI GPT models running on Microsoft Azure. With Azure OpenAI, prompts and results are processed within our Azure subscription: they are not sent to OpenAI's public service, are not available to other Azure customers, and are not used to train any model. Azure OpenAI retains prompts and results only for abuse monitoring, in line with Microsoft's published policy.
Organisations that prefer their AI usage to fall under their own agreement with Microsoft can supply their own Azure OpenAI key in inmydata's AI settings. That key is stored in AWS Secrets Manager and is never displayed in full once saved.
2. inmydata Studio
inmydata Studio (AI-assisted dashboard design) uses Anthropic's Claude models via the Anthropic API. Under Anthropic's commercial API terms, data submitted through the API is not used to train Anthropic's models and is retained only briefly for abuse monitoring.
Studio applies further safeguards of its own:
Each Studio account's data is isolated in its own database schema.
Studio reaches your inmydata data through the inmydata MCP server using a connection key that is stored in AWS Secrets Manager, never in the database.
Any SQL generated by the model runs in a locked-down in-memory sandbox with no file system or network access.
Field descriptions and query results are treated as untrusted content and sanitised before they enter a prompt.
Partners may use their own Anthropic API key so that all model usage falls under their own agreement with Anthropic.
3. Connecting your own Claude or ChatGPT to inmydata
inmydata provides an MCP (Model Context Protocol) server that lets you add inmydata as a data source in Anthropic's Claude or OpenAI's ChatGPT.
You sign in to inmydata. When you connect an AI assistant, you authenticate through inmydata's own login using OAuth. The assistant acts as you: it can only see data your inmydata user is permitted to see, and the same data-security rules apply as when you use inmydata directly.
Answers, not bulk data. The assistant asks questions of inmydata and receives the aggregated results for that question. It does not have access to the underlying database.
Your provider, your terms. In this case the results flow into your own Claude or ChatGPT account, so how that provider retains and uses the conversation is governed by your agreement with Anthropic or OpenAI. Both providers state that data sent through their commercial API and business products is not used to train their models by default.
Revocable. You can disconnect an AI assistant at any time from your inmydata account, which immediately invalidates its access.
Questions
