Compliance

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

Audits are performed every year to maintain compliance. In 2023, the auditor was Accedere.

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

a penetration test by an independent third party is performed at least once per year
our development processes are audited to ensure we do things securely (MDM for laptops, code and security reviews, documented change management process...)
our 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.

Deployment types: SaaS and self-hosted

Sifflet can be deployed both as a single-tenant software-as-a-service SaaS solution or a self-hosted solution (where you deploy Sifflet on your own infrastructure).

SaaS (software-as-a-service)

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

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

Self-hosted

You can also deploy Sifflet on your own infrastructure.

Sifflet self-hosted deployments are not "hybrid 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 to connect to the infrastructure of any other customer. Services are configured with tight permissions, preventing any customer to access the data of any other customer.

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

Data stored by Sifflet

As a rule, Sifflet does not store any sensitive data.

Sifflet does not store any data from any client database. When Sifflet needs to display column values, one of these strategies is used:

data is fetched on-demand and discarded immediately after being displayed
data is normalised (actual values are replaced with normalised values, discarding the original and making it impossible to retrieve them) - this is used for instance in anomaly detection.

As a result, Sifflet does not store any PII (personal identifiable information).

Sifflet stores the credentials required to access datasources 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 to this instance.

Sifflet only requires read-only access to the monitored datasources. 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 don't access your datasources. 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 don't contain any sensitive data. Sifflet doesn't log any data from a datasource, nor any credential used to connect to the datasource. Application logs may contain metadata (as defined below, such as table and column names). They may contain queries against datasources, but not their results. Access to logs is restricted.

List of notable data items stored by Sifflet

Data type	Details	Purpose
Datasource metadata and schemas	Table names, column names and types, dashboard names...	Data asset catalog, lineage
Datasource credentials	Dependant on the datasource: username/password, certificate... Stored in a separate secrets manager.	Connecting to datasources
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

Blog article

You can also refer to this article about our security strategy on our blog: https://www.siffletdata.com/blog/secure-by-design-how-sifflet-keeps-your-data-safe.