Data Processing Agreement

Last updated: 1 August 2026 — Version 1.0

Preamble

This Data Processing Agreement (the "DPA") forms part of, and is subject to, the HRMS Hero Terms of Use (the "Agreement") between:

• HEROSAPPS, Blomberger Str., Detmold 32756, Germany ("Processor", "we", "us") — and
• the customer organisation that installs or uses the HRMS Hero app for Atlassian Jira Cloud (the "App") on its Atlassian site (the "Controller", "you").

It governs the Processing of Personal Data carried out in connection with the App.

The architectural fact that shapes this DPA

The App is an Atlassian Forge app. It executes entirely within the Controller's own Atlassian cloud environment and declares no external network egress. In ordinary operation:

• Personal Data is stored only in Atlassian-operated storage (Forge Key-Value Store and Forge SQL) belonging to the Controller's own Atlassian site;
• the Processor operates no servers that receive Controller data, holds no copy of it, and has no technical means of accessing it; and
• the Processor cannot export, read, or reconstruct Controller Personal Data from its own systems, because none is transmitted to it.

Consequently the Processor's role is materially narrower than that of a conventional SaaS processor. This DPA nonetheless applies in full, so that the Controller has the contractual assurances required by Article 28 GDPR and equivalent laws, and so that the limited circumstances in which the Processor may come into contact with Personal Data (principally voluntary support communications, see Annex I section 5) are properly governed.

1. Definitions

Capitalised terms not defined here have the meaning given in the Agreement.

2. Roles of the parties

2.1 The Controller determines the purposes and means of the Processing. The Controller decides what Personal Data is entered into the App, about whom, on what lawful basis, and for how long it is retained.

2.2 The Processor Processes Personal Data only on behalf of the Controller and only as described in Annex I.

2.3 Where a Data Subject is an employee, contractor, or other individual whose records appear in the App, the Controller is that individual's employer or engaging organisation, and is responsible for providing privacy notices and handling rights requests.

2.4 Atlassian acts as a Sub-processor in respect of the infrastructure on which the App runs. The Controller acknowledges that its own separate agreement with Atlassian governs Atlassian's Processing of data within the Controller's Atlassian site, and that such Processing is outside the Processor's control.

2.5 CCPA. To the extent the CCPA/CPRA applies, the Processor acts as a service provider. The Processor does not sell or share Personal Data, does not retain, use, or disclose it for any purpose other than performing the services, and does not combine it with data from other sources.

3. Scope and duration of Processing

3.1 The subject matter, duration, nature and purpose of the Processing, the types of Personal Data, and the categories of Data Subjects are set out in Annex I.

3.2 Processing continues for the term of the Agreement and ceases on its termination or expiry, subject to Section 11.

4. Processor obligations

The Processor shall:

4.1 Documented instructions. Process Personal Data only on the Controller's documented instructions, including as to transfers to a third country, unless required to do otherwise by law to which the Processor is subject. In that case the Processor shall inform the Controller of that legal requirement before Processing, unless the law prohibits such information on important grounds of public interest. The Agreement, this DPA, and the Controller's configuration and use of the App constitute the Controller's complete documented instructions.

4.2 Unlawful instruction. Immediately inform the Controller if, in its opinion, an instruction infringes Data Protection Laws. The Processor may suspend the affected Processing until the instruction is confirmed, amended, or withdrawn.

4.3 Confidentiality. Ensure that persons authorised to Process Personal Data are bound by an appropriate contractual or statutory duty of confidentiality, and are granted access only on a need-to-know basis.

4.4 Security. Implement and maintain the technical and organisational measures set out in Annex II, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of Processing as well as the risk to Data Subjects (Article 32 GDPR).

4.5 Sub-processors. Engage Sub-processors only in accordance with Section 5.

4.6 Assistance with Data Subject rights. Taking into account the nature of the Processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling its obligation to respond to requests to exercise Data Subject rights (Articles 12-23 GDPR). See Section 7 for how this operates in practice given the App's architecture.

4.7 Assistance with compliance. Assist the Controller in ensuring compliance with Articles 32 to 36 GDPR (security, breach notification, data protection impact assessment, and prior consultation), taking into account the nature of the Processing and the information available to the Processor.

4.8 Deletion or return. At the Controller's choice, delete or return all Personal Data on termination, in accordance with Section 11.

4.9 Information and audit. Make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR, and allow for and contribute to audits, in accordance with Section 9.

5. Sub-processors

5.1 The Controller grants the Processor general written authorisation to engage Sub-processors, subject to this Section.

5.2 The Sub-processors engaged as at the effective date are listed in Annex III.

5.3 The Processor shall impose on each Sub-processor, by written contract, data protection obligations no less protective than those in this DPA.

5.4 The Processor shall give the Controller at least thirty (30) days' notice of the intended addition or replacement of a Sub-processor. Notice is given by updating Annex III and notifying the Controller by email to the address on record.

5.5 The Controller may object to a proposed Sub-processor on reasonable data protection grounds within the notice period. If the parties cannot resolve the objection, the Controller may terminate the Agreement, without penalty, in respect of the affected services.

5.6 The Processor remains fully liable to the Controller for the performance of each Sub-processor's obligations.

6. International transfers

6.1 The App does not transfer Personal Data internationally. Personal Data Processed by the App remains in the Atlassian cloud environment of the Controller's own site, in the region determined by the Controller's agreement with Atlassian. The Processor initiates no outbound transmission of any kind (see Annex II section 1).

6.2 Support communications are the exception, and it matters. If the Controller voluntarily discloses Personal Data to the Processor in the course of a support request (see Annex I section 5), that disclosure constitutes a restricted transfer.

6.3 For any such transfer, the parties agree that the Standard Contractual Clauses, Module Two (controller to processor), are hereby incorporated into this DPA by reference and apply, with:

• Clause 9 (sub-processors): Option 2 (general written authorisation), with the notice period in Section 5.4 above;
• Clause 11 (redress): the optional independent dispute resolution body is not included;
• Clause 17 (governing law): the law of the Federal Republic of Germany;
• Clause 18 (forum): the courts of Detmold, Germany;
• Annex I, II and III of the SCCs populated by Annexes I, II and III of this DPA respectively.

6.4 For transfers subject to the UK GDPR, the parties adopt the UK International Data Transfer Addendum (IDTA Addendum, version B1.0) to the SCCs. For transfers subject to the Swiss FADP, references in the SCCs to the GDPR are read as references to the FADP and references to Member State courts as references to Swiss courts.

6.5 The simplest mitigation is procedural, and the Controller controls it: do not include Personal Data in support requests. The Processor asks that support communications describe issues without identifying individuals, and will not request Personal Data in order to provide support.

7. Data Subject rights

7.1 The App provides the Controller with self-service means to access, correct, export, and delete the records it holds, through the App's administrative interface and its export functions. In the ordinary course, the Controller can therefore satisfy Data Subject rights requests without any involvement from the Processor.

7.2 The Processor cannot itself identify a Data Subject or locate their data, because it holds no copy of Controller data and has no access to the Controller's Atlassian site.

7.3 If the Processor receives a request directly from a Data Subject, it shall not respond to the substance of the request. It shall, without undue delay, inform the Data Subject that it is unable to act and direct them to their employer or the relevant Controller, and shall notify the Controller where it can identify which Controller is concerned.

7.4 The Processor shall provide reasonable assistance, at the Controller's cost where the assistance is substantial and not attributable to the Processor's breach, in responding to such requests.

8. Personal Data Breach

8.1 The Processor shall notify the Controller without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data Breach affecting Personal Data Processed under this DPA.

8.2 The notification shall, to the extent known, describe: the nature of the breach and the categories and approximate number of Data Subjects and records concerned; the likely consequences; the measures taken or proposed to address it; and the contact point for further information. Where information cannot be provided at once, it may be provided in phases without undue further delay.

8.3 The Processor shall take reasonable steps to mitigate and remediate the breach, and shall cooperate with the Controller in its own notification obligations to Supervisory Authorities and Data Subjects.

8.4 A vulnerability in the App is not, by itself, a Personal Data Breach, but the Processor shall notify the Controller of any vulnerability it becomes aware of that materially risks the confidentiality, integrity or availability of Controller Personal Data, and shall remediate it in accordance with Annex II section 6.

