Why this matters for security teams
Security teams have a structural conflict in Jira. They want to work with the engineering organization - filing findings in the same Jira instance, tracking remediation alongside feature work, integrating with the engineering team’s existing workflow. But the documents that drive that work (pentest reports, exploit proofs, vulnerability detail, incident artifacts) need stricter access than the surrounding tickets.
Native Jira’s all-or-nothing attachment model forces a choice: either put sensitive artifacts in Jira and accept that anyone who can see the issue can read them, or put them in a separate system and accept the fragmentation cost. Both choices are bad.
Document Vault eliminates the choice. The tickets stay broadly visible; the sensitive attachments stay scoped to the security team. The remediation engineer sees the finding summary, the affected components, the remediation steps - but doesn’t see the exploit chain in the original pentest PDF unless the security team grants access.
The compliance angle
The compliance frameworks that touch security teams - ISO 27001, SOC 2, PCI DSS, FedRAMP, HIPAA Security Rule - all require demonstrable access control on artifacts that contain regulated data. Document Vault’s audit trail produces the demonstration in a form auditors recognize: per-access logging with user, time, and content identifier.
Most security teams find that the same auditors used to push them to move sensitive artifacts out of Jira entirely. Document Vault changes the recommendation - artifacts can stay in Jira, where the rest of the work lives, as long as the access controls and audit trail are documented.
What security teams are dealing with today
- Pentest reports, vulnerability scans, and incident artifacts are sensitive documents that often need to live alongside the engineering tickets that fix them.
- Native Jira attachment permissions are issue-wide - granting an engineer read access to fix a finding also grants them read access to every other attachment on that ticket.
- Sensitive findings tend to migrate out of Jira (to encrypted shares, to email, to Confluence with restricted permissions) and the record fragments.
- On Data Center, attachments live unencrypted on the filesystem - anyone with shell or backup access reads them.
- Compliance frameworks (ISO 27001, SOC 2, PCI DSS) require demonstrated access control on sensitive artifacts. Native Jira can't demonstrate this for attachments.
How Document Vault helps security teams
Security-team-only attachments
Lock sensitive attachments (pentest reports, vulnerability detail, incident IOCs) to the security team while keeping the issue visible to the team that needs to remediate it.
Encryption at rest
Vaulted attachments are encrypted at the filesystem (Data Center) or end-to-end before storage (Cloud). Server admins, backup operators, and Atlassian's storage layer cannot read the content.
Download attestation logging
Every download of a protected attachment is logged with user, timestamp, IP, and user-agent. The log is the evidence of access for SOC 2 / ISO 27001 audits.
Bulk vault by JQL
Apply vault policies to all attachments matching a JQL filter - 'every issue in the security project, every issue with the security-finding label, every issue created via responsible-disclosure intake.'
Disclosure-readiness controls
Time-boxed access grants for responsible-disclosure workflows: external researcher can see specific attachments until the embargo lifts, then access auto-revokes.
Use cases
- Pentest report tracking. Annual pentest produces a detailed report with exploit chains. Findings are filed as Jira issues for remediation; the master report PDF is vaulted to security-team-only on the parent ticket.
- Vulnerability disclosure intake. External researcher submits a finding via JSM responsible-disclosure portal. The proof-of-concept attachment is vaulted at intake; only the triage team and the relevant product team can decrypt it. The reporter retains access until the embargo lifts.
- Incident IOC collection. During an active incident, the response team attaches log fragments, memory dumps, and network captures. These are vaulted to the response team only - SREs working remediation see the ticket but not the artifacts that contain customer data.
- Compliance evidence. ISO 27001 auditor requires evidence of access control on the SOC 2 Type II workpapers. Vaulted attachments + the download audit trail produce the evidence in one export.
Common questions from security teams
Can Document Vault prevent admins from reading vaulted attachments?
On Data Center, encryption keys can be held by an HSM or external key manager, so even a Jira admin with database access cannot read vaulted content. On Cloud, the encryption model is end-to-end - Atlassian's storage holds only ciphertext. The threat model assumes admins can be a target; the controls are designed accordingly.
How does Document Vault interact with Jira Service Management's intake?
When a customer attaches a file via the JSM portal, Document Vault can apply a vault policy automatically based on the request type or JQL. Responsible-disclosure intake is the typical example: every attached file is vaulted at upload, before any internal user sees it.
What happens to vaulted attachments during a Jira upgrade or migration?
On Data Center, vaulted attachments are part of the standard Jira backup and restore - the encrypted files move with the rest of Jira's data. Key custody must be preserved across the move. On Cloud, Atlassian's standard backup/restore processes apply; vault keys are managed via Document Vault's own configuration.
Can vaulted attachments be exported for audit?
Yes - an authorized user can decrypt and export the content, and Document Vault logs the export as an attested access event. The export carries the same audit metadata as a normal download, so the audit chain is preserved.
Is the per-attachment ACL inherited from the issue or set explicitly?
Both, configurable per policy. The common pattern: default policy on a sensitive project sets all new attachments to security-team-only at upload, with no manual action required. Specific files can be granted broader access explicitly when needed for remediation.
Try Document Vault for your team
Document Vault works for security 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: