ENISA: European Network & Information Security Agency

The European Network and Information Security Agency (ENISA) is a center of network and information expertise. It works closely with EU member states and the private sector to provide advice and recommendations on good cybersecurity practices. ENISA also supports the development and implementation of EU policy and law relating to national information security.

The ENISA Cloud Computing Information Assurance Framework (IAF) is a set of assurance criteria that organisations can review with cloud service providers (CSPs) to ensure that they have sufficient protections in place for customer data. The IAF is intended to assess the risk of cloud adoption and reduce the assurance burden on CSPs.

Atlassian aligns to the IAF by way of Atlassian's adherence to the Cloud Security Alliance (CSA) Cloud Control Matrix (CCM), which maps CCM domains and controls to IAF assurance criteria, as well as certification against ISO 27001.

Atlassian maintains the following CCM-based assurances:

• CSA Star 1 Self Assessment

The following guidance provides assurance criteria to assist organizations in choosing a cloud service provider. If you have any questions about specific details, please contact our Enterprise Sales Team at https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

The majority of questions relating to personnel will be similar to those you would ask your own IT personnel or other personnel who are dealing with your IT. As with most assessments, there is a balance between the risk and cost.

6.01. (a)

What policies and procedures do you have in place when hiring your IT administrators or others with system access? These should include:

• Pre-employment checks (identity, nationality or status, employment history and references, criminal convictions, and vetting (for senior personnel in high privilege roles)).

In accordance with the laws of their residence, new Atlassians are required to complete a background check. In accordance with the laws of their residence, newly hired employees as a result of an acquisition have a background check performed after the acquisition date. A criminal check is run on all new hires and independent contractors - education verification, employment verification, or credit checks are added in if the role or level of the position requires it. We perform full background checks for senior executive and accounting roles.

6.01. (b)

Are there different policies depending on where the data is stored or applications are run?

• For example, hiring policies in one region may be different from those in another.
• Practices need to be consistent across regions.
• It may be that sensitive data is stored in one particular region with appropriate personnel.

Atlassian maintains restriction on the personnel that need access to our systems, applications and infrastructure for their job role and responsibilities on the basis of least privilege and this is enforced through our authentication processes. All access is through authenticated sessions, and based on established permissions.

All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

More broadly, controls related to access control are covered in the Access Management Policy, an excerpt of which is available here: https://www.atlassian.com/trust

6.01. (c)

What security education program do you run for all staff?

Atlassian provides information security training as an element of onboarding training ('Day 1') for new hires, and on an ongoing basis to all staff.

In addition to this general information security training, more targeted training is provided for our developers on secure coding, and is supported through our embedded security engineers program.

We also provide ongoing topical training related to malware, phishing, and other security concerns. For more information please see: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

We maintain formal records of completion of internal staff training. Employees are required to acknowledge the Code of Conduct and reaffirm on an annual basis. This policy is provided to all employees. Security awareness, confidentiality, and privacy requirements are presented in their day one trainings, and are available to all employees in Confluence.

6.01. (d)

Is there a process of continuous evaluation?

• How often does this occur?
• Further interviews.
• Security access and privilege reviews.
• Policy and procedure reviews.

Atlassian has achieved SOC2, ISO27001 and ISO27018 certifications for our cloud services. We perform both internal / readiness audits as well as external audits at least annually. Atlassian is ISO certified across a number of products, which requires regular risk assessments and reviews of data practices.

For more information, see: https://www.atlassian.com/trust/compliance. Customers should regularly download and review updates to our Compliance Certificates and Reports from this site.

Atlassian has a documented policy framework with our Security Policy as the primary policy. Our Policy Management Program (PMP) has been defined and includes ownership, availability, review cycle and outlines our general objectives. Our policies are reviewed at least annually and approved by senior management. More information about our PMP can be found at: https://www.atlassian.com/trust/security/security-management-program

We have also published excerpts of each of our high level policies with the tl:dr, which can be found at: https://www.atlassian.com/trust/security/ismp-policies

All systems and projects undergo an impact assessment as it relates to personally identifiable information.

Our Atlassian Third-Party Agreements include security and privacy provisions as applicable. New vendors to Atlassian are required to agree to our privacy and security policies in our contracts. Our legal and procurement teams review contracts, SLAs, and vendor internal policies to manage risks associated with security, availability, and confidentiality. Atlassian's Enterprise Risk Management (ERM) Program performs an annual risk assessment which incorporates likelihood and impact for all risk categories and is aligned with the COSO risk model. We also perform functional risk assessments as needed based on risk profile. Risk assessments are revisited as part of policy renewal and anytime the relationship with the supplier changes significantly.

6.02.

The following questions apply where the cloud provider subcontracts some operations that are key to the security of the operation to third parties (eg, a SaaS provider outsourcing the underling platform to a third party provider, a cloud provider outsourcing the security services to a managed security services provider, use of an external provider for identity management of operating systems, etc). It also includes third parties with physical or remote access to the cloud provider infrastructure. It is assumed that this entire questionnaire may be applied recursively to third (or nth) party cloud service providers.

6.02. (a)

Define those services that are outsourced or subcontracted in your service delivery supply chain that are key to the security (including availability) of your operations.

Atlassian works with third party sub-contractors to provide website, application development, hosting, maintenance, back-up, storage, virtual infrastructure, payment processing, analysis, and other services. A list of sub-processors currently engaged by Atlassian and authorized by Customer are listed at https://www.atlassian.com/legal/sub-processors.

6.02. (b)

Detail the procedures used to assure third parties accessing your infrastructure (physical and/or logical).

• Do you audit your outsources and subcontractors and how often?

Our legal and procurement teams review contracts, SLAs, and vendor internal policies to manage risks associated with security, availability, and confidentiality. We also perform functional risk assessments as needed based on risk profile. Risk assessments are revisited as part of policy renewal and anytime the relationship with the supplier changes significantly. Our Supplier & Third Party Data Management Policy covers this process, of which an excerpt is available here: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

Are any SLA provisions guaranteed by outsources lower than the SLAs you offer to your customers? If not, do you have supplier redundancy in place?

Depending on the license arrangement, our customer cloud terms should be reviewed either on Monthly subscription or Annual subscription renewal. Our legal and procurement teams review contracts, SLAs, and vendor internal policies to manage risks associated with security, availability, and confidentiality. Atlassian's Enterprise Risk Management (ERM) Program performs an annual risk assessment which incorporates likelihood and impact for all risk categories and is aligned with the COSO risk model. We also perform functional risk assessments as needed based on risk profile. Risk assessments are revisited as part of policy renewal and anytime the relationship with the supplier changes significantly.

6.02. (d)

What measures are taken to ensure third party service levels are met and maintained?

Our legal and procurement teams review contracts, SLAs, and vendor internal policies to manage risks associated with security, availability, and confidentiality. We also perform functional risk assessments as needed based on risk profile. Risk assessments are revisited as part of policy renewal and anytime the relationship with the supplier changes significantly. Our Supplier & Third Party Data Management Policy covers this process, of which an excerpt is available here: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

Can the cloud provider confirm that security policy and controls are applied (contractually) to their third party providers?

All systems and projects undergo an impact assessment as it relates to PII. Our Atlassian Third-Party Agreements include security and privacy provisions as applicable. New vendors to Atlassian are required to agree to our privacy and security policies in our contracts.

Our legal and procurement teams review contracts, SLAs, and vendor internal policies to manage risks associated with security, availability, and confidentiality. Atlassian's Enterprise Risk Management (ERM) Program performs an annual risk assessment which incorporates likelihood and impact for all risk categories and is aligned with the COSO risk model. We also perform functional risk assessments as needed based on risk profile. Risk assessments are revisited as part of policy renewal and anytime the relationship with the supplier changes significantly.

6.03.

It is expected that any commercial agreement with external providers will include service levels for all network services. However, in addition to the defined agreement, the end customer should still ensure that the provider employs appropriate controls to mitigate unauthorised disclosure.

6.03. (a)

Detail your change control procedure and policy. This should also include the process used to re-assess risks as a result of changes and clarify whether the outputs are available to end customers.

Atlassian has an Enterprise Risk Management (ERM) Program aligned with the COSO risk model and ISO 31000. The ERM Program implements a risk management framework and methodology across Atlassian, and performs annual risk assessments, periodic specific risk assessments of a product environment, and functional risk assessments as needed based on risk profile.

In particular, Atlassian's risk management framework provides standards, processes, roles and responsibilities, acceptable risk tolerances and directives for the completion of risk assessment activities. Our risk management processes and practices drive the completion of our risk assessments which are repeatable and produce results that are valid, consistent, and comparable. The risk assessments Atlassian performs incorporate likelihood and impact for all risk categories, and treatment of any and all risks over our internally set risk appetite. Throughout all stages of the ERM Program, the Risk & Compliance team communicate with the relevant stakeholders and consult with appropriate SMEs.

Personnel with a role in Atlassian risk management processes are adequately aware of, and trained in their responsibilities and performance of their duties. All risks are tracked and managed using our own Jira tool, with ownership at Management level with associated treatment plans and projects. For more information, see: https://www.atlassian.com/trust/security/security-management-program or https://www.atlassian.com/trust/compliance/risk-management-program

Our Atlassian Change Management process is slightly different than traditional change processes. We rely on a Peer Review and Green Build (PRGB) control on all changes, whether to code, application or infrastructure changes. Peer Review is configured in our CD tool, where critical branches must be designated to have multiple reviewers for each Pull Request. Commonly this is two developers and the Team Lead. The Green Build portion of the control means that the integration during the CI phase must pass all integration, functional, security and other tests that have been developed. If these tests fail (a Red Build), the code will not be merged and must be reviewed again and address the failures. Once a Green Build is successful, the binary is cryptographically signed and our production environment only runs binaries that are signed with our key. Our testing process includes both automated and manual assessment components. We love to blog about what we do well. Our approach to using 'Quality Assistance' (rather than traditional 'Quality Assurance') is something we are passionate about: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Define the remote access policy.

Remote access requirements are defined in the Access Management Policy and associated Standards. Customer data may be replicated onto employee workstations for support or migration purposes and with an active Customer Support Ticket. Strict firewall rules are in place thus limiting access to the production environment to our VPN network and authorized systems. Our VPN access requires multi-factor authentication.

