Approved Bulk Actions security policy
For Approved Bulk Actions for Jira Service Management, published by Atesen Software. Updated 28 October 2026.
Report a vulnerability or incident
Email support@atesensoftware.com with Security — Approved Bulk Actions in the subject. Include the affected version, expected and observed behaviour, potential impact and a reproduction using fictional requests. Do not send passwords, API tokens or customer request content.
We acknowledge reports, investigate their scope and impact, and communicate the next steps to the reporter. Please allow time for investigation before public disclosure. Test only on accounts and data you are authorised to use; do not perform denial-of-service tests. We do not offer a paid bug bounty or a guaranteed response time.
Application architecture and access
The app runs on Atlassian Forge and uses Atlassian-hosted installation storage. Its manifest configures no external data destination or remote backend. Atesen Software operates no separate server or database that receives the app's Jira request content. Atlassian manages the hosting, transport and storage protections of the Forge platform.
Administrator operations check Jira administration permission. Administrators define the service spaces, request filter, changes, batch limit and groups or project roles for each saved action. Runs check the runner's permissions before starting; application-context writes are limited by these checks and the saved action. Run status and cancellation are restricted to the run owner; administrators can review runs. We do not promise immediate enforcement of permission changes during an already-running batch or exactly-once writes after an interruption.
Changes are previewed before execution. Disabling or changing an action stops subsequent batches; changes already written to Jira are not automatically rolled back.
Data, records and monitoring
Installation storage holds saved action definitions and run records, including the initiating account identifier, selected request identifiers, outcomes and configured changes. Configured comments and Jira error messages can contain content. See the application privacy policy for the data and cleanup behaviour.
The app has no external analytics integration. Atlassian may generate platform logs, errors and operational metrics; developer access to those logs depends on the site's log-sharing settings. Information voluntarily sent to support is separate from installation storage. This policy does not claim continuous security monitoring or that the publisher can never access shared diagnostic information.
Vulnerability management and incident response
Security work includes reviewing reported defects and dependency advisories, assessing affected versions and reproducing issues with synthetic data. Changes receive relevant local tests and release checks before deployment. Local tests and dependency checks are not independent penetration testing or proof of every deployed configuration.
For a suspected incident, we assess the affected versions, installations and data, identify containment options, and prioritise a verified correction. Containment may include advising administrators to disable an affected action or stop using the affected version. We communicate material findings and remediation steps to affected customers through available support channels, and work with Atlassian when the platform or Marketplace response is required. We review the cause and update the relevant safeguards after resolution.
We claim no security certification, independent audit, Cloud Fortified status or guaranteed remediation deadline. Marketplace review and app installation status are separate from this policy.