Privacy and Security
At Peerdom, we’re all-in when it comes to security, privacy, and transparency. We treat your precious organisational data as if it were our own and with exceptional standards. This document represents an overview of our approach to data privacy. If anything is unclear or leads to questions, please contact us at firstname.lastname@example.org so that we can discuss and improve.
Data handling 🔗
All stored data is the exclusive property of the organisation. Only confirmed, registered accounts with access to the organisation may access and consult organisational data.
In case of support, a limited number of Peerdom employees may be granted permission to access an organisation’s data. The Peerdom employees are bound by a non-disclosure agreement. In this particular case, the organisation will be contacted for prior consent.
Deleting customer data
The organisation has the right to remove all organisational data at any time. Automated backups of the Application and its data are deleted weekly. If you decide to delete your entire account, we do not continue to store any deleted data on our servers.
Exporting customer data
We are strict about no vendor lock-in. Full data exports can be furnished upon request in CSV format. These exports include all stored organisational data (peers, circles, roles, and Application data).
If the organisation does not choose to subscribe following the free trial period, their trial is put on “lock mode” and access is revoked to all associated Peerdom account. The organisational data remains stored for 90 days after the trial period has ended, as well as the associated account information, in case the organisation wishes to continue where they left off. Following these 90 days, the main contact for the organisation will receive an email asking if Peerdom should extend the data storage another 3 months or delete all organisational data.
Peerdom uses Matomo analytics to collect general usage data on the application in order to better inform our design process. By connecting to Peerdom, the user IP, date and time, title and URL of the page being viewed, screen resolution, local timezone, links clicked to external resources, approximate geolocation of the user, and main browser language. Although this information is collected, it is anonymised and not linked to Peerdom user accounts. Furthermore, the “Do Not Track” preference is enabled for users to opt-out of tracking. Analytics data is stored on a private server hosted by Exoscale, a datacentre located in Zurich, Switzerland.
Detailed access logs are kept when a connection is established to Peerdom. Information such as the device type and IP address, are recorded in these logs and can be consulted by our development team for incident tracing.
All logs are sent in real time to Google Cloud Logging with a 30-day retention period.
All user passwords are hashed using bcrypt in combination with a salt, prior to storage in our database.
All application code is stored in Git code repositories on Gitlab.com.
The Peerdom application and all organisational data are hosted on Google Cloud, on servers located in Zürich, Switzerland. The datacentre has been audited and is compliant with the following security certifications: ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 20178, SOC 1/2/3, PCI DSS, CSA STAR. Google matches 100% of the energy consumed with renewable energy and maintains a commitment to carbon neutrality. For more information see the Google Cloud Switzerland website.
We are using a Google App Engine flexible instances to run Peerdom’s container. The database is run upon Google Cloud SQL (PostgreSQL).
Separated deployment environments
We maintain separate staging and production environments. When releasing new versions of Peerdom, we first deploy to the staging environment. The two environments are maintained independently concerning software upgrades, and product data is replicated across the environments.
Network protection 🔗
Data traffic is encrypted via up-to-date, recommended protocols, and implementation is guided by current best practices. Data transfer from Peerdom to the end user is secured with an AES-256 bit SSL certificate.
Remote access to servers by our infrastructure teams is enabled through SSH via keys. We have disabled SSH access via password.
The software is automatically deployed as a Docker Container sent by our GitLab CI Runner service after various automated tests have been performed. Each deployment generates an artifact that allows a rollback to a specific version of the software.
Hostile attack prevention
Firewalls are configured according to the approved industry standards, managed by Google AppEngine.
A daily backup is made of the database on via a 7-days sliding window on the server. That is, every 8th day will replace the oldest backup. that is, the 8th day will then replace the oldest backup.
Any files associated with the organisation (e.g. avatar images or other resources) are replicated to Google Cloud Storage on a daily basis and are stored for 1 month.
Any prospective security incident will be treated with utmost priority and communicated to those affected once the situation has been properly understood (see Communication section below). Application bug reports are managed by our dedicated support team.
We use two main tools to monitor and escalate incidents to our infrastructure team. First, we have set up a Pingdom service to monitor the uptime of the Application, and second, we use Healthchecks.io to monitor that our regular server tasks are correctly executing.
In the unlikely event of downtime or other security incidents, we communicate via our Twitter account at: https://twitter.com/@peerdomorg
Physical Security 🔗
Only authorized Google Cloud personnel can access the datacentre.
Monitoring and access control
Only our Developer team has access to the production infrastructure. Each Peerdom employee only has access those Services that are truly related to their job. We have implemented strong password strength requirements on all infrastructure and account passwords.