Why this matters for legal teams
Legal work in Jira is becoming common because Jira is where the surrounding business work already lives. Contract negotiations track alongside the sales opportunity; litigation hold tickets track alongside the underlying engineering issues; M&A diligence tracks alongside the integration plan. Each of these benefits from staying in Jira - but each also involves documents that shouldn’t be visible to everyone who can see the surrounding ticket.
Native Jira doesn’t support this. Attachment visibility is an inherited property of the issue, period. The historical workarounds (separate projects, separate systems, email handoffs) fragment the record and create their own legal risk.
Document Vault keeps the documents in Jira where they belong while restricting them to the people who should see them. The audit trail, the encryption-at-rest, and the bulk policy tools are what convert it from a useful feature into a defensible one.
How legal teams typically adopt it
A common adoption pattern:
- Pilot on a single workflow - contract review or NDA tracking is usually first. Restrict the templates and drafts to legal-team-only; let the metadata stay visible.
- Expand to litigation hold - once the pattern is proven, apply it to hold-tagged issues. The per-project bulk policy makes this a settings change rather than a per-file effort.
- Standard for sensitive types - over time, issue types that handle regulated content (security findings, customer PII, financial records) default to vaulted attachments.
- Backup and disaster recovery - confirm with IT that vaulted attachments are included in backups and that the key custody plan supports restoration.
What legal teams are dealing with today
- Native Jira attachments inherit issue permissions - if 50 people can see the ticket, 50 people can download every file on it, including the contract draft.
- Sensitive documents end up in Confluence, SharePoint, or email instead of Jira, fragmenting the record.
- Litigation-sensitive attachments need stricter access than the surrounding issue, but Jira can't express that.
- On Data Center, attachments live unencrypted on the file system - anyone with shell access reads them.
- Audit trails for who downloaded what are limited in native Jira; legal needs that record for sensitive documents.
How Document Vault helps legal teams
Per-attachment permissions
Restrict a single attachment to specific users, roles, or groups - independent of the issue's permission scheme. The rest of the ticket stays broadly visible; only the locked file is gated.
Encryption at rest
Vault-protected attachments are encrypted on disk on Data Center, and end-to-end encrypted on Cloud. Server admins with shell access cannot read them; Atlassian's storage layer cannot read them.
Download audit trail
Every access to a protected attachment is logged with user, timestamp, and IP. Useful for compliance evidence and for detecting unauthorized access attempts.
Visibility-aware preview
Users without access don't see the attachment listed - so its presence isn't disclosed, just its content. Useful when the existence of a document is itself sensitive.
Bulk policy application
Apply attachment policies via JQL or project rule - 'all attachments on this project default to Legal-team-only' - instead of per-file.
Use cases
- Contract negotiation tickets. Legal works contracts in Jira tickets shared with sales and engineering. The contract drafts are restricted to the legal team; the discussion comments and metadata stay visible to everyone working the deal.
- Litigation hold attachments. Documents collected for litigation hold live on Jira tickets but are locked to outside counsel and the in-house legal team only. The hold notice and other ticket metadata can be visible to the records-management group.
- M&A due diligence. Due-diligence materials shared in Jira tickets are locked to deal team only. The ticket itself can be visible to a broader transaction team for coordination.
- Privileged communications. Attorney-client privileged documents need extra protection. Document Vault keeps them in the Jira workflow without exposing them to the engineering and operations users who see the surrounding tickets.
Common questions from legal teams
How does Document Vault differ from native Jira attachment permissions?
Native Jira has no per-attachment permission - all attachments on an issue are visible to anyone who can see the issue. Document Vault adds a permission layer one level finer: per-attachment access lists, evaluated at download time. Users who lack access don't see the file in the attachment list at all.
Where are vaulted attachments stored?
On Data Center, vaulted attachments are encrypted at rest in a dedicated vault directory, with keys managed by the Jira instance (or an HSM, depending on deployment). On Cloud, attachments are end-to-end encrypted before they leave the browser; the decryption keys are held by authorized users, not Atlassian's storage layer.
Can vaulted attachments be backed up?
Yes - the encrypted files are part of the normal Jira backup on Data Center, and Atlassian's standard backup processes on Cloud. Restoring vaulted attachments requires the same keys as live access, so backup security inherits the same protections.
Does Document Vault work with Jira Service Management?
Yes. The legal-team use case in JSM is particularly common - external customers can attach documents that need to be visible only to the legal team handling the request, not to the broader support organization.
What's the user experience for someone without access?
They don't see the attachment listed on the ticket. There's no broken icon, no 'attachment hidden' placeholder by default (configurable). For external auditors who need to know an attachment exists but not its content, a 'redacted' display mode can be enabled.
Try Document Vault for your team
Document Vault works for legal teams on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main Document Vault page for the full feature list.
Try Document Vault on the Atlassian Marketplace ↗ See the full Document Vault overview →
Also built for
Document Vault solves a different problem for each team: