Security & data handling
Last updated: 1 November 2026
| Question | Answer |
|---|---|
| Hosting | Atlassian Forge only. Eligible for Runs on Atlassian (confirmed with forge eligibility). |
| External network calls (egress) | None. The app manifest declares no external permissions. |
| Data stored by the app | None. No Forge storage, database, files or caches. |
| Data stored outside Atlassian | None. |
| Scopes | read:jira-work (issue history, fields, the user's edit permission) and write:jira-work (restore only). |
| Who the app acts as | The signed-in user. Jira applies that user's own permissions: restore is hidden for users who cannot edit the issue, and Jira rejects the write if they try. |
| Audit trail | Every restore is a normal Jira edit and appears in the issue History under the user's name. |
| Concurrent edits | A restore is refused if the field changed after the user opened the history. |
| Personal data | Only what Jira already shows in the issue history (author display names), processed in memory and not kept. |
| Data residency | Processing happens where Atlassian runs Forge for your site. The app stores no data, so there is nothing to pin or migrate. |
| Analytics and tracking | None. |
| Sub-processors | None besides Atlassian, which hosts Jira and Forge. |
| Vulnerability reports | Email redline@kenanislamoglu.com with the subject "Security". We acknowledge within 2 business days. |