Security practices

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, and Bitbucket unless otherwise noted.

What we do

Our Atlassian Trust Management System (ATMS) 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 Atlassian Trust Management System (ATMS).

Building security in

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.

Standard Sponsor Controls Domains


International Organization for Standardisation

26 requirements

6 clauses


International Organization for Standardisation

114 requirements

14 domains


Payment Card Industries

247 requirements

6 domains


Cloud Security Alliance

133 controls

16 domains


Service Organisation Controls

116 requirements

5 principles

SOX 404 (IT)

US Federal Law

22 requirements

5 domains



106 requirements

10 Domains

If you are interested in the details, read more about our Common Controls Framework.


We practice a layered approach to network access, with controls at each layer of the stack

We implement controls at each layer of the stack, dividing our infrastructure by zones, environments, and services.

Zone restrictions include limiting office, data center, and platform network traffic. Environment separation limits production and development connectivity. Services must be explicitly authorized to communicate with other services through an authentication whitelist.

We control access to our sensitive networks through the use of virtual private cloud (VPC) routing, firewall rules, and software defined networking. All connectivity is encrypted by default.

Staff connectivity requires device certificates, multi-factor authentication, and use of proxies for sensitive network access. Access to customer data requires explicit review and approval.

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.

Platform-wide Availability and Redundancy

We operate multiple geographically diverse data centers

We host all of our cloud applications with our cloud hosting partners, AWS and NTT. Thier 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.

Jira, Confluence, Statuspage, Trello, Opsgenie and Jira Align is hosted with the industry-leading cloud hosting provider Amazon Web Services (AWS), resulting in optimal performance with redundancy and failover options globally. We maintain multiple regions and availability zones across east and west regions of the U.S., the European Union and APAC.

Our Bitbucket data center hosting partner is NTT, who is SOC2 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.

For more information on how we utilise multiple data centers and availability zones for high availability, see our Customer Data Management page and our Cloud Hosting Infrasructure page.


We have an extensive backup program

Application data is stored on resilient storage that's replicated across data centers. In addition to platform-wide resiliency, we also have a comprehensive backup program for our Atlassian Cloud offerings. However, restore and recovery of these backups will only be provided on our own Atlassian Cloud platform.

Application database backups for Atlassian Cloud occur on the following frequencies: daily automated backups are performed and retained for 30 days with support for point in time recovery. All snapshot and backup data is encrypted. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We perform quarterly testing of our backups. For more information, see our Infrastructure page. For more information on how we have implemented a robust backup program, see our Customer Data Management page.

Business Continuity and Disaster Recovery

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:

  1. 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.
  2. 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.
  3. 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.
    1. We test for levels of resiliency across AWS Availability Zones so we can handle an Availability Zone failure with minimal downtime.
    2. 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.
    3. 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.
    4. 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. For more information on our disaster recovery testing and our business continuity program, see our Customer Data Management page.

We publish our service availability status in real-time to ensure you can access your data when you want.

Product Security

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.

Encryption and Key Management

Encryption in transit

All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ 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.

Encryption at rest

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest. Bitbucket does not offer encryption at rest for repositories at this time.

For encryption at rest, specifically we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments) or Confluence page data (page content, comments, attachments). Data encryption at rest helps guard against unauthorized access and ensures that data can only be access by authorized roles and services with audited access to the encryption keys.

Encryption key management

Atlassian uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.

Tenant Isolation

Tenant isolation ensures that, even though customers are sharing a common IT infrastructure, they are logically segregated so that the actions of one tenant cannot compromise the data or service of another tenant.

At Atlassian, our approach to tenant isolation varies across our applications, and we’ll be sharing the differences over time. For Jira and Confluence Cloud, which have evolved over the years into fully-fledged multi-tenant SaaS applications, Atlassian uses a concept we have called Tenant Context, implemented both in the application code, and managed by something we have built called the “Tenant Context Service” (TCS). This concept ensures that, in this shared environment :

  • Each customer's data is kept logically segregated from other tenants when at-rest; and
  • Any requests that are processed by Jira or Confluence have a "tenant-specific" view so other tenants are not impacted.

The TCS sits independently of Jira and Confluence, but is fundamental to their operation. In very broad terms, the TCS works by storing a "context" for individual customer tenants. This context includes a range of metadata associated with that tenant (such as which databases the tenant is in, what licenses the tenant has, what features they can access, and a range of other configuration information) and unique encrypted credentials. The context for each tenant is associated with a unique ID stored centrally by the TCS.

