We believe all teams have potential to do amazing things. Our mission is to unleash the potential in every team of every size and industry, and in turn, help advance humanity through the power of software.
We know that your mission is as important to you as our mission is to us, and information is at the heart of all our businesses and lives. This is why customer trust is at the center of what we do and why security is our top priority. We're transparent with our security program so you can feel informed and safe using our products and services.
Read more about our approach to security and learn about how customers can play their part.
The information on this page applies to Atlassian Cloud products Jira, Confluence, Bitbucket, and Stride unless otherwise noted.
Table of Contents
- What we do
- Building security in
- Product Security
- Operational Practices
Our Security Management Program takes each of our customers' security requirements into consideration and arrives at a set of requirements and initiatives unique to us and our environment. Details of our initiatives are provided on the Atlassian Trust site, where you can download or request our certification reports for ISO 27001 and SOC2 and review our CSA STAR questionnaire, as well as details about our Security Management Program.
We don't look at security as a destination to reach — it's an ongoing journey. We continually strive to improve our software development and internal operational processes with the aim of increasing the security of our software and services. The secure way should be the easy way, and that's why security is built into the fabric of our products and infrastructure. Here are a few ways we build security in as part of the way we work, day-to-day.
Security is front of mind when designing our applications, networks, and business processes
The Atlassian Cloud security architecture is designed with consideration of a broad range of industry standards and frameworks and in tandem with our internal threat modeling process. It's designed to balance the need for flexibility with the need for effective controls to ensure confidentiality, integrity, and availability of our customers' data.
App dev security, data security & information lifecycle management.
Crypto & encryption, threat and vulnerability management, security incident management
Asset management, access control, operations, communications security
Data center & offices
Physical and environmental security
Security governance, organization of security, personnel security, supplier & third-party data management, mobile security, business continuity, audit/compliance, privacy.
The security controls that inform our architecture are designed to align with a number of different standards, and due to many of the overlaps between these standards, we’ve built our own controls framework. This framework provides us a single list of things to focus on and effectively maps to the various standards that we comply against, as shown in Table 1 below.
International Organization for Standardisation
International Organization for Standardisation
Payment Card Industries
Cloud Security Alliance
Service Organisation Controls
SOX 404 (IT)
US Federal Law
If you are interested in the details, read more about our Common Controls Framework.
We have strict network controls with a focus on the sanctity of the “production” environment
Traditional network security theory separates the world into “inside“ and “outside” and focuses on the control points between the two areas. While we maintain strict control between our internal networks and the internet, we focus primarily on the delineation between our "production" and "non-production" environments.
We control access to our sensitive production networks through the use of strict firewall rules and require multi-factor authentication and encrypted connections. We've also implemented intrusion detection and prevention systems in both our office and production networks to identify potential security issues.
Threat modeling is used to ensure we’re designing in the right controls for the threats we face
During the product planning and design phase, we use threat modeling to understand the specific security risks associated with a product or feature. Generally speaking, threat modeling is a brainstorm session between engineers, security engineers, architects, and product managers of an application or service. Threats are identified and prioritized, and that information feeds controls into the design process and supports targeted review and testing in later phases of development.
We use the Microsoft Threat Modeling Tool and the STRIDE Threat Model framework. STRIDE is an acronym for a common set of security concerns: Spoofing, Tampering, Reputation, Information Disclosure, Denial of Service, and Elevation of Privilege.
We utilize threat modeling early and often and can ensure that relevant security configuration and controls are designed to mitigate threats specific to each product or feature we develop.
The criticality of our products will vary from customer to customer. From talking to our customers, we know that products like Jira and Confluence often end up being part of key business processes. We run our business on our own product suite, so we understand the importance of reliability and recoverability.
We operate multiple geographically diverse data centers
We host Jira, Confluence, and Bitbucket with our cloud hosting partners. These data centers have been designed and optimized to host applications, have multiple levels of redundancy built in, and run on a separate front-end hardware node on which application data is stored.
We care about high availability of your data and services. We focus on product resiliency through standards and practices that allow us to minimize downtime. Our resiliency practices are based on SOC2, ISO 27002 and ISO 22301. Key principles guiding our Disaster Recovery (DR) Program include:
- Continual improvement. We strive to ensure our improvements to resiliency grows through operational efficiencies, automation, new technologies and proven practices.
- Assurance through testing. We only know it works if we test it. With regularly scheduled testing and continual improvements, we are able to keep our DR Program at an optimum.
- Dedicated resources. Atlassian has dedicated teams to ensure our customer-facing products get the attention they need to make the Disaster Program possible. We have people on the ground to support our steering committee, risk assessments, business impact analysis, and testing.
In addition, Jira and Confluence cloud infrastructure is implemented with industry-leading services such as Amazon Web Services, resulting in optimal performance with redundancy and failover options globally. We maintain three regions and availability zones across east and west regions of the U.S. as well as the European Union.
Our Bitbucket data center hosting partners are SOC-2 and ISO27001 certified for security and availability and also provides us sufficient assurance that aspects such as physical security, network and IP backbone access, customer provisioning and problem management are controlled at a level that we require and demand.
We have an extensive daily and weekly backup regime
In addition to platform-wide resiliency, we also have a comprehensive backup program for our Software-as-a-Service (SaaS) offerings.However, restore and recovery of these backups will only be provided on our own platform. Application data is stored on a RAID 10 (mirrored and striped) storage node that's replaced to a secondary storage node every four hours. If the primary storage node has a problem or becomes unavailable, the applications can be switched over to the secondary storage node.
Application database backups for Atlassian Cloud occur on the following frequencies: daily automated backups are performed and retained for 30 days; daily manual snapshots of the standby RDS instance are sent to the secondary region and are retained for 30 days; snapshots of cross-region replicas will provide the ability to restore data in case of AWS region loss and cross-region replica loss. All backup data is encrypted. For more information, see our Infrastructure page.
We have comprehensive, tested business continuity and disaster recovery plans
We are determined to not #@!% our customers, and strive to maintain strong Business Continuity (BC) and Disaster Recovery (DR) capabilities to ensure that the effect on our customers is minimized in the event of any disruptions to our operations.
Our Disaster Recovery Program consists of a few key practices to ensure the appropriate levels of governance, oversight, and testing:
- Governance. Leadership involvement is key to how we run our DR Program. With leadership involved, we have both business and technical drivers accounted for in our strategy for resilience.
- Oversight and maintenance. We take a disciplined governance, risk, and compliance approach when monitoring and managing our DR program. It enables us to operate more efficiently and effectively when monitoring, measuring, reporting, and remediating key activities within our DR program. Site Reliability Engineers are committed to ongoing Disaster Recovery meetings and represent their critical services. They discuss identified DR gaps with the risk and compliance team and focus on the appropriate levels of remediation as necessary.
- Testing. We conduct regular testing and strive for continual improvement as part of our DR lifecycle to ensure your data and the use of your data is highly available and performant.
- We test for levels of resiliency across AWS Availability Zones so we can handle an Availability Zone failure with minimal downtime.
- We take our data backups across AWS regional datacenters. If a region is down, we protect your data in a secondary region in the event of a catastrophic incident.
- We test for AWS region failures. We understand that a complete region failure is highly unlikely. However, we continue to test our ability to fail over services and continue to mature our regional resiliency.
- Backup and restore procedures are in place and tested on a regular basis. This means that when data needs to be restored, we're prepared to get you up and running with well-trained support staff and fully tested procedures.
In addition to assurance of resiliency through governance, oversight, and testing, Atlassian emphasizes on continual improvement throughout the DR Program:
We publish our service availability status in real-time to ensure you can access your data when you want.
One of our industry's challenges is to ship secure products while maintaining a healthy speed to market. Our goal is to achieve the right balance between speed and security — after all, we run almost everything on our own software at Atlassian. There are a range of security controls we implement to keep our products and your data safe.
All data sent between our customers and our applications is encrypted in transit
All data for our services is encrypted in transit over public networks using Transport Layer Security (TLS) with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.
Content stored within Jira Cloud and Confluence Cloud isn't encrypted. However, attachments on storage in AWS are encrypted. We believe we can rely on the physical controls and management at AWS, as well as transit-level encryption to protect customer data. A minimum of 128-bit Advanced Encryption Standard (AES) is used for attachments.
Customer communication is encrypted end-to-end for Stride. Encryption keys created by customers are used for authentication and push and pull requests in Bitbucket. All off-site backups are encrypted.
Due care is given to managing encryption keys within Atlassian. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.
We take innovative approaches to building quality software
We step outside the traditional realm of Quality Assurance (QA) to ensure new features are introduced quickly and safely by adopting the notion of Quality Assistance*. We focus on inculcating a "whole team" mentality to quality by changing the role of QA to a facilitator rather than the person who does the actual QA work. We also are actively working to empower and educate developers to test their own features to our quality standards.
While we consistently strive to reduce the number of vulnerabilities in our products, we recognize that they are, to an extent, an inevitable part of the development process. Through our bug bounty partnership, we aim to increase the cost of finding and exploiting vulnerabilities over time, which makes the required investment of time and resources for the "bad guys" to find additional vulnerabilities stops being attractive.
*Note: The term Quality Assistance was initially coined by Cem Kaner, and if you’d like to find out more about it and about our overall quality process, read our series of blog posts covering QA.
We have both internal and external security testing programs with our bug bounty
Our approach to vulnerability management for our products consists of internal and external security testing. Known issues are made available through our public bug tracker.
This approach spans planning, development and testing phases, each test building on previous work and progressively getting tougher. We have an established approach to static and dynamic code analysis at both the development and testing phases. In the development phase, we focus on embedding code scanning to remove any functional and readily identifiable, non-functional security issues.
In the testing phase, both our development and security engineering team switch to an adversarial approach to attempt to break features using automated and manual testing techniques.
Our security engineering team has developed a wide range of security testing tools to automate common tasks and make specialized testing tools available to our product teams. These tools are beneficial for the security team and they empower developers to "self-serve" security scans and take ownership of the output. Our security engineering team are subject matter experts, but it's ultimately every developer in our company who is responsible for their own code.
Once a release moves to production, external testing takes over. This approach is built around the concept of "ongoing assurance"; rather than relying solely on a point-in-time penetration test, we have an always-on, always-testing model through the use of a public, crowd-sourced bug bounty model.
When a vulnerability is identified by one of our users during standard use of a product, we welcome notifications and respond promptly to any vulnerabilities submitted (detailed on our Vulnerability Information Report). We keep the submitter updated as we investigate and respond to the issue.
Specialist security consultants are used to complete penetration tests on high-risk products and infrastructure, like a new infrastructure architecture (e.g., our cloud environment), a new product, or a fundamental re-architecture (e.g., the extensive use of micro-services.)
Our approach to penetration testing is highly targeted and focused. Tests will generally be:
White box: Testers are provided design documentation and briefings from product engineers to support their testing
Code-assisted: Testers have full access to the relevant code base to help diagnose any unexpected system behavior during testing and to identify potential targets
Threat-based: Testing focuses on a particular threat scenario, such as assuming a compromised instance exists, and testing lateral movement from that starting point
We don't make these reports or extracts available externally due to the extensive information made available to the testers in conducting these assessments. The majority of these systems and products will subsequently be included in our public bug bounty program, providing additional on-going external assurance our customers seek.
As much as securing our products is a priority, we also understand the importance of being conscious of the way we conduct our internal day-to-day operations. The concept of “building security in” is the same philosophy we use with our internal processes and influences how our business is conducted.
Access to customer data stored within applications is restricted on a 'need to access' basis
Within our SaaS platform, we treat all customer data as equally sensitive and have implemented stringent controls governing this data. Awareness training is provided to our internal employees and contractors during the on-boarding / induction process which covers the importance of and best practices for handling customer data.
Within Atlassian, only authorized Atlassian employees have access to customer data stored within our applications. Authentication is done via individual passphrase-protected public keys, and the servers only accept incoming SSH connections from Atlassian and internal data center locations.
Unauthorized or inappropriate access to customer data is treated as a security incident and managed through our incident management process. This process includes instructions to notify affected customers if a breach of policy is observed.
Physical access to our data centers, where customer data is hosted, is limited to authorized personnel only, with access being verified using biometric measures. Physical security measures for our data centers include on-premise security guards, closed-circuit video monitoring, man traps, and additional intrusion protection measures.
Our support teams will only access customer data when necessary to resolve an open ticket
Our global support team has access to our cloud-based systems and applications to facilitate maintenance and support processes. Hosted applications and data are only able to be accessed for the purpose of application health monitoring and performing system or application maintenance, and upon customer request via our support system.
Our security training and awareness program doesn't just check compliance boxes but results in a genuine uplift in knowledge across the company
Our awareness program is built on the premise that security is everyone’s responsibility. These responsibilities are extracted from our internal Security Policy Program, and the training and awareness program is used as the primary vehicle for communicating these responsibilities to our staff.
Candidates and contractors are required to sign a confidentiality agreement prior to starting with us, and subsequently, during the onboarding process, security awareness courses are delivered to these new hires.
Keeping in line with the theme of ‘continuous improvement’, we disseminate security messages through company-wide email messages and blog posts. These messages generally carry a message that is relevant at that time, e.g. a newly discovered and publicised threat, and reinforces the importance of following security good practices.
We recognize that there are some great security thinkers outside the security team, and seek to utilize their enthusiasm and knowledge
Separate to our awareness program, we have also set up an internal "Security Champions" program. The idea behind this program is to try and get security embedded into every team at Atlassian - to build security in. We also want to make security more accessible, and one of the ways that we're doing this is by training people across the organization with core security knowledge - whether operational or development. This is about taking subject matter experts with a passion and aptitude for security and drafting them into the team on a part-time basis and to be our advocates in the rest of the company.
We have embraced open source style change management
Traditional change management processes rely on a pyramid-style change control hierarchy. When someone wants to make a change, it has to be presented to a board that either approves or denies it. We have embraced something we call "Peer Review, Green Build." Each change, whether going into our code or infrastructure, has a requirement to be reviewed by one or more peers to identify any issues the change may cause. We increase the number of reviews based on the criticality of the change or product. We trust our development teams and engineers to identify security issues and performance issues, and to flag the change before we allow it to go through. Relatedly, we use our own continuous integration tool, Bamboo, to identify whether any of the changes, once merged into the main branch, will create issues through our integration, unit, functional or security tests. If there are no issues identified in the build and test phases, Bamboo will signal a green dot and identify the build process was successful. If there are issues, Bamboo will signal a red dot and the merge will then be re-evaluated to identify the changes that are causing it. Our "Peer Review, Green Build" control helps identify the thousands of changes we make a week.
We strive to hire the best
Just like any company, we want to attract and hire the best and the brightest to work for us. During our weekly Global Town Hall meetings, we commonly welcome all new hires and challenge them to "do the best work of your lives" and to "seek to change Atlassian - for the better" - we want their wealth of talent make us a better company each day and each week. During recruiting, we perform employment, visa, background and financial checks. On acceptance of an offer, we ensure each new hire has a 90-day on-boarding plan and access to on-going training based on their role.
We acknowledge that there is always margin for error. We want to be proactive in detecting security issues, which allows us to address identified gaps as soon as possible to minimize the damage
Incidents will happen, but our speed and efficiency in response will keep the impact as low as possible
The security team at Atlassian aggregates logs from various sources in the hosting infrastructure and makes use of a SIEM platform to monitor and flag any suspicious activity. Our internal processes define how these alerts are triaged, investigated further, and escalated appropriately. Our customers and the wider community are encouraged to report suspected security incidents through Atlassian Support.
In the event of a serious security incident, Atlassian has access to the expertise internally - and through external subject matter experts - to investigate incidents and drive them until closure. The database of our security incidents is cataloged against the VERIS Framework.
Read more about our incident response approach.
We have an extensive vulnerability management program to ensure that we are actively seeking out weaknesses that may be present in our environment
Apart from our product-specific vulnerability management practices (discussed earlier), our security team performs on-going network vulnerability scans of both our internal and external infrastructure using an industry leading vulnerability scanner. Scan results of our cloud instances are posted online by the security team on the third Wednesday of every month. More information about this process is available on our Trust FAQ.
We also use specialist security consulting firms to complete penetration tests on high-risk products and infrastructures. Examples of this might include a new infrastructure set up for us (e.g. our Cloud environment), a new product (e.g. Stride), or a fundamental re-architecture (e.g. the extensive use of micro-services).
Internal processes are in place to review any reported vulnerabilities and act on them. The process includes predefined SLAs for patching vulnerabilities based on CVSS severity level. Read more about our Security Bug Fix Policy.
Our bug bounty program ensures that our systems are constantly being tested
At the core of our approach to security bug management is our bug bounty program which ensures that our products are being constantly tested for security vulnerabilities. In a truly agile development environment with frequent releases, continuous testing is a necessity. We believe the crowd of independent security researchers participating in our bug bounty provides the most effective external security testing process and way of achieving this.
Over 25 of our products or environments, ranging from our server products, mobile apps and Cloud products are in-scope for our bug bounty program, with over 500 testers registered. Details of the number of vulnerabilities reported, our average response time, and average payout, are all included within our Bug Bounty program.
We run our security program in compliance with a range of well-known industry standards. We appreciate that these attestations matter, as they provide independent assurance to our customers that we are on the right track. Read more about our Security Management Program.
SOC 2, ISO27001, PCI DSS and CSA STAR are standards that we certify against at the moment. More details about these programs are available on our Compliance page.
International Organization for Standardisation
Atlassian has been accredited to ISO27001, for the scope of operations described in our certificate of accreditation. In short, our security team is currently certified for its security engineering, security intelligence, and security projects functions. The scope of accreditation is currently being expanded across the organization.
International Organization for Standardisation
Atlassian is currently extending its security and privacy controls throughout the business to meet the requirements of ISO27018 as parts of its GDPR compliance program.
Payment Card Industries
Atlassian is a PCI DSS compliant merchant for receiving purchases related to our products. However, Atlassian products are not meant to process or store credit card data for our customers.
CSA CCM / STAR
Cloud Security Alliance
Atlassian has created a STAR Registry Entry covering the JIRA & Confluence Cloud, Bitbucket, and HipChat services.
Service Organisation Controls
Atlassian is SOC2 certified for our Bitbucket and JIRA & Confluence Cloud products.
We also perform comprehensive security audits through well-known audit firms, which is done at least annually.
Outputs arising from these audit and certification programs, coupled with our internal process outputs, such as vulnerability management, are all fed into a continuous improvement cycle which helps us keep sharpening the overall security program.
We appreciate our customers’ concerns about privacy – and we understand that these concerns are probably the same concerns we ourselves have when using SaaS-based applications. So, fundamentally, we try to treat your personally identifiable and other sensitive data the same way we would want our service providers to treat our data.
Atlassian and its subsidiaries comply with the EU-US Privacy Shield Framework and the associated Privacy Shield Principles for the collection, use, and retention of personal information transferred from the European Union to the US.
Atlassian publishes an annual Transparency Report which details government requests we receive for our users’ data, as well as to remove content or suspend user accounts.
In the cloud, the security of your data on our systems is a joint responsibility. This shared responsibility is addressed more extensively in our recently published whitepaper “The Atlassian Cloud Security Team (You’re part of it)”.
At a high level, Atlassian handles security of the applications themselves, the systems they run on, and the environments those systems are hosted in. We ensure these systems and environments are compliant with relevant standards including PCI DSS and SOC2 as required.
You – our customers – manage the information within your accounts, manage the users accessing your accounts and related credentials, and control which apps you install and trust. You ensure your business is meeting its compliance obligations in using our systems.
In brief, here are a few things that we would like our customers to consider:
The decisions you make about how you set up our products have a significant influence on the way security is implemented. Key decisions are:
- All products – Domain verification & central management. You can verify one or multiple domains to prove that you or your organization owns those domains. Domain verification allows your organization to centrally manage all its employees' Atlassian accounts and apply authentication policies (including password requirements and SAML). After verifying your domain, all users with existing Atlassian accounts under that domain will receive an email explaining that they are transitioning to a managed account. Anyone signing up to a new Atlassian account with that domain will see that they are getting a managed account.
- Bitbucket – Public vs Private repositories. You designate whether the repositories are public (meaning that anyone coming to the Bitbucket website can view them) or private (meaning that access to those repositories will be limited to those who have permission to access the repositories).
- All products – Granting access. Our products are designed to enable collaboration. Collaboration requires access. But you do need to be careful about granting permissions to access your data to other users, and to apps. Once you grant such permissions, we will not be able to prevent those users from taking the actions allowed under those permissions, even if you don’t approve of those actions.
Being a SaaS solution, our customers are responsible for ensuring the appropriateness of user access to their data. Understanding the classification of the data that goes into the system, and ensuring that users that have access to the system are authorized to access that data are key considerations in this context.
Where applicable, using role-based authentication will make it easy to align with access restrictions that may need to be imposed to comply with data classification and handling requirements.
Encouraging users to practice good password hygiene will also mitigate threats such as password guessing and malicious parties reusing leaked credentials from materializing.
The Atlassian Ecosystem consists of Atlassian as the service provider, customers and their respective users, and the Marketplace. Our customers have full control over which apps they choose to install. At installation, the installer (typically a user administrator), will be able to review permissions granted to the apps. It's important for customer admins to pay attention to these permissions. Once permission is granted, we will have very little visibility as to how the app uses customer data.
Customers are expected to verify the app developer and the suitability and reasonableness of permissions requested by the apps prior to installation. Once the add-on is installed, monitoring app activity and reporting suspicious activity will help us keep the Ecosystem clean.
Want to dig deeper?
We’ve referred to quite a few other documents and resources on this page and we encourage you to dig into them if you want to understand more about our approach to security and trust.