| Principle 1: Data in Transit Protection |
| 1.1 Encryption | Atlassian maintains encryption on the internal wireless network including modifying default vendor settings. Atlassian's Workplace Technology team protects our wireless networks by utilising WPA2-AES authentication and PEAP-EAP-MSCHAPv2 encryption. We authenticate to our wireless network through 802.1x utilising our internal identity store. We scan for rogue wireless access points regularly, and maintain a list of rogue access points found.
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 | Our security and data privacy policies
Encryption of Data | Atlassian Trust Center Data
Encryption | Atlassian Cloud architecture and operational practices |
| 1.2 Network Protection | Atlassian's Policy Management Program (PMP) includes a Communications Security Policy which establishes responsibility for management of the network.
For network access Atlassian use a centralised LDAP enabled directory implementing role based access control based on defined profiles. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Internal production network access rules are maintained using explicitly designated Security Groups within AWS VPC environments.
Atlassian's Workplace Technology team protects wireless networks by utilising WPA2-AES authentication and PEAP-EAP-MSCHAPv2 encryption. We authenticate to our wireless network through 802.1x utilising our internal identity store.
Atlassian Network Engineering uses IPS technologies that are built into our cloud and office firewalls and we have 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 unauthorised disclosure or modification, whether over HTTPS or SMTPS. Atlassian implementations of TLS enforce the use of strong ciphers. | Our security and data privacy policies
Building Security into our Network Infrastructure | Atlassian Trust Center |
| 1.3 Authentication | 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 sing-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.
Atlassian supports the use of Google, Microsoft and Apple identities for authentication to most products. We also support SAML for our Atlassian cloud services through Atlassian Access, see : https://www.atlassian.com/enterprise/cloud/access | Our security and data privacy policies
Securing access to our networks through ZeroTrust | Atlassian Trust Center Service
Authentication & Authorization | Atlassian Cloud architecture and operational practices |
| Principle 2: Asset protection and resilience |
| 2.1 Physical location and legal jurisdiction | Physical Location
Today, Atlassian maintains data centers and hosts data in the US, Germany, Ireland, Singapore, and Australia. We provide all customers with secure, fast and reliable services by hosting their content in multiple regions around the world.
All production Atlassian Cloud systems reside in US-East and US-West regions of Amazon AWS, the AWS Ireland region, the AWS Frankfurt region, the AWS Sydney region and the AWS Singapore region.
Our Atlassian platform optimizes upon sign-up where customer data is located based on origin of access, ensuring more reliable performance and reduced latency.
Currently, data residency is available today as part of our cloud Standard, Premium, and Enterprise plans for Jira Software, Confluence, and Jira Service Management. You can also choose to host certain product data in Australia, Europe, or the United States. Learn about data residency controls.
Keep an eye on our cloud roadmap to see the latest updates, including data residency for additional locations, data residency for apps, and more. | Physical Location
Keeping Data Secure | Atlassian Trust Center
Atlassian Cloud Hosting Infrastructure | Atlassian Cloud architecture and operational practices |
| Use of your Data
Please refer to Atlassian's Customer Agreement, Privacy Policy and Data Processing Addendum. | Use of your data
Atlassian Customer Agreement | Atlassian
Privacy Policy | Atlassian
Data Processing Addendum | Atlassian |
| Additional Considerations
Please refer to Atlassian’s Commitment to GDPR and other data protection legislation. | Additional Considerations
GDPR commitment | Atlassian | Atlassian |
| 2.2 Data Center Security | This is addressed in Atlassian’s Data Processing Addendum where Atlassian makes commitments to protect your data, including regarding data center and network security and data security.
Atlassian anticipates physical threats to its data centers and has implements countermeasures to prevent or limit impact from these threats.
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 maintains multiple certifications for the protection of their data centers. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/ | See
https://www.atlassian.com/trust/security/securitypractices#physical-security |
| 2.3 Data Encryption | Atlassian maintains encryption on the internal wireless network including modifying default vendor settings. Atlassian's Workplace Technology team protects our wireless networks by utilising WPA2-AES authentication and PEAP-EAP-MSCHAPv2 encryption. We authenticate to our wireless network through 802.1x utilising our internal identity store. We scan for rogue wireless access points regularly, and maintain a list of rogue access points found.
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 | Our security and data privacy policies
Encryption of Data | Atlassian Trust Center
Data Encryption | Atlassian Cloud architecture and operational practices |
| 2.4 Data Sanitization & Equipment Disposal | 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/ | Retention & Deletion of Data | Atlassian Trust Center
Track storage and move data across products | Atlassian Support |
| 2.5 Physical Resilience & Availability | 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. This policy covers areas such as secure working areas, securing our IT equipment wherever it may be, restricting access to our buildings and offices to appropriate personnel, and monitoring physical ingress and egress points. Our physical security practices include reception attendance during work hours, requirements for visitors to register, badge access to all non-public areas, and we partner with our office building management for after hours access and video recording at ingress and egress points - both for main entrances as well as loading areas.
Our partner data centres 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 centres 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.
In addition to the above measures, we also publish our service availability status in real-time for our customers using our own Statuspage product. If there are any issues with any of our products, our customers will know as soon as we do. | Physical Security | Atlassian Trust Center |
| Principle 3: Separation between customers |
| | While our customers share a common cloud-based IT infrastructure when using Atlassian’s products, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.
Atlassian’s approach to achieving this varies across our applications. In the case of Jira and Confluence cloud, we use a concept we refer to as the “tenant context” to achieve logical isolation of our customers. This is implemented both in the application code, and managed by something we have built called the “Tenant Context Service” (TCS). This concept ensures that:
- Each customer’s data is kept logically segregated from other tenants when at-rest
- Any requests that are processed by Jira or Confluence have a “tenant-specific” view so other tenants are not impacted
In broad terms, the TCS works by storing a "context" for individual customer tenants. The context for each tenant is associated with a unique ID stored centrally by the TCS, and includes a range of metadata associated with that tenant (such as which databases the tenant is in, what licenses the tenant has, what features they can access, and a range of other configuration information). When a customer accesses Jira or Confluence cloud, the TCS uses the tenant ID to collate that metadata, which is then linked with any operations the tenant undertakes in the application throughout their session.
The context provided by the TCS effectively acts as a ''lens'' through which any interactions with customer data occur – and this lens is always confined to one specific tenant. This ensures that one customer tenant does not access data of another tenant – nor for one tenant to affect the service of another tenant through their own actions.
More information about our cloud architecture is available as part of our cloud support resources. | Atlassian Cloud architecture and operational practices | Atlassian Trust Center |
| Principle 4: Governance Framework |
| | Atlassian recognizes that regulated entities need to review our internal controls, systems, and data security and privacy protections for the services as part of their risk assessments. Atlassian yearly undergoes several independant third-party audits to provide verification of our operations and internal controls.
To view our current compliance program, please visit our Compliance Resource Center to access all downloadable verification and certifications of our products.
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. | Our security and data privacy policies
Compliance & Risk Management | Atlassian Trust Center
Our Atlassian Trust Management System (ATMS) | Atlassian Trust Center
Data Processing Addendum | Atlassian Trust Center |
| Principle 5: Operational Security |
| 5.1 Vulnerability Management | Atlassian is constantly working to reduce the severity and frequency of vulnerabilities in our products, services and infrastructure and ensure that identified vulnerabilities are fixed as quickly as possible. To facilitate this, we have implemented a multi-faceted and continually evolving approach to vulnerability management that utilizes both automated and manual processes to identify, track, and remediate vulnerabilities across our applications and infrastructure.
For all our products and service offerings, we have an extensive bug remediation process (utilising our own product Jira which captures issues and helps us to manage resolving requests). Underpinning this are numerous security bug fix policies, advisories services and SLOs that we adhere to. We take in bug reports via our Support Channel, our Bug Bounty program, and security@atlassian.com. Further information is available on our Trust Center (https://www.atlassian.com/trust ) about our Security Bug Fix SLOs (https://www.atlassian.com/trust/security/bug-fix-policy ).
Our Atlassian Security Team uses multiple methods to detect vulnerabilities in both internal and external infrastructure. 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.
More information is available in our dedicated paper on Atlassian’s Approach to Vulnerability Management.
More information about our Approach to Security Testing is also at our Trust Center at : Approach to External Security Testing | Atlassian | Vulnerability Management | Atlassian Trust Center
Security Bugfix Policy | Atlassian Trust Center
Approach to External Security Testing | Atlassian Trust Center
Approach to Vulnerability Management | Atlassian Trust Center |
| 5.2 Protective Monitoring | In recognition of the need to build upon our approach to incident management in the context of an increasingly complex threat landscape, Atlassian has introduced what we call our “security detections program”. Detections are searches that run proactively on a scheduled basis on Atlassian’s Security Incident and Event Management platform to detect malicious activity targeting Atlassian and its customers.
Our detection and response team focuses on the regular creation of new detections, tuning and improving existing detections, and automating detection responses. They do this across a number of dimensions, including products, attack types and log sources so as to ensure the coverage of our detections is as effective and comprehensive as possible.
The aim of the program is to ensure we not only ensure we are prepared for the threats we face today, but sufficiently anticipate and prepare for the threat landscape of the future. Our detection and response team has also created a tool to standardize the detections we create to ensure a high level of consistency and quality amongst the detections we execute – something we believe is a first in the industry.
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. 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 | Atlassian Detections Program | Atlassian Trust Center
Making use of Logs | Atlassian Trust Center
Data Processing Addendum | Atlassian Trust Center |
| 5.3 Incident Management | Atlassian has a comprehensive approach to handle security incidents. We consider a security incident to be any instance where there is a negative impact to the confidentiality, integrity or availability of customers’ data, Atlassian’s data, or Atlassian’s services.
We have a clearly defined internal framework that includes documented playbooks for different incident types. The framework covers the steps we need to take at all stages of incident response to ensure our processes are consistent, repeatable and efficient. These include coverage of incident detection and analysis, incident categorization, containment, eradication and recovery. This consistency is supported through the use our own products, including Confluence, Jira and Bitbucket as part of our incident response processes:
- Confluence is used to create, document and update our response processes in a central location
- Jira is used to create tickets for tracking progress on the response process for security incidents (potential and actual) from start to finish
- Bitbucket is used in instances where we develop code-based solutions for responding to certain edge-case problems that arise with certain incidents
Comprehensive and centralized logging and monitoring of our products and infrastructure is in place to ensure we quickly detect potential incidents, supported by a team of highly-qualified on-call incident managers who have significant experience in coordinating an effective response. We also have access to a range of external experts to assist us with investigating and responding as effectively as possible.
We have notification processes in place for our customers if their data is involved in a confirmed incident, as well as a robust post-incident review process so we can take any lessons from an incident to improve our practices to make the job of malicious actors harder in the future. For more information, please see our separate paper our Atlassian Trust Center on Our Approach to Managing Security Incidents. | Incident Management | Atlassian Trust Center
Data Processing Addendum | Atlassian Trust Center |
| 5.4 Configuration and Change Management | Our change management process is slightly different from a traditional one. Traditional change management processes rely on a pyramid-style change control hierarchy. That is, when someone wants to make a change, it has to be presented to a board that eventually approves or denies it.
We have embraced an open source style approach we call “Peer Review, Green Build” (PRGB). In contrast to a traditional change management process the PRGB approach requires that each change – be it a code change or an infrastructure change – is reviewed by one or more peers to identify any issues the change may potentially cause. We increase the number of reviewers based on the criticality of the change or the criticality of the systems that the change is going to impact, trusting our engineers to identify issues and then flag them before the change can go through. This process works well to provide a dynamic and adaptable way of managing changes in our environment. The green build portion of this control refers to a successful or clean build in our CI/ CD with the new changes included. If the change introduces components that do not successfully pass any of the integration, function, unit or security tests, the build is rejected and returns to the original change request to address any issues.
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 | Managing changes to our Environment | Atlassian Trust Center
How to Move from Quality Assurance to Quality Assistance |
| Principle 6: Personnel Security |
| | Company Values
Information about Atlassian’s Company Values is available here: https://www.atlassian.com/company/values
| Company Values
Company values | Atlassian
|
| Employee background checks
New Atlassians 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 the position requires it. We perform full background checks for senior executive and accounting roles. | Employee background checks
Background Checks | Atlassian Trust Center |
| Security training for all Atlassian employees
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. Security Awareness | Atlassian Trust Center | Security training for all Atlassian employees
Security Awareness | Atlassian Trust Center |
| Principle 7: Secure Development | 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 appropriate 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 (Atlassian’s bug bounty program | Bugcrowd ) to provide continuous assurance of our applications.
In addition, you can review Atlassian’s SOC 2 report. The focus of this report is to evaluate an organization's systems relevant to security, availability, processing integrity, confidentiality and privacy. | Data Processing Addendum | Atlassian Trust Center |
| Principle 8: Supply chan security | 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
| Supplier Risk Management | Atlassian Trust Center
Atlassian SOC 2 | Page 29 (Vendor Management) |
| Principle 9: Secure user management |
| 9.1 Authentication of users to management interfaces and support channels | Here at Atlassian - we believe that this is a shared responsibility between both customer and Atlassian.
Authenticated Users
We treat all customer data as equally sensitive and have implemented stringent controls governing this data. Awareness training is provided to our internal employees and contractors during the on-boarding process which covers the importance of and best practices for handling customer data.
Within Atlassian, only authorized Atlassians have access to customer data stored within our applications. Authentication is done via individual passphrase-protected public keys, and servers only accept incoming SSH connections from Atlassian and internal data center locations. All access is restricted to privileged groups unless requested and reviewed, with additional authentication requiring 2FA.
With stringent authentication and authorization controls in place, our global support team facilitates maintenance and support processes. Hosted applications and data are accessed for the purpose of application health monitoring and performing system or application maintenance, or upon customer request via our support system. Our customers are also provided with options regarding explicit consent as to which support engineers are appropriate to access their data through our consent control checker.
Unauthorized or inappropriate access to customer data is treated as a security incident and managed through our incident management process. This process includes instructions to notify affected customers if a breach of policy is observed. | Controlling access to customer data | Atlassian Trust Center
Data Processing Addendum | Atlassian Trust Center |
| 9.2 Separation and access control within management interfaces | With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Issue service and Confluence Analytics.
Atlassian developers provision these services through an internally developed platform-as-a-service (PaaS), called Micros, which automatically orchestrates the deployment of shared services, infrastructure, data stores, and their management capabilities, including security and compliance control requirements (see figure 1 above). Typically, an Atlassian product consists of multiple "containerized" services that are deployed on AWS using Micros. Atlassian products use core platform capabilities (see figure 2 below) that range from request routing to binary object stores, authentication/authorization, transactional user-generated content (UGC) and entity relationships stores, data lakes, common logging, request tracing, observability, and analytical services.
On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud products. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.
To learn more, please visit https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Multi-tenant Architecture | Atlassian Cloud architecture and operational practices
Data Processing Addendum | Atlassian Trust Center |
| Principle 10: Identity and Authentication |
| | Please refer to 9.1 and 9.2 for more information on authentication and access management. | N/A |
| Principle 11: External Interface Protection |
| | Please refer to Principle 5 for more information on how Atlassian Trust protects our cloud cloud customers. | N/A |
| Principle 12: Secure Service Administration |
| | In Atlassian’s Data Processing Addendum, we make commitments to protect customer data, including access control and privilege management.
Please refer to 9.1 and 9.2 for more information on authentication and access management. | N/A |
| Principle 13: Audit Information For Users |
| | All access to Customer application is logged. Every user interface interaction is recorded in application audit log.
Atlassian restricts, logs and monitors privileged access to our Atlassian Account Identity Store and other information security management systems.
Logs are stored in a logically separate system and write-access to the logs is restricted to members of the Security Team. Alerts are sent to the Security Team or Service Desk when specific actions or events are identified within the logs. Our centralized logging Service (covering the Atlassian Cloud Platform, JIRA, Confluence and Bamboo) is integrated with our security analytics infrastructure for automated analysis and alerts are created to identify potential issues.
For Bitbucket, audit logs are used for post-incident investigation. Puppet managed service configuration and as a declarative configuration format ensures that all system configurations managed by its manifests are configured properly on every run. Monitoring alerts are in place if puppet fails to run on a given server. Our internal and external vulnerability scanners include alerting on any unexpected ports being open or other configuration changes (e.g., TLS profiles of listening servers).
Refer to Atlassian Access, for more information, see : Atlassian Access | Security & SSO for Jira, Confluence, Etc.
Internally for Atlassian, logs are stored in a logically separate system and write-access to the logs is restricted to members of the Security Team and our Observability Team. Our centralized logging Service is integrated with our security analytics infrastructure for automated analysis and alerts are created to identify potential issues.
For Atlassian Cloud customers, audit logs for changes to the organization are available as part of Atlassian Access. With audit logs, you have visiblity into admin actions to users, groups, permissions etc. More information can be found here: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
Atlassian cloud products also have their own audit logging for product specific changes. | N/A |
| Principle 14: Secure Use of the Service |
| | Here at Atlassian - we believe that this is a shared responsibility between both customer and Atlassian.
There are a range of other resources we’ve referred to in this paper or which you can otherwise consult to get more information about our approach to vulnerability management, as well as security more generally.
| N/A |