Krisp employs information security policies and there is an executive-level commitment to implement and follow the policies throughout the organization.
Information Security program is lead by the Head of Security @ Krisp.
You can download the SOC-2 Type II audit executive summary from here.
Please contact [email protected] if you would like to review the full report.
Krisp (Windows and Mac) is a desktop app which removes background noise while the user is doing calls, video meetings, making recordings or podcasts using their favorite apps (Zoom, Skype, Loom, Squadcast, etc). Krisp is designed as a virtual microphone and speaker and hence can plug into any other app. Krisp processes all voice audio data on the end user’s machine. This data never leaves the user’s machine unless explicitly opted in by users for recordings (more about this below).
Krisp stores the following customer data in its cloud:
Recordings is an optional feature in Krisp. Currently, this feature is available to Personal and Personal Pro plan users only. Krisp Team and Enterprise plan users cannot use this feature at the moment.
Krisp allows users to record audio from the machine’s microphone and speaker. This feature is disabled unless the user explicitly opts in for it. When users opt-in, they can hit a record button from inside Krisp app and Krisp will start recording the audio for that session. The audio files are stored on Krisp’s AWS S3 storage, in encrypted form.
If you would like to learn more about how this feature works, please contact [email protected]
TLS 1.2 is enforced throughout all our services (no exception).
All production databases and customer data are encrypted at rest with AES-256 (no exception).
Krisp supports three authentication methods for users:
Krisp backend doesn’t store passwords.
Customers can delete all their data by sending an email to [email protected]
Customers can request all their data by sending an email to [email protected]
Once a user account is deleted, all associated data (account settings, etc.) are removed from Krisp systems. This action is irreversible.
Account data is gated at the application layer. Account data is not physically segregated at the database or storage layers.
This document provides the full list of authorized Krisp Sub-processors and describes the process of receiving notifications on sub-processor changes.
By default, only our key engineering leads have access to customer data. All other engineers do not have access to customer data unless granted permission for debugging purposes.
Krisp app operates locally on the users’ machines and most of the time doesn’t need to connect to its backend. When it detects that it can no longer connect to the backend it stops operating.
Our backend infrastructure is entirely hosted on AWS, it’s fully automated and monitored by continuous functional tests to detect any sort of downtime.
Krisp backend is entirely hosted on AWS and leverages all the security benefits (physical security, key management, redundancy, scalability, etc) that AWS provides. The IT infrastructure that AWS provides to its customers is designed and managed in alignment with security best practices and a variety of IT security standards, including SOC 1/SSAE 16/ISAE 3402 • SOC 2 • SOC 3 • FISMA, DIACAP, and FedRAMP • DOD CSM Levels 1-5 • PCI DSS Level 1 • ISO 9001 / ISO 27001 • ITAR • FIPS 140-2 • MTCS Level 3.
In addition, Krisp backend is security-hardened by:
Krisp Backend doesn’t use passwords which makes it very lightweight from a security perspective. Instead, it relies on Google Sign-in, SSO and email code verification for all user sign-in events.
Krisp Backend is leveraging Stripe for payments and therefore it doesn’t store credit cards.
Krisp Backend is regularly scanned with industry-standard scanning tools for monitoring and detecting vulnerabilities. In addition, every quarter we do a thorough and detailed pentest using 3rd party pentest companies.
We consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present.
We encourage security researchers to work with us to mitigate and coordinate the disclosure of potential security vulnerabilities. If you discover a vulnerability, we would like to know about it so we can take steps to address it as quickly as possible. We would like to ask you to help us better protect our clients and our systems.
Please do the following:
What we are seeking:
On our frontend applications – security bugs that are results of improper deserialization of input data which could lead to vulnerabilities like dom xss on the web, various kinds of overflows, incorrect memory handlings, and anything else that could lead to user account, machine, private data compromise.
On the backend side – security bugs that are results of improper user input handling, security misconfiguration, improper access control and anything else that could lead to user account, private data compromise, information disclosure, various kinds of abuses, server compromise.
What is in scope:
What we promise:
We strive to resolve all problems as quickly as possible, and we would like to play an active role in the ultimate publication on the problem after it is resolved.
All members of our team go through a Security 101 training for increased security awareness
If you have any questions about this doc please contact us at:
[email protected]