UK PRA Guidance

Introduction

1.1

The Bank of England prudentially regulates and supervises financial services firms through the Prudential Regulation Authority (PRA).

The SS2/21 (Outsourcing and Third Party Risk Management) supervisory statement sets out the PRA's expectations of how PRA-regulated firms should comply with regulatory requirements and expectations relating to outsourcing and third party risk management.

Your agreement with Atlassian governs the terms of use for Atlassian’s products and services, however, we have also provided guidance on how we assist PRA-regulated firms in complying with PRA SS2/21 requirements. If you would like to understand how these guidelines apply to your specific agreement, please contact our Enterprise Sales Team at https://www.atlassian.com/enterprise/contact?formType=product-features.

SS2/21 - Outsourcing and Third Party Risk Management

Outsourcing Agreements

6.1

In line with Article 31(3) of MODR (banks) and 274(3)(c) of the Solvency II Delegated Regulation (insurers), all outsourcing arrangements must be set out in a written agreement.

Your Atlassian customer contract is a written agreement between you and Atlassian.

6.2

Where there is a master service agreement that allows firms to add or remove certain services, each outsourced service should be appropriately documented, although not necessarily in a separate agreement.

Services are documented in your Atlassian order form.

The Atlassian Product Family page (https://www.atlassian.com/legal/privacy-policy/product-family) includes links to each service's terms of services and privacy policy.
 
In addition, an overview of Atlassian products is available for customer review prior to signing a contract with Atlassian. To view the description of Atlassian products, see: https://confluence.atlassian.com/confeval/other-atlassian-evaluator-resources/overview-of-all-atlassian-products.

6.3

Firms should ensure that written agreements for non-material outsourcing arrangements include appropriate contractual safeguards to manage and monitor relevant risks. Moreover, regardless of materiality, firms should ensure that outsourcing agreements do not impede or limit the PRA's ability to effectively supervise the firm or outsourced activity, function, or service.

Our Atlassian Customer Agreement outlines the shared responsibilities between Atlassian and our Customers. For more information, see: https://www.atlassian.com/legal/atlassian-customer-agreement.

Material Outsourcing Agreements

6.4

Written agreements for material outsourcing should set out at least:

6.4 (a)

A clear description of the outsourced function, including the type of support services to be provided;

Our documentation (https://confluence.atlassian.com/alldoc/atlassian-documentation-32243719.html), which is incorporated by reference into the Atlassian customer contract for qualifying customers, contains clear descriptions of the Covered Cloud Products.

6.4 (b)

The start date, next renewal date, end date, and notice periods regarding termination for the service provider and the firm;

The Atlassian customer contract sets out the default length of a subscription term and all applicable notice periods. In addition, when placing an order for one or more Covered Cloud Products, it will contain the start and end date of the corresponding subscription term.

6.4 (c)

The governing law of the agreement;

The default governing law of Atlassian Customer Contract is California law. Please contact our Enterprise Sales Team for more details at https://www.atlassian.com/enterprise/contact?formType=product-features.

6.4 (d)

The parties' financial obligations;

The pricing for each of the Covered Cloud Products is published on www.atlassian.com

6.4 (e)

Whether the sub-outsourcing of a material function or part thereof is permitted and, if so, under which conditions;

In order to provide global products with minimal interruptions, we may sub-outsource certain critical or important functions to high-quality service providers (e.g., data hosting providers). With respect to material sub-outsourcing, Atlassian commits to ensuring that is has appropriate contracts with such sub-outsourcers, which grant audit, access and information rights, and require such sub-outsourcers to comply with all applicable laws.
 
 Also, see row 7 (6.2), above.

6.4 (f)

The location(s), ie regions or countries, where the material function or service will be provided, and/or where relevant data will be kept, processes, or transferred, including the possible storage location, and a requirement for the service provider to give reasonable notice to the firm in advance if it proposes to change said location(s);

Certain Covered Cloud Products include in-product data residency functionality, as further described here: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/, which allows our customers’ administrators to pin in-scope product data to a location of their choice. This page (https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices) describes our Cloud hosting infrastructure.
 
We contractually commit to (a) not materially degrade product functionality during the applicable subscription term, and (b) notifying customers of any changes to our data hosting locations.

6.4 (g)

Provisions regarding the accessibility, availability, integrity, confidentiality, privacy, and safety of relevant data (see Chapter 7);

See responses to chapter 7 in rows 36 (7.1) through 73 (7.13), below.

6.4 (h)

The right of the firm to monitor the service provider's performance on an ongoing basis (this may be reference to KPIs);

We publish service availability updates at status.atlassian.com, and contractually commit to notifying customers of events that have a material impact on the availability of the Covered Cloud Products.

6.4 (i)

The agreed service levels, which should include qualitative and quantitative performance criteria and allow for timely monitoring, so that appropriate corrective action can be taken if these service levels are not met;

The corresponding service level terms, as well as the remedies for not meeting service levels, for the Covered Cloud Products are provided for in our Service Level Agreement (https://www.atlassian.com/legal/sla) and the corresponding Product Specific Terms (https://www.atlassian.com/legal/product-specific-terms#atlassian-intelligence-specific-terms).

6.4 (j)

The reporting obligations of the service provider to the firm, including a requirement to notify the firm of any development that may have a material or adverse impact on the service provider's ability to effectively perform the material function in line with the agreed service levels and in compliance with applicable laws and regulatory requirements;

We publish service availability updates at status.atlassian.com, and commit to notifying customers of events that have a material impact on the availability of the Covered Cloud Products.

6.4 (k)

Whether the service provider should take out mandatory insurance against certain risks and, if applicable, the level of insurance cover requested;

Atlassian maintains insurance coverages against a number of identified risks and as required by Laws that are applicable to our business.

6.4 (l)

The requirements for both parties to implement and test business contingency plans. For the firm, these should take account of their impact tolerances for important business services. Where appropriate, both parties should commit to take reasonable steps to support the testing of such plans;

We maintain business continuity plans and disaster recovery plans, as described on our Trust Center (https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management). These plans are reviewed and tested at least annually.

6.4 (m)

Provisions to ensure that data owned by the firm can be accessed promptly in the case of the insolvency, resolution, or discontinuation of business operations of the service provider;

We allow the customer to access and export its data throughout the duration of our contract.
 
Neither of these commitments are disapplied on Atlassian’s insolvency. Nor does Atlassian have the right to terminate for Atlassian’s own insolvency - although the customer can elect to terminate for convenience in this scenario.
 
In the unlikely event of Atlassian’s insolvency, the customer can refer to these commitments when dealing with the appointed insolvency practitioner.

6.4 (n)

The obligation of the service provider to co-operate with PRA and Bank, as resolution authority, including persons appointed to act on their behalf (see Chapter 8, including the section on the Bank's and PRA's information gathering and investigatory powers);

Atlassian will cooperate with the regulated institution’s competent authorities and resolution authorities in their exercise of their audit, information and access rights.

6.4 (o)

For banks, a clear reference to the Bank's resolution powers, especially under sections 48Z and 70C-D of the Banking Act 2009 (implementing Articles 68 and 71 of Directive 2014/59/EU (BRRD)), and in particular, a description of the 'substantive obligations' of the written agreement in the sense of Article 68 of that Directive);

Atlassian understands that regulated institutions and any resolution entity must be able to carry on business during resolution. To provide support through resolution, we commit to continue providing the Covered Cloud Products during resolution as required by the BRRD.

6.4 (p)

The rights of firms and the PRA to inspect and audit the service provider with regard to the material outsourced function (see Chapter 8);

Atlassian recognizes that regulated entities under UK PRA must be able to audit our services. Atlassian grants certain audit, access and information rights to such regulated entities and their supervisory authorities in compliance with applicable laws. Regulated entities may access their data on the services at any time and may provide their supervisory authority with access.
 
See responses to chapter 8 in rows 76 (8.1) through 110 (8.14), below.

6.4 (q)

If relevant:

6.4 (q) (i)

• Appropriate and proportionate information security related objectives and measures, including requirements such as minimum ICT security requirement, specifications of firms' data lifecycles, and any requirements regarding to data security (see Chapter 7), network security, and security monitoring processes; and

Protection of customer data is a priority at Atlassian. For more information, see: https://www.atlassian.com/trust/security/data-management.
 
 Also see responses to chapter 7 in rows 36 (7.1) through 73 (7.13), below.

6.4 (q) (ii)

• Operational and security incident handling procedures, including escalation and reporting; and

Atlassian has a documented Security Incident Response Policy and Plan, the fundamental principles of which include the following:

• - Anticipate security incidents and prepare for incident response

• - Contain, eradicate, and recover from incidents

• - Invest in our people, processes, and technologies to ensure we can detect and analyze a security incident when it occurs

• - Make the 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.

6.4 (r)

Termination rights and exit strategies covering both stressed and non-stressed scenarios, as specified in Chapter 10. As in the case of business contingency plans, both parties should commit to take reasonable steps to support the testing of firms' termination plans. Firms may elect to limit contractual termination rights to situations such as:

We provide customers with a broad right to terminate for convenience, which would allow them to terminate in any circumstances.
 
If required, when terminating your agreement with Atlassian, PRA-regulated firms can extend their subscription term for a short period to enable its transition to another service provider.
 
 At any time during a customer’s subscription, customers may access, import, and export their Customer Data using Atlassian’s tools. For more information on Atlassian Cloud data export, see our import and export documentation (https://support.atlassian.com/jira-Cloud-administration/docs/export-issues/).
 
Details of the data deletion process on contract termination can be found at https://community.atlassian.com/t5/Trust-Security-discussions/Contract-Termination-amp-Data-Deletion/td-p/1316109.
 
 Also see responses to chapter 10 in rows 137 (10.1) through 173 (10.16), below.

6.4 (r) (i)

• Material breaches of law, regulation, or contractual provisions;

See row 30 (6.4 (r)), above.

6.4 (r) (ii)

• Those that create risks beyond their tolerance; or

See row 30 (6.4 (r)), above.

6.4 (r) (iii)

• Those that are not adequately notified and remediated in a timely manner.

See row 30 (6.4 (r)), above.

6.5

If an outsourced service provider in a material outsourcing arrangement is unable or unwilling to contractually facilitate a firm's compliance with its regulatory obligations and expectations, including those in paragraph 6.4, firms should make the PRA aware of this.

Atlassian is an industry leaders in security, compliance, third party audits and certifications, which support all our customers' compliance needs.
 
Moving to the Cloud means protecting sensitive workloads while achieving and maintaining compliance with complex regulatory requirements, frameworks, and guidelines. Our team is constantly working to expand coverage to help organizations meet compliance needs.
 
Our Cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally.
 
For more information, see our dedicated resource center with white paper mappings against frameworks and laws where formal certifications or attestations may not be required or applied (https://www.atlassian.com/trust/compliance/resources).

Data Security

7.1

In this chapter, the term 'data' should be interpreted very broadly to include confidential, firm sensitive, and transactional data. It may also cover open source data (eg from social media) collected, analysed, and transferred for the purpose of providing financial services as well as the systems used to process, transfer or store data. The expectations in this chapter apply to material outsourcing arrangements and other third party arrangements that involve the transfer of data with third parties in line with eh EBA ICT GL. This chapter should also be interpreted consistently with requirements under data protection law.

7.2

Where a material outsourcing or third party agreement involves the transfer of or access to data, the PRA expects firms to define, document, and understand their and the service provider's respective responsibilities in respect of that data and take appropriate measures to protect them.

We have a number of measures to ensure that we keep customer data secure, available and that customers retain control over it to the fullest extent possible. For more information, see our Security practices paper (https://www.atlassian.com/trust/security/security-practices#keeping-data-secure) and our Data Processing Addendum (https://www.atlassian.com/legal/data-processing-addendum).

7.3

Building on General Organisation Requirements 2.4 (banks) and Article 274(e) of the Solvency II Delegated Regulation, where a material outsourcing or third party agreement involves the transfer of data, the PRA expects firms to:

7.3 (a)

Classify relevant data based on their confidentiality and sensitivity;

Atlassian is data agnostic. This is a customer consideration.

7.3 (b)

Identify potential risks relating to the relevant data and their impact (legal, reputational, etc.);

Atlassian is data agnostic. This is a customer consideration.

7.3 (c)

Agree an appropriate level of data availability, confidentiality, and integrity; and

The corresponding service level terms, as well as the remedies for not meeting service levels, for the Covered Cloud Products are provided for in our Service Level Agreement and the corresponding Product Specific Terms.
 
 Also see rows 57 (7.10) to 73 (7.13), below.

7.3 (d)

If appropriate, obtain appropriate assurance and documentation from third parties on the provenance or lineage of the data to satisfy themselves that it has been collected and processed in line with applicable legal and regulatory requirements.

This is a customer consideration.

7.4

Some risks relating to data that the PRA expects firms to consider include but are not necessarily limited to unauthorised access, loss, unavailability, and theft.

See row 57 (7.10), below.

Data Classification

7.5

Firms are responsible for classifying their data. While the PRA does not prescribe a specific taxonomy for data classification, it expects firms to implement appropriate, risk-based technical and organisation measures to protect different classes of data (eg confidential, client, personal, sensitive, transaction) when:

7.5 (a)

Developing and implementing their outsourcing policy and other relevant policies and strategies in paragraph 4.10 (business continuity, contingency planning, disaster recover, ICT, information security, operational resilience, OCIR, and risk management); and

Atlassian is data agnostic. This is a customer consideration.
 
More information about Atlassian's security practices can be found in our Security Whitepaper on the Atlassian Trust website, https://www.atlassian.com/trust/security/security-practices.

7.5 (b)

Sharing data with third parties, including but not limited to as part of an outsourcing arrangement.

Atlassian is data agnostic. This is a customer consideration.

Data Location

7.6

As noted in Chapter 10, the PRA recognises the potential benefits for operational resilience of firms using Cloud technology to distribute their data and applications across multiple, geographically dispersed availability zones and regions. This approach can strengthen firms' ability to respond and recover from local operational outages faster and more effectively, and enhance their ability to cope with fluctuations in demand.

Certain Covered Cloud Products include in-product data residency functionality, as further described here (https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/), which allows our customers’ administrators to pin in-scope product data to a location of their choice. This (https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices) page describes our Cloud hosting infrastructure.

7.7

The PRA also recognises the potential negative consequences of restrictive data localisation requirements on firms' innovations, resilience, and costs. None of the expectations in this SS and in particular this section should be interpreted as explicitly or implicitly favouring restrictive data localisation requirements.

For Atlassian Cloud, we are currently hosted within redundant AWS Availability Zones (AZ). For information on specific regions, see: https://www.atlassian.com/trust/reliability/infrastructure.
 
Each AZ is designed to be isolated from failures in other AZs, and to provide inexpensive, low-latency network connectivity to other AZs in the same region. The multi-zone high availability is the first line of defence and means that services running in multi-AZ deployments should be able to withstand AZ failure.
 
In the unlikely event that two AZs have long-term service interruptions, Atlassian Cloud has been designed to recover with limited service interruption and a maximum of 1 hour of data loss. For more information on AZs, see: https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices#availability-zones.

7.8

However, the PRA expects firms to adopt a risk-based approach to the location data that allows them to simultaneously leverage the operational resilience advantages of outsourced data being stored in multiple locations and manage relevant risks, which may include:

7.8 (a)

Legal risks stemming from conflicting or less developed relevant legal or regulatory requirements in one or more of the countries where the data may be processed;

Atlassian only provides customer data to third parties in accordance with our Guideline for Law Enforcement Requests. Details of these guidelines can be found at https://www.atlassian.com/trust/privacy/guidelines-for-law-enforcement.

Atlassian processes all data equally in accordance with it’s DPA. 

 Atlassian also publishes Transparency Reports on the government requests received for customer data at https://www.atlassian.com/trust/privacy/transparency-report/.

7.8 (b)

Challenges to firms', the Bank's, and PRA's ability to access firm data in a timely manner if required (eg as part of their enforcement, resolution, or supervisory functions) due to local law enforcement, legal, or political circumstances; and

Atlassian only provides customer data to third parties in accordance with our Guideline for Law Enforcement Requests. Details of these guidelines can be found at https://www.atlassian.com/trust/privacy/guidelines-for-law-enforcement .
 
 Atlassian also publishes Transparency Reports on the government requests received for customer data at https://www.atlassian.com/trust/privacy/transparency-report/ .

Atlassian grants certain audit, access and information rights to such regulated entities and their supervisory authorities in compliance with applicable laws. Regulated entities may access their data on the services at any time and may provide their supervisory authority with access.

7.8 (c)

Other potential risks to the availability, security, or confidentiality of data, for instance, high risk of unauthorised access or ICT risks stemming from inadequate data processing equipment.

See rows 57 (7.10) to 73 (7.13), below.

7.9

As part of their due diligence and risk assessment in the pre-outsourcing phase, firms should identify whether their data could be processed in any jurisdictions that are outside their risk tolerance and, if so, bring this to the attention of the third party when negotiating the contractual arrangement in order to discuss adequate data protection and risk mitigation measures.

Our production systems for Jira and Confluence are hosted in AWS regions US-East, US-West, Ireland, Frankfurt, Singapore, and Sydney availability regions within Amazon AWS services. For more information, see: https://www.atlassian.com/trust/reliability/infrastructure.
 
At this time, most customers cannot define which jurisdictions their data travels through. We have optimized for latency, and your data will be housed in the region closest to your users. We offer data residency for our Enterprise, Premium, and Standard Cloud customers. For more information, please see: https://www.atlassian.com/enterprise/Cloud & https://www.atlassian.com/software/data-residency.

Data Security

7.10

The PRA expects firms to implement appropriate measures to protect outsourced data and set them out in their outsourcing policy (see Chapter 4) and, where appropriate, in their written agreements for material outsourcing (see Chapter 6).

This is a customer consideration.
 
However, we provide several resources to assist its customers in conducting the necessary risk assessments and due diligence they require. For more information on Atlassian's security and operational practices, visit Atlassian's Trust Center (https://www.atlassian.com/trust) where you will find:

• Security practices - https://www.atlassian.com/trust/security

• Compliance program - https://www.atlassian.com/trust/compliance

• Audit reports/security questionnaires - https://www.atlassian.com/trust/compliance/resources

 
Further, we offer a Data Processing Addendum (https://www.atlassian.com/legal/data-processing-addendum) that provides detailed commitments regarding the processing and security of customer personal data.

7.11

The PRA expects firms to implement robust controls for data-in-transit, data-in-memory, and data-at-rest. Depending on the materiality and risk of the arrangement, these controls may include a range of preventative and detective measures, including but not necessarily limited to:

The following sub-questions are customer considerations.

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
 
 However, Atlassian has robust controls in place, which have been summarised per question.

7.11 (a)

Configuration management. This is a particularly important measure, as for example, in the context of Cloud, misconfiguration of Cloud services can be a major cause of data breaches;

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

7.11 (b)

Encryption and key management;

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 auditing process. Master Keys within KMS, upon creation, enable an auto-rotation to generate Master Key Material every 365 days (annually).
 
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#keeping-data-secure.
 
Secrets are managed using Vault. Vault features the secure storage of credentials using Transparent Data Encryption. Atlassian also maintains encryption keys in AWS KMS. See the Vault whitepaper at https://www.hashicorp.com/resources/unlocking-the-Cloud-operating-model-security/ for more information.

7.11 (c)

Identity and access management, which should include stricter controls for individuals whose role can create a high risk in the event of unauthorised access, (eg systems administrators). Firms should be particularly vigilant about privileged accounts becoming compromised as a result of phishing attacks and other leaking or theft of credentials in line with paragraph 31 of the EBA ICT GL;

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

7.11 (d)

The ongoing monitoring of 'insider threats' (ie employees at the firm and at the third party who may misuses their legitimate access to firm data for unauthorised purposed maliciously or inadvertently). The term 'employee' should be construed broadly for these purposes and may include contractors, secondees, and sub-outsourced service providers (see Chapter 9);

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.
 
At Atlassian, we are intent on making sure all of our staff know how to do their work securely and are empowered to act accordingly. For more information on how we secure our people through security awareness training, security champions program, and background checks, see: https://www.atlassian.com/trust/security/security-practices#securing-our-people.
 
Further, we secure out internal environment through ZeroTrust. Simply stated, the core tenet of ZeroTrust is: "never trust, always verify". See how we handle a ZeroTrust security model in our public Whitepaper: https://www.atlassian.com/trust/security/security-practices#securing-access-through-zerotrust.

7.11 (e)

Access and activity logging;

See row 62 (7.11 (d)), above.

7.11 (f)

Incident detection and response;

See row 29 (6.4 (q) (ii)), above.

7.11 (g)

Loss prevention and recovery;

See row 22 (6.4 (l)), above.

7.11 (h)

Data segregation (if using multi-tenant environment);

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.

7.11 (i)

Operating system, network, and firewall configuration;

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.

7.11 (j)

Staff training;

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.

7.11 (k)

The ongoing monitoring of the effectiveness of the service provider's controls, including through the exercise of access and audit rights (see Chapter 8);

See rows 53 (7.8 (b)) & 57 (7.10), above.

7.11 (l)

Policies and procedures to detect activities that may impact firms' information security (eg data breaches, incidents, or misuse of access by third parties) and response to these incidents appropriately (including appropriate mechanisms for investigations and evidence collection after an incident); and

See row 29 (6.4 (q) (ii)), above.

7.11 (m)

Procedures for the deletion of firm data from all the locations where the service provider may have stored it following an exit or termination, provided that access to the data by the firm or PRA is no longer required (see Chapters 8 and 10). When deciding when to delete data, firms will need to consider their obligations under data protection law and their potential data retention obligations.

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/

7.12

Where data is encrypted, firms should ensure that any encryption keys or other forms of protection are kept secure by the firm or outsourcing provider. The data protected by encryption (although not necessarily the encryption keys themselves) should be provided to the PRA in an accessible format if required, in accordance with Fundamental Rule 7 and other potentially relevant regulatory requirements.

See row 60 (7.11 (b)), above.
 
In addition, at any time during a customer’s subscription, customers may access, import, and export their customer fata using Atlassian’s tools. For more information on Atlassian Cloud data export, see our import and export documentation (https://support.atlassian.com/jira-Cloud-administration/docs/export-issues/).

7.13

The ability of service providers to respond to customer-specific data security requests may vary depending on the service being provided. Generally, the more standardised the service, the more difficult it might be for the service provider to accommodate these requests. The PRA’s focus is on the overall effectiveness of the service provider’s security environment, which should allow firms to meet their regulatory and risk management obligations and be at least as effective as their in-house security environment. As long as service providers can provide assurance that this is the case, the PRA does not have specific expectations around customer-specific requests.

Our Cloud products are provided in a SaaS delivery model. There is a clear delineation between the administrative responsibilities of Atlassian (in providing the platform) and our tenants (in using the platform, including administering their organizational users and data). For more information, have a look at our Shared Responsibility Security Whitepaper: https://www.atlassian.com/whitepapers/Cloud-security-shared-responsibilities.

Access, Audit, and Information Rights

Bank and PRA Information Gathering and Investigatory Powers

8.1

Independent of the expectations on access, audit, and information rights set out later in this chapter, the Bank and PRA have a range of statutory information-gathering and investigatory powers, some of which may apply directly to outsourced service providers as well as firms. The PRA expects firms to make service providers aware of the powers and requirements as set out in Tables 6 and 7 below, which are not exhaustive. However, failure to do so will not affect their applicability.

Atlassian will cooperate with the institution’s competent authorities and resolution authorities in their exercise of their audit, information and access rights.
 
Our audit program is designed to allow qualifying customers and their supervisory authorities to audit the Covered Cloud Products effectively.

Non-Material Outsourcing Arrangements

8.2

The PRA expects firms to adopt a risk-based approach to access, audit, and information rights in respect of non-material outsourcing arrangements. In doing so, they should take into account the arrangement’s riskiness and the likelihood of it becoming material in the future (see Chapter 5).

See row 76 (8.1), above.

Material Outsourcing Arrangements

8.3

Building on Chapter 6, the PRA expects firms to take reasonable steps to ensure that written agreements for material outsourcing arrangements provide firms, firms’ auditors, the PRA, the Bank (as a resolution authority), and any other person appointed by firms or the Bank and PRA, with full access and unrestricted rights for audit and information to enable firms to:

See row 76 (8.1), above.
 
In addition, at any time during a customer’s subscription, customers may access, import, and export their customer data using Atlassian’s tools. For more information on Atlassian Cloud data export, see our import and export documentation (https://support.atlassian.com/jira-Cloud-administration/docs/export-issues/).

8.3 (a)

Comply with their legal and regulatory obligations; and

See row 76 (8.1), above.

8.3 (b)

Monitor the arrangement.

See row 76 (8.1), above.

8.4

Access, audit, and information rights in material outsourcing arrangements should include where relevant:

8.4 (a)

Data, devices, information, systems, and networks used for providing the outsourced service or monitoring its performance. This may include, where appropriate, the service provider’s policies, processes, and controls on data ethics, data governance, and data security;

Atlassian provides several resources to assist its customers in conducting the necessary due diligence they require. For more information on Atlassian's security and operational practices, visit Atlassian's Trust Center at https://www.atlassian.com/trust, where you will find details on our security practices, compliance programs, and audit reports/security questionnaires.
 
 In addition, Atlassian makes available the following information:

• Corporate Governance and Financial information at https://investors.atlassian.com/;

• Managerial/Executive team information at https://www.atlassian.com/company/news/press-kit;

• Performance record at https://status.atlassian.com/; and

• Customer information at https://www.atlassian.com/customers.

8.4 (b)

The results of security penetration testing carried out by the outsourced service provider, or on its behalf, on its applications, data, and systems to ‘assess the effectiveness of implemented cyber and internal IT security measures and processes’;

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.
 
Atlassian also hires a third-party specialist to review the security state of our Cloud applications based on the risk of new services or new environments. Details on our Vulnerability Management program can be found at: https://www.atlassian.com/trust/security/vulnerability-management.
 
Atlassian also offers customers the right to carry out penetration testing at any time without Atlassian’s prior approval: atlassian.com/trust/security/security-testing.

8.4 (c)

Company and financial information; and

Atlassian was founded in 2002 in Sydney, Australia. For more information about our company, see: https://www.atlassian.com/company. As a publicly traded company, Atlassian's annual investor reports can be found here: https://investors.atlassian.com/financials-and-filings/annual-reports/default.aspx

8.4 (d)

The service provider's external auditors, personnel, and premises.

Our Cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally. You can review Atlassian's industry leading security, third party audits and certifications, documentations, and legal commitments that help support your compliance at our Compliance Resource Center (https://www.atlassian.com/trust/compliance/resources).
 
For information on our leadership team and board of directions, see: https://investors.atlassian.com/governance/Management-team/default.aspx & https://investors.atlassian.com/governance/management-team---board-of-directors/default.aspx.
 
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.

8.5

The PRA considers that it is not sufficient for firms merely to negotiate adequate access, audit, and information rights; these must also be used when appropriate. The purpose of the rights outlined in this chapter is to support firms’ identification, assessment management, and mitigation of any identified risks relating to a material outsourcing arrangement. The appropriate exercise of these rights is key to providing the assurance that such an arrangement is being provided as agreed with the outsourced provider and in line with regulatory requirements.

See row 76 (8.1), above.

Pooled Audits and Third Party Certificates and Reports

8.6

The PRA expects firms to exercise their access, audit, and information rights in respect of material outsourcing arrangements in an outcomes-focused way, to assess whether the service provider is providing the relevant service effectively and in compliance with the firm’s legal and regulatory obligations and expectations, including as regards operational resilience.

This is a customer consideration. Please also see row 76 (8.1), above.

8.7

Firms may use a range of audit and other information gathering methods, including:

8.7 (a)

Offsite audits, such as certificates and other independent reports supplied by service providers; and

See row 97 (8.9 (a)), below.

8.7 (b)

Onsite audits, either individually or in conjunction with other firms (pooled audits).

Atlassian does not allow onsite visits by customers or customer audits. We have had our security and GRC program validated by Ernst & Young. For copies of Atlassian's compliance certificates, see: https://compliance.atlassian.com.

8.8

Firms can choose any appropriate audit method as long as it enables them to meet their legal, regulatory, operational resilience, and risk management obligations. The level of assurance expected will, however, become more onerous depending on proportionality (ie whether the firm is significant (see Chapter 3)) and the materiality of the arrangement (see Chapter 5). For instance, a significant firm that outsources an important business service for which it has set a low impact tolerance should demand a higher level of assurance.

This is a customer consideration.
 
However, Atlassian is an industry leaders in security, compliance, third party audits and certifications, which support all our customers' compliance needs.
 
Moving to the Cloud means protecting sensitive workloads while achieving and maintaining compliance with complex regulatory requirements, frameworks, and guidelines. Our team is constantly working to expand coverage to help organizations meet compliance needs.
 
Our Cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally.
 
For more information, see our dedicated resource center with white paper mappings against frameworks and laws where formal certifications or attestations may not be required or applied (https://www.atlassian.com/trust/compliance/resources).

Third Party Certificates and Reports

8.9

Certificates and reports supplied by service providers may help firms obtain assurance on the effectiveness of the service provider’s controls. However, in material outsourcing arrangements, the PRA expects firms to:

8.9 (a)

Assess the adequacy of the information in these certificates and reports, and not assume that their mere existence or provision is sufficient evidence that the service is being provided in accordance with their legal, regulatory, and risk management obligations; and

Atlassian undergoes annual external audits as prescribed by industry best practices and guidance. Each of our major Cloud products have achieved SOC2, ISO27001, and ISO27018 certifications. Customers may download these certification reports from our Trust Center after signing an NDA. For a list of these products and applicable certification reports, please visit https://www.atlassian.com/trust/compliance.

8.9 (b)

Ensure that certificates and audit reports meet the expectations in Table 8.

See row 97 (8.9 (a)), above.

8.10

In material outsourcing arrangements, the PRA expects firms to retain the contractual rights to:

8.10 (a)

Request additional, appropriate, and proportionate information if such a request is justified from legal, regulatory, or risk management perspectives; and

See row 76 (8.1), above.

8.10 (b)

Perform onsite audits (individual or pooled) at their discretion.

See row 93 (8.7 (b)), above.

Onsite Audits

8.11

Before an onsite audit, the PRA expects firms, individuals, and organisations acting on their behalf to:

8.11 (a)

Provide reasonable notice to the service provider, unless this is not possible due to a crisis or emergency, or because it would defeat the purpose of the audit. Such notice should include the location and purpose of the visit and the personnel that will participate in the visit;

See row 93 (8.7 (b)), above.

8.11 (b)

Verify that whoever is performing the audit has appropriate expertise, qualifications, and
skills; and

See row 93 (8.7 (b)), above.

8.11 (c)

Take care if undertaking an audit of a multi-tenanted environment, (eg a Cloud data centre), to avoid or mitigate risks to other clients of the service provider in the course of the audit (eg availability of data, confidentiality, impact on service levels).

See row 93 (8.7 (b)), above.

8.12

Certain types of onsite audit may create an unmanageable risk for the environment of the provider or its other clients, for example, by impacting service levels or the confidentiality, integrity, and availability of data. In such cases, the firm and the service provider may agree alternative ways to provide an equivalent level of assurance, for instance, through the inclusion of specific controls to be tested in a report or certification. The PRA expects that firms should retain their underlying right to conduct an onsite audit. For material outsourcing arrangements, the PRA would expect the firm to inform their supervisor if alternative means of assurance have been agreed.

See row 93 (8.7 (b)), above.

Pooled Audits

8.13

Pooled audits may be organised by groups of firms sharing one or more service providers or facilitated by the service providers. They may be performed by representatives of the participating firms or specialists appointed on their behalf. Pooled audits can be more efficient and cost effective for firms and less disruptive for service providers running multi-tenanted environments. They can also help spread costs and disseminate best industry practices with regard to audit methods among firms.

Our audit program permits institutions to review the Covered Cloud Products using pooled audits and/or third party certifications.

8.14

Where pooled audits lead to common, shared findings, the PRA expects each participating firm to assess what these findings mean for it individually, and whether they require any follow-up on their part.

This is a customer consideration.

Sub-Outsourcing

9.1

The EBA Outsourcing GL define ‘sub-outsourcing’ as ‘a situation where the service provider under an outsourcing arrangement further transfers an outsourced function to another service provider’, which may also include part of an outsourced function. The PRA Rulebook also explicitly acknowledges that a service provider may perform ‘a process, a service or an activity which would otherwise be undertaken by the firm itself [...] directly or by sub-outsourcing’. Sub-outsourcing, which is also sometimes referred to as ‘chain’ outsourcing, can amplify certain risks in material outsourcing, including:

9.1 (a)

Limiting firms’ ability to manage the risks of the outsourcing arrangement, in particular, where there are large chains of sub-outsourced service providers spread across multiple jurisdictions; and

Where Atlassian engages any third-party suppliers (including contractors and Cloud service providers) we are intent on making sure those engagements do not in any way jeopardise our customers or their data. To this end, a review process is undertaken by our legal and procurement teams for any proposed third-party supplier engagements. For any engagements we deem high or critical risk, these are subject to additional reviews by our security and risk and compliance teams. Ongoing due diligence also occurs via subsequent reviews - either upon contract renewal or annually depending on the risk level of the engagement.
 
Atlassian also requires its suppliers to comply with minimum security requirements as part of their engagement with us. These are enforced via inclusion in our supplier contracts. These requirements will vary depending on the risk level of the engagement, and includes the following:

• SAML integration with Atlassian’s single sign on platform

• Encryption for data in transit and at rest using non-deprecated algorithms

• Having sufficient logging mechanisms in place to provide Atlassian with relevant information regarding potential security incidents

 
For more information see how we secure our ecosystem and supply chain partners - https://www.atlassian.com/trust/security/security-practices#securing-our-ecosystem-and-supply-chain-partners

9.1 (b)

Giving rise to additional or increased dependencies on certain service providers, which the firm may be fully aware of or may not want.

See row 113 (9.1 (a)), above

Firms' Oversight of Sub-Outsourcing

9.3

The PRA expects firms to assess the relevant risks of sub-outsourcing before they enter into an outsourcing agreement. It is important that firms have visibility of the supply chain, and that service providers are encouraged to facilitate this by maintaining up-to-date lists of their sub-outsourced service providers.

This is a customer consideration.
 
 See row 113 (9.1 (a)), above and https://www.atlassian.com/trust/security/security-practices#supplier-risk-management, for information about how Atlassian manages its supply risk management.

9.4

The PRA expects firms to pay particular attention to the potential impact of large, complex sub-outsourcing chains on their operational resilience, including their ability to remain within impact tolerances during operational disruption. Firms should also consider whether extensive sub-outsourcing could compromise their ability to oversee and monitor an outsourcing arrangement.

This is a customer consideration.
 
However Atlassian gives the assurance that security is built into the fabric of our Cloud products, infrastructure, and processes, so you can rest assured that your data is safeguarded. For more information see our security pages in our Trust Center (https://www.atlassian.com/trust/security).

9.5

Firms should assess whether sub-outsourcing meets the materiality criteria set out in Chapter 5, which includes the potential impact on the firm’s operational resilience and the provision of important business services. Firms should only agree to material sub-outsourcing if:

9.5 (a)

The sub-outsourcing will not give rise to undue operational risk for the firm in line with Outsourcing 2.1(1) (banks) and Conditions Governing Business 7.2(2) (insurers); and

This is a customer consideration.
 
However where Atlassian engages any third-party suppliers (including contractors and Cloud service providers) we are intent on making sure those engagements do not in any way jeopardise our customers or their data.
 
 See row 113 (9.1 (a)), above.

9.5 (b)

Sub-outsourced service providers undertake to:

9.5 (b) (i)

• Comply with all applicable laws, regulatory requirements, and contractual obligations; and

Atlassian is a industry leaders in security, compliance, third party audits and certifications, which support all our customers' compliance needs.
 
 Moving to the Cloud means protecting sensitive workloads while achieving and maintaining compliance with complex regulatory requirements, frameworks, and guidelines. Our team is constantly working to expand coverage to help organizations meet compliance needs.
 
Our Cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally.
 
For more information, see our dedicated resource center with white paper mappings against frameworks and laws where formal certifications or attestations may not be required or applied (https://www.atlassian.com/trust/compliance/resources).

9.5 (b) (ii)

• Grant the firm, Bank, and PRA equivalent contractual access, audit, and information rights to those granted to the service provider.

Customers are able to search Atlassian’s industry leading security, third party audits and certifications, documentations, and legal commitments that help support your compliance.
 See https://www.atlassian.com/trust/compliance/resources

9.6

Firms should ensure that the service provider has the ability and capacity on an ongoing basis to appropriately oversee any material sub-outsourcing in line with the firm’s relevant policy or policies. This includes establishing that the service provider has in place robust testing, monitoring, and control over its sub-outsourcing.

See rows 113 (9.1 (a)), 15 (6.4 (e)), and 7 (6.2), above.

9.7

If the proposed material sub-outsourcing could have significant adverse effects on a material outsourcing arrangement or would lead to a substantive increase of risk, the firm should exercise its right to object to the material sub-outsourcing and/or terminate the contract.

See row 30 (6.4 (r)), above.

9.8

There may be situations where the same service provider has a direct contractual relationship with a firm and is also a sub-outsourced service provider to that firm. An example might be a firm that has an agreement with a Cloud service provider that provides services to one or more software vendors used by that firm. In those situations, where appropriate, firms may leverage their direct contractual relationship with that service provider to assess its resilience in respect of all the services it relies on that provider for, including as a material sub-outsourced service provider.

This is a customer consideration.

Written Agreement

9.9

In line with Chapter 6, the PRA expects written agreements for material outsourcing to indicate whether or not material sub-outsourcing is permitted, and if so:

9.9 (a)

Specify any activities that cannot be sub-outsourced;

See row 15 (6.4 (e)), above

9.9 (b)

Establish the conditions to be complied with in the case of permissible sub-outsourcing, including specifying that the service provider is obliged to oversee those services that it has sub-contracted to ensure that all contractual obligations between the service provider and the firm are continuously met;

See row 15 (6.4 (e)), above

9.9 (c)

Require the service provider to:

9.9 (c) (i)

• Obtain prior specific or general written authorisation from the firm before transferring data (see Article 28 GDPR); and

Atlassian provides product and cloud terms that outline all contractual agreements, including sub-outsourcing. As Atlassian services are provided as one-to-many, if a customer had the right to object to a sub-outsourcing, this could result in a single customer denying all Atlassian customers the benefits provided by the sub-outsourcing arrangement. For further information, see: https://www.atlassian.com/legal/product-specific-terms & https://www.atlassian.com/legal/atlassian-customer-agreement.

9.9 (c) (ii)

• Inform the firm of any planned sub-outsourcing or material changes, in particular where that might affect the ability of the service provider to meet its responsibilities under the outsourcing agreement. This includes planned significant changes to sub-contractors and to the notification period. Firms should be informed sufficiently early to allow them to at least carry out a risk assessment of the proposed changes and object to them before they come into effect;

See row 131 (9.9 (c) (i)), above

9.9 (d)

Ensure that, where appropriate, firms have the right to:

9.9 (d) (i)

• Explicitly approve or object to the intended material sub-outsourcing or significant changes thereto; and

See row 30 (6.4 (r)), above for information about customers right to terminate in any circumstance.
 
However, as Atlassian services are provided as one-to-many, if a customer had the right to object to a sub-outsourcing, this could result in a single customer denying all Atlassian customers the benefits provided by the sub-outsourcing arrangement.

9.9 (d) (ii)

• Ensure that the firm has the contractual right to terminate the agreement in the case of specific circumstances, (eg where the sub-outsourcing materially increases the risks for the firm or where the service provider sub-outsources without notifying the firm).

See row 30 (6.4 (r)), above.

Business Continuity and Exit Plans

10.1

For each material outsourcing arrangement, the PRA expects firms to develop, maintain, and test a:

10.1 (a)

Business continuity plan; and

This is a customer consideration.
 
At Atlassian, 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 addressed. 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.

10.1 (b)

Documented exit strategy, which should cover and differentiate between situations where a firm exits an outsourcing agreement:

10.1 (b) (i)

• In stressed circumstances, (eg following the failure or insolvency of the service provider (stressed exit)); and

The corresponding service level terms, as well as the remedies for not meeting service levels, for the Covered Cloud Products are provided for in our Service Level Agreement and Atlassian Customer Agreement. (https://www.atlassian.com/legal/sla) and the corresponding Product Specific Terms
 https://www.atlassian.com/legal/product-specific-terms
 https://www.atlassian.com/legal/atlassian-customer-agreement).
 
We allow the customer to access and export its data throughout the duration of our contract.
 
 Neither of these commitments are disapplied on Atlassian's insolvency. Nor does Atlassian have the right to terminate for Atlassian’s own insolvency - although the customer can elect to terminate for convenience in this scenario.
 
 In the unlikely event of Atlassian’s insolvency, the customer can refer to these commitments when dealing with the appointed insolvency practitioner.

10.1 (b) (ii)

• Through a planned and managed exit due to commercial, performance, or strategic reasons (non-stressed exit).

See row 140 (10.1 (b) (i)), above.

10.2

The PRA’s primary focus when it comes to business continuity plans and exit strategies is on the ability of firms to deliver important business services provided or supported by third parties in line with their impact tolerances in the event of disruption. Consequently, notwithstanding the importance of effectively planning for non-stressed exits, the main focus of this chapter is on business continuity and stressed exits.

This is a customer consideration.

Business Continuity

10.3

Firms should implement and require service providers in material outsourcing arrangements to implement appropriate business continuity plans to anticipate, withstand, respond to, and recover from severe but plausible operational disruption.

See row 138 (10.1 (a)), above.

10.4

An important objective of the access, audit, and information rights in Chapter 8 is to enable firms, the PRA, and the Bank to assess the effectiveness of service providers’ business continuity plans. In particular, they should be able to assess the extent to which they may enable the delivery of important business services for which a firm relies (wholly or in part) on the service provider, within the firm’s impact tolerance in severe but plausible scenarios.

In addition to our BCP and DRP (row 138, 10.1 (a), above), Atlassian also publishes our service availability plan in real-time for our customers using our own Statuspage product. Customers will know of any issues as soon as Atlassian does. For more information, see: https://www.atlassian.com/trust/security/security-practices#service-availability.

10.5

In material Cloud outsourcing arrangements, the PRA expects firms to assess the resilience requirements of the service and data that are being outsourced and, with a risk-based approach, decide on one or more available Cloud resiliency options, which may include:

10.5 (a)

Multiple data centres spread across geographical regions;

See row 55 (7.9), above.

10.5 (b)

Multiple active data centres in different availability zones within the same region, which allows the service provider to re-route services if a data centre goes down;

For Atlassian Cloud, we are currently hosted within redundant AWS Availability Zones (AZ). For information on specific regions, see: https://www.atlassian.com/trust/reliability/infrastructure.
 
Each AZ is designed to be isolated from failures in other AZs, and to provide inexpensive, low-latency network connectivity to other AZs in the same region. The multi-zone high availability is the first line of defence and means that services running in multi-AZ deployments should be able to withstand AZ failure.
 
In the unlikely event that two AZs have long-term service interruptions, Atlassian Cloud has been designed to recover with limited service interruption and a maximum of 1 hour of data loss. For more information on AZs, see: https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices#availability-zones.

10.5 (c)

A hybrid Cloud (ie a combination of on-premises and public Cloud data centres);

We use Amazon Web Services (AWS) as a Cloud service provider and leverage AWS' compute, storage, network, and data services to build our products and platform components. For more information, see: https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices#atlassian-Cloud-hosting-architecture.

10.5 (d)

Multiple or back-up vendors;

At Atlassian, we operate a comprehensive backup program. With respect to our Cloud products, we use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.
 
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, https://www.atlassian.com/trust/reliability/Cloud-architecture-and-operational-practices#data-backups.

10.5 (e)

Retaining the ability to bring data or applications back on-premises; and/or

This is a customer consideration.
 
However Atlassian facilitates the ability to import and/or export content data from each specific Cloud product used by the customer. For more information see Atlassian's Data Storage FAQ, https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

10.5 (f)

Any other viable approach that can achieve and promote an appropriate level of resiliency.

This is a customer consideration

10.6

There is no hierarchy or one-size-fits-all combination of Cloud resiliency options. The optimal option or combination of options will depend on various factors, including but not limited to the:

10.6 (a)

Size and internal organisation and the nature, scope, and complexity of the firm’s activities (proportionality);

This is a customer consideration

10.6 (b)

Potential impact of the outsourcing arrangement on the provision of important business services by the firm (materiality); and

This is a customer consideration

10.6 (c)

The relative costs and benefits of different options, taking into account the risks that failure or prolonged operational disruption may pose to UK financial stability or the safety and soundness of the firm, and (for insurers) policyholder protection.

This is a customer consideration

10.7

If a significant firm wants to outsource its core banking platform to the Cloud, the PRA may expect it to adopt one or more of the most resilient options available to maximise the chances to maintain its resilience in the event of a serious outage. Conversely, if a non-significant firm wishes to do so, then a less resilient but nonetheless robust option or combination of options could be appropriate.

Our Cloud infrastructure takes advantage of elastic scale, multi-level redundancy, and failure options across regions to reduce latency, maintain reliability, and scale with your organization's needs.
 
We make it easy to stay informed on our system availability and performance at all times. The real-time status of Atlassian Cloud products are posted on our Statuspage.
 
We offer a financially-backed SLA of 99.95% uptime with our Jira and Confluence Cloud Enterprise plans, so your teams can count on reliable products that allow them to focus on your organization’s objectives.
 
 For more information, see https://www.atlassian.com/trust/reliability.

10.8

The PRA expects firms to consider the implications of deliberately destructive cyber-attacks when establishing or reviewing data recovery capabilities, either individually or collaboratively.

Atlassian assumes responsibility for security, availability and performance of the applications we provide, the systems they run on, and the environments within which those systems are hosted. However, security is a joint responsibility between Atlassian and our customers with respect to four areas in particular:

• policy and compliance,

• users,

• information, and

• marketplace apps.

 
 At Atlassian, we appreciate that disruptions can happen. So we are determined to build-in processes to plan for disruptions, and handle disruption with minimal impact to our customers when they do occur. Our business continuity (BC) and disaster recovery (DR) programs capture the various activities done to meet those objectives. To this end, our BC and (DR) programs involve the following activities:

1. building-in redundancy measures to meet resiliency requirements

2. testing and verifying those redundancy measures

3. learning from tests to continuously keep improving BC and DR measures

 
 For more information see https://www.atlassian.com/trust/security/security-practices#sharing-responsibility-for-managing-customer-data & https://www.atlassian.com/trust/security/security-practices#making-use-of-logs.

10.9

In line with Fundamental Rule 7, in the event of a disruption or emergency (including at an outsourced or third party service provider), firms should ensure that they have effective crisis communication measures in place. This is so all relevant internal and external stakeholders, including the Bank, PRA, FCA, other international regulators, and, if relevant, the service providers themselves, are informed in a timely and appropriate manner.

This is a customer consideration.
 
However, Atlassian has an established framework for managing incidents. To ensure our incident response process is consistent, repeatable and efficient, we have a clearly defined internal framework that covers the steps we need to take at each phase of the incident response process.
 
Every incident we experience is managed by one of our highly-qualified and experienced Major Incident Managers (or MIMs). The MIMs are further supported by incident analysts who lead the investigation and analysis of incidents, as well as a range of other roles to assist with the response process including access to external experts where required.
 
 For more information, see our Security Incident Management pages: https://www.atlassian.com/trust/security/security-incident-management.

Stressed Exits

10.10

Firms’ exit plans should cover stressed exits and be appropriately documented and tested as far as possible.

This is a customer consideration. Please also see row 30 (6.4 (r)), above.

10.11

A key objective of the stressed exit part of exit plans is to provide a last resort risk mitigation strategy in the event of disruption that cannot be managed through other business continuity measures, including those mentioned in the previous section, (eg the insolvency or liquidation of a service provider).

This is a customer consideration.
 
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/.

10.12

The PRA does not prescribe or have a preferred form of exit in stressed scenarios. Its focus is on the outcome of the exit, (ie the continued provision by the firm of important business services provided or supported by third parties), rather than the method by which it is achieved.

This is a customer consideration

10.13

The PRA does, however, expect firms to identify viable forms of exit in a stressed exit scenario, and give meaningful consideration to those that best safeguard their operational resilience, which may include but not be limited to:

10.13 (a)

Bringing the data, function, or service back in-house/on-premises;

We have provisions in place so that we can respond to user requests to delete personal information, and we also help end users with Atlassian accounts delete their personal information.
 
We also have import and export tools so that our customers can access, import and export their data using Atlassian’s tools. For more information, see https://www.atlassian.com/trust/security/security-practices#retention-and-deletion-of-data.
 
For more information on transferring data, see: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

10.13 (b)

Transferring the data, function, or service to an alternative or back-up service provider; or

See row 165 (10.13 (a)), above

10.13 (c)

Any other viable methods.

See row 165 (10.13 (a)), above

10.14

The PRA expects firms to consider the available tools that could help facilitate an orderly stressed exit from a material outsourcing arrangement. Such tools are constantly evolving, in particular in technology outsourcing, including Cloud, and may include:

10.14 (a)

New potential service providers;

This is a customer consideration

10.14 (b)

Technology solutions and tools to facilitate the switching and portability of data and applications; and

This is a customer consideration

10.14 (c)

Industry codes and standards.

This is a customer consideration.
 
However, our Cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally. For information see our Compliance Resource Center, https://www.atlassian.com/trust/compliance/resource.

10.15

The PRA recognises that, in an intragroup outsourcing context, firms’ exit options might be more limited than in other scenarios. This is particularly true for third-country branches, which are unable to enter into standalone contractual arrangements with third parties. Nevertheless, the PRA expects third-country branches to take reasonable steps to try and identify options, however limited, to maintain their operational resilience.

This is a customer consideration

10.16

Firms should also actively consider temporary measures that can help ensure the ongoing provision of important business services following a disruption and/or a stressed exit, even if these are not suitable long-term solutions, (eg contractual or escrow arrangements), allowing for continued use of a service or technology for a transitional period following termination.

This is a customer consideration