Overview

0. Google security assessment

1. OAuth-driven Authentication

2. Zero data storage from third-party sources

3. HTTPS Protocol

4. Database encryption

5. Database access control

6. Multi-factor authentication (MFA) for infrastructure access

7. Software development best practices

At Pod, we’re building the only smart productivity workplace for enterprise account executives. Our mission is to provide a more unified way for our users to update, organize, and prioritize their work. To achieve this goal, we integrate with a variety of existing sales tools our users currently use. We are dedicated to handling our customers’ sensitive data and adhere to the best-practice standards of security and data compliance across our application.

You’ll find below a list of security measures we’ve taken to keep our users (and ourselves!) safe:

A 3rd party firm, appointed by Google, conducts a full end-to-end security audit of the Pod platform. Their assessment is based on:

The certification is renewed on a yearly basis.

When connecting to 3rd party systems (i.e., Salesforce, GSuite), we leverage their OAuth-based authentication option. This way, users will never give Pod access to their credentials (i.e., username, password). This way, we eliminate the risk that our users’ credentials get compromised (or accessed) through Pod by a malicious party. Additionally, we’re currently in the final steps of obtaining Google Verified App certification - which would add yet another feather of security & reliability to Pod’s cap. As an example, in order to connect their Salesforce or Google Suite accounts, users enter their credentials in a pop-up window controlled by the 3rd party application (i.e., Salesforce, Google). Through this service, the users then grant Pod permission to access their data.

We understand that these systems host sensitive information. None of our customers’ data are stored when our users integrate their Salesforce or GSuite instances. Therefore, the question of any SFDC/GSuite data getting leaked or exposed doesn’t arise in the first place.

All our API requests & responses are sent and received using the HTTPS protocol (rather than HTTP), which encrypts request/response data and prevents potential man-in-the-middle attacks.

In order to protect our database, we encrypt all data that users generate on Pod (i.e., tasks, documents, preferences). Therefore, in the unlikely event that a malicious third party is able to access Pod’s database, the data is completely unusable. Given it is encrypted, it would appear entirely nonsensical.

Our database is set so that it can only interact with specific pre-defined IP addresses, corresponding to Pod back-end servers). This creates a further level of security and ensures that only authorized entities can access our database.

In order to ensure that malicious individuals aren’t able to access our application’s codebase or servers, we’ve enabled multi-factor authentication.

In addition to the above guidelines, we ensure to stay mindful of security best practices as part of our engineering processes. For example, we use environment variables to store sensitive information (i.e., credentials, keys). Also, we only request access to the minimum required amount of information from external sources. We consistently review and upgrade our security guidelines to ensure our approach to managing customer information is in line with the best-in-class security & compliance approach.

💡 Helping our customers is core to our value proposition and we are dedicated to protecting them and their data. If you have any additional questions and/or comments regarding Pod’s Security & Compliance guidelines, feel free to reach out at [email protected].