Skip to main content

Data Protection

We use a comprehensive set of technical controls to support general security needs as well as security for data we receive.

Authentication and Access Management

End users may log in to WhyLabs using an Identity Provider, leveraging WhyLabs’ support for the Security Assertion Markup Language (SAML) or via the “Sign-in with Google” OpenID service. These services will authenticate an individual’s identity and may provide the option to share certain personally identifying information with WhyLabs, such as your name and email address to pre-populate our sign up form. WhyLabs’ SAML support allows organizations to control authentication to WhyLabs and enforce specific password policies, account recovery strategies and multi-factor authentication technologies.

All requests to the WhyLabs API must be authenticated. Requests that write data require at least reporting access as well as an API key. Requests that read data require full user access as well as an application key. These keys act as bearer tokens, allowing access to WhyLabs' service functionality.

Protection of Customer Data

Data submitted to the WhyLabs service by authorized users is considered confidential. This data is protected in transit across public networks and encrypted at rest. Customer Data is not authorized to exit the WhyLabs production service environment, except in limited circumstances such as in support of a customer request.

All data transmitted between WhyLabs and WhyLabs users is protected using Transport Layer Security (TLS) with public certificates. If encrypted communication is interrupted, the WhyLabs application is inaccessible.

WhyLabs maintains data in the United States. Customer submitted service data never leaves the United States. WhyLabs utilizes encryption at various points to protect Customer Data and WhyLabs secrets, including encryption at rest (e.g. AES-256), asymmetric encryption (e.g. PGP) for system backups, and KMS-based protections for the protection of secrets (passwords, access tokens, API keys, etc.).

Access to Customer Data is limited to functions with a business requirement to do so. WhyLabs has implemented multiple layers of access controls for administrative roles and privileges. Access to environments that contain Customer Data requires a series of authentication and authorization controls, including Multi-Factor Authentication (MFA). WhyLabs enforces the principles of least privilege and need-to-know for access to Customer Data, and access to those environments is monitored and logged for security purposes. WhyLabs has implemented controls to ensure the integrity and confidentiality of administrative credentials and access mechanisms, and enforces full-disk encryption and unique credentials for workstations.

WhyLabs monitors critical infrastructure for security related events by using a custom implementation of open source and commercial technologies. Activity data such as API calls and operating system level calls are logged to a central point where the information is passed through a series of custom rules designed to identify malicious or unapproved behavior. The results of these rules are fed into an orchestration platform that triggers automated actions, which may include directly alerting the security team or triggering additional authentication requirements.

Multi-tenancy

The WhyLabs platform is built with a multi-tenancy-first architecture. We employ multiple layers of separation to ensure that paid customers’ data never inter-mix. These layers include separate object key-prefixes, using customer’s Organization ID) as a primary key component in both the data and metadata layer, using separate encryption keys for different customers, and tagging all data access with customer ID. All access from both the application interface and the API key is tagged with the associated organization ID, and is checked against the target organization ID to prevent unauthorized access at multiple levels.

SOC 2 Compliance

We are very happy to announce that we successfully completed our SOC 2 Type 2 examination with zero exceptions. WhyLabs is committed to ensuring our current, and future customers are well informed about the robust capabilities and security of the WhyLabs AI Observatory platform. A part of that commitment is our guarantee to have our business policies and practices evaluated and validated by independent third parties.

System and Organization Controls (SOC) reports are issued to organizations that provide services like WhyLabs, and whose controls have been evaluated by a third party against defined standards. SOC 2 is one of the most comprehensive certifications within SOC and is broadly considered the most trusted third-party security verification.

WhyLabs’ successful SOC 2 Type 2 examination was focused on controls as they relate to security. This designation recognizes that WhyLabs meets all the infrastructure and data control policy requirements to regularly monitor for malicious or unrecognized activity, monitor user access levels, and document system configuration changes. The results reveal that our information and systems are thoroughly protected against unauthorized access, disclosure of information, and damage to systems. The report is available to customers and prospects evaluating the effectiveness of WhyLabs’ policies and procedures for controlling our services. To request The WhyLabs SOC 2 Type 2 report, please contact your account manager or email [email protected].

Prefooter Illustration Mobile
Run AI With Certainty
Get started for free
Prefooter Illustration