Security policy

Security policy for our Atlassian apps

How we build and run our apps for Jira and Confluence Cloud: where your data is kept, how it is protected, how we find and fix vulnerabilities, and what we do if something goes wrong. Each app's privacy policy lists exactly what it reads and stores.

Last reviewed: 3 November 2026. We review this policy every 12 months, and sooner when an app or the platform changes.

Scope

Apps this policy covers

All twelve apps run on Atlassian Forge. Each asks only for the permissions it needs, and eight of them cannot change anything on your site.

License Audit for JiraRead-only. Stores scan progress and, for each inactive user, an Atlassian account ID and how long they have been inactive. Privacy policy
License Audit for ConfluenceRead-only. Stores scan progress and, for each inactive user, an account ID and how long they have been inactive. Privacy policy
Seat Reclaim for JiraRead permissions plus one write permission (write:group:jira). It is used only when a site admin confirms a reclaim or an undo, to take a user out of a product access group or put them back. Stores account IDs with their inactivity band and groups at scan time, the history of reclaims and undos, the protected list and the seat price an admin enters. Privacy policy
Seat Reclaim for ConfluenceRead permissions plus one write permission (write:confluence-groups), used in the same way and only after a site admin confirms. Stores the same kinds of data as Seat Reclaim for Jira. Privacy policy
Access Review for JiraRead-only. Stores each review: account IDs, their groups and products, last activity, the decision and note an admin records, and who signed the review off. Privacy policy
Group & Permission Usage for JiraRead-only. Stores each report: groups, projects, permission scheme grants, project role members, and who filters, dashboards, security levels and notification schemes are shared with, with people as account IDs only. Privacy policy
Portal Details for Jira Service ManagementRead-only. Stores each service project's panel settings (the chosen fields, SLA targets, labels and link types) and the account ID of whoever saved them last. The request data shown in the panel is read when the panel opens and is not stored. Privacy policy
Customers & Organizations Export for JSMRead-only. Stores the three newest scans of each service project: request counts and dates per customer and organization, with people as account IDs, organization IDs and names, the project's ID, key and name, and who started the scan. Names and emails are looked up when you export and are not stored. Privacy policy
Merge Requests for Jira Service ManagementRead permissions plus write permissions to add comments, files, request participants, organizations, watchers and links to the main request and to close the duplicate. They are used only when an agent confirms a merge. Stores the site and project settings and a log of the newest 200 merges: request keys, what was copied or left out and why, and the agent's account ID. Privacy policy
Budget & Cost Tracking for JiraRead-only in Jira. Stores budgets, expense lines, hourly rates per person or group, hours per person per month and per work log, and who changed what, with people as account IDs only. Privacy policy
Permissions & Access Review for ConfluenceRead permissions plus one write permission (write:content.restriction:confluence). It is used only when a Confluence admin confirms a change to page restrictions, or its undo. Stores snapshots of space permissions and restricted pages (space names and keys, page IDs, account and group IDs), the last 12 reviews with decisions and notes, and a log of the last 50 changes. Privacy policy
Secret & Personal Data Scanner for ConfluenceRead-only. Stores each finding with the page ID, the type, a masked value, the line around it with every match masked, a keyed hash and the last editor's account ID. It never stores the full value. Privacy policy

Data handling

