Security Self-Assessment Program

Scope

Questions

Passing criteria

Answer

Status

1a

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.

Yes

Customer data is different according to the app:

• Elements Checklist: licensing information, configuration, data.

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

• Elements Copy & Sync: licensing information, configuration.

• Elements Publish: licensing information, configuration.

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

Any data is always stored in secure databases hosted by AWS, in their Northern Virginia data center. Data is encrypted at rest and in transit. Moreover, only few Elements administrators has 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.

1b

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

N/A Reference information.

N/A

2

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.

Yes

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.

3

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.

Yes

4

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.

Yes

5

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

Yes, and provides details.

Yes

6

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

7

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.

Yes

8

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.

Yes

In the event where a security breach is detected by our infrastructure and confirmed as genuine, we have documented a security procedure on our Confluence to raise a ticket with the Atlassian service desk (e.g.: https://ecosystem.atlassian.net/servicedesk/customer/portal/14/create/129)

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.

9

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.

Yes

10

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.

Yes

11

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.

No

We do not provide any public information partly because no known vulnerability has been exploited yet through our apps.

If needed, we have means of reaching to our customers via mailing and our public facing web sites, Jira instances (e.g., Support), our documentation and the Atlassian Marketplace.

As for handling security issues we mostly rely on three elements:

• Specific tooling to detect libraries with known vulnerabilities or potential issues with our own code.

• Strict peer code review.

• Sonar review.

Note: we participate in the Bug Bounty Program.

12

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

Yes, with description.

Yes

For this, we rely on AWS to do the actual infrastructure management and have set up some customisations in order to better suit our needs.

• Our apps are hosted by Amazon Web Services. Thus we automatically benefit from the expertise and high availability provided:

  • For Elements Connect and Elements Checklist: these apps run on EC2 instances. Those are automatically managed by services such as Elastic Beanstalk and Elastic Container Service.

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

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

• Our apps start automatically when the servers are restarted to mitigate possible downtime.

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

13

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.

Yes