/
Privacy Policy for Dependency Manager for Jira

Privacy Policy for Dependency Manager for Jira

1. Purpose

This statement describes how Dependency Manager for Jira Cloud accesses, uses, stores, and protects data when installed in a Jira Cloud site.

It is based on the current implementation in this repository and is intended to provide transparent, customer-friendly documentation of data handling practices.

2. Data Access Scope

Release Planning accesses Jira data needed to deliver release planning and forecasting features, including:

  • Jira project, board, sprint, and issue metadata

  • Issue fields used for planning and forecasting (for example issue key, status, priority, assignee, estimates, resolution dates, fix versions)

  • Version/release metadata

  • Jira user identifiers and display names where required for collaboration features

The app requests Jira scopes in manifest.yml to enable these capabilities.

3. How Data Is Used

Data is used only to provide app functionality, including:

  • Probabilistic release forecasting (for example p50/p85/p95 forecast dates)

  • Scope planning and prioritization workflows

  • Capacity planning support

  • Staging and applying queued issue/release updates

  • Rendering Jira-linked planning views in the app UI

The app does not use customer data for advertising.

4. Data Storage

4.1 Atlassian Forge-hosted storage

The app stores operational planning data in Forge-hosted SQL tables (for example product/board configuration, issue layout state, pending change queues, and capacity-planning records).

Examples of stored operational fields include issue identifiers, version identifiers, user account identifiers for queued-change authorship, and configuration values needed to restore planning state.

4.2 Browser local storage

The Custom UI frontend stores a limited set of user interface preferences in browser localStorage (for example selected page, UI tweaks, selected product/version, and filter preferences) to restore the user experience after reload.

5. Authentication and Authorization Model

  • Backend Jira API requests are made through Forge and primarily use user-context calls (asUser) for Jira data operations.

  • Frontend-to-backend calls are made through Forge bridge invoke resolvers.

  • Frontend Jira calls use requestJira, which executes within Atlassian’s authenticated context.

6. Data Sharing and Egress

Based on the current manifest and codebase:

  • No third-party outbound data egress destinations are configured in manifest.yml.

  • Data access is limited to Jira/Atlassian platform APIs required by app features.

7. Security Controls (Implementation-Level)

The implementation applies security-minded practices such as:

  • Input validation and type checks in resolver/backend paths

  • Scoped API permissions declared in manifest.yml

  • Parameter encoding/safe URL construction for Jira API calls

  • Separation of frontend and backend responsibilities through explicit API layers

Infrastructure-level controls (such as platform-managed isolation and encryption controls) are provided by Atlassian Forge and Jira Cloud.

8. Data Retention and Deletion

Operational app data persists in Forge storage while the app is installed and in use, and browser UI preferences persist in the user’s browser storage unless cleared.

Data can be reduced or removed through normal product operations (for example deleting planning entities/queued changes) and by app uninstallation/site-level cleanup processes.

9. Customer Responsibilities

Customers should:

  • Review granted app scopes during installation

  • Apply least-privilege access in Jira project permissions

  • Ensure internal policies cover use of planning data (including assignee/member names in capacity workflows)

10. Updates to this Statement

This statement should be reviewed and updated whenever there are material changes to app data access, storage, security controls, or scope requirements.