Last updated: 29 July 2026
This Privacy Policy explains how HEROSAPPS ("we", "us", "our"), the publisher of the HRMS Hero app for Atlassian Jira Cloud (the "App"), handles information when the App is installed and used on an Atlassian site.
This policy covers the App only. It does not cover Atlassian's own products or services, which are governed by the Atlassian Privacy Policy, nor any other software you use.
1. Summary
HRMS Hero is an Atlassian Forge app. This has a specific and unusual consequence for privacy, and it is the most important thing in this document:
The App runs entirely on Atlassian's infrastructure and transmits no data to us or to any third party. The App declares no external network egress. All data it processes stays inside the Atlassian cloud environment of the customer's own site.
We do not operate servers that receive your data. We do not have a database of your data. We do not sell, rent, share, or monetise data of any kind.
2. Who is responsible for the data (controller and processor)
| Role | Party | Meaning |
|---|---|---|
| Data controller | The Atlassian site owner (the customer organisation) | Decides what personal data is entered into the App, why, and on what lawful basis |
| Data processor | HEROSAPPS | Publishes software that processes that data on the controller's instructions, within Atlassian's infrastructure |
| Sub-processor | Atlassian Pty Ltd | Hosts and operates the infrastructure the App runs on |
If you are an employee whose data appears in HRMS Hero, your employer is the controller. Requests to access, correct, export, or delete your data must be directed to your employer, not to us — we have no ability to identify you or reach your organisation's data. See section 9.
3. What the App processes
The App is an HR, timesheet, leave, and approvals platform. Within the customer's Atlassian environment it processes:
3.1 Identity and organisation data
- Atlassian account IDs, display names, and avatar URLs
- Jira group membership (used solely to resolve the app role: employee, manager, HR, finance, admin)
- Organisational structure configured by the customer: teams, portfolios, squads, reporting lines, roles, and capacity allocations
3.2 Work and HR records
- Timesheet worklogs, hours, categories, periods, and submission/approval status
- Leave requests, leave types, dates, durations, balances, and accruals
- Overtime records and computed overtime days
- Punch in/out (clock) session times
- Approval decisions, approval chains, and decision history
- Non-regulated free-text business content such as a log description, an approval comment, or a re-open note
3.3 Configuration and operational data
- Reference data configured by administrators: leave policies, overtime policies, work calendars, approval chains, expected hours, pay cycles
- Cost bands used for reporting (see 4.3)
- An immutable audit trail of state-changing administrative actions
3.4 Email addresses — transient use only
The App requests the read:email-address:jira scope for one purpose: the administrator-only bulk user import, which matches existing Jira users by email in order to resolve their Atlassian account ID.
The email address is used at import time and then discarded. It is not written to the roster, to a user profile, to the audit trail, or to any other store. If your Atlassian site hides email addresses, the import fails with an explanatory message and makes no partial changes.
4. What the App deliberately does not process
These are design constraints of the product, not merely policy statements:
4.1 No regulated personal data
The App does not store salary figures, bank or payment details, medical or health information, government identifiers (national insurance, social security, tax ID), or identity-document data. It provides no field for them. Automated privacy tests run against the App's outputs and exports scan for both banned field names and banned value patterns (email-shaped, IBAN-shaped, card-shaped, national identifier-shaped) and fail the build if any appear.
4.2 No credentials
The App implements no authentication of its own — no login screen, no password handling, no credential store. The acting user's identity is taken solely from the Atlassian platform's invocation context. Sign-in, multi-factor authentication, conditional access, and de-provisioning are inherited from your organisation's existing Atlassian identity configuration.
4.3 No compensation data
Cost and liability figures shown in reports use a per-cost-band day-rate proxy configured by an administrator. They are never an individual's salary or compensation. Visibility of any cost figure is additionally gated to administrator, finance, HR, and designated executive roles.
4.4 No tracking
The App contains no analytics, telemetry, advertising, behavioural tracking, fingerprinting, or third-party scripts. It sets no cookies of its own. All fonts, icons, and images are bundled with the App and served from within it — no content is loaded from an external CDN or any other outside host.
5. Where data is stored
All App data resides in app-private, encrypted Forge Storage and Forge SQL, operated by Atlassian and scoped to the customer's own installation. It is not readable by other Jira users, by other apps, or by other Atlassian customers.
Data residency follows Atlassian's data residency arrangements for the customer's site. We do not select, control, or override where Atlassian stores it.
6. Data transfers
The App makes no outbound network requests to any non-Atlassian destination. Its manifest declares an empty external-fetch permission (external.fetch.backend: []), which is enforced by the Atlassian Forge platform rather than merely promised by us. A code-level lint rule additionally blocks external URLs from being introduced into the App's interface code.
There is therefore no transfer of personal data to us, to any sub-processor other than Atlassian, or to any third country by the App.
6.1 The export feed — an inbound pull the customer controls
The App provides an optional payroll/BI export endpoint. It is inbound only: an authorised system belonging to the customer calls it and receives data. The App never pushes data anywhere.
The endpoint requires an app-issued bearer token stored in encrypted app storage. Requests without a valid token are rejected before any data is read. The customer is responsible for safeguarding this token and for whatever system they connect to it. Anyone holding the token can retrieve data through it. Rotate it if it may have been exposed.
7. Our access to your data
We want to be precise here rather than reassuring.
We have no routine access to customer data. We cannot browse, query, or export it, and we hold no copy of it.
As the App's publisher we can, through the Atlassian developer console, view application logs for installations of the App. The App is written to log only error codes, generic error messages, and operational counters; its logging layer deliberately excludes personal data, and the audit writer actively rejects records containing regulated field names or free-text reasons. We do not inspect logs as a matter of course — only when diagnosing a fault, and in practice only when a customer has reported one.
If a customer grants us access to their site or shares screenshots, exports, or configuration in the course of a support request, we will see whatever that material contains. We use it solely to resolve that request and retain it no longer than necessary.
8. Retention and deletion
App data lives inside the customer's Atlassian installation for as long as the App remains installed. Deletion follows Atlassian's platform behaviour for uninstalled Forge apps: when the App is uninstalled, its data becomes inaccessible and is subsequently deleted by Atlassian in accordance with their retention practices.
Within the App, records are designed to preserve history rather than erase it:
- The audit trail is append-only and immutable — there is no update or delete path.
- Deactivating a user re-routes their pending approvals and deletes nothing; their historical records remain available for reporting on past periods.
If your organisation needs specific records removed, this is a controller decision and must be carried out by your administrator.
9. Your rights
If you are an individual whose data is in HRMS Hero, applicable law (including the GDPR and UK GDPR where they apply) may give you rights to access, rectify, erase, restrict, port, or object to the processing of your data.
Exercise those rights with your employer, who is the controller and the only party able to identify you and act on your data. We cannot action such a request directly, because we have no access to the data and no way to determine which installation, if any, relates to you.
If a customer instructs us to assist with such a request, we will provide reasonable cooperation as their processor.
10. Security
Measures in place include:
- Server-side authorisation on every operation. Interface-level hiding is never treated as a security control. Permission, role, and scope checks are re-verified on the server regardless of what the interface displayed.
- Narrow-only data scoping. Every reporting and data-read path compiles the caller's permitted scope through a single audited function. User-supplied filters can only narrow that scope, never widen it; an out-of-scope request returns an empty result rather than an error revealing that other data exists.
- Parameterised queries throughout, with report definitions resolved against a fixed server-side allowlist so that user input never reaches query construction.
- Injection-safe exports. Spreadsheet exports are structurally incapable of carrying formulas; CSV exports neutralise formula-leading characters.
- Immutable audit trail for state-changing administrative actions.
- Blocking security gates in our development pipeline: static analysis, dependency vulnerability scanning (build fails on High or Critical), secret scanning, and licence compliance, with dependencies pinned to exact versions.
No system is perfectly secure. We do not represent that the App cannot be compromised.
10.1 Reporting a vulnerability
Report suspected security issues to privacy@herosapps.com. Please give us a reasonable opportunity to remediate before public disclosure.
11. Children
The App is business software licensed to organisations. It is not directed to children and we do not knowingly process children's data.
12. Changes to this policy
We may update this policy as the App evolves. Material changes will be reflected in the effective date above and published with the App's Atlassian Marketplace listing. Continued use of the App after a change takes effect constitutes acceptance of the updated policy.
13. Contact
This document describes the App as published on the Atlassian Marketplace. Where this policy and the Atlassian Marketplace Partner terms differ in respect of Atlassian's own obligations, the Atlassian terms govern Atlassian's conduct.