When a customer accesses Jira or Confluence Cloud, the TCS uses the tenant ID to collate that metadata, which is then linked with any operations the tenant undertakes in the application throughout their session. Importantly, the context provided by TCS effectively acts as a ''lens'' through which any interactions with customer data occur – and this lens is always confined to one specific tenant. This ensures that one customer tenant does not access data of another tenant – nor for one tenant to affect the service of another tenant through their own actions.

Read more about our Atlassian Cloud Architecture.

Product Security Testing

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.

Internal Testing

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.

External Testing

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. For more information about how we validate product security testing, see our Approach to External Security Testing page.

Product Vulnerability Management

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. For more information about how we validate product vulnerability management, see our Approach to External Security Testing page.

*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.

Operational Practices

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

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.

A broader policy governing access to customer data and metadata is included in our Privacy Policy.

Support Access

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.

Training and Awareness

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.

Security Champions

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.

Change Management

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.

Employee Hiring

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.

Customer Exit Procedure

If a contract between Atlassian and one of our customers using our cloud products ends, customer data will be removed from our cloud environment according to the timelines below.

Scenarios where customer contract can end include:

  • Missed payments: Where an existing customer misses a payment for their product subscription (whether monthly or annually);
  • Subscription cancellation: Where an existing customer cancels their subscription;
  • Evaluation period ends: Where the trial period for a customer evaluating one of our products chooses not to proceed to a paid subscription.

Missed payments

Where a customer misses a payment or the payment cannot be made, they are unsubscribed from all products 15 days after the due date for the payment. Once this occurs, their data is retained in cold backup for 60 days, after which it is deleted. Customers can ensure their data is not deleted by rectifying any missed payments within the 15 days. It is not possible to restore customer data after this timeline even if payment has been made.

Subscription cancellation

If a customer ends their subscription intentionally, customer data is deleted 60 days after current subscription period ends (for paid sites).

For Jira, if a customer unsubscribes from one Jira product (e.g. Jira Software) and retains another (e.g. Jira Service Desk), their Jira data will be retained. This includes situations involving evaluations; if the evaluation period for one Jira product ends, but the customer still has other Jira products on their subscription, their Jira data is retained. However, if they unsubscribe from all Jira products, their Jira data will be deleted immediately.

Similarly, if a customer removes Confluence from their Atlassian product subscription, this will immediately delete their Confluence data and remove Confluence access for all users.

Evaluation period ends

Where a customer’s evaluation period ends, and they choose not to proceed with a paid subscription, their data is deleted after 15 days (for evaluation sites)

Once customer data is deleted in any of the above scenarios, it cannot be recovered.

Data Destruction

Your data will be deleted 15 days (for evaluation sites) or 60 days (for paid subscription sites) after you have been unsubscribed due to missed payment for an Atlassian product subscription or you cancel your subscription.

What happens if I miss a payment or cancel an individual product subscription?

If payment fails for your Atlassian product subscription, you will be unsubscribed from all products 15 days after the payment due date, at which point users will no longer be able to access the product.

Canceling your Atlassian product subscription will prevent any further site renewals from being processed. Your site will remain accessible until 15 days after the end of your current subscription period, at which point your site will be deactivated.

Data retention

Your site will be deactivated 15 days after the end of your current subscription period. Atlassian retains data for deactivated sites for 15 days (for evaluation sites) or 60 days (for paid subscription sites) after the end of your current subscription period.

Evaluations for individual products on an annual Atlassian product subscription last for 30 days. If we fail to receive payment, you will be unsubscribed from Jira and Confluence products 17 days after the payment due date, at which point users will lose access to Jira and Confluence.

Confluence data will be deleted 15 days after the product is unsubscribed. If your evaluation for one Jira product (e.g. Jira Service Desk) ends but you still have other Jira products (e.g. Jira Software) on your annual subscription, your Jira data will not be deleted. Jira data will only be deleted if you unsubscribe from all Jira products.

Your data cannot be recovered after it's deleted. We strongly recommend creating a Confluence site backup or Jira site backup, as noted below.

How should I prepare my data to move to another site?

Security Processes

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.

Security Incident Management

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 security incident management process and about our shared responsibilities during a security incident.

Vulnerability Management

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. 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.

For more information on our security testing, see : Our Approach to External Security Testing.

For more information on our Vulnerability Management program, see : Atlassian Vulnerability Management.

Bug Bounty

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.

For more information on our security testing, see : Our Approach to External Security Testing.

Download current test reports

Any security vulnerabilities identified in the reports below are tracked in our internal Jira as they come through the Bug Bounty intake process and are closed according to the SLA timelines on our Security Bug Fix Policy.


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.

