Account security information

Access Management

What access does your staff have to client data? How are these staff accounts protected?
Our staff have unrestricted read access to our client's data; this is to help us better assist in specific cases where the app isn't behaving as expected. To counteract the risk these accounts pose, we have several mitigations:

• The staff accounts require 2-factor authentication.

• The staff accounts also require authentication via Google Apps.

• The staff accounts also require access to the Atlassian VPN.

How do you manage who has access to an account? How do you manage which user can access which functionality?
The people with access to an account are referred to as ‘team members', and the team member who owns the account is the 'Site admin’. Site admins manage the users and groups in Statuspage. They have access to the site's settings in Atlassian administration (admin.atlassian.com) and access to the products through this group.

• Site admins and organization admins can invite new team members to the organization. Only organization admins can deactivate or delete a user from organizations and across sites.

• G Suite and SAML single sign-on can be configured and managed in Atlassian administration. An Atlassian Guard Standard subscription is required for SAML single on.

Can we restrict which person can see a page, or parts of a page?
Yes. Audience-specific pages allow fine-grained control over what is exposed to a given set of users with pre-specified credentials.

Can we leverage an existing credential store (e.g. single sign on, SAML, etc)?
Yes, G Suite and SAML single sign-on can be configured and managed in Atlassian administration. An Atlassian Guard Standard subscription is required for SAML single on.

Do you store passwords?
We hash the password with bcrypt. At no point do we store or log the password.

Do you lock accounts for suspicious activity? Do you log people out after a certain amount of time?
We do detect suspicious activity, and we automatically log users out after one month; we do not allow customizing or controlling this.

Do you have password requirements? Can we impose additional requirements on passwords? Can we impose additional requirements on the max session time? Can we log users out remotely? Can we require passwords are periodically reset?
No; if you want additional security measures we recommend using SAML and imposing the security requirements on the identity provider itself. An Atlassian Guard Standard subscription is required for SAML single on.

Do site admins have direct control over team members? Can site admins immediately invalidate team member sessions in the event of unauthorized access or involuntary termination?
Yes, site admins and organization admins have full control over who is on the team and who is not. Removing a team member from an account results in an immediate loss of access, and adding a team member allows immediate access by the new user.

Do you offer periodic reports on user activity and access, page activity, or configuration changes?
No, but we do offer some insight into recent activity via the activity log.

Incident Response and Change Management

All our change management is encapsulated by our agile development:

1. Code changes require peer approval.

2. Code changes must meet all team standards of security, privacy, feature, and availability needs.

3. Changes breaking existing expectations must contact the customer as the change happens.

Will customers be informed of all changes in advance? Are there changes applied without notification?
Customers are only informed of changes if they are feature releases, fixes for bugs that the customer reported, or unexpected changes in the way the customer uses the product, especially the unexpected removal of features. Notification of said changes will only occur after they are in production; in the case that some customer preparation for a change is required, we will allow for the customer to adjust their configuration before the change is permanent. In very rare cases, we may make breaking changes without prior notification to preserve the health of the rest of the product or of the security and privacy of customer data.

Does an incident handling procedure exist?
Yes, at Atlassian we have extensive incident handling. We will notify you in at least these two cases:

1. Someone has, or may have, breached your private data.

2. Your account has suffered a loss of critical functionality or data that did not affect enough clients to be posted directly to www.metastatuspage.com .

However, we highly recommend subscribing to www.metastatuspage.com to receive the latest updates to the health of our service; this is the main way we contact our customers in the event of a widespread issue.

Disaster Recovery

How do you protect against availability and data failures?

• In the event of high traffic such as a DDOS attack on our service, we do not offer any guarantees as to the availability of your service. However, availability is a high priority to us and we have made extensive efforts internally to ensure that we have several mitigating controls to allow you to update your status page during such an event; we realize that this is likely to be particularly important for internet-scale issues.

• In the event of a database failure, we can "fail over" within a minute, ensuring that any data loss is measured on the order of single seconds.

• In the event of a catastrophic region failure affecting both the database leaders and followers, we have a database follower in alternate region we can activate. This will result in data loss and data recovery times on the order of hours before the resumption of service.

Do you monitor the health of your product?
Generally, we have many ways of tracking the health of the service. We aim to know about problems well ahead of any of our customers, and we build the product with a high level of resilience to begin with.

Data Security and Privacy

Do you store any private, personally identifiable information (PII)?
Yes, we store emails, phone numbers, and full names.

• Emails are provided by email subscribers, or from the team member login account.

• Phone numbers are provided by SMS subscribers, or may be provided by team members.

• The names are optional, opted in by each individual team member.

Do you encrypt your data in transit?
Yes, we use TLS v1.2

Do you encrypt your data at rest?
Yes, we use AES 256 disk encryption to ensure only we can access our databases.

Is unencrypted traffic restricted to private subnets?
Yes.

Do you allow staff to directly access the disk, the database, or other ways of bypassing app-level controls?
Yes, in some cases it is necessary for engineers to bypass application-level controls to validate a change, provide support, or respond to emergency situations. We log the details of each such authorized access and also regularly review the list of engineers who have such access.

Do you undergo security audits? Can we conduct our own? Can we see the results?
We have done security audits in the past. We use the "bug bounty" approach to security audits; we use bugcrowd to identify, triage, and fix problems, not to mention reward the people who found them. We do not recommend running security audits yourself without contacting us, because this will likely result in an automatic ban from accessing our service.