Privacy and Security

Terms

• We refer to the Peerdom web platform at https://peerdom.org as the “Application”
• We also refer to Peerdom (the company) as “we” or “us” or using “our”.
• We refer to all the products and services we provide, individually and collectively, as the “Services”.
• We refer to you, the person or representative of an organisational entity accessing our Application or using our Services, as “you” or “your” or “customer” or “the organisation”.
• We refer to our main contacts at “the organisation” as “representatives”.

Access rights and data visibility

Each Peerdom App (e.g. Map, Journal, Feedback, etc.) can be set to private or public. This setting affects the way that organisational and personal data is shared within the app. If the Map app is set to private, all other apps will be automatically set to private.

• Private – Only those who are logged in with a Peerdom account associated with your organisation will have access to the content in the app. The access rights category (see below) determines what information is visible within the app. By activating a shared private link, you can provide Guest access to a private app.
• Public – Any visitor to your Peerdom address (e.g. https://peerdom.org/organisation-name) will have access to the app with Guest access rights (see below). Those who visit a public app while logged in with a Peerdom account associated with your organisation will have access to your organisation’s data according to their access rights (see below).

In addition to the public/private setting for each app, Peerdom has four categories of data access rights.

• Guest – Can view app content for a specific app. For the Map, this includes your organisation’s structural data (e.g. role descriptions and assignments), as well as some personal data (e.g. names, profile photos). Email addresses are not visible.

Visitors of public apps or to those accessing a private app via a private shared link are given Guest access rights.

• Member – Can view all app content for all activated apps within the organisation. For the Map, this includes your organisation’s structural data (e.g. role descriptions and assignments), as well as all personal data (e.g. names, email addresses, profile photos). Members can also edit their own Peerdom profile (name, email address, photo).
• Editor – Can view, add, edit, and remove app content as well as invite new peers to the organisation with Member access rights.
• Owner – Can view, add, edit, and remove app content as well as invite new peers as Members, Editors, or Owners, administrate peer access rights, request data exports and data removal. Owners are the organisation’s representatives.

Data retention

Customer data

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 (see Access Rights section above).

When supporting an organisation, a limited number of Peerdom employees may be granted permission to access your data. Prior consent to access organisational data is required. Peerdom employees are bound by a non-disclosure agreement.

Personally identifiable information (PII)

Peerdom collects the following personally identifiable information.

• Full names
• Email address
• Job roles (positions)
• Login details (* except for login via single-sign on providers)
• Anonymised IP addresses (if product analytics tracking is enabled)
• Photo
• Birth date (only if Salary app is activated)

We process these data on behalf of the organisation to provide our main service (a cloud-based, SaaS organisational mapping tool). We collect and process this data only to provide you direct value. We will never sell, trade, or provide your personal data to third parties without explicit consent.

• The nature of operations carried out on the data is collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, erasure and/or destruction of personal data.
• The purpose of the processing is to allow your organisation and its members to map and explore organisational roles and responsibilities, contact one another, and understand who is working on what.
• The data subjects in our case consist of people working in an organisation.

Termination of trial period or subscription

If the organisation does not choose to subscribe following the free trial period, or to not renew their subscription, the organisation will become locked. Members can continue to consult a locked organisation but access rights for all members will be set to Member (read-only).

After three months of inactivity, the organisation will be archived. Archived organisations cannot be consulted, but the organisational data remains safely stored for easy retrieval.

In cases of longterm inactivity, Peerdom may elect to flag organisational data for deletion. In this case, the representatives will be contacted and offered to subscribe, extend the grace period, export or delete their data. In the absence of a response, the organisation’s data will be fully deleted after 7 days (with a 7-day retention).

Deleting customer data

The organisation has the right to delete their organisational data at any time. Data deletion requires support intervention, and the request must come from a representative of the organisation. Upon request from an organisational representative, we are also able to remove specific items from the database.

Following data deletion, backups remain for 7 days and are then permanently deleted. Following this, we do not continue to store the deleted data on our servers in any way.

Exporting customer data

Data portability and no vendor lock-in are priorities for us. Take your data with you to another service or see what we have on record by requesting a full data export. These exports include all stored organisational data (peer information, circle and role descriptions, and Application data). Organisation data exports will only be provided to organisation representatives. Personal data exports can also be requested for individual data that is not associated with an organisation (i.e. name, email address, photo).

Product analytics

Peerdom uses Matomo analytics to collect general usage data on the Application in order to better inform our design process. Product analytics data is stored on a private server hosted by Exoscale, a datacentre located in Zurich, Switzerland. This data is never transferred or shared with third parties.

By connecting to Peerdom, the anonymised 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 are collected.

All information is anonymised and is not linked in any way to Peerdom user accounts. We also have enabled cookie-less tracking, meaning that no personally identifiable information can be aggregated across multiple visits. Furthermore, the “Do Not Track” preference is enabled for users who wish to opt-out of tracking.

Organisation-wide settings are available to fully opt-out of product analytics tracking. Only those with Owner access rights can enable or disable product analytics for the entire organisation.

Logging

Access logs

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.

Log management

All logs are sent in real time to Google Cloud Logging with a 30-day retention period.

Application

Code

All application code is stored in Git code repositories on Gitlab.com.

Open-source version tracking

Using Renovate, we additionally check for the newest versions of every code dependency in our code base with each new, bi-weekly release.

Encryption

Authentication

All user passwords are hashed using bcrypt in combination with a salt, prior to storage in our database..

Data in transit

Data transfer from Peerdom to the end user is secured with an AES-256 bit SSL certificate. Data traffic is encrypted via up-to-date, recommended protocols, and implementation is guided by current best practices, for example a TLS version > 1.2.

Data at rest

Peerdom stores three types of data at rest: Profile images, access logs, and the database (see Servers below). For all these data, we have selected Encryption at Rest as a default for our Google Cloud Platform configuration. See https://cloud.google.com/security/encryption-at-rest/ for more information.

Profile images are stored in a separate folder for each organisation. The file and organisation names are anonymised using UUIDv4, and the image data is encrypted at rest.

Infrastructure

Datacenter

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.

Servers

We are using a Google App Engine flexible instances to run Peerdom’s container. The database is run upon Google Cloud SQL (PostgreSQL).

Hardening

By default, SSH access is disabled. Remote access to servers by our infrastructure team (restricted to three people) is enabled exclusively through the Google CLI which activates a SSH server on demand. Connection to this temporary SSH server authenticated on the Google Identity platform. Google Cloud ensures keeping our core software (operating system and infrastructure) up to date. By default, GCP also enforces strict firewall rules for inbound traffic and only publicly expose the necessary ports. The GCP also eliminates deprecated ciphers and protocols and adheres to safe TLS protocols (> TLSv1.2).

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

Server software

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. Regular updates to the PaaS components (i.e. operating system, database) are provided through the Google Cloud Platform.

Hostile attack prevention

Firewalls are configured according to the approved industry standards, managed by Google AppEngine.

Annual penetration tests

Each year, we hire an external security auditor to perform a network pen test which also covers application and API testing. The results of their audit, including our response and response time to any reported vulnerabilities, is published in a report. This report can be requested at any time.

Any major changes to our infrastructure or code base may also trigger additional pen tests in addition. Additional pen tests can also be requested for tailored security audits.

Backups

Database

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.

Files

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.

Business continuity

We believe that the best way to prevent security incidents is through preventative measures. Above we have described many of our proactive techniques and security rituals to prevent incidents. In the unlikely case of an incident, we describe here how we handle things retrospectively.

Monitoring

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.

Incident management protocol

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.

Communication

In the unlikely event of downtime or other security incidents, we communicate via our Twitter account at: https://twitter.com/@peerdomorg

Service termination

If we were to ever decide to cease doing business as Peerdom, our clients will be immediately informed. From that point, we will continue to host all organisations’ data for 30 days. We will provide full exports of the organisational data to all organisations hosted on Peerdom’s infrastructure and make the Peerdom source code publicly available so that organisations can continue to host Peerdom on their own servers.

Physical Security

Datacentre staff

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.