8.5 A breach of Atlassian's infrastructure is subject to Atlassian's own notification obligations to the Controller under the Controller's agreement with Atlassian. The Processor shall notify the Controller of any such breach of which it becomes aware.

8.6 Report suspected breaches or vulnerabilities to security@herosapps.com.

9. Audit

9.1 The Processor shall make available to the Controller the information necessary to demonstrate compliance with Article 28 GDPR, including this DPA, its published security documentation, and its Marketplace security self-assessment.

9.2 Where that information is insufficient, the Controller may request an audit no more than once per twelve (12) month period, on at least thirty (30) days' written notice, during normal business hours, subject to confidentiality obligations, and conducted so as not to disrupt the Processor's operations. An additional audit may be conducted following a Personal Data Breach affecting the Controller or on the documented instruction of a Supervisory Authority.

9.3 The Controller bears its own costs and the Processor's reasonable costs of an audit, unless the audit reveals a material breach of this DPA by the Processor.

9.4 Audit rights do not extend to Atlassian's infrastructure, which the Processor neither operates nor controls. Atlassian publishes its own certifications and reports, available to the Controller directly.

10. Liability

10.1 Each party's liability under this DPA is subject to the exclusions and limitations of liability in the Agreement.

10.2 Nothing in this DPA limits either party's liability to a Data Subject under Article 82 GDPR, or any liability that cannot lawfully be limited.

11. Deletion and return

11.1 On uninstallation of the App, all data held in the App's Forge storage is deleted by the Atlassian platform in accordance with Atlassian's data retention practices. This occurs within the Controller's own environment; no action by the Processor is required or possible.

11.2 The Controller is responsible for exporting any data it wishes to retain before uninstalling. The App provides export functions for this purpose.

11.3 The Processor holds no copy of Controller Personal Data to delete or return, save for any Personal Data voluntarily included in support communications, which the Processor shall delete within ninety (90) days of resolution of the relevant support request, unless retention is required by law.

12. General

12.1 Order of precedence. If there is a conflict between this DPA and the Agreement, this DPA prevails in respect of the Processing of Personal Data. If there is a conflict between this DPA and the SCCs, the SCCs prevail.

12.2 Severability. If any provision is held invalid or unenforceable, the remainder continues in full force.

12.3 Changes. The Processor may update this DPA where necessary to reflect changes in Data Protection Laws, Sub-processors, or the App's Processing. Material changes will be notified at least thirty (30) days in advance. Continued use of the App after that period constitutes acceptance.

12.4 Governing law. This DPA is governed by the law stated in the Agreement, save that Section 6 and the SCCs are governed as stated in Clause 17 of the SCCs.

12.5 Contact. Data protection enquiries: privacy@herosapps.com. Security: security@herosapps.com.

Annex I — Details of Processing

1. Subject matter

Provision of the HRMS Hero app for Atlassian Jira Cloud: an HR, timesheet, leave, attendance, overtime, and approvals platform operating within the Controller's Atlassian site.

2. Duration

For the term of the Agreement, until the App is uninstalled from the Controller's Atlassian site.

3. Nature and purpose

Storage, organisation, structuring, retrieval, consultation, and use of employment-related records within the Controller's own Atlassian environment, for the purpose of enabling the Controller to administer working time, leave, attendance, overtime, approvals, and organisational reporting.

4. Categories of Data Subjects

• Employees, contractors, and other personnel of the Controller who are users of, or are recorded in, the Controller's Atlassian site.

5. Types of Personal Data

Processed by the App, within the Controller's Atlassian environment:

Received by the Processor: none in ordinary operation, save for any Personal Data the Controller voluntarily includes in a support request, bug report, or other communication it initiates. The Processor does not solicit such data. See Section 6.5.

6. Categories of Personal Data expressly NOT processed

The App is designed not to process the following, and the Controller should not enter them:

• Special category data under Article 9 GDPR (health, biometric, racial or ethnic origin, religious or philosophical beliefs, trade union membership, sex life or sexual orientation, genetic data)
• Criminal conviction and offence data (Article 10 GDPR)
• Government identifiers (national ID, passport, social security, tax identification numbers)
• Salary, compensation, or bank details. Cost reporting uses pay-band rate proxies only, never individual remuneration
• Credentials, passwords, or Atlassian Personal Access Tokens
• Home addresses, personal telephone numbers, dates of birth, or next-of-kin details

