Data Security @ Hex

Hex is built on industry-leading security and privacy standards that keep our customer's data secure while connecting, querying, analyzing, and sharing. Hex is committed to helping customers of all sizes meet their data protection and compliance requirements.

As evidence of this, we have obtained our SOC 2 Type II report, which attests to the effectiveness and our adherence to security controls and processes.

Visit for more detail on Hex's Security and Compliance posture.

Data Security is our most important job

Hex has created a security-first company culture that begins at employee onboarding and expects accountability in our obligation to ensure customer data security and privacy protection. Employees are required to attend data security classes and adhere to policies required to maintain SOC2 certification. Hex has employed software vendors and consultants to enforce employee adherence to policies, and test against infiltration.

Your data, temporary by design, secure everywhere

With Hex, your analysis is powered by live queries against your database, and data applications are shared securely without ever giving access to underlying data. No more extracting data to notebooks, .csv, and Excel files, proprietary third-party databases, or desktops. This is a distinguishing feature of Hex; minimizing data movement and restricting data access to a need-to-know basis.

Data in Hex projects are ephemeral by design, ensuring that your data is short-lived in the kernel memory. Hex's configurable caching layer gives full control over the query cost to your data warehouse cost without the sacrifice of storing data long-term.


Hex's data workspace is built from the ground up with security in mind. Data warehouse credentials are stored securely in a vault, encrypted at rest. Hex queries your data warehouse to answer questions, returns the result to an isolated kernel, then optionally caches the result.

Hex logic and app environments are ephemeral by nature, and any data uploaded or cached is encrypted at rest.

Administrators have control over what users have access to and can restrict access to databases, and the ability to view or edit projects.


Hex supports SSO (Google Apps, OKTA, and OIDC).

Hex's approach to data access is especially valuable for companies with GDPR or other privacy considerations and in sectors with specific security requirements.

Hex has a comprehensive control structure, which breaks down into three main categories:

  1. User Roles - limits what actions users can take within Hex, and also (if enabled) what role users are added to by default.
  2. Data Access - limits what data connections are shared with the organization. Access can be restricted to allow editors to only use provided database credentials or connections shared with them.
  3. Project Access - project owners can restrict permissions of collaborators, controlling access to underlying data, app logic, and the data app itself.

Deployment optionality

Data is stored in transit and at rest. Hex uses AES 256 bit encryption to secure database credentials, file uploads, and cached query results at rest. Further, Hex employs TLS 1.2 to encrypt network traffic data in transit in Hex's servers and between Hex and user's browsers.

For customers who need to meet specific regulations or privacy considerations, Hex is deployable to a single-tenant hybrid model. This configuration safeguards your ability to meet regulatory compliances and standards by enforcing data will only be written to disk on your premises.

Data Security Policy

What data does Hex store?

At Hex, we follow a policy of data minimization. We will never access or store data that is not actively used by a current Hex project, and we store the minimal amount of data needed to run each project's logic.

Hex also provides controls to allow granular access to customer data, so that as the customer you can ensure that no unauthorized data ever enters Hex's system.

Data security

We run all systems on AWS and store data using RDS, EBS, and S3. All data is encrypted at rest and end-to-end in transit, and all systems are protected by network security policies that prevent access outside of secure enclaves. To access Hex systems, employees must authenticate through a bastion host that maintains audit logs of all access. We also require multi-factor authentication for all systems that handle customer data.

Access control

We also subscribe to the policy of least privilege at Hex: the only people who can access your data are engineers who require database access to perform their duties, and direct data access is only allowed in response to a customer issue. All access control policies are maintained using AWS IAM roles.

On the application side, Hex gives users the tools to implement role-based access control on all Hex artifacts, so you have fine-grained control over who from your organization has access to specific data.

Data use

Our customers' data is their data. We don't sell, access, or use it for anything, ever, aside from improving our product and supporting users.

Application security

All changes to the Hex codebase, including the infrastructure definitions, must pass a code review, which assesses both code correctness and security implications. We perform automated vulnerability scans of the entire codebase to ensure that none of our dependencies introduce additional vulnerabilities.


For all customers, Hex provides technical support via email on weekdays from 9 am to 5 pm Pacific Time as a minimum. Support via Slack channel may also be provided upon request.

Incident response

In the event of a security incident, leadership is immediately notified and the incident triaged according to its severity. From there, we work quickly to mitigate the issue and eventually come to a resolution. For incidents involving customer data, we will notify you as soon as reasonably possible and keep you up to date on all progress towards resolving the incident.