All devices (Atlassian owned, or BYOD) used by Atlassian employees that may access ANY Atlassian tools are enrolled in device management using MDM software security profiles and security posture checking. Atlassian uses a Zero Trust security model for all Atlassian devices.Read more here:https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

Does the provider maintain documented operating procedures for information systems?

Atlassian's basic principles of operations security includes the development of standard operating procedure documents. We have also published excerpts of each of our high level policies with the tl:dr, which can be found at: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Is there a staged environment to reduce risk, e.g., development, test and operational environments, and are they separated?

Atlassian has information security policies prohibiting the use of production data in non-production environments, and any attempted data migration between the environments would be identified through the change management process. The code moves from centralized build system with unit testing first. Then into feature branch validation with additional test automation and gate reviews by PM, Dev, QA. Then into UAT, Security, and performance validation. Developers cannot promote code to production directly. Further details are available at https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

We maintain logical and physical separation of production and non-production (development) environments and methods are used to isolate these environments.

Our staging environment is logically separated (but not physically separated) but is managed under production-grade change control and access processes. For more information about our code security practices, see: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Define the host and network controls employed to protect the systems hosting the applications and information for the end customer. These should include details of certification against external standards (e.g., ISO 27001/2).

Atlassian Network Engineering uses IPS technologies built into our cloud and office firewalls, and Atlassian has implemented IDS technologies in our office environments. Network threat protection is performed by AWS, including DDoS protection and some Web Application Firewall features. All data for our services is encrypted in transit using TLS to protect it from unauthorized disclosure or modification, whether over HTTPS or SMTPS.

Atlassian has achieved SOC2, ISO27001 and ISO27018 certifications for our cloud services. We perform both internal / readiness audits as well as external audits at least annually.

For more information, see: https://www.atlassian.com/trust/compliance. Customers should regularly download and review updates to our Compliance Certificates and Reports from this site.

6.03. (f)

Specify the controls used to protect against malicious code.

Atlassian has implemented Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) for our Windows and Mac fleet. We do not use anti-malware on our Linux machines. Anti-malware is included in our vulnerability management policy.

We maintain a Threat and Vulnerability Management Policy. Our Policy Management Program (PMP) has been defined and includes ownership, availability, review cycle and outlines our general objectives. Our policies are reviewed at least annually and approved by senior management. More information about our PMP can be found at : https://www.atlassian.com/trust/security/security-management-program

We have also published excerpts of each of our high level policies with the tl:dr, which can be found at: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Are secure configurations deployed to only allow the execution of authorised mobile code and authorised functionality (e.g., only execute specific commands)?

All servers are configured using our centralized puppet configuration system to our standard operating environment, including removal of select packages from the default image and critical package updates. All server roles have a default deny all for incoming networking requests, with select ports opened only to the other server roles which require access to that port for their function.

Our corporate network is segregated from our production network, and our machine images are hardened to only allow necessary ports and protocols. All production systems are currently hosted within US regions of our cloud provider. All data in transit outside of hardened virtual private cloud networks (VPC) are encrypted over industry standard channels.

Additionally, an IDS system is in place on all production servers, which includes real time monitoring and alerting of any changes to the production system files or configuration and anomalous security events.