7. Frequency

Continuous, for the duration of the Controller's use of the App.

Annex II — Technical and organisational measures

These measures are implemented in the App itself, verified by automated gates in the Processor's build pipeline, and documented in the App's published security documentation.

1. Network isolation — no egress

The App declares empty external network egress in its Forge manifest (external.fetch.backend: []). It is therefore technically incapable of transmitting data to the Processor or to any third party. This is enforced at two levels:

• Platform: the Atlassian Forge runtime blocks any network destination not declared in the manifest;
• Build: a lint rule in the Processor's continuous integration pipeline fails the build if any hard-coded external URL appears in the source. This rule is verified to fire.

2. Data storage and encryption

• All data resides in Forge Key-Value Store and Forge SQL, operated by Atlassian within the Controller's own site environment.
• Storage is app-private and encrypted at rest by the Atlassian platform.
• All transport is over TLS, terminated by Atlassian.
• The Processor operates no database, no file store, and no logging infrastructure that receives Controller data.

3. Access control and authorisation

• Least-privilege scopes. The App requests only: read:jira-work, write:jira-work, read:jira-user, manage:jira-configuration, read:email-address:jira, storage:app.
• Platform-verified identity. The caller's identity is taken from the Forge invocation context and is never accepted from client input.
• Server-side authority. Every operation is authorised on the server. Interface-level hiding is treated as presentation only and never as a security control.
• Role-based access derived from Atlassian group membership, with the most privileged matching role applied.
• Scope narrowing. Reporting tiers are strictly nested (self, team, organisation); a request outside the caller's reach returns an authorised-empty result rather than widening.

4. The export feed

The App exposes one inbound, read-only HTTPS endpoint so the Controller's own payroll or business intelligence systems may pull approved records:

• Authenticated by a bearer token provisioned by the Controller's administrator and held in app-private storage. The Processor never holds or sees this token.
• The token is accepted from the Authorization header only, never from a query parameter, so it cannot leak via access logs, proxy logs, browser history, or Referer headers (CWE-598).
• Token comparison is length-checked and constant-time, mitigating timing disclosure.
• A missing or mismatched token returns 401 with no data, and the response does not reveal whether a token is configured.
• There is no create, update, or delete path.

5. Auditability and integrity

• State-changing administrative actions write an immutable audit record.
• Audit records are free of personal data by design — they record actor account identifiers, action types, and outcome flags, never names, email addresses, or record content.
• Deactivating a person never deletes history; approvals awaiting them are re-routed rather than stranded.
• Idempotency markers ensure repeated workflow events cannot double-apply.

6. Secure development and vulnerability management

Every change is gated in continuous integration by:

• Static application security testing (SAST) over all application source;
• Software composition analysis (SCA) — the build fails on any known vulnerability in production dependencies;
• Secret scanning — the build fails if a credential is committed;
• Licence compliance checking;
• Type checking and linting, including the egress tripwire described in section 1;
• Automated test suites covering authorisation boundaries, activation enforcement, and licence enforcement.

Vulnerability reports: security@herosapps.com. The Processor acknowledges reports within five (5) business days and remediates according to severity.

7. Logging

Application logs record diagnostic codes and error messages only. The App is written so that raw payload values are never written to logs. Logs remain within the Atlassian platform and are not exported to the Processor or to any third party.

8. Organisational measures

• Personnel with any access to systems relevant to the App are bound by confidentiality obligations.
• Access to the Processor's development and publishing accounts is restricted to authorised personnel and protected by multi-factor authentication.

9. Availability and resilience

Availability, backup, and disaster recovery for the underlying infrastructure and stored data are provided by Atlassian as operator of the Forge platform, under the Controller's agreement with Atlassian. The Processor does not operate infrastructure hosting Controller data and therefore does not independently back it up.

Annex III — Sub-processors

No other Sub-processor is engaged. The Processor uses no analytics provider, no error-reporting service, no customer data platform, and no external hosting in connection with the App, because the App transmits no data externally (Annex II section 1).

Related: Privacy Policy and Terms of Use. This document is reviewed on any change to Sub-processors, Processing, or Data Protection Laws; otherwise annually.