Responsible Disclosure Program
At Teamable we embrace the security community and we operate a responsible disclosure program to facilitate security vulnerability reporting.
If you believe you’ve discovered a potential vulnerability, please let us know by emailing us at firstname.lastname@example.org. We will acknowledge your email within one week. Provide us with a reasonable amount of time to resolve the issue before disclosing it to the public or a third party. We aim to resolve critical issues within ten business days of disclosure. Make a good faith effort to avoid violating privacy, destroying data, or interrupting or degrading the Teamable service. Please only interact with domains you own or for which you have explicit permission from the account holder.
While researching, we’d like you to refrain from:
- Distributed Denial of Service (DDoS)
- Social engineering or phishing of Teamable employees or contractors
- Any attacks against Teamable’s physical property or data centers
- Connections & hosting
Teamable is served over TLS only. All internal API calls and connections are also over TLS.
We use Amazon Web Services, AWS, and have no physical infrastructure or physical access to the servers themselves. Our production databases are on Amazon RDS and S3. Please refer to Amazon’s SOC2 report for an in-depth audit report. Our databases are encrypted-at-rest; all data and backups are also stored encrypted at rest.
How we handle credentials
All user tokens are encrypted with 256-bit AES, widely considered to be amongst the top ciphers. Keys are rotated the soonest of the following events: monthly, employee attrition, a suspicious activity report. Teamable immediately encrypts tokens upon receipt. They are never stored or transmitted in the clear.
Data we collect
We store email data, and we integrate with ATS’s, such as Greenhouse, for which we store ATS users, ATS candidates, and ATS jobs.
We access the least email data that we need. For emails that are generated by Teamable, those message bodies can be seen internally. Access to raw headers is limited to the production devops team.
For emails that are generated by Teamable we store the full message body. For these messages we use the full body to tune our emails. For all other emails, we store the metadata (headers) only. We never access or store the body or attachments of these emails.
Recipient and sender headers are saved so that Teamable can protect your brand when a user tries to contact someone that the team has previously contacted.
Additional message headers such as message IDs, are used to detect replies to messages. This helps Teamable report on performance metrics like raw activity and response rates, as well as control follow up messages.
We have a mandatory security policy in force for all employees. More specialized security policies apply at the department level.
For production access, our admin team is required to enable 2FA and use a strong, random password stored inside a password manager. Historical encryption keys are stored in a shared admin password vault.
No employees other than the devops production team can see customer data. All access to customer data is logged. Production data never leaves its environment, not even for development. Customer data is never stored on laptops, which are required to be encrypted. Teamable orders grey box, open code assessments (penetration tests), both for vulnerabilities and secure coding practices, twice per year.
All code requires mandatory peer review and automated security review.
Teamable has achieved SOC 2 Type 2 compliance. If you are a current customer who would like to request a report, please email us at email@example.com.
Our entire engineering team is involved in security. Email to firstname.lastname@example.org will alert all engineers, and the CEO.
Teamable will make application and database logs available in the case of a security incident via RESTful API.