In order to secure our systems and the data we are processing we defined the following security policies which act as foundation for all of our internal and external processes.

We review these guidelines on a regular basis to adopt the polices to new security technologies, trends, and best practices.

If you have any questions, please contact use via our Support Center or via e-mail (security@weweave.net). Before sending and email, please read and accept our Privacy Policy.

General

We use secure connections for our data flows to encrypt the data with best practice industry standard security protocols.

For any logins we use strong passwords which are securely managed in a password manager. Securing logins with a second factor (multifactor authentication) is the preferred way to archive additional security.

Processes are in place to regularly check and update any third party dependencies in our systems.

Data storage and management

We protect our data (both internal data and customer data) from unauthorized access.

When technically possible, the following guidelines ensure additional security to end user and personal data:

• We encrypt data that is stored outside of the application (such as in backups).

• We permanently delete data that is no longer needed.

The following table lists all 3rd parties, which have any kind of access to our data. We explain for every partner what kind of access on which data exists and why.

Backups

Backups are created automatically on a regular basis.

Backup data is encrypted before storing it off-site. Our backup process includes all data (such as application data, infrastructure configuration, source code). In combination with our automation (see “Infrastructure Setup”), this enables rapid restores of our complete infrastructure and system stack within hours.

As part of our regularly infrastructure maintenance tasks, we check if backups can indeed be restored. The backup routine is monitored to prevent silent errors in backups or completely missing backups.

Infrastructure setup

We host all our infrastructure exclusively within data centers located in Germany. Processes to (re)deploy business-critical systems in another data center in case of technical problems/outages are in place. To ensure best performance worldwide, we employ a CDN system to serve all static content (see also section “Data storage and management“).

Our infrastructure configuration is managed as code for all aspects (i.e., software provisioning, configuration management, application-deployment). This allows us to quickly detect any possibly unauthorized or unwanted changes to the system configuration and to ease disaster recovery processes.

For additional hardening, decoupling apps requirements and dependencies of the host system, and to further strengthen data security, all our apps are confined within their own container and do not have access to other apps’ data. Additionally, security updates are applied automatically.

https://status.weweave.net/ provides a public uptime status monitoring of all our apps. Cloudflare provides a status page for their CDN.

In addition, we monitor all critical metrics of our infrastructure. As part of our regularly infrastructure maintenance tasks, we review both current and historical metrics, including, but not limited to CPU and memory usage, network traffic, disc usage and response times. This allows us to identify any resource shortage or possibly attempted attacks early enough before they could affect service quality.

Release management and source code

Release management is a documented process supported by automations for testing and deploying the changes. This allows rollbacks and rollforwards to be done within 60 minutes including a deployment to production.

We manage our apps’ source code in our internal source code control system. All code changes/commits are linked to a ticket in our internal ticket system. This provides an accurate history and changelog, to answer the question: What was changed when and why?

To reduce the chance of errors in production, we employ a combination of automated (i.e., unit and integration tests) and manual (with human interaction) tests. These tests are performed at least once before deploying any changes. Additionally, we use our source code control system to apply a four-eye principle for code changes. This ensures no code changes will be deployed without being reviewed and approved by another developer.

Incident management

Incidents are either reported via our uptime and resource monitoring or by our customers via our Support Center. Our developers are notified in real time if one of our uptime sensors reports an issue or if a customer opens a support request. We communicate with the customers via our support center. In case we have a technical problem, we open a ticket in our internal ticket system to track the overall progress, what effected the issue, and how we solved it.

Atlassian apps

In addition to the general policies listed above, the following policies apply to our Confluence and Jira apps.

Atlassian apps – Data storage and management

Our Atlassian Cloud apps do not store any personal data. We reduce the data our apps store permanently in their own database to a minimum. Whenever possible, we store the app’s data in the customer’s Confluence or Jira instance. In case we need to store data in the app’s database due to technical limitations in the Atlassian Cloud infrastructure, role-based access controls are in place to protect that data from unauthorized access. In general, none of our apps stores sensitive data (such as credit card data, personally identifiable information (PII), financial data, source code, trading algorithms or proprietary models) in its database. Technically, Atlassian’s SaaS platform (the ecosystem our apps are running in) can access the data that is sent from and to the end users.

Our Atlassian Server and Data Center apps store all data in the customer’s on-premises Confluence or Jira environment.

Atlassian apps – Backups

Backups are created automatically on a daily basis.

Backup data is encrypted before storing it off-site. Our backup process includes the app’s database, configuration, and the source code. The theoretical maximum data loss period (for the data stored outside the customer’s Jira or Confluence instance) a customer could experience would be less than 24 hours.

Atlassian apps – Security breaches

If a security breach was detected, we will report the incident by using the “Report security incidents” functionality provided in the Atlassian Marketplace’s vendor section.

Atlassian apps – Additional app programs

All of our Atlassian apps are part of the following Atlassian Marketplace programs:

• Marketplace Security Bug Bounty Program (see https://developer.atlassian.com/platform/marketplace/marketplace-security-bug-bounty-program/)

• Cloud Fortified Apps Program (see )

Exceptions are Atlassian apps that are new to the Marketplace and which are running through the required Atlassian's approval processes.