Backlog Hygiene for Jira Privacy Policy

Source Policy Text

# Privacy And Data Handling

Prepared on `2026-03-13` as repo-backed source material for a future customer-visible privacy/data-handling page. This document is not yet a published privacy-policy URL.

Use `npm run marketplace:publication -- --base-url <https://docs.example.com/app> --output-dir <dir> [--support-email <addr> | --support-portal-url <url>] [--security-email <addr>]` to render this source document into a hostable `privacy-policy.html` page plus a publication manifest.

## Summary

Backlog Hygiene for Jira is implemented as a Forge-native Jira Cloud app. For the current release stream, the repo does not introduce external application servers or external data-processing services. App data is processed inside Atlassian-hosted Forge services and Jira Cloud APIs.

## Data Categories Used By The App

The app processes the minimum Jira and app data needed to provide its released capabilities:

- Jira project metadata used to discover and label scanned projects
- Jira issue metadata used for staleness scoring and explorer results
- app configuration data, including global defaults and per-project overrides
- scan lifecycle state and historical score snapshots
- bulk action audit records required for explicit user-initiated resolve/undo flows
- notification recipient account IDs and delivery-attempt state used for Jira-native digests

## Purpose Of Processing

The data above is used only to support the app's shipped functionality:

- identify stale and warning issues
- compute project hygiene scores and trend history
- render dashboard, explorer, onboarding, and configuration views
- execute explicit bulk-resolution actions initiated by authorized users
- send Jira-native notification digests to configured recipients

## Storage Model

- Forge SQL stores relational scan and audit data such as `scan_runs`, `project_scores`, `stale_issues`, and `bulk_actions`.
- Forge KVS stores configuration and operational state such as `config:*`, `scan:*`, and notification-recipient keys.
- The current default retention period for historical scan and audit data is `90` days, with pruning aligned to the lifecycle documented in `DATA_MODEL.md`.
- Individual `stale_issues` rows are retained only for the latest scored scan; historical trend reporting is carried by `project_scores`.

## Data Sharing And Egress

- The current release stream uses Jira REST APIs and Atlassian Forge hosted storage only.
- The repo does not define outbound integrations to external SaaS providers or customer-managed endpoints.
- Notification delivery is performed through Jira's notification APIs rather than an external email service.

## Requested App Permissions

The current `manifest.yml` requests:

- `storage:app`
- `read:jira-work`
- `write:jira-work`
- `read:jira-user`
- `send:notification:jira`

These scopes support storage, scan/read paths, explicit bulk actions, recipient/account lookup, and Jira-native notifications.

## Publication Gap

- A customer-visible privacy-policy URL has not yet been published for the release candidate.
- This source document is intended to accelerate that publication step, not to claim that it is already complete.

## Evidence Basis

- `manifest.yml`
- `ARCHITECTURE.md`
- `DATA_MODEL.md`
- `docs/features/configuration.md`
- `docs/features/scanner.md`
- `docs/features/email-notifications.md`