Please defer to https://www.atlassian.com/trust; this page documents the specifics of statuspage.io.
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:
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 'Owner'.
Can we restrict which person can see a page, or parts of a page?
Yes. We offer our Access Control feature to allow fine-grained control over what is exposed to a given set of access credentials.
Can we leverage an existing credential store (e.g. single sign on, SAML, etc)?
Yes, we have full support for federated login via both SAML and Google authentication.
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.
Do account owners have direct control over team members? Can owners immediately invalidate team members sessions in the event of unauthorized access or involuntary termination?
Yes, owners 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.
All our change management is encapsulated by our agile development:
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:
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.
How do you protect against availability and data failures?
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.
Do you store any private, personally identifiable information (PII)?
Yes, we store emails, phone numbers, and full names.
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?
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.