Data security policy
Updated: 7th June 2021
Protecting our customers’ data is the most important thing we do at Perdoo. Due to the nature of the data we store, our users have extremely high expectations when it comes to protecting their data. We understand how important the responsibility of safeguarding this data is to our customers and work hard every day to maintain that trust.
Our Security Team
We spend a lot of time finding the best people, especially when it comes to our engineers. Our Security Team includes people who have built highly secure enterprise mobile and web applications at companies ranging from startups to large public companies.
Our Security Team is dedicated to ensuring that current best practices around security are embedded into our day-to-day product development and wider organizational security practices. They are also responsible for our regular security audits.
In addition to our internal Security Team’s audits, we work with well-regarded third-party auditors, Vaadata and Cure53, to check our systems for security vulnerabilities on an ongoing basis. Their vast knowledge complements our internal expertise to ensure effective year-round security auditing.
We use services like Papertrail, Sentry, and Sqreen to provide an audit trail over our infrastructure and the Perdoo application. Auditing allows us to do ad-hoc security analysis, track changes made to our setup, and audit access to every layer of our tech stack.
We hold external data providers to the same high standards to which we hold ourselves.
Perdoo does not run its own routers, load balancers, DNS servers, or physical servers.
Perdoo runs all of its services in the cloud. All of these are hosted on Heroku, which is built on Amazon Web Services (AWS). Both services maintain multiple certifications for their data centers, including multiple ISO compliance (eg 27001), PCI Certification, and SOC reports. For more information about their certification and compliance, please visit the AWS Security website, AWS Compliance website, and Heroku security policy.
All customer data is stored in AWS data centers in Ireland.
We store our customer data in multi-tenant databases. Strict privacy controls and test suites exist in our application code to prevent cross-tenant access. Our CTO and Security Team conduct thorough code reviews to uphold these high standards.
AWS data centers meet the highest security standards. Physical access is controlled at building ingress points by professional security staff utilizing surveillance, detection systems, and other electronic means, plus CCTV is used at all physical access points to server rooms. AWS data centers are equipped with independent power, cooling, and networking components, protecting services against single data center failures.
Encryption and access control
Perdoo is served 100% over HTTPS. All data sent to or from Perdoo is encrypted in transit using 256-bit encryption, using SHA-256 with RSA Encryption and SHA-256 ECDSA as the key exchange mechanism. Our API and application endpoints are TLS/SSL only and score an “A” rating on SSL Labs’ tests. In addition, all connections from our application servers to our databases are TLS encrypted. Finally, user passwords are always encrypted, in addition to encryption in transit.
All databases used by Perdoo are encrypted at rest, meaning that we also encrypt the database files on the hard disks themselves. Data encryption is deployed using industry-standard encryption and best practices for every framework we use.
Credit card safety
As a paying Perdoo customer, we do not store any of your card information on our servers. We use Stripe and ChargeBee to handle this, both companies dedicated to storing your sensitive data on PCI-Compliant servers.
Our PostgreSQL databases offer continuous rollbacks, so we can quickly recover from a database failure. It also takes regular snapshots of the database and securely moves them to a separate data center so that we can restore them elsewhere as needed, even in the event of a regional Heroku or AWS failure. All backups are encrypted and transferred to an external data center while preserving data residency (Europe) using a secure TLS connection.
After a 30-day window, with the exception of any information that we are legally required to retain, an automated process deletes or anonymizes all data in the platform related to the expired contract.
Server logs are retained for 7 days though they do not contain any personal or sensitive/confidential information. Only our CTO and Security Team are able to view the server logs.
In the event of a data breach, we would notify affected customers within 72 hours of becoming aware of the breach. In the event that personal data was involved, we would also notify the governing body for data privacy in Germany, where Perdoo is subject to GDPR.
We have two-factor authentication (2FA) and strong password policies for all services that our employees use. These include Slack, Intercom, AWS, Heroku, GitHub, and Google. We also encrypt the hard drives on all the laptops used within Perdoo by our employees.
Employee laptops are encrypted before the employee receives the laptop. Apple devices use Filevault 2, and Linux devices use dm-crypt with LUKS. Additionally, we’re mainly on Apple, which is substantially harder to attack than Windows.
All new Perdoo staff undergo data security training and we conduct reference checks for all new hires.
There is only one employee with access to the production databases: our CTO. This is purely for Engineering purposes and access times are kept as low as possible.
Access to our admin panel where employees can gain access to customer accounts is limited to only those employees who require access. Perdoo employees are not able to access customer accounts without explicit confirmation from the customer that they are happy to grant access to the account. Access to our admin panel is audited monthly and is granted based on the principle of least privilege, where requests must specify the level of permissions the individual needs to access, and are time-bound. Relatedly, Perdoo employees’ rights within third-party tools are granted based on the principle of least privilege – employees do not have administrative rights unless completely necessary.
All Perdoo employees must use the 1Password password manager to ensure password security across all applications and website logins. For detailed information on 1Password’s own security, please read this article.
All employees are also trained to tackle social engineering attacks. In addition, as we’re a small team, it’s very difficult for someone to pretend that they are someone important from another business division.
Physical access to our office locations
Even though we do not rely on physical locations to process customer data, our office spaces are extremely secure. There is always an authorized person on the front desk, there is 24/7 CCTV across the building, the building makes use of sophisticated alarm systems, and all employees access the building using keycards. These keycards are “blank” – they do not contain the employee’s name, company logo, or building address.
Within the Perdoo Product, there are three user roles that determine the permissions of each user in the platform. Administrators can assign roles when inviting new users to the platform, or when editing a current user. Administrators can see the Last Activity, role status, and can deprovision users from a central administration interface in the Perdoo application.
We offer Single Sign-On via Google and SAML. Clients can enable Two-Factor Authentication with all types of SSO. Automatic user provisioning can be accomplished via all types of SSO. Additionally, authentication tokens for SSO are signed and verified with SHA-256 grade cryptographic hash function.
We do not rely on physical locations to provide services, therefore our exposure to most threats of disaster is minimal. However, we do have an extensive business continuity policy and incident response procedure. This includes established roles for incident response and a dedicated emergency response team made up of high-level employees from across the organization.
Our engineering teams maintain documented standard operating procedures and runbooks to address a variety of scenarios. Engineering teams run backup restoration tests for critical services at least once a year. We also have an on-call rotation to ensure 24/7 coverage of our systems in the event of an incident.
For more information on our uptime commitments, please review our Terms of Service.
Recovery Point Objectives (RPO)
Perdoo’s systems have an RPO of 24 hours maximum, meaning that at the worst case, no more than 24 hours of data are lost and valid backups are taken at least every 24 hours.
Recovery Time Objectives (RTO)
The majority of Perdoo’s products have an RTO of less than one business day. The one exception to this is the case of ongoing and critical failure of any of our critical third-party vendors, eg AWS or Heroku. It could take up to a month to await system recovery or switch to an alternative vendor.
Product development and quality assurance
In addition to the aforementioned code reviews and privacy controls in our application’s code, we also never use customer data during our development or testing processes. Also, to maximize protection, there is no direct connectivity between our Production, Staging, and Development environments.
Perdoo operates an extensive test suite that covers both functionality and security of the application. We maintain a high level of test coverage with every change we make to the code.
We use security tools to continuously scan our web application for security vulnerabilities. Dependencies, including third-party libraries and tools, are monitored and updated promptly when new issues are discovered. Our version control application, GitHub, also automatically updates any packages that have security patches.
We closely monitor the security community and are committed to promptly upgrading our services in response to the evolving threat landscape.
We do not have an official bug bounty program. This means we do not have standing financial or internal resources dedicated to handling unsolicited bug reports. That said, we are happy to accept submissions to firstname.lastname@example.org, and we may choose to provide compensation for these submissions where appropriate. Vulnerabilities found are not confidential, but we’d ask that you don’t publicly disclose the things you find without giving us ample time to remedy any issues. We will do our best to provide valid findings with appropriate compensation. Please bear in mind that our assessment of what’s appropriate may differ from yours, and we do not negotiate reward amounts.
Feedback on this security policy
If you have feedback on this security policy, please email email@example.com.