Usage and admin help
Account security information
Cloud Security Alliance questionnaire is available here: https://cloudsecurityalliance.org/star/registry/atlassian/
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:
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 'Owner'.
At this time, we do not offer access control lists, privileges, roles, or restrictions for team members. Any team member for an organization has full access to the organization.
All team members can invite new team members to the organization, but only the owner can delete other team members.
If your account has not opted in to using some form of SSO, we offer Google authentication for additional account security.
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.
Incident Response and Change Management
All our change management is encapsulated by our agile development:
Code changes require peer approval.
Code changes must meet all team standards of security, privacy, feature, and availability needs.
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:
Someone has, or may have, breached your private data.
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.
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 follower, we can "fail over" to a follower in a matter of minutes, ensuring that any data loss is measured on the order of single seconds.
In the event of a catastrophic failure affecting both the database leaders and followers, we have full backups we can restore. 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?
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.
Was this helpful?