Security statement

Group & Project Watchers for Jira · Last updated October 22, 2026.

Publisher: NITROSOFT TECHNOLOGY INC. Security reporting information is available on the support page. Company and data-handling details appear in the privacy policy.

Hosting and access

Watcher rules, subscriptions and processing records run on Atlassian Forge and use Jira APIs. Each installation has its own storage. The app has no advertising or external analytics integration. This public website uses separate Microsoft Azure App Service hosting and does not receive application records. Azure and DNS services process visitor request/network metadata to serve and protect the pages. Azure and DNS providers manage these operational records under their hosting settings and retention controls. Support correspondence is also separate from app processing.

Atlassian documents hosted-storage encryption on disk and installation scoping in its storage reference. Nitrosoft® is responsible for application logic, permissions, dependencies and support practices under Forge's shared responsibility model.

Application controls

• Only project administrators can manage rules. The app checks the signed-in person's permissions, selected users and groups, and project filters when saving a rule.
• Personal subscriptions are scoped to the signed-in caller and current project. The app checks that the person can browse the project and that any selected component belongs to it.
• Automatic watcher additions and optional notices use Jira permissions. They keep the project's existing issue-access restrictions.
• An active app license is required to change settings or add watchers. When license information is missing, inactive or unavailable, settings remain saved and watcher processing pauses. Scheduled privacy reporting and cleanup continue independently of the app license.
• Each project can retain up to 100 rules. Disabled and archived rules remain saved and count toward this limit.
• The app checks for existing watchers before adding people and pauses when Jira asks it to wait. Notification records prevent automatic repeat notices when a previous delivery request could not be confirmed.
• Persistent application records contain identifiers, configuration, the matched rule-plan hash, counters, statuses and retry timestamps. Issue summaries, descriptions, comments, email addresses and display labels are not copied into these records. The privacy policy explains retention and account erasure or refresh processing.
• Notification requests use fixed text, explicit recipient account IDs and Jira Browse restrictions. They do not broadcast to all watchers, reporter, assignee, voters or groups through the notification request's recipient selectors.

Permission purposes

The app requests storage access, read access to the Jira work metadata and user/group information required by these features, and Jira write access for adding watchers and requesting optional notifications. App code does not edit issue summaries, descriptions or comments. The app verifies Jira permissions for each protected action. Site administrators can review requested permissions when installing or upgrading the app.

Data retention and logs

Rules and disabled subscriptions remain stored without general automatic expiry. Scheduled privacy reporting sends stored account identifiers to Atlassian and applies account erasure or refresh instructions across rules, subscriptions, notification tracking and current or historical backfill records. Affected notification recipients are cleared while a suppressed marker remains; account-owned backfill runs are removed and other affected runs are stopped and scrubbed.

Hashed account-ID suppression markers are retained without automatic expiry to prevent queued work or later group expansion from recreating removed references. They are pseudonymous, not anonymous. A privacy refresh does not automatically restore preferences. Interrupted checks and cleanup are retried; a Jira request already in progress cannot be recalled. Notification markers have no automatic expiry, and one-day throttle keys are separate. Support records, existing Jira watchers, already queued platform work and platform diagnostics are outside this stored-record cleanup. See the privacy policy for details.

Application-authored notification logs contain fixed status labels. Platform diagnostics can contain invocation/request metadata. The app does not export its logs to an external service. Platform diagnostics may include request or user-linked metadata and follow Atlassian's access and retention controls.

Website support controls

The support form is hosted on Microsoft Azure separately from the Forge app. It checks the information you enter, protects against submissions from other websites and limits repeated requests. Each form can create one ticket; opening a new form starts a new request.

Your report is stored in the Nitrosoft® Jira support queue. Credentials and submitted reports stay off public pages, and the form does not visit the Jira URL you provide. The confirmation page gives you a ticket ID for your records. The form does not send email; Jira administrators manage any project notifications separately. Learn about support records and the essential cookie in the privacy policy.

Report a concern

Use the support form and choose General. Prepare the affected app version, operation, impact and reproduction steps using synthetic data where possible. Do not include passwords, API tokens, customer issue content or unnecessary personal records. The same form accepts privacy requests. Do not perform destructive testing on another customer's installation.