You have put your trust in us and we won’t let you down.
Read our Trust Report
Where we can, we store application data in our customers' Jira instance. Where we can’t, customer data is stored in our AWS account in the US Oregon region (specifically us-west-2) and Frankfurt (specifically eu-central-1) for our customers located in the EU.
We classify four types of data:
We use the principle of least privilege to limit team member access to these three types of data.
As per Cloud Platform (above), this data is stored in the US region on AWS, Atlassian, and third-party providers. These providers are classified as Subprocessors under our Privacy Policy.
No, our team members can not access your company’s Jira data.
Atlassian Server / Data Center - none.
Atlassian Cloud - Our apps for Jira Cloud require these Atlassian Connect Scopes (permissions): Read, Write, Delete and Project Administration. The Atlassian Connect framework respects the permissions of the user, project, etc. so requests for Jira data are made by the account of the person using the app.
The CEO, Tech Lead of the Platform Engineering team, and our Security and IT Manager have access to our production AWS account which includes Customer Application Data. A non-exhaustive list of data this contains:
If you believe you have found or experienced a security vulnerability with an Easy Agile product or service raise a security incident.
We align with Atlassian’s Severity Levels for Security Issues, and their App Security Incident Management Guidelines for Atlassian Marketplace Vendors.
The Cloud Security Alliance provides the CAIQ-Lite questionnaire covering 73 of the most common security questions from the industry. If you are looking for the standardised responses see our most recent CAIQ-Lite.
Our apps are primarily client-side Javascript applications that run in a user's web browser. They retrieve most of the data they require directly from your company’s Atlassian Jira instance. We augment the Jira data with specific application data (referred to as Customer Data below).
Where that Customer Data is stored depends on whether you are using Atlassian Cloud, or their Server/Data Center solution:
All of our production infrastructure resides in AWS in the US and Frankfurt regions. We leverage several services, yet of particular importance is our use of Organizations, Security Hub, GuardDuty, Config and CloudTrail to continuously audit and improve our security posture.
We use several separate AWS accounts covering our development, test, stage and production environments for both internal systems and our customer-facing applications. This ensures that we can segregate access and systems, knowing clearly who has access to which environment.
We leverage the Atlassian Connect framework for the delivery of our apps which extend Jira. This framework has Atlassian’s standard security best practices built in, and so we get those for ‘free’.
In addition, as a Platinum Atlassian Marketplace Partner, we are a participant in the Cloud Fortified, Bug Bounty, Ecoscanner, Vulnerability Disclosure and Cloud Security programs. Each of these has annual renewal requirements and confirms that we are, at a minimum, meeting Atlassian’s security standards.
In addition to Atlassian and Amazon platform services, we leverage several other services to provide our services.
From an application health perspective, we leverage Bugsnag and Datadog for exception and application performance monitoring respectively. Neither of these contain PII or customer data.
For customer outreach, we use Hubspot and BigMarker. These do contain end-user PII and Customer Company Information. They do not contain Customer Application or Jira Data.
Finally, we have several internal systems which enable us to understand the health of our business. These do contain PII and Customer Company Information. These systems reside in AWS accounts separate from our customer-facing applications.
An ‘Easy Agile’ flavour, and one that continuously adapts based on the size of the company (growing), the product portfolio (evolving), and the needs of our customers.
Automation between Jira and Github makes sure that a standard approach is followed across all software engineers. For example, source code branches must have a Jira issue key and two approvers are required on a pull request to merge a branch into main.
Automated testing in development, test and staging environments with final promotion from stage to production provides confidence that what we ship is what we mean to ship. Telemetry around all of these aspects gives us visibility into the health of the applications through the software development and delivery lifecycle.
Yes, our infrastructure in AWS is created via code (Amazon Web Services CDK). All changes to our infrastructure follow the same flow as changes to our applications - a pull request is created, that requires two additional approvers, the branch is then merged and promoted via stage and into production, providing time for future testing in each environment.
Changes are finally promoted to production, all with an audit trail from the first commit to production.
Our customer-facing applications leverage the existing Atlassian authentication as they extend the functionality of Jira.
As for our internal systems and procedures, we leverage an SSO solution and require MFA on all of our Cloud Platform providers.
Passwords are only ever used once and stored in a password manager by each team member.
Finally, we use the principle of least privilege to minimise access to systems to only those necessary and on request.
No, each of our environments is segregated into a different AWS account (under one Organization for billing purposes). As production is in a completely separate AWS account we can limit access.
Two team members have access to the production AWS account. Authentication is via our SSO solution, which in turn requires MFA. Only a CEO can change who has access to the production account.
See our Service Level Agreement.
Yes, we do have a business continuity procedure and it was tested and modified extensively in 2020 and 2021. We have a flexible approach to work, supporting team members in setting up home offices and ensuring they can continue to work regardless of the environment.
We have not yet exercised our disaster recovery procedure, yet given our infrastructure as code and snapshots of databases we feel confident we can restore our Cloud Platform on another provider if needed.
Another aspect to consider here is that Atlassian also uses AWS exclusively. So if AWS is down, Atlassian Cloud is down, and all of our primary software development systems are then also down. We do not factor this scenario into our disaster recovery procedure today.
Easy Agile has conducted two penetration tests. One in 2022, and another in 2023. Our 2024 penetration test is scheduled to be completed by the end of June,
Yes, we use a device management solution to track company device compliance with our security policy. As we do not have physical server infrastructure and use AWS this device management is limited to team member laptops.
As a Platinum Atlassian Marketplace Partner we adhere to the App Security Incident Management Guidelines for Atlassian Marketplace Vendors.
If you have any further questions, don't hesitate to reach out.