Security policy

Comment Vault for Jira runs entirely inside your own Atlassian cloud. It has no servers of ours, no external endpoints and no third-party sub-processors.

Reporting a vulnerability

Where	contact@morglaz.com, subject “Security”
Acknowledgement	Within 2 business days
Fix deadlines	We follow Atlassian's Marketplace security bug fix policy for apps
Disclosure	Please give us a reasonable period to fix an issue before publishing it

Tell us what you found, how to reproduce it and what impact you believe it has. We will tell you what we conclude and when it is fixed. We do not run a paid bug bounty, and we will not take legal action against research conducted in good faith against your own test site.

How the app is built

• No data leaves Atlassian. The app is built on Atlassian Forge and declares no external egress permission, so it cannot send your data anywhere. It is eligible for Atlassian's Runs on Atlassian programme.
• One database per installation. Comment history is stored in Forge SQL and Forge KVS, provisioned per site by Atlassian, encrypted at rest and backed up by them. No site can reach another's data.
• Data residency. Because all stored data lives in Forge hosted storage, it follows the location your organisation pins its Jira data to, and moves with it.
• Read-only in Jira. The app requests no write scope: it never creates, edits or deletes anything in Jira.
• No credentials. The app never asks for a password, an API token or a personal access token, and stores no secret of any kind.
• No AI. No machine learning model receives your content. Comparisons between comment versions are computed by the app itself.

Data residency

All of the app's stored data lives in Forge hosted storage, so it is pinned to the location your organisation chose for its Jira data and is migrated with it. Atlassian shows the app as PINNED in your data residency interface. These are the data types we consider in scope and out of scope.

In scope

• Comment content: every recorded version of a comment, stored both as rich text and as plain text
• Display names of people mentioned inside a stored comment, as Jira supplies them in the comment itself
• Atlassian account IDs of comment authors and of whoever created, edited or deleted a comment
• The index of Atlassian account IDs mentioned in stored comment content
• Comment, work item and project identifiers, including work item keys
• Timestamps: when a change happened, when the comment was created, when the app recorded it
• Comment visibility restrictions, including the name of the role or group a comment was limited to
• App configuration: retention period, visibility mode, recording on or off
• Background job state, including the JQL an administrator entered for a baseline sync, and the personal data reporting position

Out of scope

• Forge platform logs. The app writes only counters and error messages to them — never comment content, account IDs or credentials — but platform logs sit outside data residency.

There is nothing else: the app keeps no analytics, no telemetry and no copy of your data anywhere outside Forge hosted storage.

Who can see what

• Comment history is filtered with the viewer's live Jira permissions. Someone who cannot see a comment in Jira cannot see its history.
• An optional admins-only mode restricts history to Jira and project administrators.
• The audit log and every administrative action require the Jira ADMINISTER permission, checked on each request.
• CSV exports neutralise spreadsheet formulas, so an exported comment cannot execute anything when the file is opened.

Your data, your choices

• Retention is configurable, from 30 days to indefinitely, and enforced daily.
• A Jira administrator can erase all stored history at any time, from the app's admin page.
• The app reports the accounts it holds data for to Atlassian weekly, and acts on closures and changes so that data subject requests reach it. See the privacy policy.
• Uninstalling the app deletes its data under Atlassian's Forge data deletion policy.

How we work

• Every change runs an automated suite of unit and integration tests, type checking and manifest validation before it can be deployed.
• Dependencies are limited to official Atlassian packages and React, and are scanned for published advisories on every change.
• Database access uses bound parameters throughout; user input is validated before use.

Questions about any of this are welcome at contact@morglaz.com.