Security

In the first half of 2026, we'll be moving Easy Agile Cloud apps from Atlassian Connect to Atlassian Forge, Atlassian's new Cloud developer platform.

Most customers won't notice day to day changes, but we want to be clear about what's happening, why we're doing it, and what (if anything) you may need to do.

What's changing

We're migrating our Easy Agile Cloud apps to Forge during the first half of 2026. Because each app has its own rollout plan, the best way to stay informed is to watch for email updates related to the specific Easy Agile apps you use.

We’re aiming for like-for-like behaviour, but a small number of changes are hard to avoid. Depending on the app you use, you may notice:

• Minor cosmetic updates.
• Custom fields shown on work items will link to the work item search page, showing all work items in a program or increment.
• The URL will change, so any saved bookmarks may need updating. You can still access the app from the Jira navigation.

Why we're doing this

Atlassian is moving away from Connect, the previous developer platform, over time. Forge is where Atlassian is investing for the future of Cloud apps, and we're making this shift so we can continue to:

• Deliver ongoing improvements and fixes
• Stay aligned with Atlassian's platform direction
• Keep our apps secure and supported over the long term

Having our apps Forge native also means greater reliability, security, and performance for our customers.

Impact for customers

Will there be downtime?

While we do our best to keep any downtime a minimum, there maybe some small periods of time where features are inconsistent or missing. This is due to data and features migrating within the Atlassian platform and are expected to only last minutes at the most.

Will performance or reliability change?

We do not expect any meaningful performance or reliability changes as a result of the migration.

Will admins need to take action (re-consent/permissions)?

Our goal is to make this as smooth as possible. We don't expect administrators to need to approve new permissions as part of this transition.

Data and compliance

Does this change where your data is stored or processed? 

No change right now. We will continue using our existing secure platform to store and process app data.

Does more data leave Atlassian than before?

No. This migration does not introduce any additional data leaving Atlassian compared to our current Connect-based apps. Data captured in our apps (like your retrospective data) continues to be stored and processed in our existing secure platform, due to limitations of the current offerings on the Forge platform. These offerings are in active development and can change in the future, so we are constantly assessing the readiness of the platform.

Data residency, policies, and documentation

There are no changes to data residency or compliance documentation as part of this migration.

Do Easy Agile apps qualify for Atlassian’s “Runs on Atlassian” badge?

Not at this time. That badge applies to apps that use only Atlassian-hosted compute and storage. Some of our data processing still uses our existing secure platform due to current Forge limitations, and we’ll reassess as Forge evolves.

Pricing

This migration to Forge will not change what customers are currently paying.

If anything related to pricing were to ever change in the future, we would communicate that separately with appropriate notice.

Next steps

If you use one of our apps on Cloud, you don't need to do anything right now. We’ll send app-specific emails as each migration rolls out, including what to expect, any visible changes, and anything admins may need to review.

If you have questions about your environment, security review requirements, or data handling, please reach out to our team via support@easyagile.com and we'll point you in the right direction.

‍

‍

Software security—it’s definitely not the sexiest of topics, but it’s an important one. When not prioritized, it can lead to devastating results for developers, stakeholders, and users.

Software security isn’t about strong passwords or authentication. It happens long before, while a product is being built. By implementing best practices early in the design process, software developers can embed rigorous security measures into every aspect of a product's design.

In this post, we’ll share 6 critical strategies for improving and maintaining software security.

As a Platinum Atlassian Marketplace Partner, Easy Agile products adhere to stringent security measures.

Try Easy Agile Apps for Jira

The importance of software security

Customers depend on their applications being secure. Software security protects against malicious cyberattacks, hacking, and other online risks. It’s a prevention method that addresses security early rather than waiting for security issues to occur.

The number of cyberattacks increases every year with no sign of slowing down. More and more of our business practices and personal lives are moving online, which means there are more and more opportunities for hackers to exploit.

This is why it is critical that software designers understand the gravity of software security and put security protocols front and center in the design process. When issues and vulnerabilities get spotted early, you can address them quickly and with fewer costs.

How to improve and maintain software security

Software security is an ongoing process. You always need to work to improve your security by investing in training, making security part of your software design process, and meticulously testing for potential vulnerabilities.

Follow our 6 strategies to improve and maintain your software security.

📖 READ: Easy Agile Trust Centre - Our commitment to you

1. Make security decisions at the design level

The best way to prevent a security risk is by building security into the earliest stages of development. Keeping software security top-of-mind while making any design decision will prevent attacks from disrupting your product.

Putting in the time early in the design process will save time later on, and it’s much more cost-effective than a break/fix method that deals with issues as they occur. You can safeguard the security of software and prevent security breaches as well as dangerous software defects if everyone on your team addresses security throughout the design process, especially when making big product decisions.

Just like keeping customer needs at the forefront of decision-making, consider security every step of the way. A security breach or application downtime could negatively impact your stakeholders and users severely.

2. Invest in team training and education

