nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Do you have any retention policies in Jira? If so, how do you implement them?

Kraig Hengst

Hi All,

Does anyone here have data retention policies they implement in Jira? If so, how do you implement these? I would love to hear what others are doing.

Comments

Mykenna Cepek

The only data retention I've ever implemented (over a few small/medium sized companies) was for the weekly cloud backups.

Since we stored these elsewhere in the cloud (e.g. Box), having a defined retention plan helped in these ways:

Clarity with leadership about what data will be kept (and when data will be deleted).
Limiting the amount of data storage we would need.
A crude method of monitoring data size (based on the backup file size).

A typical plan:

Keep all weekly backups for the last 3 months.
Keep 2 backups per month (1st and 3rd) for months 4-6.
Keep 1 backup per month for months 7-12.
Keep 1 backup per quarter for months 13-36.
No backups older than 3 years.

I'd be interested in knowing the "Why?" behind your need for a data retention policy. Are there legal constraints to adhere to? Data storage limits? Just wanting to be tidy?

I'm also curious about the depth/granularity of the purging you envision. Project-level only? Issue-level? Certain data elements within issues (e.g. attachments, comments, etc)?

Kraig Hengst

Thanks for the info @Mykenna Cepek

The why is for a few combinations of things. One driver is that we've been operating on a Jira instance for >8 years, so the unneeded "cruft" has built up. (We don't need to save the fact that Jenny requested a new laptop back in 2013)

We've been exploring a retention policy to help clean things up and remove legacy unneeded data. We're looking at an initial sweep of unused projects with a goal of the remaining projects in our instance active, or recently active projects.

From there, implementing blanket retention policy of XX months on issues so that any issue not updated in XX months is deleted.

Mykenna Cepek

Thanks for that info. A few further thoughts:

You might want "XX months" to be > 12 or more, to ensure that you're not impacting any historical reports in Jira that might be useful to the teams.
Confirm retention limits with the business. For example, does Sales or HR need longer retention than Support or Dev teams?
All existing archived projects seem like low hanging fruit.
I'd run through each project with a quick JQL search showing all issues sorted by "UpdatedDate" descending - the top result is the most recent update.
Not sure if "LastViewed" might be helpful also (probably not). If using this, don't click into any issues in an old project. (I wouldn't use this)
Eliminating all ancient projects first will help any remaining issue-level cleanup go faster.
Automation can be used to delete issues matching certain criteria. But even as an Jira automation expert, I would be very reluctant to actually implement this.
Instead, I'd probably use Automation to periodically scan and notify me when old issues pass some threshold (e.g. age, or quantity, or a combination). I'd then manually target those projects using JQL and then bulk-edit and delete. That would allow me to spot-check things. I'd add this to my weekly Jira maintenance, but maybe only actually perform it once a month.

It might be worth deciding whether you really want the hassle of dealing with individual issues. Or instead just wait until an entire project hasn't been touched in N years, and then delete the project. The latter would be much less work, and automation can still help you hunt for them.

Nick Wade -Opus Guard-

I realize this question is three years old but it's worth revisiting (before it hits retention period expiry, LOL) because things have changed quite a bit in three years. Here's a quick list off the top of my head (full disclosure, I'm with a vendor of Data Retention apps for Confluence and Jira Cloud):

ISO 27001:2202 is now fully in effect as of April 2024, and there are penalties for not effecting records management requirements properly, up to and including revocation of the ISO 27001 certificate. We wrote a post on the key updates.
AI is suddenly "everywhere" and ISO 42001 applies in much the same ways as above, but also GDPR and CCPA and other privacy legislation. But the real problem is feeding the beast. Rovo sees everything, so proper content controls including retention policies is now important to indexing costs, and effectiveness of outputs (stale input, hallucinatory output, confused users or customers). You can probably guess we wrote a post on this topic and ISO 42001 too.
To illustrate my points in a back-handed way, here's some starting research I did via ChatGPT on the matter: https://chatgpt.com/share/682b961c-3ad8-800b-af0b-d5f30c35fa64
It all adds up to people realizing that keeping everything forever and effecting retention only in backup copies is not enough anymore.

So we built and released Content Retention Manager for Confluence Cloud and for Jira Cloud last year. We recently added Lite versions that are free and have no write/delete permissions so you can at least start modeling your organization's retention policies without cost or data loss worries and do so immediately. They're all 100% Runs on Atlassian (Forge only) with zero customer data egress and data residency + data realms support as well. Upgrade to our standard apps if/when ready to automate retention policies and have complete audit trails, is simple and seamless. You can find all of them on Atlassian Marketplace.

Our Jira customers so far are mostly centered on JSM and requirements related to GDPR. There's a bit more on all this on our website: https://www.opusguard.com

Best, -nick wade
Cofounder and COO, Opus Guard
Keep what you need, remove what you don't

Welcome!

It looks like you're new here. Sign in or register to get started.