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.
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 policywrite: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 policywrite: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 policyData 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 lintmust be clean, andnpm auditmust 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:
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.