Compliance

Sifflet is compliant with ISO 27001 and SOC 2 Type 2 standards.

Independent auditors audit Sifflet every year to maintain compliance.

These standards cover a large range of topics, such as:

an independent third party performs a penetration test at least once per year
Sifflet development processes are audited to ensure they are secure (MDM for laptops, code and security reviews, documented change management process...)
Sifflet infrastructure implements all the security best practices (firewalls, encryption at rest and in transit...)
all Sifflet employees attend mandatory yearly security training
Sifflet keeps security and compliance procedures up-to-date and regularly tests them

Sifflet is a French company and is GDPR-compliant.

Compliance Documentation (Trust Center)

You can request access to compliance documentation, including audit reports, from the Sifflet Trust Center.

Deployment Types: SaaS, Hybrid and Self-Hosted

Sifflet offers three deployment models:

SaaS (software-as-a-service): Sifflet hosts your entire instance. You have no infrastructure to manage. Recommended for most customers.
Hybrid (SaaS with agent): Sifflet hosts your instance. You deploy a small agent on your internal network, or a Snowflake native app, to allow your Sifflet instance to query your databases.
Self-hosted: you deploy the entire Sifflet instance on your own infrastructure, and maintain the instance. Not recommended for most customers.

SaaS (Software-as-a-Service)

With this option, Sifflet deploys your instance on its own infrastructure, manages the maintenance and upgrades, and ensures the security of your instance.

Sifflet is a web application that does not require installing a client (besides a web browser).

Unless you have strict compliance requirements, Sifflet recommends the SaaS solution, as it frees you from installation and maintenance concerns.

All ingress and egress flows are encrypted: connections to data sources are encrypted by default (the exact scheme depends on the data source), and the Sifflet API is served over HTTPS only.

If your sources are not reachable from the public Internet, you have two options:

private connectivity: see Private Link and custom networking setups
deploy the Sifflet Agent in a hybrid deployment, see next section.

Hybrid: SaaS with Agent

This option extends the SaaS deployment with a lightweight agent that can query data sources on private networks:

to connect to sources on an internal network, see Sifflet Agent (preview).
to connect to a Snowflake that blocks traffic from the public Internet, see Sifflet Native App for Snowflake (private preview).

Self-Hosted

Organizations with strict compliance requirements that are not covered by the Sifflet Agent or custom networking setups can also consider self-hosted deployments.

With a self-hosted deployment, no data ever leaves your environment. Self-hosted Sifflet instances can be deployed in environments without any Internet connection.

More details about this deployment type are available in a dedicated page.

Isolation Between Customers: Dedicated Instances

Sifflet is a single-tenant application. Each customer gets a dedicated, isolated instance, with a separate database. Network policies prevent a customer instance from connecting to the infrastructure of any other customer. Services are configured with tight permissions, preventing any customer from accessing the data of any other customer.

Customers can choose where their Sifflet instance is created to fulfill their compliance obligations, such as US, Europe or Asia regions.

Permissions Used by Sifflet

Sifflet relies on read-only permissions on the monitored sources. Sifflet does not need any write permissions. The list of permissions that you need to grant to Sifflet is described in the documentation of each Sifflet integration.

When configuring the Sifflet integration, you should follow the principle of least privilege and not grant any permission not explicitly listed in the documentation.

Data Stored by Sifflet

By default, Sifflet does not store any sensitive data.

When Sifflet needs to display column values, it uses one of these strategies:

Sifflet fetches data on demand and discards it immediately after displaying it. Sifflet uses this strategy for data preview, for instance.
data is normalized (actual values are replaced with normalized values, discarding the original and making it impossible to retrieve them). Sifflet uses this strategy in anomaly detection, for instance.
some expensive queries are cached; the results are encrypted in the database with a per-customer encryption key (in addition to any disk-level encryption). Sifflet uses this strategy to store monitor group-by values, for instance, as well as SQL statements from Asset History.

As a result, Sifflet does not store any PII (personally identifiable information), with one notable exception: if the asset update history is enabled, the stored SQL statements might contain PII. Refer to the feature documentation for more information.

Sifflet stores the credentials required to access data sources in a separate secrets manager, outside the main database. Access to any secret is logged. Per the previous section, a given Sifflet instance can only access the secrets associated with this instance.

Sifflet only requires read-only access to the monitored data sources. Granting any form of write access to Sifflet is highly discouraged.

You can revoke the permissions you granted to Sifflet at any time, in which case Sifflet no longer has access to any of your data.

Sifflet engineers do not access your data sources. Any access to a production environment is logged, and access to said production environment is only granted to engineers when required to investigate a production issue.

Application logs do not contain any sensitive data. Sifflet does not log any data from a data source, nor any credential used to connect to the data source. Application logs may contain metadata (as defined below, such as table and column names). They may contain queries against data sources, but not their results. Access to logs is restricted.

List of Notable Data Items Stored by Sifflet

Data type	Details	Purpose
Data source metadata and schemas	Table names, column names and types, dashboard names...	Data asset catalog, lineage
Data source credentials	Dependent on the data source: username/password, certificate... Stored in a separate secrets manager.	Connecting to data sources
User email addresses	Email addresses of users configured from the Sifflet interface or single sign-on provider. (these are email addresses of your organization employees or contractors, not your end-users).	Authentication / log in.
Monitoring results	Sifflet stores the historical and current status of all monitors and incidents, but not the data used by the monitor.	Data quality monitoring
Data source usage history	A 7-day history of the read queries made against the data assets (tables, views, etc.).	Asset History
Data source update history (optional)	A 7-day history of the write operations made against the data assets. These operations can include SQL statements that might expose sensitive information. This feature is disabled by default. Refer to the documentation of the Asset History feature for more information.	Asset History

Data Accessed by Sifflet

In addition to the data stored by Sifflet, as described in the previous section, Sifflet may access (but does not store) data from your data sources.

Data type	Details	Purpose
Table rows (or equivalent)	Monitors require running SQL queries against your data, and accessing the result. This result depends on the monitor type, but is typically some metadata about your rows (such as the most recent row, or the total number of rows, or the number of rows per category).	Data quality monitoring
Failing rows	A sample of rows that failed a monitor. Sifflet fetches these rows on demand and does not store them.	Incident resolution

AI Features

Customer data or metadata is not used by Sifflet or any provider to train AI models.

A proprietary time-series forecasting model is used by Sifflet to define monitor thresholds based on historical data. This model is fitted on aggregated results from the monitor (for instance, the number of rows in a table) and is not trained on customer data.

Third-Party Vendors with Access to Data

Some third-party vendors may have access to one of these categories of data:

application data that may contain personal data, as defined by the GDPR (such as user emails)
asset data (content of tables monitored by Sifflet) - as described above, this is limited to very specific use cases
asset metadata, such as table names, column names and types...

These vendors are listed in the Sifflet Trust Center.

Blog Article

You can also refer to this article about the Sifflet security strategy on the Sifflet blog: Secure by design: how Sifflet keeps your data safe.