Sisense for Cloud Data Teams Security

Nothing is more important than the security of your data — your business depends on it. That’s why we’ve built a cloud security infrastructure that follows industry wide best practices and standards.

Sisense Data Security Architecture

1 Customers connect to Sisense Data over HTTPS, the protocol used for online banking.

2 Sisense’s Web and Backend servers connect to each other using encrypted connections over SSL.

3 Sisense connects to customer databases from static IP addresses that customers can whitelist in their firewall settings. For databases in private networks, Sisense can connect through using SSH tunnels.

Security Certifications

Sisense for Cloud Data Teams conducts a variety of audits to ensure continuous compliance with industry standard best practices. All Sisense Data certifications require an independent 3rd party to audit specific adherence to their respective guidelines annually. In addition to SOC2, HIPAA, and ISO audits, Sisense performs its own internal audits at regular intervals to ensure ongoing compliance.

• Sisense is SOC 2 Type II certified for data security for cloud-based service providers. Documentation available upon request.

• Sisense is HIPAA-HITECH certified for all medical and patient-centered data. Documentation available upon request.

• Sisense Analytics Services is ISO 27001:2013 compliant in Information Security practices. Documentation is available via the following link, but can also be provided upon request.

• All servers receive quarterly patching and security updates, and intrusion detection systems monitor for security incidents.

• Sisense is E.U.-U.S. and Swiss-U.S. Privacy Shield certified , which allows mechanism to comply with data protection requirements when transferring personal data from the European Union and Switzerland to the United States in support of transatlantic commerce.


Our architecture is designed to keep requests encrypted with SSL/TLS connections as they enter and move throughout Sisense . Inbound requests enter Sisense and are routed throughout our stack. They are only decrypted when reaching their destination and are re-encrypted for transport.

• All traffic between your web browser and Sisense’s servers is encrypted with 256-bit AES encryption.

• Database connections use JDBC over SSL. For additional layers of security, we recommend connecting through SSH tunnels and whitelisting access to our static IPs.

• Sisense maintains strong connections with HTTP Strict Transport Security (HSTS) protocols to protect against a multitude of security attacks.

Data Security and Information Systems

The following details outline our data security, physical security, and audits. Sisense for Cloud Data Teams is hosted on Amazon Web Services (AWS), we recommend referencing their compliance documents in addition to our own. Sisense for Cloud Data Teams is governed by its Information Security Management System (ISMS), a set of policies and procedures designed to keep customer data and Sisense corporate assets safe and restricted to their intended and authorized use. Sisense’s ISMS is compliant with the HIPAA HITECH Security Rule and is SOC2 Certified. Details of Sisense’s ISMS and compliance audit procedures follow.

• Sisense follows OWASP best practices and security guidelines.

• No customer data is sold to any 3rd party for any reason.

• Access to production servers is restricted except for the automated deployment of code written by Sisense software engineers, and during declared emergencies by on-call engineers. Non- Sisense code is never deployed on our production servers.

• Sisense performs cross-site scripting and SQL injections checks to defend against unauthorized access.

Sisense Data Governance

Data Encryption & Intrusion Prevention

To prevent unauthorized access, Sisense has taken a number of steps to ensure that data security is maintained, even in the context of breach. Network-level Access Control Lists (ACLs) monitor all network-level transactions, and verify that servers attempting to communicate with each other are authorized to do so. These ACLs specify which ports are approved for network communication depending on the individual server’s role in the overall Sisense architecture. ACLs are analogous to firewalls that operate at the subnet level. Engineering access to production systems are secured via SSH keys. Passwords and connection configurations are encrypted.

User-Level Security

• Sisense offers SAML-based Single Sign-On functionality. We support Okta, OneLogin, Microsoft Azure Active Directory and Google Apps SSO providers.

• Sisense requires strong passwords. Audit logging lets administrators see when users last logged in and when passwords were last changed.

• Sisense empowers all Sisense users to secure their access with Two-Factor Authentication.

• Admins on our Enterprise plan can mandate two-factor authentication for all users.

• Sisense helps you restrict data access to only those who should have it with Data Permissions. Available with Enterprise plans.

Communications and Operations Management

• All code changes and application updates to our production environment are reviewed for security issues before general release.

• Sisense isolates development, testing, staging, and production environments in different engineering environments.

• User passwords are salted, irreversibly hashed, and stored in Sisense’s Postgres database. Sisense employees are restricted from accessing user passwords.

Incident Event and Communication Management

• Sisense conducts penetration tests on external networks annually.

• Sisense has formal incident response plans for major events.

• For major events, our email notification system contacts affected companies within 24 hours.

Disaster and Data Recovery

Sisense for Cloud Data Teams is distributed across each of the AWS availability zones (AZs) in the US East (N. Virginia) Region. This posture allows for a self-healing infrastructure with redundant servers for critical services present in each AZ. The platform features built-in mechanisms to detect when components are not operating or operating in a degraded state. It will automatically scale within the alternate AZs to ensure that services remain available and responsive.