ISO/IEC 27001 also leverages the comprehensive security controls detailed in ISO/IEC 27002. The basis of this certification is the development and implementation of a rigorous security management program, including the development and implementation of an Information Security Management System (ISMS). This widely-recognized and widely-respected international security standard specifies that companies that attain certification also:

  • Systematically evaluate our information security risks, taking into account the impact of security threats and vulnerabilities
  • Design and implement a comprehensive suite of information security controls to address security risks
  • Implement an overarching audit and compliance management process to ensure that the controls meet our needs on an ongoing basis

View the Atlassian ISO/IEC 27001 Certificate.


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.

ISO/IEC 27018 is a code of practice that focuses on protection of personal data in the cloud. It is based on the information security standard ISO/IEC 27002 and provides additional implementation guidance for ISO/IEC 27002 controls applicable to public cloud Personally Identifiable Information (PII). It also provides a set of additional controls and associated guidance intended to address public cloud PII protection requirements not addressed by the existing ISO/IEC 27002 control set.

View the Atlassian ISO/IEC 27018 Certificate.


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.

When you pay with your credit card for Atlassian products or services you can rest assured that we handle the security of that transaction with appropriate attention. We are a Level 2 merchant and we engage with Qualified Security Assessor (QSA) to assess our compliance with PCI DSS. We are currently compliant with PCI DSS v3.2, SAQ A.

View or download our PCI Attestations of Compliance (AoC):


Cloud Security Alliance

A CSA STAR Level 1 Questionnaire for Atlassian is available for download on the Cloud Security Alliance’s STAR Registry web site.

The CSA Security, Trust & Assurance Registry (STAR) is a free, publicly accessible registry that documents the security controls provided by various cloud computing offerings, thereby helping customers assess the security of cloud providers they currently use or are considering contracting with. Atlassian is a CSA STAR registrant and Corporate Member of the Cloud Security Alliance (CSA) has completed the Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ). The latest version of the CAIQ, aligned to CSA’s Cloud Controls Matrix (CCM) v.3.0.1, provides answers to over 300 questions a cloud customer or a cloud security auditor may wish to ask of a cloud provider

See our Atlassian CIAQ entries at the CSA Star Registry.


Service Organisation Controls

Atlassian's Service Organization Control (SOC) Reports are certified by a third party and demonstrate how Atlassian achieves key compliance controls and objectives. The purpose of these reports is to help you and your auditors understand the controls established to support operations and compliance at Atlassian.

Atlassian has achieved SOC2 certifications for many of our products. Download Atlassian's SOC2 and SOC3 certifications here.

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.

GDPR Compliance

We are wholly invested in our customers' success and the protection of customer data. One way that we deliver on this promise is by helping Atlassian customers and users understand, and where applicable, comply with the General Data Protection Regulation (GDPR). The GDPR is the most significant change to European data privacy legislation in the last 20 years and went into effect on May 25, 2018.

We appreciate that our customers have requirements under the GDPR that are directly impacted by their use of Atlassian products and services, which is why we have devoted significant resources toward helping our customers fulfill their requirements under the GDPR and local law.

Below are several GDPR initiatives for our cloud products:

  • We have made significant investments in our security infrastructure and certifications (see security and certifications section).
  • We support appropriate international data transfer mechanisms by maintaining our Privacy Shield certifications, and by executing Standard Contractual Clauses through our updated Data Processing Addendum.
  • We offer data portability and data management tools including:
  • We have ensured Atlassian staff that access and process Atlassian customer personal data have been trained in handling that data and are bound to maintain the confidentiality and security of that data.
  • We hold any vendors that handle personal data to the same data management, security, and privacy practices and standards to which we hold ourselves.
  • We have committed to carrying out data impact assessments and consulting with EU regulators where appropriate.

Learn more about our approach and investment in GDPR on our Atlassian GDPR Compliance page.


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.

Our approach to privacy is laid out in detail in our Privacy Policy.

Handling Law Enforcement Requests

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.

Shared Responsibility

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.

Responsibility tree

In brief, here are a few things that we would like our customers to consider:

Key Decisions

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 on the internet can view those repositories) or private (meaning that access to those repositories will be limited to those who have permission to access the repositories).
  • Trello – Public vs Private teams and boards. In Trello, you can choose visibility settings for boards, including the ability to make boards public (with some limitations if your Trello account is managed). If a board is set to public, that means anyone on the internet can see it, and it may show up in search results from search engines like Google. Learn more about Trello’s board visibility settings here. You can also choose to make your team public so that your team profile can be viewed by anyone on the internet. Learn more about Trello’s Team visibility settings here.
  • 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.

User Access

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.