Security Statement and Self-Assessment – QuotaWatch for Jira
QuotaWatch for Jira is built exclusively on Atlassian Forge, a secure, cloud-native platform that provides strong isolation, encrypted storage, and protected execution environments. We take the security of your data seriously and have designed our app to operate with the minimum required access and strong safeguards.
QuotaWatch respects Jira’s permission model and does not expose any data beyond what the logged-in user is authorized to view. The app stores only minimal operational metadata (rate-limit snapshots, capacity scan results, aggregated activity metadata, and configuration settings). When quota thresholds are breached, the app posts a structured alert comment to a user-designated monitoring issue — this is the only automated write operation performed.
1. General Information
Item | Details |
|---|---|
App Name | QuotaWatch for Jira |
App Type | Jira Cloud App (Atlassian Forge) |
Hosting Model | Atlassian Forge (Atlassian-hosted) |
Deployment | Jira Cloud only |
Target Users | All Jira Users, Jira Administrators |
Data Sensitivity | Low (operational metrics, capacity data, and metadata only) |
2. Authentication & Authorization
Area | Implementation |
|---|---|
User Authentication | Handled by Atlassian (Jira Cloud login) |
Authorization Model | Hybrid: User-as-user for UI actions (e.g. searching issues), App-as-App for background polling, async queue consumers, and event triggers |
Permission Enforcement | Fully enforced by Jira APIs and Forge platform |
Elevated Privileges | Not used |
App Roles | Standard Jira UI access; administrators manage app installation/billing |
3. Permission Scopes Requested
Scope | Purpose | Risk Level |
|---|---|---|
| Required by Forge to retrieve rate-limit headers via standard Jira API calls | Low |
| Identity context for poller executions and activity event processing | Low |
| Required by Forge to post alert comments and update properties on the monitoring issue | Low |
| Required to scan site-wide governance configurations (e.g., workflows, fields) for capacity limits | Low (Read-Only Usage) |
| Required to retrieve project-level metadata (e.g., components, versions) for capacity scanning | Low (Read-Only Usage) |
| Native Forge storage for configuration, capacity checkpoints, and historical snapshots | Low |
| Granular scope for resolving issue searches | Low |
| Granular scope for issue interaction | Low |
| Granular scope for reading alert properties on issues | Low |
| Granular scope for writing alert signals to issue properties | Low |
(Note: Both classic and granular scopes are included to ensure broad compatibility during Atlassian's ongoing scope migration period).
4. Jira APIs Used
API Category | Usage | Permission Context |
|---|---|---|
Identity API | Standard heartbeat check ( | App (asApp) |
Search API | Autocomplete for monitoring issue picker within the UI | User (asUser) |
Project & Config APIs | Scanning projects, components, workflows, and fields for capacity thresholds | App (asApp) / User (asUser) |
Properties API | Signaling alerts via issue property updates | App (asApp) |
Forge Storage | Persistent history, governance thresholds, and activity/capacity scan metadata | App (asApp) |
5. Data Stored by the App
Data Type | Stored? | Details |
|---|---|---|
Issue Content (Body) | No | Never stored, parsed, or transmitted |
PII (User Data) | No | No Personal Identifiable Information is processed or stored |
Rate-Limit Metric | Yes | "Minified" snapshot of headers (Quota, Remaining, etc.) |
Capacity Metrics | Yes | Aggregated snapshots of project counts, field limits, and scheme sizes |
Activity Metadata | Yes | Anonymized activity events (e.g., issue creation) for workspace activity tracking |
Configuration Data | Yes | Threshold settings and selected Monitoring Issue Key |
Snapshot Timestamp | Yes | Stored for 24-hour timeline visualization |
Alert Signals | Yes | Written as comments on the monitoring issue and as transient Jira Issue Properties. |
6. Data Retention & Deletion
Aspect | Behavior |
|---|---|
Default Retention | 24-hour rolling history (maximum 288 snapshots based on 5-minute polling) |
Data Deletion on Uninstall | Automatic via Forge (app storage is completely cleared by Atlassian) |
Manual Deletion | Admins can clear all historical data manually via the app settings UI |
Backups | Managed and secured natively by Atlassian Forge infrastructure |
7. Operational Security
Area | Approach |
|---|---|
Logging | Forge platform logs only (contains HTTP status codes and quota percentages; no issue payloads) |
Monitoring | Available via Atlassian Partner console |
Rate Limiting | Native awareness and adherence to Jira's dynamic API limits and backoff periods |
Tenant Isolation | Enforced natively by the Forge platform architecture |
Zero Egress | The app has zero external network permissions and cannot send data outside Atlassian |
8. Compliance Considerations
Regulation / Standard | Status |
|---|---|
GDPR / CCPA | Compliant (does not process PII as a data controller or external processor) |
RoA Status | Eligible (verified by Atlassian CLI during deployment) |
SOC2 / ISO 27001 | Inherited natively via Atlassian Forge infrastructure |
9. Known Limitations & Mitigations
Risk | Mitigation |
|---|---|
API Latency | Dashboard loads asynchronously (doesn't block Jira UI rendering) |
Scan Timeouts | Capacity scans utilize resumable checkpoints to operate strictly within Forge limits |
Storage Limits | Snapshot "Minification" ensures 24h history stays strictly under Forge's 32KB entity limit |
Data Residency | Data stays 100% within the customer's Jira region via Forge Storage natively |
10. Explicit Non-Goals
We do not read or analyze issue summaries, descriptions, or comments at any time.
We do not perform automated issue transitions or field edits. The only automated write is posting structured alert comments to a single, user-designated monitoring issue when quota thresholds are breached.
We do not extract, aggregate, or sell any Jira metadata to third parties.
Contact: connect@logiclemurlabs.atlassian.net