Last update and review by Atlassian:



Passing criteria



Customer Data


Do you store customer data from the customer Atlassian instance? If so, please outline any protection mechanisms you will have in place to protect this customer data.

Ideally No. If Yes, provide details of controls in place.



Customer data is different according to the app:

  • Elements Connect: analytics, licensing information, configuration (containing connection details of datasources), datasource data.

  • Elements Copy & Sync: analytics, licensing information, configuration.

  • Elements Spreadsheet: analytics, licensing information. Spreadsheet documents are not stored on Elements side, but directly stored inside the customer instance as page attachments.

  • Elements Publish: analytics, licensing information, configuration.

  • Elements Overview: analytics.

Any data is always stored in secure databases hosted on AWS, in their Northern Virginia data center. Data is encrypted at rest and in transit. Moreover, only few Elements employees have the possibility to get access to these databases, and only on request, from a unique IP, following a specific procedure. By default, all databases are closed and not exposed to the Internet. The previous mentioned procedure explains how to temporarily expose a database only to our private network for maintenance purposes.


If you have answered Yes to Question Number 1a, what is the jurisdiction(s) of where this data is hosted?

N/A Reference information.



Data is hosted in the AWS Data Center, in Northern Virginia, USA. So, jurisdiction of this location applies.
Sensitive Data


Is your application designed to store sensitive information? (For example: Credit card data, Personally Identifiable Information, Financial data, Source code, Trading algorithms or proprietary models)

Ideally No. If Yes, provide details of controls in place.



Only Elements Connect stores sensitive data; customer databases connection details. This data is of course encrypted in the database, and access to it is highly controlled and restricted.

Other apps are not supposed to store sensitive data.

Security Policy


Do you have an Information Security Policy with supporting Standards and Procedures? Please provide details (or provide a copy of the policy).

Yes, and provides details.



Our policy is currently undergoing a major overhaul, as our SOC2 project was officially launched this year with Drata.
Release Management


Do you have formal change control and release management processes to manage code changes? Please provide details (or provide a copy of the documented process).

Ideally Yes and provides process documents. If no, describe the current process.



Our process is currently undergoing a major overhaul, as our SOC2 project was officially launched this year with Drata.


Do you undertake audits or other reviews to ensure that security controls are being implemented and operating effectively?

Yes, and provides details.



We perform periodic security reviews of all of our hosting services. The last one has been performed in 2020, by a french company named Vaadata. A new one should be performed this year or next. In addition, we use Sonar and many security rules from several standards such as CWE, SANS and OWASP to strengthen reviews.



Are you accredited to any relevant security standards (e.g., SSAE16 SOC1/2/3, ISO27001, PCI DSS)?

N/A No accreditation required to pass, but beneficial.

No (not yet)


Accreditation is in progress. We plan to be SOC2 Type 2 compliant this year (2023) with the help of Drata.
Penetration Testing


Do you undertake penetration testing (or similar technical security testing, code review or vulnerability assessment); and are you able to provide copies of results/findings?

Ideally Yes and provides results. Or Yes and describe process.



We perform periodic penetration testing of all of our hosting services. The last one has been performed in 2020 by the same french company (Vaadata). No major security flaw has been found up to now. A new penetration test should be performed this year or next. Moreover, our Sonar tool is once again strongly used to ensure the security of our apps. Finally, we participate in the Bug Bounty Program in order to get a continual security testing.
Notifying Atlassian


Do you have mechanisms to notify Atlassian in case of a security breach?

An Add-on Security Incident ticket should be filed with us immediately upon your detection of a security incident. You must stay available to communicate with our security team during resolution and inform our team via the ticket when the incident is resolved. While you are responsible for informing your affected customers as necessary, your communication with us helps us direct customers who have reached out to Atlassian for help. It also informs us in case we need to take necessary action to prevent additional breaches.

Yes, and provide details of the documented plan with notification and follow up procedure.



In an event of a successful security breach caught by our infrastructure we have documented a security procedure on our Confluence to raise a ticket with the Atlassian portal (

The procedure may be summarized as follows:

  • Confirm the breach and gather all details.

  • Create a ticket with Atlassian.

  • While investigating or performing corrective actions keep the ticket up to date with important information.

  • When the incident is closed, update the ticket with the resolution.

Employee Access


Do your employees (e.g., developers or system administrators) have access to Atlassian customer data? How is this access controlled and monitored?

Ideally No. If Yes, provide details of a tightly controlled system.



Only few Elements administrators could get access. These persons are identified, and every access is logged.


Are all personnel required to sign Non-Disclosure Agreement (NDA) or Confidentiality Agreements (CA) as a condition of employment to protect customer information?

Yes if they have access to sensitive information. Otherwise not necessary.



Customer information is legally protected by a Confidentiality Agreements clause in every employment contract.
Managing Security Vulnerabilities


Do you have a publicly documented process for managing security vulnerabilities in your application(s)?

Yes, and provides the URL to the documentation. Or No, and describes handling of security vulnerability identified in the code.



Here is our process.

1) Discovering & Categorization

We define the nature of the security vulnerability.

2) Escalation & Exploration

We set its severity, its CVSS Score and the associated SLA.

3) Remediation

We fix and we test.

4) Communication

We contact Atlassian for any P1 (as soon as possible).

We inform our customers:

  • by email (only for P1).

  • with a "mea culpa" in our documentation.

  • with a reference in the release notes.

5) Post mortem.

We learn.

Disaster Recovery


Do you have Business Continuity and/or Disaster Recovery Plans? If Yes, please provide details including backup and redundancy mechanisms.

Yes, with description.



Our infrastructures rely on AWS. Thus, we automatically benefit from the expertise and high availability provided.

  • For Elements Connect: this app runs thanks to Elastic Container Service.

  • For Elements Copy & Sync, Elements Publish and Elements Spreadsheet: these apps are completely Serverless and use services like Lambda.

  • For Elements Overview: it's different because this app is built with the Forge framework, which means the whole infrastructure is handled by Atlassian.

Databases are managed by RDS and DynamoDB services.

There is a Load Balancer in front of each app.

We have set up monitoring probes that detect apps downtime and other factors such as high servers load, disk usage, etc. and automatically notify system administrators which are available 24H/5 days a week (excluding weekends).

If a server is down, another one is automatically deployed and the service is restored in few minutes.

For apps specific support, we have agents in many major time zones (present in both Europe and Canada) so we can provide a very quick feedback depending on the issue severity.

Data Recovery


Do you have capability to recover data for a specific customer in the case of a failure or data loss? Please outline your processes and recovery capabilities for data loss including time frames. What is the maximum data loss period a customer can expect?

Yes, with backup every 24 hrs.



We have set up daily backups (RDS snapshots and Point-In-Time-Recovery for DynamoDB tables) and we hold backups for at least one month.