Where your data is kept and how it is protected

  • No servers of our own. The apps run on Atlassian Forge, inside Atlassian's cloud. We have no copy of your data and no way to reach it from outside Atlassian.
  • Stored in your data region. Everything an app keeps is in Forge hosted storage, in the same data residency region as your Atlassian site.
  • Encrypted at rest and in transit. Atlassian encrypts Forge storage at rest. All traffic between your browser, your site and the app uses HTTPS (TLS), handled by Atlassian.
  • No outbound connections. None of the apps declares an external host, so Forge blocks any request to a server outside Atlassian. No data is sent to us or to any third party.
  • No keys or tokens to leak. The apps sign in through Forge's built-in authentication. They create no API tokens and hold no secrets.
  • Minimum data. We store account IDs, not people's names or email addresses. Names and emails are read from Atlassian when a page shows them and are never written to storage. The apps never store issue or page content, comment text or attachments. The one exception is the Secret & Personal Data Scanner: it keeps the line around each finding and the page title, with every value it finds masked, so the other words there can still include a name.
  • Logs without personal data. The apps log IDs, counts and errors only, never personal data, credentials or tokens. Only the app's developers can see its logs.
  • AI stays inside Atlassian. Some apps include a Rovo agent. Rovo is Atlassian's own AI, and these agents can only read the app's results. We send no data to any other AI service.
  • Removed on uninstall. When you uninstall an app, Atlassian deletes its stored data under Forge's data deletion rules. We confirm deletion in writing on request.

Access control

Who can use the apps, and who can change them

  • Administrators set them up. Each app's main page opens from the product's administration area, which only administrators can reach. Some apps also have a page in project settings for project admins, an action for agents on a request (Merge Requests), a panel for customers on the portal (Portal Details) or a project page (Budget & Cost Tracking, where a Jira admin chooses who sees the money). An app that changes something does so only after a person confirms it on screen: a site admin in the two Seat Reclaim apps and a Confluence admin in Permissions & Access Review, both with undo, and an agent in Merge Requests, where every merge is logged.
  • Multi-factor authentication is required on every account used to build, deploy or manage the apps: Atlassian, source control, email and our website host.
  • Least privilege. People get only the access their role needs. We review access every quarter and remove it the same day it is no longer needed.
  • Protected devices. Laptops used for development have full-disk encryption, automatic security updates and a screen lock.

Secure development

How we build and release

  • Source code is kept in private repositories, never only on a laptop.
  • Every release is tested on a development install first. Before it goes to production, the unit tests must pass, forge lint must be clean, and npm audit must show no known vulnerabilities in production dependencies.
  • We keep dependencies to a minimum: Atlassian's official Forge packages and our build tools.
  • We follow the OWASP Top 10. Every request is validated, input is accepted only from fixed lists where possible, and values placed into Jira or Confluence queries are always quoted.
  • Each permission is justified in the app's manifest and on its Marketplace listing. We do not add a permission an app doesn't use.

Vulnerability management

Finding and fixing security problems

Email [email protected] with "security" in the subject. Tell us which app, what you found and how to reproduce it.

  • We confirm receipt within one business day.
  • We send our assessment and a fix date within five business days.
  • We fix confirmed problems within Atlassian's deadlines for cloud apps:
CriticalWithin 10 days
HighWithin 4 weeks
MediumWithin 12 weeks
LowWithin 25 weeks

We also act on reports from Atlassian's security team and its automated scanning. We won't take legal action over good-faith research that doesn't harm customers or access their data. Please don't publish a problem until we've released a fix.

Incident response

If something goes wrong

We keep a written incident response plan. If an incident could affect customer data, we:

  • contain it first, for example by disabling the affected feature or removing access;
  • tell Atlassian within 24 hours;
  • tell affected customers within 72 hours: what happened, what data was involved, what we've done and what you should do;
  • fix the cause, and write up what we changed so it doesn't happen again.

Our source code is kept in private repositories, so any app can be rebuilt and redeployed quickly from a known good version.

Certifications

Compliance

We don't hold SOC 2 or ISO 27001 certification ourselves. The apps run on Atlassian's Forge platform, and Atlassian publishes its own security and compliance programme at atlassian.com/trust. Once a year we check ourselves against Atlassian's security requirements for cloud apps, the Marketplace Partner Agreement and the GDPR, and fix any gaps.

Vendor
TELCOMA Technologies Private Limited (TELCOMA Global)
In business since
2009
Registered office
Ludhiana, Punjab, India
Security contact
[email protected]
Data processing agreement
Available on request

Send us your security questionnaire and we'll complete it.