Further, we have implemented a centralized system management solution (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) for our Mac laptop fleet. We use full disk encryption on our laptops. Also, we have implemented a mobile device management solution for our smartphones (https://www.vmware.com/products/workspace-one.html). All devices must be enrolled to access internal systems and applications. If a mobile device is not enrolled, they cannot access any internal resources and are on a guest network that can only access the Internet. Access is managed through role based access controls to ensure only users requiring access to customer/tenant data have it.

6.03. (h)

Detail policies and procedures for backup. This should include procedures for the management of removable media and methods for securely destroying media no longer required. (Depending on his business requirements, the customer may wish to put in place an independent backup strategy. This is particularly relevant where time-critical access to back-up is required.)

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud products, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance. Amazon RDS snapshots are retained for 30 days with support for point-in time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups. For Bitbucket, data is replicated to a different AWS region and independent backups are taken daily within each region.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product. Customers should also perform their own periodic backups to be able to roll-back customer initiated changes. For more information, see: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types. Data is classified in line with our Atlassian Data Security & Information Lifecycle Policy, and controls implemented based on that. For customer data, on termination of an Atlassian contract, the data belonging to a customer team will be removed from the live production database and all file attachments uploaded directly to Atlassian will be removed within 14 days. The team’s data will remain in encrypted backups until those backups fall out of the 90-day backup retention window and are destroyed in accordance with our Atlassian data retention policy. In the event that a database restore is necessary within 90 days of a requested data deletion, the operations team will re-delete the data as soon as reasonably possible after the live production system is fully restored. For more information, see: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

Audit logs are used in the event of an incident required investigation as well as for troubleshooting. For these purposes, the end customer will need assurance that such information is available.

6.03. (i)

Can the provider detail what information is recorded within audit logs?

• For what period is this data retained?
• Is it possible to segment data within audit logs so they can be made available to the end customer and/or law enforcement without compromising other customers and still be admissible in court?
• What controls are employed to protect logs from unauthorised access or tampering?
• What method is used to check and protect the integrity of audit logs?

Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

Atlassian restricts ability to view and read audit logs to authorized personnel on our centralized logging platform.

Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types. Data is classified in line with our Atlassian Data Security & Information Lifecycle Policy, and controls implemented based on that. For customer data, on termination of an Atlassian contract, the data belonging to a customer team will be removed from the live production database and all file attachments uploaded directly to Atlassian will be removed within 14 days. The team’s data will remain in encrypted backups until those backups fall out of the 90-day backup retention window and are destroyed in accordance with our Atlassian data retention policy. In the event that a database restore is necessary within 90 days of a requested data deletion, the operations team will re-delete the data as soon as reasonably possible after the live production system is fully restored. For more information, see: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

How are audit logs reviewed? What recorded events result in action being taken?

Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

Atlassian restricts ability to view and read audit logs to authorized personnel on our centralized logging platform.

6.03. (k)

What time source is used to synchronise systems and provide accurate audit log time stamping?

Atlassian Cloud utilizes AWS Time Sync for all deployed instances.

6.03.01. (a)

Define controls used to protect the integrity of the operating system and applications software used. Include any standards that are followed, e.g., OWASP, SANS Checklist, SAFECode.

Our team of security engineers continually do a rolling review of all source code in our products as part of our development cycle. Both automated and manual techniques are employed. We also utilize a mandatory dual peer review process, where multiple senior or lead developers review all commits to master. Agile workflows let us identify and fix any vulnerabilities quickly, especially for our cloud services.

The Atlassian secure code review process includes automated scanning (i.e. software composition analysis) for known vulnerabilities, including those exploited in real world attacks. Additionally, our vulnerability management program scans hosts and container images for known vulnerabilities using Snyk. For more information, see: https://www.atlassian.com/trust/security/vulnerability-management.

We engage with BugCrowd to maintain a Bug Bounty program, to conduct ongoing vulnerability assessments of our publicly available Applications and Services; the program is available at: https://bugcrowd.com/atlassian. We do share ongoing pen testing results from our Bug Bounty program at: https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

How do you validate that new releases are fit-for-purpose or do not have risks (backdoors, Trojans, etc)? Are these reviewed before use?

Our Atlassian Change Management process is slightly different than traditional change processes. We rely on a Peer Review and Green Build (PRGB) control on all changes, whether to code, application or infrastructure changes. Peer Review is configured in our CD tool, where critical branches must be designated to have multiple reviewers for each Pull Request. Commonly this is two developers and the Team Lead. The Green Build portion of the control means that the integration during the CI phase must pass all integration, functional, security and other tests that have been developed. If these tests fail (a Red Build), the code will not be merged and must be reviewed again and address the failures. Once a Green Build is successful, the binary is cryptographically signed and our production environment only runs binaries that are signed with our key. Our testing process includes both automated and manual assessment components. We love to blog about what we do well. Our approach to using 'Quality Assistance' (rather than traditional 'Quality Assurance') is something we are passionate about: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Post-deployment we employ regular automated vulnerability scanning and an industry-leading bug bounty program (https://bugcrowd.com/atlassian) to provide continuous assurance of our applications. System configuration changes are managed by an automated process which includes review.

The Atlassian secure code review process includes automated scanning (i.e. software composition analysis) for known vulnerabilities, including those exploited in real world attacks. Additionally, our vulnerability management program scans hosts and container images for known vulnerabilities using Snyk. For more information, see: https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

What practices are followed to keep the applications safe?

Our applications require a Peer Review and Green Build (PRGB) after which the applications artifacts are cryptographically signed, automatically deployed by our CI/CD pipeline, and only Atlassian signed applications are able to be run in our Production Environment.

Atlassian performs secure development practices across all the phases of the development lifecycle. Please See: https://www.atlassian.com/trust/security/security-in-development for more information.

At the design phase, practices including threat modelling, design review, and our regularly updated library of security standards ensure security requirements are considered. During development, we rely on a mandatory peer review process as the first line of security review. This is supported by automated static analysis checks (SAST) and manual security testing (both by internal teams and 3rd-party experts as dictated by our risk assessment process). Development is also supported by application security training programs and a security knowledge-base maintained by the security team. Formal operational readiness and change control processes then ensure that only approved changes are deployed to production. Post-deployment we employ regular automated vulnerability scanning and an industry-leading bug bounty program (https://bugcrowd.com/atlassian) to provide continuous assurance of our applications. System configuration changes are managed by an automated process which includes review of all changes before deployment to production. Atlassian Service Operations can deploy patches as soon as a significant risk is identified. We have internal criteria to determine how quickly to implement any patches, and can apply within 12 hours for all machines. An IDS system is also in place which includes monitoring of system configuration files.

6.03.01. (d)

Is a software release penetration tested to ensure it does not contain vulnerabilities? If vulnerabilities are discovered, what is the process for remedying these?

Atlassian performs secure development practices across all the phases of the development lifecycle. Please See: https://www.atlassian.com/trust/security/security-in-development for more information.

During development, we rely on a mandatory peer review process as the first line of security review. This is supported by automated static analysis checks (SAST) and manual security testing (both by internal teams and 3rd-party experts as dictated by our risk assessment process). Development is also supported by application security training programs and a security knowledge-base maintained by the security team.

Formal operational readiness and change control processes then ensure that only approved changes are deployed to production. Post-deployment we employ regular automated vulnerability scanning and an industry-leading bug bounty program (https://bugcrowd.com/atlassian) to provide continuous assurance of our applications.

6.03.02. (a)

Provide details of the patch management procedure followed?

We maintain a Threat and Vulnerability Management Policy. Our Policy Management Program (PMP) has been defined and includes ownership, availability, review cycle and outlines our general objectives. Our policies are reviewed at least annually and approved by senior management. More information about our PMP can be found at: https://www.atlassian.com/trust/security/security-management-program

We have also published excerpts of each of our high level policies with the tl:dr, which can be found at: https://www.atlassian.com/trust/security/ismp-policies

Atlassian uses a combination of endpoint management to deploy updates and patches to operating systems and key applications across our endpoint fleet. We have also implemented multiple endpoint protection solutions to protect against threats such as malware. For more details, see: https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

Can you ensure that the patch management process covers all layers of the cloud delivery technologies - i.e., network (infrastructure components, routers and switches, etc), server operating systems, virtualisation software, applications and security subsystems (firewalls, antivirus gateways, intrusion detection systems, etc)?

System configuration changes are managed by an automates process which includes review of all changes before deployment to production. Atlassian Service Operations can deploy patches as soon as a significant risk is identified. We have internal criteria to determine how quickly to implement any patches, and can apply within 12 hours for all machines. An IDS system is in place which includes monitoring of system configuration files.

Atlassian Cloud Products can update to the latest AMI as quickly as needed. Our SaaS applications are updated multiple times a week. We have rapid and controlled deployment mechanisms for updates to our code and system configurations. Atlassian actively uses a change control for unscheduled and emergency changes.

6.03.03. (a)

Define the controls used to mitigate DDoS (distributed denial-of-service) attacks.

• Defence in depth (deep packet analysis, traffic throttling, packet black-holding, etc).
• Do you have defences against 'internal' (originating from the cloud providers networks) attacks as well as external (originating from the Internet or customer networks) attacks?
<

Network security requirements are defined in the Communication Security Policy, which is reviewed annually in line with our Policy Management Program (PMP). For more information on our PMP, see: https://www.atlassian.com/trust/security/security-management-program

Our Atlassian Cloud Platform has very little surface area that is exposed through the firewalls. We review firewall rules on a periodic basis. We have deployed IDS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrates with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable. Atlassian Network Engineering uses IPS technologies that are built into our firewalls and we have implemented IDS technologies in our office and cloud environments. DDoS capabilities are provided by our Internet Service Provider / Carrier.

The performance of our firewalls is also assessed regularly through our vulnerability assessment (https://www.atlassian.com/trust/security/vulnerability-management) and penetration testing (https://www.atlassian.com/trust/security/security-testing) programs.

6.03.03. (b)

What levels of isolation are used?

• For virtual machines, physical machines, network, storage (e.g., storage area networks), management networks and management support systems, etc.
<

Atlassian is a multi-tenant SaaS application. Multi-tenancy is a key feature of Atlassian Cloud that enables multiple customers to share one instance of the Jira or Confluence application layer, while isolating each customer tenant’s application data. Atlassian Cloud accomplishes this through the Tenant Context Service (TCS). Every user ID is associated with exactly one tenant, which is then used to access the Atlassian Cloud applications. For more information, see : https://www.atlassian.com/trust/security/security-practices#tenant-isolation

We maintain logical and physical separation of production and non-production (development) environments and methods are used to isolate these environments.

Our staging environment is logically separated (but not physically separated) but is managed under production-grade change control and access processes.

6.03.03. (c)

Does the architecture support continued operation from the cloud when the company is separated from the service provider and vice versa (e.g., is there a critical dependency on the customer LDAP system)?

A Business Continuity and Disaster Recovery policy and Business Continuity and Disaster Recovery Plan is in place and is reviewed on an annual basis by the Business Continuity / Disaster Recovery steering committee. For more information, see : https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e and https://www.atlassian.com/trust/security/data-management.

Atlassian utilizes AWS' highly available data center facilities in multiple regions world wide to ensure continued operation. For more information, see: https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

Is the virtual network infrastructure used by cloud providers (in PVLANs and VLAN tagging 802.1q architecture) secured to vendor and/or best practice specific standards (e.g., are MAC spoofing, ARP poisoning attacks, etc, prevented via a specific security configuration)?

Network security requirements are defined in the Communication Security Policy, which is reviewed annually in line with our Policy Management Program (PMP). For more information on our PMP, see: https://www.atlassian.com/trust/security/security-management-program

Our Atlassian Cloud Platform has very little surface area that is exposed through the firewalls. We review firewall rules on a periodic basis. We have deployed IDS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrates with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable. Atlassian Network Engineering uses IPS technologies that are built into our firewalls and we have implemented IDS technologies in our office and cloud environments. DDoS capabilities are provided by our Internet Service Provider / Carrier.

The performance of our firewalls is also assessed regularly through our vulnerability assessment (https://www.atlassian.com/trust/security/vulnerability-management) and penetration testing (https://www.atlassian.com/trust/security/security-testing) programs.

In addition, at Atlassian we monitor the configuration of our AWS environments against established configuration baselines.

6.03.04. (a)

Does the provider ensure virtual images are hardened by default?

All servers are configured using our centralized puppet configuration system to our standard operating environment, including removal of select packages from the default image and critical package updates. All server roles have a default deny all for incoming networking requests, with select ports opened only to the other server roles which require access to that port for their function.

Our corporate network is segregated from our production network, and our machine images are hardened to only allow necessary ports and protocols. All production systems are currently hosted within US regions of our cloud provider. All data in transit outside of hardened virtual private cloud networks (VPC) are encrypted over industry standard channels.

Additionally, an IDS system is in place on all production servers, which includes real time monitoring and alerting of any changes to the production system files or configuration and anomalous security events.

In the Atlassian Cloud Platform, individual containers don’t have an image, when the container is initiated, an image is picked from a standard repository. We maintain on-going auditing for each of the images and provide a re-application of the images by our configuration tools when necessary. As a result, changes are not made to the virtual machine images.

The AWS Linux AMI base OS image builds have limited ports, protocols and services. We compare our builds against current AMI version to ensure appropriate settings.

Our Docker images are managed in a tightly controlled change environment to ensure appropriate review and approval of all changes.

6.03.04. (b)

Is the hardened virtual image protected from unauthorised access?

All servers are configured using our centralized puppet configuration system to our standard operating environment, including removal of select packages from the default image and critical package updates. All server roles have a default deny all for incoming networking requests, with select ports opened only to the other server roles which require access to that port for their function.

Our corporate network is segregated from our production network, and our machine images are hardened to only allow necessary ports and protocols. All production systems are currently hosted within US regions of our cloud provider. All data in transit outside of hardened virtual private cloud networks (VPC) are encrypted over industry standard channels.

Additionally, an IDS system is in place on all production servers, which includes real time monitoring and alerting of any changes to the production system files or configuration and anomalous security events.

In the Atlassian Cloud Platform, individual containers don’t have an image, when the container is initiated, an image is picked from a standard repository. We maintain on-going auditing for each of the images and provide a re-application of the images by our configuration tools when necessary. As a result, changes are not made to the virtual machine images.

The AWS Linux AMI base OS image builds have limited ports, protocols and services. We compare our builds against current AMI version to ensure appropriate settings.

Our Docker images are managed in a tightly controlled change environment to ensure appropriate review and approval of all changes.

Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

6.03.04. (c)

Can the provider confirm that the virtualized image does not contain the authentication credentials?

All servers are configured using our centralized puppet configuration system to our standard operating environment, including removal of select packages from the default image and critical package updates. All server roles have a default deny all for incoming networking requests, with select ports opened only to the other server roles which require access to that port for their function.

Our corporate network is segregated from our production network, and our machine images are hardened to only allow necessary ports and protocols. All production systems are currently hosted within US regions of our cloud provider. All data in transit outside of hardened virtual private cloud networks (VPC) are encrypted over industry standard channels.

Additionally, an IDS system is in place on all production servers, which includes real time monitoring and alerting of any changes to the production system files or configuration and anomalous security events.

In the Atlassian Cloud Platform, individual containers don’t have an image, when the container is initiated, an image is picked from a standard repository. We maintain on-going auditing for each of the images and provide a re-application of the images by our configuration tools when necessary. As a result, changes are not made to the virtual machine images.

The AWS Linux AMI base OS image builds have limited ports, protocols and services. We compare our builds against current AMI version to ensure appropriate settings.

Our Docker images are managed in a tightly controlled change environment to ensure appropriate review and approval of all changes.

Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

6.03.04. (d)

Is the host firewall run with only the minimum ports necessary to support the services within the virtual instance?

All servers are configured using our centralized puppet configuration system to our standard operating environment, including removal of select packages from the default image and critical package updates. All server roles have a default deny all for incoming networking requests, with select ports opened only to the other server roles which require access to that port for their function.

Our corporate network is segregated from our production network, and our machine images are hardened to only allow necessary ports and protocols. All production systems are currently hosted within US regions of our cloud provider. All data in transit outside of hardened virtual private cloud networks (VPC) are encrypted over industry standard channels.

Our Atlassian Cloud Platform has very little surface area that is exposed through the firewalls. We review firewall rules on a periodic basis. We have deployed IDS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrates with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable. Atlassian Network Engineering uses IPS technologies that are built into our firewalls and we have implemented IDS technologies in our office and cloud environments. DDoS capabilities are provided by our Internet Service Provider / Carrier.

The performance of our firewalls is also assessed regularly through our vulnerability assessment (https://www.atlassian.com/trust/security/vulnerability-management) and penetration testing (https://www.atlassian.com/trust/security/security-testing) programs.

6.03.04. (e)

Can a host-based intrusion prevention service (IPS) be run in the virtual instance?

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.03.05.

Generally speaking, PaaS service providers are responsible for the security of the platform software stack, and the recommendations throughout this document are a good foundation for ensuring a PaaS provider has considered security principles when designing and managing their PaaS platform. It is often difficult to obtain detailed information from PaaS providers on exactly how they secure their platforms - however the following questions, along with other sections within this document, should be of assistance in assessing their offerings.

6.03.05. (a)

Request information on how multi-tenanted applications are isolated from each other - a high level description of containment and isolation measures is required.

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.03.05. (b)

What assurance can the PaaS provider give that access to your data is restricted to your enterprise users and to the applications you own?

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.03.05. (c)

The platform architecture should be classic 'sandbox' - does the provider ensure that the PaaS platform sandbox is monitored for new bugs and vulnerabilities?

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.03.05. (d)

PaaS providers should be able to offer a set of security features (re-usable amongst their clients) - do these include user authentication, single sign on, authorization (privilege management), and SSL/TLS (made available by an API)?

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.03.06.

The SaaS model dictates that the provider manages the entire suite of applications delivered to end-users. Therefore SaaS providers are mainly responsible for securing these applications. Customers are normally responsible for operational security processes (user and access management). However the following questions, along with other sections within this document, should assist in assessing their offerings:

6.03.06. (a)

What administration controls are provided and can these be used to assign read and write privileges to other users.

Customers of our Enterprise and Premium Cloud offerings have access to a centralized administration control panel. Your organization's admins can manage user access and permissions across all your product instances. See our blog post here: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian customers can use their chosen third party identity provider if supported by Atlassian. An Atlassian Support page details these features and how to connect your chosen identity provider, see: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Is the SaaS access control fine grained and can it be customized to your organizations policy?

Customers of our Enterprise and Premium Cloud offerings have access to a centralized administration control panel. Your organization's admins can manage user access and permissions across all your product instances. See our blog post here: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian customers can use their chosen third party identity provider if supported by Atlassian. An Atlassian Support page details these features and how to connect your chosen identity provider, see: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

In the event of resource overload (processing, memory, storage, network)?

• What information is given about the relative priority assigned to my request in the event of a failure in provisioning?
• Is there a lead time on service levels and changes in requirements?
<

Atlassian plans capacity 6-12 months ahead, with high level strategic planning going out 36 months.

Atlassian maintains analytics for Cloud AWS and Azure scaling-in and scaling-out architecture and uses this data to design for Atlassian product growth. However, this data is not provided to customers at this time.

6.03.07. (b)

How much can you scale up? Does the provider offer guarantees on maximum available resources within a minimum period?

Atlassian plans capacity 6-12 months ahead, with high level strategic planning going out 36 months.

Atlassian maintains analytics for Cloud AWS and Azure scaling-in and scaling-out architecture and uses this data to design for Atlassian product growth. However, this data is not provided to customers at this time.

6.03.07. (c)

How fast can you scale up? Does the provider offer guarantees on the availability of supplementary resources within a minimum period?

Atlassian plans capacity 6-12 months ahead, with high level strategic planning going out 36 months.

Atlassian maintains analytics for Cloud AWS and Azure scaling-in and scaling-out architecture and uses this data to design for Atlassian product growth. However, this data is not provided to customers at this time.

6.03.07. (d)

What processes are in place for handling large-scale trends in resource usage (eg, seasonal effects)?

Atlassian plans capacity 6-12 months ahead, with high level strategic planning going out 36 months.

Atlassian maintains analytics for Cloud AWS and Azure scaling-in and scaling-out architecture and uses this data to design for Atlassian product growth. However, this data is not provided to customers at this time.

6.04.01.

The following controls apply to the cloud provider's identity and access management systems (those under their control).

6.04.01. (a)

Do any accounts have system-wide privileges for the entire cloud system and, if so, for what operations (read/write/delete)?

Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

6.04.01. (b)

How are the accounts with the highest level of privilege authenticated and managed?

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

6.04.01. (c)

How are the most critical decisions (e.g., simultaneous de-provisioning of large resource blocks) authorised (single or dual, and by which roles within the organisation)?

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

Segregation of duties controls are in place for our core products and include, but are not limited to:

• Access controls reviews
• HR application managed security groups
• Change Approval/peer review/implementation (PRGB)
• Workflow controls

6.04.01. (d)

Are there any high-privilege roles allocated to the same person? Does this allocation break the segregation of duties or least privilege rules?

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

Segregation of duties controls are in place for our core products and include, but are not limited to:

• Access controls reviews
• HR application managed security groups
• Change Approval/peer review/implementation (PRGB)
• Workflow controls

6.04.01. (e)

Do you use role-based access control (RBAC)? Is the principle of least privilege followed?

Atlassian has an established workflow linking our HR management system and our access provisioning system. We use role based access control based on pre-defined user profiles. All user accounts must be approved by management prior to their access to data, applications, infrastructure or network components.

Atlassian maintains restrictions on the personnel that need access to our systems, applications and infrastructure for their job role and responsibilities on the basis of least privilege and this is enforced through our authentication processes.

6.04.01. (f)

What changes, if any, are made to administrator privileges and roles to allow for extraordinary access in the event of an emergency?

Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

6.04.01. (g)

Is there an 'administrator' role for the customer? For example, does the customer administrator have a role in adding new users (but without allowing him to change the underlying storage!)?

Atlassian provides customers with the role of 'Organization Admin' who administers users and groups for the customer's products. For more information see: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

What checks are made on the identity of user accounts at registration? Are any standards followed? For example, the e-Government Interoperability Framework?

• Are there different levels of identity checks based on the resources required?

New Atlassian's globally are required to complete a background check. Newly hired employees as a result of an acquisition have a background check performed after the acquisition date. A criminal check is run on all new hires and independent contractors - education verification, employment verification, or credit checks are added in if the role or level of position requires it. We perform full background checks for senior executive and accounting roles.

Atlassian has an established workflow linking our HR management system and our access provisioning system. We use role based access control based on pre-defined user profiles. All user accounts must be approved by management prior to their access to data, applications, infrastructure or network components.

6.04.02. (b)

What processes are in place for de-provisioning credentials?

Our de-provisioning process currently incorporates termination of employment, contract or agreement. Users who transfer internally will generally retain their access rights in order to enable ongoing engagement and support. In order to provide a highly responsive and flexible customer focused team, in line with our company values, our focus is on detecting unauthorized use of access rather than on restricting access which may slow down our responsiveness.

6.04.02. (c)

Are credential provisioned and de-provisioned simultaneously throughout the cloud system, or are there any risks in de-provisioning them across multiple geographically distributed locations?

Atlassian has an established workflow linking our HR management system and our access provisioning system. We use role based access control based on pre-defined user profiles. All user accounts must be approved by management prior to their access to data, applications, infrastructure or network components.

Our HR application is synced with our internal Identity Store every 8 hours, removing any accounts for employees or contractors who are no longer employed.

6.04.03. (a)

What data storage and protection controls apply to the user directory (eg, AD, LDAP) and access to it?

Data is classified and handled in line with our Information Lifecycle and Data Security Policy, and controls implemented based on that. For more information, see: https://www.atlassian.com/trust/security/security-practices

All systems and projects undergo an impact assessment as it relates to PII. Our Atlassian Third-Party Agreements include security and privacy provisions as applicable. New vendors to Atlassian are required to agree to our privacy and security policies in our contracts.

Atlassian is ISO certified across a number of products, which requires regular risk assessments and reviews of data practices.

Our Data Transfer Impact Assessment can be found at: https://www.atlassian.com/legal/data-transfer-impact-assessment

Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types. Data is classified in line with our Atlassian Data Security & Information Lifecycle Policy, and controls implemented based on that.

For customer data, on termination of an Atlassian contract, the data belonging to a customer team will be removed from the live production database and all file attachments uploaded directly to Atlassian will be removed within 14 days. The team’s data will remain in encrypted backups until those backups fall out of the 90-day backup retention window and are destroyed in accordance with our Atlassian data retention policy. In the event that a database restore is necessary within 90 days of a requested data deletion, the operations team will re-delete the data as soon as reasonably possible after the live production system is fully restored. For more information, see : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Is user directory data exportable in an interoperable format?

Admins can export the directory of users from the admin panel. Guides are available on Atlassian's Support site here: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

Is need-to-know the basis for access to customer data within the cloud provider?

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

Segregation of duties controls are in place for our core products and include, but are not limited to:

• Access controls reviews
• HR application managed security groups
• Change Approval/peer review/implementation (PRGB)
• Workflow controls

6.04.04.

For keys under the control of the cloud provider:

6.04.04. (a)

Are security controls in place for reading and writing those keys? For example, strong password policies, keys stored in a separate system, hardware security modules (HSM) for root certificate keys, smart card based authentication, direct shielded access to storage, short key lifetime, etc.

Atlassian maintains Encryption & Cryptography Policies and implementation guidelines. This policy is reviewed and updated annually in line with our Policy Management Program (PMP). For more information, see: https://www.atlassian.com/trust/security/security-management-program.

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. AWS KMS Service is SOC 1, SOC 2, SOC 3 Compliant. For more information, see: https://aws.amazon.com/kms/

6.04.04. (b)

Are security controls in place for using those keys to sign and encrypt data?

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Master Keys within KMS, upon-creation, enable an auto-rotation to generate Master Key Material every 365 days (annually).

6.04.04. (c)

Are procedures in place in the event of a key compromise? For example, key revocation lists.

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. AWS KMS Service is SOC 1, SOC 2, SOC 3 Compliant. For more information, see: https://aws.amazon.com/kms/

6.04.04. (c)

Are procedures in place in the event of a key compromise? For example, key revocation lists.

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. AWS KMS Service is SOC 1, SOC 2, SOC 3 Compliant. For more information, see: https://aws.amazon.com/kms/

6.04.04. (d)

Is key revocation able to deal with simultaneity issues for multiple sites?

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. AWS KMS Service is SOC 1, SOC 2, SOC 3 Compliant. For more information, see: https://aws.amazon.com/kms/

6.04.04. (e)

Are customer system images protected or encrypted?

Atlassian uses industry standard Transport Layer Security (“TLS”) version 1.2 to create a secure connection using 256 ­bit Advanced Encryption Standard (“AES”) encryption. Servers holding user data will use full disk, industry-standard AES encryption. Tenant data is encrypted within the AWS RDS or RDS backups, and is also encrypted in long term storage (S3) as well as all attachments. For more information, see: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

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.

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

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.

6.04.05. (a)

Encryption can be used in multiple places - where is it used?

• Data in transit?
• Data at rest?
• Data in processor or memory?

Atlassian maintains Encryption & Cryptography Policies and implementation guidelines. This policy is reviewed and updated annually in line with our Policy Management Program (PMP). For more information, see : https://www.atlassian.com/trust/security/security-management-program .

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status.

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.

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

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.

6.04.05. (b)

Is there a well-defined policy for what should be encrypted and what should not be encrypted?

Atlassian maintains Encryption & Cryptography Policies and implementation guidelines. This policy is reviewed and updated annually in line with our Policy Management Program (PMP). For more information, see: https://www.atlassian.com/trust/security/security-management-program.

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Atlassian-managed keys are rotated upon relevant changes of roles or employment status.

6.04.05. (d)

Who holds the access keys?

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.

6.04.05. (e)

How are the keys protected?

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.

6.04.06. (a)

What forms of authentication are used for operations requiring high assurance? This may include login to management interfaces, key creation, access to multiple-user accounts, firewall configuration, remote access, etc.

• Is two-factor authentication used to manage critical components within the infrastructure, such as firewalls, etc?

We follow the guidelines outlined in NIST Special Publication 800-63B. See : https://pages.nist.gov/800-63-3/sp800-63b.html

The process for allocating passwords is covered in the Atlassian Password Policy. New passwords will not be communicated electronically, except for instances where an initial one-time password is sent. In these instances the user will be forced to change the one-time password upon first use.

More broadly, controls related to access control are covered in the Access Management Policy, an excerpt of which is available here: https://www.atlassian.com/trust/security/ismp-policies

Atlassian maintains restriction on the personnel that need access to our systems, applications and infrastructure for their job role and responsibilities on the basis of least privilege and this is enforced through our authentication processes. All access is through authenticated sessions, and based on established permissions.

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sign-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

6.04.07. (a)

Do you provide anomaly detection (the ability to spot unusual and potentially malicious IP traffic and user or support team behaviours)? For example, analysis of failed and successful logins, unusual time of day, and multiple logins, etc.

Our Atlassian Cloud Platform has very little surface area that is exposed through the firewalls. We review firewall rules on a periodic basis. We have deployed IDS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrates with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable. Atlassian Network Engineering uses IPS technologies that are built into our firewalls and we have implemented IDS technologies in our office and cloud environments. DDoS capabilities are provided by our Internet Service Provider / Carrier.

Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

6.04.07. (b)

What provisions exist in the event of the theft of a customer's credentials (detection, revocation, evidence for actions)?

In the context of Atlassian cloud services, our customers may be responsible for some or all aspects of access management for their service users under their control.

Accordingly, Atlassian enables our customers to manage access by service users under the service customer’s control, such as by providing administrative rights to manage or terminate access. Atlassian also checks customers’ credentials against leaked credentials databases, and force users to update their password.

Atlassian does not provide Data Loss Prevention (DLP) directly as part of Cloud deployments. However, there are vendors in the Atlassian Marketplace, such as Nightfall that Atlassian recommends for customers desiring this DLP capability. See the Marketplace product page for Nightfall here: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall includes automatic scanning of sensitive information including credentials, secrets, and API keys.

Atlassian has launched Beacon, which is in Beta and adds DLP features. Until Beacon is launched out of Beta, Atlassian still recommends Nightfall. See more information about Atlassian Beacon at: https://www.atlassian.com/software/beacon.

We have a documented Security Incident Response Policy and Plan, the key principles of which include:

• Anticipate security incidents and prepare for incident response
• Contain, eradicate and recover from incidents
• Invest in our people, processes and technologies to ensure we have the capability to detect and analyze a security incident when it occurs
• Make protection of Personal data and customer data the top priority during security incidents
• Regularly exercise the security incident response process
• Learn from and improve the security incident management function
• Communicate critical security incidents to the Atlassian Leadership Group

6.04.08.

The following questions apply to the identity and access management systems which are offered by the cloud provider for use and control by the cloud customer.

6.04.08.01. (a)

Does the system allow for a federated IDM infrastructure which is interoperable both for high assurance (OTP systems, where required) and low assurance (eg. Username and password)?

Atlassian Access supports identity federation standards across our Atlassian Products (Confluence, Jira, Jira Align, Bitbucket, etc). Atlassian Access can automatically sync your Active Directory to Atlassian with Okta, Azure AD, or OneLogin. For more information, see: https://www.atlassian.com/enterprise/cloud/access. Specific Product SSO Setup (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie supports multiple SSO providers. For more information, see: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello supports multiple SSO providers. For more information, see: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage supports multiple SSO providers. For more information, see: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

Is the cloud provider interoperable with third party identity providers?

Atlassian customers can use their chosen third party identity provider if supported by Atlassian. An Atlassian Support page details these features and how to connect your chosen identity provider, see: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Is there the ability to incorporate single sign-on?

Atlassian supports the use of Google, Microsoft, and Apple identities for the authentication of most products. We also support SAML for our Atlassian cloud services through Atlassian Access. See: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Does the client credential system allow for the separation of roles and responsibilities and for multiple domains (or a single key for multiple domains, roles and responsibilities)?

Atlassian is a multi-tenant SaaS application. Multi-tenancy is a key feature of Atlassian Cloud that enables multiple customers to share one instance of the Jira or Confluence application layer, while isolating each customer tenant’s application data. Atlassian Cloud accomplishes this through the Tenant Context Service (TCS). Every user ID is associated with exactly one tenant, which is then used to access the Atlassian Cloud applications. For more information, see : https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Customers of our Enterprise and Premium Cloud offerings have access to a centralized administration control panel. Your organization's admins can manage user access and permissions across all your product instances. See our blog post here: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian provides customers with the role of 'Organization Admin' who administers users and groups for the customer's products. For more information see: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

How do you manage access to customer system images - and ensure that the authentication and cryptographic keys are not contained within in them?

Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

6.04.08.03. (a)

How does the cloud provider identity itself to the customer (ie, is there mutual authentication)?

• When the customer sends API commands?
• When the customer logs into the management interface?

Atlassian utilizes mutual authentication to identify itself to the customer. Atlassian API documentation can be found at: https://developer.atlassian.com/cloud/. Atlassian Service Authentication Protocol (ASAP) is a service-to-service authentication protocol that utilizes access token implemented using JSON Web Token (JWT) and signed using a RSA keys from an Atlassian trusted authority. To learn more, see Atlassian Service Authentication Protocol. We don’t use traditional notions of ‘Service Accounts’, we do rely on Service-to-Service authentication and authorization.

6.04.08.03. (b)

Do you support a federated mechanism for authentication?

Atlassian Access supports identity federation standards across our Atlassian Products (Confluence, Jira, Jira Align, Bitbucket, etc). Atlassian Access can automatically sync your Active Directory to Atlassian with Okta, Azure AD, or OneLogin. For more information, see: https://www.atlassian.com/enterprise/cloud/access. Specific Product SSO Setup (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie supports multiple SSO providers. For more information, see: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello supports multiple SSO providers. For more information, see: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage supports multiple SSO providers. For more information, see: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

It is important to ensure the provider maintains a current list of hardware and software (applications) assets under the cloud providers control. This enables checks that all systems have appropriate controls employed, and that systems cannot be used as a backdoor into the infrastructure.

6.05. (a)

Does the provider have an automated means to inventory all assets, which facilitates their appropriate management?

Our production systems are located in infrastructure obtained through cloud service providers. These systems are not tracked at a hardware level due to the nature of the service. The underlying microservices that our products run on are tracked in a custom-built ‘Service’ database. This database is updated automatically when a service is deployed.

Our Workplace technology team maintains an asset inventory of all endpoints using our own Jira software for tracking purposes.

6.05. (b)

Is there a list of assets that the customer has used over a specific period of time?

Atlassian is a multi-tenant SaaS application. Multi-tenancy is a key feature of Atlassian Cloud that enables multiple customers to share one instance of the Jira or Confluence application layer, while isolating each customer tenant’s application data. Atlassian Cloud accomplishes this through the Tenant Context Service (TCS). Every user ID is associated with exactly one tenant, which is then used to access the Atlassian Cloud applications. For more information, see: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

The following questions are to be used where the end customer is deploying data that would require additional protection (i.e.. Deemed as sensitive).

6.05. (c)

Are assets classified in terms of sensitivity and criticality?

• If so, does the provider employ appropriate segregation between systems with different classifications and for a single customer who has systems with different security classifications?

Atlassian maintains a 4-tier rating on our assets and services, with uptime, service level, and continuity requirements set per tier. For more information, see: https://www.atlassian.com/trust/security/data-management.

6.06.

This set of questions should be considered in order to understand the risks related to vendor lock-in.

6.06. (a)

Are there any documented procedures and APIs for exporting data from the cloud?

Customer data is available via Web App and API. Details for specific products are below.

• Confluence & Jira & Jira Align: Details on our Atlassian API can be found at : https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: board data is available for export by board members in JSON format via the Trello REST API. File attachments can be retrieved individually directly from Amazon S3 using the file’s unique hyperlink. Trello Business Class and Enterprise editions offer a simplified data export process for all organization data and attachments. Each Business Class and Enterprise organization includes one-click export of all Boards within the organization. Optionally, file attachments uploaded directly to Trello can be included in the export file. Within the export, each board’s data is included in both JSON and Comma Separated Values (“CSV”) format.
• Opsgenie: API can be found at: https://docs.opsgenie.com/docs/api-overview
• Statuspage: API can be found at: https://doers.statuspage.io/api/v1/
• Bitbucket: Any source code or repos can be downloaded or exported from Bitbucket for interoperability purposes. See: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: has a CSV export feature. You can read more documentation here: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Does the vendor provide interoperable export formats for all data stored within the cloud?

Atlassian facilitates customer requests to export their data, should it be hosted on Atlassian products. Robust data portability and data management tools for exporting product and user data is available. For more information on Atlassian Cloud data export, see our import and export documentation here: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Further, see: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ for details on exporting data into common formats such as CSV, HTML, and XML.

6.06. (c)

In the case of SaaS, are the API interfaces used standardized?

Details on our Atlassian Cloud APIs can be found at: https://developer.atlassian.com/explore-the-apis/

Specific Product API details:

• Trello: API documentation is available at: https://developer.atlassian.com/cloud/trello
• Jira Align: API can be found at: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: API can be found at: https://doers.statuspage.io/api/v1
• Opsgenie: API can be found at: https://docs.opsgenie.com/docs/api-overview
• Halp: does not have a public API at this time.

6.06. (d)

Are there any provisions for exporting user-created applications in a standard format?

This is not applicable, as Atlassian operates a Software as a Service (SaaS) model.

6.06. (e)

Are there processes for testing that data can be exported to another cloud provider - should the client wish to change provider, for example?

Atlassian facilitates customer requests to export their data, should it be hosted on Atlassian products. Robust data portability and data management tools for exporting product and user data is available. For more information on Atlassian Cloud data export, see our import and export documentation here: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Further, see: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ for details on exporting data into common formats such as CSV, HTML, and XML.

6.06. (f)

Can the client perform their own data extraction to verify that the format is universal and is capable of being migrated to another cloud provider?

Atlassian facilitates customer requests to export their data, should it be hosted on Atlassian products. Robust data portability and data management tools for exporting product and user data is available. For more information on Atlassian Cloud data export, see our import and export documentation here: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Further, see: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ for details on exporting data into common formats such as CSV, HTML, and XML.

6.07.

Providing continuity is important to an organization. Although it is possible to set service level agreements detailing the minimum amount of time systems are available, there remain a number of additional considerations.

6.07. (a)

Does the provider maintain a documented method that details the impact of a disruption?

• What are the RPO (recovery point objective) and RTO (recovery time objective) for services? Detail according to the criticality of the service.
• Are information security activities appropriate addressed in the restoration process?
• What are the lines of communication to end customers in the event of a disruption?
• Are the roles and responsibilities of teams clearly identified when dealing with a disruption?

A Business Continuity and Disaster Recovery policy and Business Continuity and Disaster Recovery Plan is in place and is reviewed on an annual basis by the Business Continuity / Disaster Recovery steering committee. For more information (including in relation to RPOs, RTOs, and resiliency via the use of availability zones) see: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management and https://www.atlassian.com/trust/security/data-management.

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/

6.07. (b)

Has the provider categorized the priority for recovery, and what would be our relative priority (the end customer) to be restored? Note: this may be a category (HIGH/MED/LOW).

All mission-critical systems, processes, or services owners ensure proper business continuity and/or disaster recovery that aligns with the tolerance for disruption in case of a disaster. BCDR plans are tested quarterly and any issues identified are addresses. For more information, see: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management and https://www.atlassian.com/trust/security/data-management.

6.07. (c)

What dependencies relevant to the restoration process exist? Include suppliers and outsource partners.

Atlassian has a procedure for, and a log of, data restoration efforts. At high level, this is contained in our internal Backups Standard and Business Continuity and Disaster Recovery policy. However, for each Atlassian service, we have various internal documents which include runbooks, schedules and procedures for customer initiated restores and Atlassian initiated restores.

6.07. (d)

In the event of the primary site being made unavailable, what is the minimum separation for the location of the secondary site?

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/

6.07.01.

Incident management and response is a part of business continuity management. The goal of this process is to contain the impact of unexpected and potentially disrupting events to an acceptable level for an organization.To evaluate the capacity of an organization to minimize the probability of occurrence or reduce the negative impact of an information security incident, the following questions should be asked to a cloud provider:

6.07.01. (a)

Does the provider have a formal process in place for detecting, identifying, analyzing and responding to incidents?

We have a documented Security Incident Response Policy and Plan, the key principles of which include:

• Anticipate security incidents and prepare for incident response
• Contain, eradicate and recover from incidents
• Invest in our people, processes and technologies to ensure we have the capability to detect and analyze an security incident when it occurs
• Make protection of Personal data and customer data the top priority during security incidents
• Regularly exercise the security incident response process
• Learn from and improve the security incident management function
• Communicate critical security incidents to the Atlassian Leadership Group


Under this policy, Atlassian maintains a Security Incident Response plan. For more information about our Security Incident Response process, see: https://www.atlassian.com/trust/security/security-incident-management

Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

For more on our Detections Program, see: https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

Is this process rehearsed to check that incident handling processes are effective? Does the provider also ensure, during the rehearsal, that everyone within the cloud provider's support organization is aware of the process and of their roles during incident handling (both during the incident and post analysis)?

For our Atlassian Cloud services, Business Continuity and Disaster Recovery plans are tested at least quarterly. Multiple region availability is monitored in real time. Automated region failover tests are performed each week on pre-production environment. Automated configuration data restoration tests are performed daily on Production. All of Atlassian services perform Availability Zone resiliency test on pre-production environment every quarter. For more information on our Business Continuity program, see: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Our Disaster Recovery plans are tested and validated by our external auditors as part of our Compliance Program, for more information, see: https://www.atlassian.com/trust/compliance/resources

We have exercised our Security Incident Response plan via live incident activity. We maintain a continuous improvement approach to optimizing our response capabilities.

After a high severity 1 or 2 incident has been resolved, the original incident ticket is closed and a post-incident review (PIR) process is initiated. For high severity incidents, the security team performs a root cause analysis and proposes potential improvements to the system and/or handling of the issue.

6.07.01. (c)

How are the detection capabilities structured?

• How can the cloud customer report anomalies and security events to the provider?
• What facilities does the provider allow for customer-selected third party RTSM services to intervene in their systems (where appropriate) or to co-ordinate incident response capabilities with the cloud provider?
• Is there a real time security monitoring (RTSM) service in place? Is the service outsourced? What kind of parameters and services are monitored?
• Do you provide (upon request) a periodical report on security incidents (eg,. according to the ITIL definition)?
• For how long are the security logs retained? Are those logs secure stored? Who has access to the logs?
• Is it possible for the customer to build a HIPS/HIDS in the virtual machine image? Is it possible to integrate the information collected by the intrusion detection and prevention systems of the customer into the RTSM service of the cloud provider or that of a third party?

Our Atlassian Cloud Platform has very little surface area that is exposed through the firewalls. We review firewall rules on a periodic basis. We have deployed IDS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrates with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable. Atlassian Network Engineering uses IPS technologies that are built into our firewalls and we have implemented IDS technologies in our office and cloud environments. DDoS capabilities are provided by our Internet Service Provider / Carrier. For more on our Detections Program, see: https://www.atlassian.com/trust/security/detections-program Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup. Atlassian restricts ability to view and read audit logs to authorized personnel on our centralized logging platform. Atlassian maintains external reporting channels through which we may become aware of vulnerabilities or incidents, including through our Bug Bounty program, our customer support portal, and defined security email inboxes and phone numbers. Atlassian encourages customers to report any authorized access or malicious behavior. To see more: https://www.atlassian.com/trust/security/security-incident-management and https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

How are severity levels defined?

Atlassian uses Common Vulnerability Scoring System (CVSS) as a method of assessing security risk and prioritization for each discovered vulnerability. The security levels used are based on Atlassian's self-calculated CVSS score including:

• Critical;
• High;
• Medium, and
• Low.


For more details, including what score ranges determine severity, see: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

How are escalation procedures defined? When (if ever) is the cloud customer involved?

We have a documented Security Incident Response Policy and Plan, the key principles of which include:

• Anticipate security incidents and prepare for incident response
• Contain, eradicate and recover from incidents
• Invest in our people, processes and technologies to ensure we have the capability to detect and analyze an security incident when it occurs
• Make protection of Personal data and customer data the top priority during security incidents
• Regularly exercise the security incident response process
• Learn from and improve the security incident management function
• Communicate critical security incidents to the Atlassian Leadership Group


Under this policy, Atlassian maintains a Security Incident Response plan. For more information about our Security Incident Response process, see: https://www.atlassian.com/trust/security/security-incident-management

Atlassian understands how important it is for you to be notified promptly of any data breach. That is why Atlassian has built out an extensive cross-functional team and process to handle security incidents as described at: https://www.atlassian.com/trust/security/security-incident-management

Atlassian has a strong track record of timely and proactive notification of incidents, and working with our customers on any necessary mitigations.

Because it is critical that Atlassian's security incident response teams to immediately focus on triage and mitigation of an incident as it develops, we cannot agree to a 72 hour timeline. Instead, we offer customers notification 'without undue delay', which follows the legal requirement under GDPR for data processors, which meets the legal needs of most of our customers.

Incidents can range from simple to incredibly complex, so while we can offer what is necessary under the law we cannot agree to a 'one-size fits all' timeline.

6.07.01. (f)

How are incidents documented and evidence collected?

Jira tickets are created for tracking and remediation purposes, and due dates are assigned according to our SLO based on both severity and the source of the vulnerability. We have an on-going process to issue tickets for identified vulnerabilities to system owners, and our Security Management Team reviews any reported vulnerabilities and ensures action is taken against them.

After a high severity 1 or 2 incident has been resolved, the original incident ticket is closed and a post-incident review (PIR) process is initiated. For high severity incidents, the security team performs a root cause analysis and proposes potential improvements to the system and/or handling of the issue.

6.07.01. (g)

Besides authentication, accounting and audit, what other controls are in place to prevent (or minimise the impact of) malicious activity by insiders?

Atlassian has deployed IDS at our office sites and our cloud hosting environment. Log forwarding integrates with a Security Analytics Platform for the Atlassian Cloud Platform. Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. For more on our Detections Program, see: https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

Does the provider collect incident metrics and indicators (ie,. Number of detected or reported incidents per months, number of incidents caused by the cloud provider's subcontractors and the total number of such incidents, average time to respond and to resolve, etc.)?

• Which of these does the provider make publicly available (NB not all incident reporting data can be made public since it may compromise customer confidentiality and reveal security critical information)?

At this time, we do not make our internal metrics public but we do share Post Incident Actions for Sev 0 or Sev 1 Operational Incidents on our Statuspage, see: https://status.atlassian.com/.

6.07.01. (j)

How often does the provider test disaster recovery and business continuity plans?

For our Atlassian Cloud services, Business Continuity and Disaster Recovery plans are tested at least quarterly. Multiple region availability is monitored in real time. Automated region failover tests are performed each week on pre-production environment. Automated configuration data restoration tests are performed daily on Production. All of Atlassian services perform Availability Zone resiliency test on pre-production environment every quarter. For more information on our Business Continuity program, see: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Our Disaster Recovery plans are tested and validated by our external auditors as part of our Compliance Program, for more information, see: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

Does the provider collect data on the levels of satisfaction with SLAs?

We monitor all Cloud instances for performance and availability, but we do not currently offer a formal application availability SLA. Our support team provides an initial response time SLA, and while we have no official support resolution SLA our internal goal is to resolve all assigned cases within 48 hours. Atlassian displays statistics of our latest Cloud system status here: https:status.atlassian.com.

If you elect to use our Premium or Enterprise offerings, yes, we offer SLA guarantees.

6.07.01. (l)

Does the provider carry out help desk tests? For example:

• Impersonation tests (is the person at the end of the phone requesting a password reset, really who they say they are?) or so called 'social engineering' attacks.

Atlassian provides information security training as an element of onboarding training ('Day 1') for new starters, and on an ongoing basis to all staff.

In addition to this general information security training, more targeted training is provided for our developers on secure coding, and is supported through our embedded security engineers program.

We also provide ongoing topical training related to malware, phishing, and other security concerns. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

We maintain formal records of completion of internal staff training. Employees are required to acknowledge the Code of Conduct and reaffirm on an annual basis. This policy is provided to all employees. Security awareness, confidentiality, and privacy requirements are presented in their day one trainings, and are available to all employees in Confluence.

6.07.01. (m)

Does the provider carry out penetration testing? How often? What are actually tested during the penetration test - for example, do they test the security isolation of each image to ensure it is not possible to 'break out' of one image into another and also gain access to the host infrastructure? The tests should also check to see if it is possible to gain access, via the virtual image, to the cloud providers management and support systems (e.g., example the provisioning and admin access control systems).

We maintain an internal Red Team that conducts ongoing penetration test operations of all our infrastructure, cloud services and people.

We engage third-party consultancies to perform annual penetration tests on externally facing applications. We also supplement these tests with smaller, ongoing security testing engagements performed by our internal security testing team. The Letters of Assessment for these penetration tests can be found here, along with more information about our testing process, and our approach to external security testing, see: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Does the provider carry out vulnerability testing? How often?

Our Atlassian Security Team performs ongoing network vulnerability scans of both internal and external infrastructure using an industry-recognized vulnerability scanner on an on-going basis. For more information on our Vulnerability Management program, see: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

What is the process for rectifying vulnerabilities (hot fixes, re-configuration, uplift to later versions of software, etc)?

Jira tickets are created for tracking and remediation purposes, and due dates are assigned according to our SLO based on both severity and the source of the vulnerability. We have an on-going process to issue tickets for identified vulnerabilities to system owners, and our Security Management Team reviews any reported vulnerabilities and ensures action is taken against them.

Details on our Vulnerability Management program can be found at: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

As with personnel security, many of the potential issues arise because the IT infrastructure is under the control of a third party - like traditional outsourcing, the effect of a physical security breach can have an impact on multiple customers (organizations).

6.08. (a)

What assurance you provide to the customer regarding the physical security of the location? Please provide examples, and any standards that are adhered to, eg,. Section 9 of ISO 27001/2.

Physical security controls in our offices are guided by our physical and environmental security policy which ensures robust physical security is implemented across our environments on premises and in the cloud.

Our partner data centers are SOC-2 compliant, at a minimum. These certifications address a range of security controls including physical and environmental security and protection. Access to the data centers is limited to authorized personnel, and verified by biometric identity verification measures. Physical security measures include on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures.

6.08. (a) (i)

Who, other than authorized IT personnel, has unescorted (physical) access to IT infrastructure?

• For example, cleaners, managers, 'physical security' staff, contractors, consultants, vendors, etc.

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points. We have published excerpts of all of our internal technology operations and security policies at: https://www.atlassian.com/trust/security/ismp-policies

Atlassian offices have access controls including badge readers, as well as camera surveillance, and have the ability to restrict access to specific times/days as needed. Logs of access to office buildings are maintained by Building Management, and are available to Workplace Experience for investigation purposes.

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance

6.08. (a) (ii)

How often are access rights reviewed?

• How quickly can access rights be revoked?

Atlassian evaluates the performance and effectiveness of its ISMS using suitable metrics. We monitor the performance of the Atlassian Trust Management System (ATMS) and the relevant controls via internal and external audit reviews. The Atlassian Compliance Team manages both our Internal / Internal Readiness Audit schedule as well as our External Audit Schedule (which are documented internally on our Audit Roadmaps page). Internal audits focus on high risk areas across Atlassian and occur on a regular basis according to predetermined schedules and according to the Enterprise Audit Schedule agreed to between the Risk and Compliance Team and the Internal Audit Team. At this time, we do not make our internal metrics public. The ATMS is assessed on an annual basis by independent third parties, and also following any significant changes. Atlassian has achieved SOC 2, ISO27001 and ISO7018 certification for each of our major cloud services. Atlassian also monitors each of the pillars of the ATMS by periodic operational review meetings including specific metrics for each. This includes weekly compliance health reviews of the ATMS and other meetings which are documented internally on our ATMS: Compliance Health Review page and our ATMS Meeting Notes page. For more information please refer to https://www.atlassian.com/trust/compliance.

We have a formal security management program and we review our Information Security Management Program (ISMP) on an annual basis. For more information about our Security Management Program, see: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

Do you assess security risks and evaluate perimeters on a regular basis?

• How frequently?

Atlassian evaluates the performance and effectiveness of its ISMS using suitable metrics. We monitor the performance of the Atlassian Trust Management System (ATMS) and the relevant controls via internal and external audit reviews. The Atlassian Compliance Team manages both our Internal / Internal Readiness Audit schedule as well as our External Audit Schedule (which are documented internally on our Audit Roadmaps page). Internal audits focus on high risk areas across Atlassian and occur on a regular basis according to predetermined schedules and according to the Enterprise Audit Schedule agreed to between the Risk and Compliance Team and the Internal Audit Team. At this time, we do not make our internal metrics public. The ATMS is assessed on an annual basis by independent third parties, and also following any significant changes. Atlassian has achieved SOC 2, ISO27001 and ISO7018 certification for each of our major cloud services. Atlassian also monitors each of the pillars of the ATMS by periodic operational review meetings including specific metrics for each. This includes weekly compliance health reviews of the ATMS and other meetings which are documented internally on our ATMS: Compliance Health Review page and our ATMS Meeting Notes page. For more information please refer to https://www.atlassian.com/trust/compliance.

We have a formal security management program and we review our Information Security Management Program (ISMP) on an annual basis. For more information about our Security Management Program, see: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

Do you carry out regular risk assessments which include things such as neighboring buildings?

Atlassian evaluates the performance and effectiveness of its ISMS using suitable metrics. We monitor the performance of the Atlassian Trust Management System (ATMS) and the relevant controls via internal and external audit reviews. The Atlassian Compliance Team manages both our Internal / Internal Readiness Audit schedule as well as our External Audit Schedule (which are documented internally on our Audit Roadmaps page). Internal audits focus on high risk areas across Atlassian and occur on a regular basis according to predetermined schedules and according to the Enterprise Audit Schedule agreed to between the Risk and Compliance Team and the Internal Audit Team. At this time, we do not make our internal metrics public. The ATMS is assessed on an annual basis by independent third parties, and also following any significant changes. Atlassian has achieved SOC 2, ISO27001 and ISO7018 certification for each of our major cloud services. Atlassian also monitors each of the pillars of the ATMS by periodic operational review meetings including specific metrics for each. This includes weekly compliance health reviews of the ATMS and other meetings which are documented internally on our ATMS: Compliance Health Review page and our ATMS Meeting Notes page. For more information please refer to https://www.atlassian.com/trust/compliance.

We have a formal security management program and we review our Information Security Management Program (ISMP) on an annual basis. For more information about our Security Management Program, see: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

Do you control or monitor personnel (including third parties) who access secure areas?

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points. We have published excerpts of all of our internal technology operations and security policies at: https://www.atlassian.com/trust/security/ismp-policies

Atlassian offices have access controls including badge readers, as well as camera surveillance, and have the ability to restrict access to specific times/days as needed. Logs of access to office buildings are maintained by Building Management, and are available to Workplace Experience for investigation purposes.

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance

6.08. (a) (vi)

What policies or procedures do you have for loading, unloading and installing equipment?

At Atlassian office facilities, loading docks are isolated from working areas, and are monitored by CCTV and Building Staff at all times. Our data center hosting partners manage physical security, and we rely on their compliance certifications to validate the controls are effective.

6.08. (a) (vii)

Are deliveries inspected for risks before installation?

At Atlassian office facilities, loading docks are isolated from working areas, and are monitored by CCTV and Building Staff at all times. Our data center hosting partners manage physical security, and we rely on their compliance certifications to validate the controls are effective.

6.08. (a) (viii)

Is there an up-to-date physical inventory of items in the data center?

An excerpt of our Asset Management Policy is available in https://www.atlassian.com/trust/security/ismp-policies. Atlassian maintains an inventory of all production assets along with asset owners. All our systems are located in AWS-based data centers. Our AWS systems are not tracked at a hardware level due to the nature of the service.

All microservices are tracked in a custom-built Service database, which is updated as any Service is deployed. Atlassian Workplace Technology (WPT) maintains an asset inventory of all endpoints using our own Jira Software for tracking purposes.

All microservices are categorized into tiers, which have uptime, availability, RTO and RPO expectations associated with each tier. For examples, see: https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

Do network cables run through public access areas?

• Do you use armored cabling or conduits?

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points. We have published excerpts of all of our internal technology operations and security policies at: https://www.atlassian.com/trust/security/ismp-policies

Atlassian offices have access controls including badge readers, as well as camera surveillance, and have the ability to restrict access to specific times/days as needed. Logs of access to office buildings are maintained by Building Management, and are available to Workplace Experience for investigation purposes.

6.08. (a) (x)

Do you regularly survey premises to look for unauthorized equipment?

An excerpt of our Asset Management Policy is available in https://www.atlassian.com/trust/security/ismp-policies. Atlassian maintains an inventory of all production assets along with asset owners. All our systems are located in AWS-based data centers. Our AWS systems are not tracked at a hardware level due to the nature of the service.

All microservices are tracked in a custom-built Service database, which is updated as any Service is deployed. Atlassian Workplace Technology (WPT) maintains an asset inventory of all endpoints using our own Jira Software for tracking purposes.

6.08. (a) (xi)

Is there any off-site equipment?

• How is this protected?

An excerpt of our Asset Management Policy is available in https://www.atlassian.com/trust/security/ismp-policies. Atlassian maintains an inventory of all production assets along with asset owners. All our systems are located in AWS-based data centers. Our AWS systems are not tracked at a hardware level due to the nature of the service.

All microservices are tracked in a custom-built Service database, which is updated as any Service is deployed. Atlassian Workplace Technology (WPT) maintains an asset inventory of all endpoints using our own Jira Software for tracking purposes.

6.08. (a) (xii)

Do your personnel use portable equipment (eg,. Laptops, smart phones) which can give access to the data center?

• How are these protected?

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/

Authorized and trained members of Atlassian Engineering teams who have undergone background checks authenticate to the VPN using unique strong passwords and TOTP based 2FA and then only access the production environment via ssh terminal connections using passphrase protected personal RSA certificates. An IDS system is in place on all production servers, which includes realtime monitoring and alerting of any changes to the production system files or configuration and anomalous security events. For those authorized and trained members of the operations team with access to the production system, any workstations running Windows or OS X used for ssh terminal access to the production environment must be running current and active anti-virus software. Customer data is not replicated onto employee workstations or mobile devices.

6.08. (a) (xiii)

What measures are in place to control access cards?

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points. We have published excerpts of all of our internal technology operations and security policies at: https://www.atlassian.com/trust/security/ismp-policies

Atlassian offices have access controls including badge readers, as well as camera surveillance, and have the ability to restrict access to specific times/days as needed. Logs of access to office buildings are maintained by Building Management, and are available to Workplace Experience for investigation purposes.

6.08. (a) (xiv)

What processes or procedures are in place to destroy old media or systems when required to do so?

• data overwritten?
• physical destruction?

Workplace Technology handles this process, equipment is sanitized and degaussed appropriately. Atlassian does not manage any physical media that supports our cloud products and services.

6.08. (a) (xv)

What authorization processes are in place for the movement of equipment from one site to another?

• How do you identify staff (or contractors) who are authorized to do this?

Atlassian's data center hosting partners (AWS) manage physical security, and we rely on their SOC2 to validate the controls are effective.

Atlassian Cloud products do not physically move customer data. Hard drives with customer data are destroyed or sanitized prior to leaving our secured AWS data centers. For systems hosted in AWS, data may be moved between regions in a redundancy scenario but will remain within the AWS. For more information about our AWS regions, see: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

How often are equipment audits carried out to monitor for unauthorized equipment removal?

Atlassian's data center hosting partners (AWS) manage physical security, and we rely on their SOC2 to validate the controls are effective.

Atlassian Cloud products do not physically move customer data. Hard drives with customer data are destroyed or sanitized prior to leaving our secured AWS data centers. For systems hosted in AWS, data may be moved between regions in a redundancy scenario but will remain within the AWS. For more information about our AWS regions, see: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

How often are checks made to ensure that the environment complies with the appropriate legal and regulatory requirements?

Our Atlassian Legal Team and Compliance Teams monitor our regulatory obligations. Please see https://www.atlassian.com/legal/ for our Legal Program. More information on our Compliance program can be found at: https://www.atlassian.com/trust/compliance.

6.09. (a)

What procedures or policies are in place to ensure that environmental issues do not cause an interruption to service?

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points.

Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/

A Business Continuity and Disaster Recovery Policy and Business Continuity and Disaster Recovery Plan are in place and are reviewed annually by the Business Continuity / Disaster Recovery steering committee. All mission-critical systems, processes, or services owners ensure proper business continuity and/or disaster recovery that aligns with the tolerance for disruption in case of a disaster. BCDR plans are tested quarterly and any issues identified are addresses. For more information, see: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management and https://www.atlassian.com/trust/security/data-management.

6.09. (b)

What methods do you use to prevent damage from a fire, flood, earthquake, etc?

• In the event of a disaster, what additional security measures are put in place to protect physical access?
• Both at the primary as well as at the secondary sites?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (c)

Do you monitor the temperature and humidity in the data centre?

• Air-conditioning considerations or monitoring?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (d)

Do you protect your buildings from lightening strikes?

• Including electrical and communication lines?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (e)

Do you have stand-alone generators in the event of a power failure?

• For how long can they run?
• Are there adequate fuel supplies?
• Are there failover generators?
• How often do you check UPS equipment?
• How often do you check your generators?
• Do you have multiple power suppliers?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (f)

Are all utilities (electricity, water, etc) capable of supporting your environment?

• How often is this re-evaluated and tested?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (g)

Is your air-conditioning capable of supporting your environment?

• How often is it tested?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (h)

Do you follow manufacturers recommended maintenance schedules?

Atlassian relies on our partner data hosting partners to validate their datacenter security and environmental controls. For AWS, see https://aws.amazon.com/compliance/programs.

6.09. (i)

Do you only allow authorised maintenance or repair staff onto the site?

• How do you check their identity?

Physical access to office facilities is protected by electronic badge access, business hours reception with mandatory sign-in for visitors, and CCTV at all building entry and exit points. Loading docks are monitored by CCTV and Building Staff at all times. Our data center hosting partners manage physical security, and we rely on their compliance certifications to validate the controls are effective.

6.09. (j)

When equipment is sent away for repair, is the data cleaned from it first?

• How is this done?

Workplace Technology handles this process, equipment is sanitized and degaussed appropriately. Atlassian does not manage any physical media that supports our cloud products and services.

6.10.

Customers and potential customers of cloud provider services should have regard to their respective national and supra-national obligations for compliance with regulatory frameworks and ensure that any such obligations are appropriately complied with.

The key legal questions the customer should ask the cloud provider are:

6.10. (a)

In what country is the cloud provider located?

Atlassian has 12 offices across 8 countries, including Sydney, Amsterdam, Ankara, Boston, Bengaluru, San Francisco, Mountain View, Austin Texas, NYC, Manila, Gdansk, and Japan. For more information, see: https://www.atlassian.com/company/contact.

6.10. (b)

Is the cloud provider's infrastructure located in the same country or in different countries?

For Atlassian Cloud, we are currently hosted within redundant AWS availability zones. For information on specific regions, see: https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

Will the cloud provider use other companies whose infrastructure is located outside that of the cloud provider?

Atlassian cloud products and data are hosted on industry-leading cloud provider Amazon Web Services (AWS). Our products run on a platform as a service (PaaS) environment that is split into two main sets of infrastructure that we refer to as micros and non-micros. Jira, Confluence, Statuspage, Access, and Bitbucket run on the micros platform, while Opsgenie, and Trellow run on the non-micros platform.

6.10. (d)

Where will the data be physically located?

Atlassian uses Amazon Web Services (AWS) in the US-Eat, US-West, Ireland, Frankfurt, Singapore, and Sydney regions (Confluence & Jira).

Specific product details:

• Trello: available in AWS US-East (Ohio).
• Jira Align: physical location of customer data can be requested via support ticket request. See: https://support.atlassian.com/jira-align/.
• Statuspage: available in AWS US-West (Oregon, California) US-East (Ohio) regions.
• Opsgenie: has AWS accounts in both the US and Europe. Customer shall opt-in for AWS US (Oregon, California) or EU (Frankfurt) on sign-up.
• Halp: hosted at AWS in US-East-2 and US-West-2 regions.
• Bitbucket: repositories and core application features are hosted with AWS in US-East and US-West.


For more information about data residency, see: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

Will jurisdiction over the contract terms and over the data be divided?

The default governing law of Atlassian Customer Contract is California law. Please contract our Enterprise Sales Team for more details.

6.10. (f)

Will any of the cloud provider's services be subcontracted out?

Atlassian works with third party sub-contractors to provide website, application development, hosting, maintenance, back-up, storage, virtual infrastructure, payment processing, analysis and other services. These service providers may have access to or process PII for the purpose of providing those services for us.

Atlassian discloses to its relevant customers any use of sub-contractors whom may process their PII, via notification before processing occurs. An external facing list of sub-contractors Atlassian works with is provided on the Atlassian Subprocessors page at: https://www.atlassian.com/legal/sub-processors. On this page, visitors are invited to subscribe to an RSS feed to be notified when we add new Atlassian Subprocessors.

6.10. (g)

Will any of the cloud provider's services be outsourced?

Where Atlassian engages any third-party suppliers we are intent on making sure those engagements do not in any way jeopardize our customers or their data. The Atlassian legal and procurement departments review contracts, SLAs, and vendor internal policies to determine whether the vendor meets requirements for security, availability, and confidentiality. For more information, see: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

How will the data provided by the customer and customer's customers, be collected, processed and transferred?

Atlassian processes information in a way that is compatible with the purposes for which it has been collected or subsequently authorized by the individual, and in particular, in accordance with the Atlassian External Privacy Policy.

User privacy is important to us at Atlassian, and so is being transparent about how we collected, use, and share information about users. For further information please refer to our 'Privacy at Atlassian' page as part of the Atlassian Trust Center at https://www.atlassian.com/trust/privacy, and our Privacy Policy at https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

What happens to the data sent to the cloud provider upon termination of the contract?

Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types. Data is classified in line with our Atlassian Data Security & Information Lifecycle Policy, and controls implemented based on that. For customer data, on termination of an Atlassian contract, the data belonging to a customer team will be removed from the live production database and all file attachments uploaded directly to Atlassian will be removed within 14 days. The team’s data will remain in encrypted backups until those backups fall out of the 90-day backup retention window and are destroyed in accordance with our Atlassian data retention policy. In the event that a database restore is necessary within 90 days of a requested data deletion, the operations team will re-delete the data as soon as reasonably possible after the live production system is fully restored. For more information, see : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/