Security is only as strong as your weakest link, which is why it’s so important to invest heavily in employee training. Regularly training your team in software security best practices will ensure everyone is on the same page about what’s expected, where in the software development life cycle (SDLC) security is addressed, and how to keep up with the evolving security landscape.

Malicious attackers are always coming up with new ways to disrupt and exploit software, so it’s important that teams are regularly trained and updated about how to keep up with security requirements.

Don’t only train new employees in computer security. You should provide secure coding training and other safety tutorials for all software engineers, no matter their rank or experience. Require mandatory participation and ensure compliance. Everyone needs to be on the same page about how important software security is in the design process. This means introducing new training and reviewing basics multiple times a year.

Have team members complete test runs or simulations of phishing attacks that will help them improve intrusion detection. The sooner they can shut down an attack, the less damage will be done. Practicing this exercise regularly will ensure the entire team knows exactly what to do in the event of a cyberattack.

3. Have set policies and procedures in place

Your policies around security need to be clear and available to all team members. Ensure you have thorough protocols in place to make sure nothing slips through the cracks.

What are your current processes for ensuring software security is addressed throughout software development? Who is in charge of maintaining and updating these protocols and security controls? Does everyone on your team know about these protocols, and are team members up to date on what’s expected?

4. Embed software security within your SDLC

Make software security part of your software development life cycle (SDLC). Intentionally including it in your SDLC will make sure building secure software is an aspect of your standard business practices.

Ensuring security is adequately represented in your SDLC will take time, but it’s well worth it. Put in the time upfront for tasks like searching for security vulnerabilities, security remediation, and code review, completing a risk analysis, and conducting software composition analysis. The sooner you can address bug fixes and vulnerabilities, the better.

5. Complete risk analysis and rigorous testing

Test, test, test. The sooner you spot a vulnerability, the sooner you can begin fixing it. The more you test, the more likely you are to find issues, vulnerabilities, or software defects that cybercriminals are going to exploit.

Complete thorough risk analysis and various forms of testing early and often. Use a variety of analysis techniques for application security testing, such as penetration testing (or pen testing), which can identify the many ways your system’s vulnerabilities can be exploited.

6. Implement least privilege access

The principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, is an information security concept and practice that gives modules (such as users, programs, or processes) the bare minimum level of access or permissions required to perform their or its standard job functions.

Least privilege refers to a person or program’s authority to bypass security restraints. It’s a cybersecurity best practice that protects privileged access to high-value data and assets. Such access should only be given out on a need-to-know basis to safeguard against security issues.

An intern or temporary employee won’t have the same access as a manager or business owner. They’ll only be given exactly as much access as is needed for them to complete their job.

Privilege creep can also be detrimental to your security. This happens when access control and other privileges are not revoked by administrators once they are no longer needed, such as at the conclusion of a project or after transitioning into a different role. Ensure you have protocols in place for how leaders within your business keep track of access. How often do you assess your user privileges? Who is responsible for this task? Will you put security teams in place?

A quick recap and additional resources

Let’s go over these critical software security steps one more time:

1. Invest in team training and education.

2. Make security decisions at the design level.

3. Have set policies and procedures in place.

4. Embed software security within your SDLC.

5. Complete risk analysis and rigorous testing.

6. Implement least privilege access.

There’s plenty more where this came from. We are dedicated to helping teams work better with agile tools and practices. We make plugins for Jira that have simple, collaborative, and customer-focused functionality, including;

Easy Agile TeamRhythm‍

We are thrilled to announce that Easy Agile has successfully achieved SOC 2 Type II compliance, a significant milestone in our unwavering commitment to maintaining high standards of security and privacy.

What is SOC 2 Type II Compliance?

System and Organization Controls (SOC) 2 is a widely recognized security standard developed by the AICPA that specifies how organizations should manage customer data. A SOC 2 report is often the primary document that security departments rely on to assess a service provider's ability to maintain adequate security.

Service providers like Easy Agile voluntarily undergo a rigorous audit and assessment to ensure their security controls meet AICPA’s Trust Services Criteria, including:

• Security
• Availability
• Processing integrity
• Confidentiality

SOC 2 compliance comes in two forms: A SOC 2 Type I report describes the design of a service provider’s system controls to meet relevant trust criteria as of a specific point in time, while a SOC 2 Type II report details the operational effectiveness of those systems controls to perform as designed over a specified period. An independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards.

What does this mean for you?

Our achievement of SOC 2 Type II compliance means that when you use Easy Agile's services, you can continue to do so with the confidence that we have robust controls in place to secure your data. We believe that security is a shared responsibility, and this milestone is part of our ongoing effort to provide transparent and secure practices that support your business.

We want to thank you for your trust and support in Easy Agile. Your data security and privacy are our top priorities, and we are committed to delivering services that not only meet but exceed industry standards.

When is ISO 27001 coming?

Now that we've completed our SOC 2 Type II compliance we'll be setting our sights on ISO 27001 compliance in the next 12 to 18 months.

Where can I learn more?

Visit our Trust Report to access security reports and monitoring.

For any questions or more information about our SOC 2 Type II compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.