Convince My Boss
Set the default comment security level per project or globally, so internal comments stay internal.
In native Jira, the safe option depends on someone remembering to pick it every single time. One person forgetting once is all it takes for an internal note to land in front of a customer. Policy and training do not fix this, because the failure is a missed dropdown, not a lack of knowledge.
Below are two emails you can copy, adjust and send.
Informal Email
Subject: A way to stop internal Jira comments reaching customers
Hi [Recipient’s Name],
Hope you’re well.
We have a risk in Jira that I do not think we have properly covered. Comments default to visible, so keeping an internal note internal relies on the person remembering to set the security level every time. That is fine until someone is in a hurry, and then an internal comment goes to a customer.
There is an app called Comment Security Default from Redmoon Software that changes the default:
- Safe by default. You set the default security level per project or globally, so the protective option is the one that applies automatically.
- Removes the human step. Nobody has to remember anything. The failure mode we are exposed to today is a missed dropdown, and this removes the dropdown from the critical path.
- Works per project. Customer-facing service desk projects can be locked down while internal projects stay open.
Details here: Comment Security Default.
This is the kind of thing that costs very little now and looks obvious in hindsight after an incident.
Best,
[Your Name]
Formal Email
Subject: Recommendation to adopt Comment Security Default to reduce accidental disclosure risk in Jira
I hope this message finds you well.
I am writing to recommend Comment Security Default from Redmoon Software as a control against accidental disclosure of internal information through Jira comments.
The current position is that comment visibility defaults to unrestricted, and applying a security level is a manual action taken per comment. Our exposure therefore depends on individual users making the correct selection every time, in projects that may be visible to customers, contractors or external collaborators. This is a control that relies entirely on human consistency, which is the weakest form of control available to us.
Comment Security Default addresses this:
- Default-deny rather than default-open. The protective security level is applied automatically at project or global scope, so the safe outcome is the default outcome.
- Removes reliance on training and policy. Existing mitigation is awareness-based. This converts it into a configuration-based control, which is materially more defensible in a security review.
- Scoped per project. Customer-facing Jira Service Management projects can be configured differently from internal engineering projects.
- Reduces incident and breach exposure. A single misdirected comment containing personal data or commercial detail is a reportable event in some circumstances; this reduces the likelihood of that occurring.
Further detail: Comment Security Default.
For a security review, the app is available for Jira Cloud and Jira Data Center. Our Cloud Security Statement and Data Processing Agreement cover the Cloud edition; on Data Center all data remains inside our own Jira instance.
I would recommend we trial this on our customer-facing projects first.
Best regards,
[Your Name]