Trust, security, and data-handling details for our Jira Cloud approval app
This document describes the hosting, security, permissions, and data-handling characteristics of Business Sign-off & Approval for Jira Cloud (the “App”). It is intended for Jira administrators, procurement teams, and security reviewers.
It covers this product, including relevant product-support practices. It does not govern visits to the Cahaba Forge corporate website or general marketing activities. For privacy commitments, processing roles, and customer rights, see the Cloud Privacy Policy.
App code executes within Atlassian’s managed Forge environment. Cahaba Forge does not host the App’s execution or approval-data storage on its own servers.
Atlassian provides infrastructure security, encryption at rest and in transit, and installation-level storage isolation. Jira Cloud permissions govern access to native Jira data. The App uses this platform isolation for customer installations rather than a shared Cahaba Forge-operated data store.
For platform background, see Atlassian Forge security and Atlassian Trust.
Forge-hosted storage follows Atlassian’s data residency model for the host product. This does not guarantee that every platform service, operational log, or usage measurement is processed in the same region as the customer’s Jira site. International transfers are subject to Atlassian’s applicable residency and transfer policies.
Atlassian manages platform backup and recovery. Platform backups are not a customer-accessible App restore feature or a promise that all App information is included in a Jira backup. Uninstall and reinstallation limitations are described below.
The App accesses Jira information needed for approvals, configuration, notifications, and audit reporting:
Retained App information includes assignment and decision records; historical identity and issue-context snapshots; approval and administrative audit records; settings; temporary audit-export information and generated CSV content; and account lifecycle information used for personal-data reporting. Logs and feature-use measurements are described separately below.
Email addresses available from Jira may be read at runtime for issue-panel display. The App does not persist user email addresses in its App-managed data stores or audit records. Jira controls the availability of email addresses and delivery of Jira notifications.
Decision comments and other customer-provided text can contain personal or sensitive information. Customers should consider the information they enter and their own retention obligations.
Approval records, settings, and audit information are held within Forge-hosted storage and Jira Cloud. The App also writes native Jira approval fields, aggregate approval information, and selected approval audit records for search, workflow integration, and accountability.
Configured App processing does not send approval data to an external Cahaba Forge backend or an external third-party processing service. Account lifecycle reporting, logs, and feature-use counters use Atlassian’s infrastructure.
Authorized Cahaba Forge App developers can access platform-hosted logs and usage measurements subject to Atlassian’s access controls. This is distinct from having direct access to a customer’s Jira site or browsing its approval records.
Information customers send directly to Cahaba Forge for product support, including screenshots or exports, is handled separately from the App’s Atlassian-hosted processing. The Cloud Privacy Policy describes this product-support and Marketplace information.
Automatic cleanup depends on successful processing and is not an instantaneous or unconditional deletion guarantee. Contact Cahaba Forge if you need help verifying a deletion or responding to a privacy request.
Uninstalling the App does not immediately erase all data. As described in the Cloud Privacy Policy and Atlassian’s Forge-hosted storage documentation, hosted App data is retained for 28 days after uninstall and is not automatically restored on reinstallation.
Any platform-assisted recovery depends on Atlassian’s process, customer consent, and applicable time limits. This document does not promise successful recovery, automatic restoration, or re-ingestion after reinstall. Contact Cahaba Forge promptly if recovery is needed.
Native Jira custom-field values and issue audit records remain after uninstall and require separate customer management. Uninstall should not be treated as immediate, complete erasure for a privacy request.
The App reports stored account identifiers and associated timestamps through Atlassian’s personal-data reporting service. This allows Atlassian to identify closed accounts and profile updates; the reporting payload does not include display names, email addresses, or decision comments.
When Atlassian reports an account as closed, the App attempts to replace relevant stored display-name references with “Deleted user” and clear decision comments authored by that user in the approval and audit records it processes. Underlying records and account identifiers remain for audit continuity. This is pseudonymization, not full deletion or a guarantee of anonymization.
Account-closure processing is not immediate, and failures or incomplete coverage may require support follow-up. Historical audit snapshots are not automatically revised when a profile changes. Customer-downloaded exports and Jira-managed data must also be considered when responding to a privacy request.
Jira administrators can use account-based privacy reports and supported audit CSV exports to assist with privacy requests. The privacy report summarizes counts and issue references; it is not a copy of every underlying record or a guarantee of coverage of every data category.
For rights, processing roles, the DPA, and operational limitations, see the Cloud Privacy Policy.
The App follows a least-privilege approach. Site administrators review and authorize requested scopes during installation or an upgrade that adds permissions.
| Scope | Customer-facing purpose |
|---|---|
storage:app | Retain approval information, settings, and audit history within Atlassian’s infrastructure |
read:jira-work | Read issue and project information needed for approvals |
write:jira-work | Update approval-related Jira data |
read:jira-user | Read user information for approver selection and display |
manage:jira-configuration | Support configured Jira operations, including approval notifications |
write:app-data:jira | Update App-managed Jira data |
report:personal-data | Support Atlassian personal-data reporting |
write:project.property:jira | Manage project-level panel visibility |
delete:project.property:jira | Remove project-level panel visibility settings |
Separation of Duties can restrict approval by the issue’s reporter or assignee. Decision locking and comment requirements provide additional configurable governance controls. These features support a customer’s approval process; they do not replace appropriate Jira permissions or workflow configuration.
See the Cloud Administrator Guide for configuration, workflow enforcement, and operational limitations.
The App records approval and administrative activity for accountability and compliance review. Audit CSV exports offer Include Integrity Verification, enabled by default and adjustable for each export.
Verification reports detected changes to audit records and distinguishes legitimate privacy redactions from unexplained changes. Customers should review unexpected results with Cahaba Forge support.
Integrity checks provide evidence of detected changes, including accidental corruption or casual editing. They do not prevent an authorized Jira user from altering or deleting native Jira data or establish that every authorized action was appropriate. Retaining native Jira audit information after uninstall does not guarantee automatic restoration or recovery of App-managed history.
Customers remain responsible for access controls, workflow configuration, review of audit evidence, and secure retention of downloaded exports. Approval history and integrity verification support compliance activities; using the App does not by itself establish compliance with SOC 2, SOX, GDPR, or another framework. This document makes no certification or attestation claim for BSO or Cahaba Forge.
The App does not request Atlassian credentials, third-party service credentials, or customer-managed secrets for normal operation. Customer-provided comments, issue context, and support correspondence can contain information supplied by customers.
Standard operational logging is active for errors and warnings. Administrators can enable additional diagnostic logging for a configured period of 1–8 hours. Logs can contain account and issue identifiers used for troubleshooting, including account-closure processing information.
Authorized App developers can access platform-hosted logs under Atlassian’s controls. The diagnostic duration stops additional logging; it does not delete existing log entries after that period. Retention is governed by Atlassian’s logging policies.
Customers should use the shortest diagnostic duration that allows them to reproduce a problem and consider what information they submit to support.
The App does not load Google Analytics or other external analytics scripts, add advertising trackers or tracking pixels, or use its own browser cookies for tracking. Atlassian’s Jira and platform practices are governed by Atlassian’s policies.
The App records numeric feature-use counts through Atlassian’s Forge metrics service. The App’s submitted counter payload does not include account IDs, display names, email addresses, issue IDs, decision comments, or audit-record contents.
This is not a guarantee that platform measurements are anonymous or cannot be associated with an installation. Platform metadata, retention, access, site-level filtering, and administrator controls are governed by Atlassian’s service, as described in the Cloud Privacy Policy.
Cahaba Forge uses the following development and verification practices:
Testing and scan results provide supporting evidence; they are not a guarantee that an application has no vulnerabilities. Customers may contact Cahaba Forge with security-review or procurement questions. Additional security information may be available on request.
Report security issues to security@cahabaforge.com.
Responsible disclosure expectations:
Cahaba Forge targets the following remediation timelines for confirmed vulnerabilities in the App’s own application code:
These are remediation targets, as also described in the Support Policy. If a security incident or critical vulnerability affects the App, Cahaba Forge will coordinate notification to Atlassian and affected customers as appropriate. Atlassian-managed infrastructure, Forge platform services, and Jira Cloud are subject to Atlassian’s incident-response processes; Cahaba Forge will assist with reporting and coordination where applicable. Applicable personal-data breach notification obligations are governed by the DPA, as described in the Support Policy.
Atlassian provides infrastructure, hosting, storage, and platform execution for the App. No additional external subprocessors are used for the App’s configured approval-data processing.
Personal-data reporting and feature-use counters operate within Atlassian’s platform. They do not represent App approval data being sent to an external analytics provider.
Product-support correspondence and Marketplace information received directly by Cahaba Forge are separate from the App runtime. Relevant handling and product-support service providers are described in the Cloud Privacy Policy.
Organizations may contact Cahaba Forge with procurement questions or security questionnaires. Additional security information may be available on request; this does not guarantee provision of a particular report, dependency inventory, or architecture document.
Contact security@cahabaforge.com for security-review requests.