Small Improvements Software GmbH

Germany

It’s our policy that customers decide when they want to either delete individual pieces of information, or when they want to close their account and delete all data. We don’t interfere with customer data at all, and don’t delete anything except if asked by customers. We advise customers to remove any data that they don’t need anymore on a regular basis. This applies especially to former employees and old reviews. It’s easy to download PDF versions of old reviews and store them on site if needed, so that former employees can ultimately get deleted from Small Improvements if this is desired by the customer. Please note that even after data is deleted from the active database, the data remains accessible in backups for up to 6 months. See our Replication and Data Backup policy for more information. Deletion of a customer account by the customer does not automatically erase the data from our subprocessors. Email metadata will live on for 30 to 60 days at our email sending provider, and if you’d like to erase the remaining data also from our CRM and Support system, please notify us at support@small-improvements.com. The only exception to data deletion is that our German entity has a legal requirement to store invoices and credit notes for at least 10 years, so that information can’t get erased even when a customer requests it.

Backups It’s crucial we keep backups of our core production data, so in the event of major failure (like a coding error that erases customer data from the database) we can roll back to a previous safe state. Requirements - We take daily snapshots of all production data and store it on an independent system. - We get notified in case a backup didn’t succeed - We replay backups frequently in order to ensure they are still working - We delete backups after 6 months Implementation - Our Application runs in Google Cloud App Engine, the live database being in Google Data Store. Our backups are stored in the Google Cloud Storage service, which is entirely independent. Even if a coding error or App Engine related proble, led to our entire databse being wiped, we’d be able to recreate the database within hours. - A daily notification mail sent to key employees when a backup has been taken, and in case anything in the process has failed the email states this very clearly in the subject line, and we’ll take immediate action to ensure the backup will work - At least every 2 months we take a backup and replay it onto an empty server and ensure the process still works - Backups are deleted after 6 months Replication Goal - It’s important that we don’t have a single point of failure. All our production systems need to survive individual servers or even entire datacenters going down Implementation - We run all of our crucial production systems in the Google Cloud. Most services have cross-datacenter replication built in by default (our database and production servers for instance). In the few cases where we have to build our own infrastructure like our Google-hosted Load balancers, or our Google-hosted PDF-generation-servers, we ensure that there is always enough replication in place for single servers or even datacenters to fail without jeopardizing the service itself.

Our customer data is highly sensitive and we spend a lot of effort to keep it safe from data loss, breach and disruption. The efforts range from careful hiring over defensive coding, automated testing, intense code reviews to a continuous penetration testing program and to careful handling of the data by staff. The following outline some of our practices and commitments All sensitive textual content is encrypted at rest using AES256, and we hash passwords using bcrypt. Customer data is stored logically separated from each other in the databases, and only pseudonymized or anonymized data will be used for test purposes. Development and QA environments are entirely separated from the production database. We collect only the data that we need to be able to provide the service, and we’re especially careful regarding data sharing with other providers. We work hard at keeping the list of our subprocessors as small as possible, and we only share the absolute necessary amount of data with those processors. The core employee data is stored in the Google Cloud, and we only share as much PII employee data that’s required to be able to send email notifications with our email provider. Other than that, the other subprocessors only process data about users that interact with us – for instance during the sales process or when solving a support ticket. All of the highly confidential data does not leave the main database in the Google data center. We employ internal role-based and user-based permissions to restrict access to the only those staff who need to be able to access a set of information (need-to-know basis). We revisit access levels regularly and choose the minimum levels possible. Access to functionality like large-scale exports from our product is only available to special role members, and must be made available manually by our Customer Success team.

Cloud hosted

Google Cloud

yes

no

2021-11-30

yes

Okta, OneLogin, Google Apps, PingIdentity, Centrify

yes

no

security@small-improvements.com

no

yes

yes

no

no