Jira Document Management: How Teams Actually Store and Control Files

Jira is very good at tracking work. It was never designed to be a document management system, and the difference shows up the moment a team tries to use it as one.

This is a practical look at what Jira’s native file handling actually does, where teams run into the wall, and what the realistic options are.

What Jira gives you natively

Attachments in Jira are simple by design. You upload a file to an issue (or a work item, in Jira Cloud’s newer terminology) and it sits there against that item.

That model has three consequences worth being clear about:

Attachments inherit the item’s permissions. There is no separate access list for a file. If you can see the item, you can see and download every file on it.
There is no version history. Uploading a corrected contract does not create version 2 of the original. It creates a second, separate file, and now the item has two contracts on it and no indication of which one is current.
There is no document library. Files live scattered across individual items. There is no folder, no index, and no way to browse “all documents for this project” without building a filter and hoping people attached things consistently.

For a development team attaching screenshots and log files to bug reports, this is completely fine. The model matches the need.

Where teams hit the wall

The problems start when the files stop being screenshots.

The permission problem is the common one. A recruitment team runs hiring in Jira and wants to attach a candidate’s salary expectations to the hiring item. The hiring manager needs to see it. The six other people in the project who can view the item do not. Jira offers no way to express that. The only native lever is restricting the entire item, which also hides the work tracking from people who legitimately need it.

The same shape appears everywhere:

Legal teams attaching contracts to a matter that a wider team can see
Finance attaching invoices or bank details to a procurement request
Support teams handling customer files that contain personal data
Anyone in a regulated industry where “who could have accessed this file” is a question that gets asked in an audit

The second problem is that people work around it. When Jira cannot hold the file safely, the file goes somewhere else: a Drive folder, a SharePoint site, someone’s desktop. The work item then links to a document that half the team cannot open, and the link breaks the next time someone reorganizes the folder. You have not solved the access problem, you have moved it somewhere with less oversight.

The three realistic options

Option 1: attach everything and accept the exposure

Keep using native attachments and accept that item visibility equals file visibility. Manage the risk with project structure: put sensitive work in projects (or spaces, on Cloud) with a tight permission scheme, and keep the wider team out entirely.

Works when your sensitive work can live in its own project and the people who need the work tracking are the same people who should see the files.

Fails when those two groups are different, which is most of the time.

Option 2: keep documents outside Jira

Store files in a dedicated system and link to them from the item.

Works when you already have a document platform your whole organization uses, and the discipline to keep links current.

Fails on two permission models drifting apart, broken links, and no guarantee that the person reading the item can actually open the file. It also means the audit trail for the work and the audit trail for the document live in different places.

Option 3: an access-controlled attachment area inside Jira

Add a second attachment area to the item that is visible only to a configured group, so the work item stays open to the team while the files stay restricted.

This is what Document Vault does. Access can be granted to specific user groups, project roles, users named in single or multi-user custom fields, users in group custom fields, or to the item’s Reporter, Assignee, or Creator. You can grant full access (view, upload, edit, delete) or read-only. Everyone outside the list sees nothing, not even the file names.

Two things worth knowing before you assume it solves everything:

Permissions apply to the Vault as a whole, not to individual files. You are separating “team can see the work” from “this group can see the documents”. You are not setting a different access list per attachment.
Version history exists on Project Documents, not on item attachments. If versioning is the main thing you need, check that distinction against your use case first.

On Jira Cloud, Document Vault is built on Atlassian Forge, so files stay inside your Atlassian instance rather than being sent to a vendor’s servers. The per-file limit there is 50 MB.

A document management workflow that holds up

If you are designing this properly rather than patching it, the questions worth answering are:

Who needs to see the work, and who needs to see the files? If those are the same group, native attachments plus a tight project permission scheme is genuinely enough. Do not over-build.
Does anything you attach contain personal, financial, or contractual data? If yes, “everyone who can see the item” is a decision you are making, whether or not you meant to make it.
Do you need to prove access control later? Regulated teams get asked who could have opened a file, not just who did. That is a question about the permission model, and it needs answering before the audit, not during it.
Does the file need version history? If a document genuinely changes over time and you need the earlier versions, check where the tool you pick actually provides that.
What happens when someone leaves the group? Access should follow the group membership automatically. If it depends on someone remembering to update a list, it will drift.

For the person who has to approve this

If you are the one who found the problem and someone else signs off on the fix, the argument that tends to land is not about features. It is that today, file access is a side effect of work item visibility rather than a decision anyone made. Adding one person to a project to help with the work also gives them every document attached to it. That is the risk, and it is worth spelling out in those terms.

There is a fuller version of that argument on the Document Vault business case page.

Frequently asked questions

Does Jira have a document management system? Not in the way a dedicated DMS does. Jira stores files as attachments against an issue or work item, and those attachments inherit the permissions of the item they are attached to. There is no separate document library, no per-file access control, and no version history on an attachment beyond uploading a new file with a new name. For many teams that is enough. For teams handling contracts, HR files, or customer data it usually is not.

Can I control who sees an individual attachment in Jira? Not natively. Anyone who can view the issue or work item can see and download every file attached to it. Jira has no per-attachment permission model, so the only native lever is restricting the whole item, which usually restricts more than you intended.

How do teams manage documents in Jira today? Three common patterns: attach files directly to the item and accept that everyone who can see the item can see the files; keep sensitive files in an external system such as SharePoint or Google Drive and link to them; or add an app that provides a separate, access-controlled attachment area inside Jira. Each has real trade-offs, covered above.

What is the file size limit for Jira attachments? On Jira Data Center the default is 10 MB per file and an administrator can change it. On Jira Cloud the limit depends on your plan. Apps built on Atlassian Forge have their own ceiling: Document Vault for Jira Cloud allows 50 MB per file.

Does linking to Google Drive or SharePoint solve the problem? It solves access control and gives you real version history, but it moves the file outside Jira. You then have two permission models to keep in step, links that break when someone moves a folder, and no guarantee the person reading the item can open the document. It works, but it is a trade, not a fix.

Start Document Vault free trial ↗ Document Vault overview →