Skip to content

Data Processing Agreement — Formation for Jira

MassMod LLC Addendum to MassMod Terms of Service

Effective Date: July 30, 2026 Last Updated: July 30, 2026

1. Introduction and Scope

1.1 Parties

This Data Processing Agreement ("DPA") forms part of, and is incorporated by reference into, the MassMod Terms of Service between MassMod LLC ("Processor" or "MassMod") and the customer ("Controller" or "Customer") identified in the relevant Atlassian Marketplace license.

1.2 Purpose

This DPA governs the processing of Personal Data by MassMod on behalf of the Customer in connection with the Customer's use of the MassMod Formation application and related services (the "Services"). It is designed to satisfy the requirements of:

(a) the EU General Data Protection Regulation (Regulation (EU) 2016/679) ("GDPR"); (b) the UK General Data Protection Regulation, as incorporated into UK law by the Data Protection Act 2018 ("UK GDPR"); (c) other applicable data protection laws, where relevant.

1.3 Precedence

In the event of a conflict between this DPA and the Terms of Service on a topic governed by GDPR or other applicable data protection law, this DPA controls.

1.4 Definitions

Terms not defined in this DPA have the meanings given in the GDPR. Key terms:

  • "Personal Data" — any information relating to an identified or identifiable natural person (a "Data Subject"), as defined in GDPR Article 4(1).
  • "Processing" — any operation performed on Personal Data, as defined in GDPR Article 4(2).
  • "Controller" — the entity that determines the purposes and means of Processing (Customer, in this DPA).
  • "Processor" — the entity that processes Personal Data on behalf of the Controller (MassMod, in this DPA).
  • "Sub-processor" — a third party engaged by the Processor to process Personal Data.
  • "Data Subject" — the natural person to whom Personal Data relates.

2. Roles and Responsibilities

2.1 Customer as Controller

The Customer is the Controller of all Personal Data that flows through the Services. The Customer determines:

(a) the categories of Data Subjects (users who create or edit work items in the Customer's Jira and Jira Service Management projects where a rule applies, and individuals referenced within the Customer's field-governance rules); (b) the categories of Personal Data (the Atlassian account identifiers, display names, group names, and role memberships of users referenced in rules — alert recipients, rule audiences, and user-field values — together with the field values, comments, and configuration the Application reads or writes at the Customer's direction); (c) the purposes of Processing (governing the fields and forms of the Customer's Jira and Jira Service Management projects — setting, defaulting, requiring, hiding, restricting, validating, relabeling, and locking fields, and alerting on governed changes); (d) the retention periods and any further Processing activities.

2.2 MassMod as Processor

MassMod acts as a Processor strictly on documented instructions from the Customer. The Customer's instructions are constituted by the configuration and operational choices the Customer makes within the Services, plus the explicit instructions in this DPA and the Terms of Service.

2.3 Architectural Limitation

MassMod expressly acknowledges that the Services are designed such that Personal Data resides exclusively within the Customer's Atlassian Cloud environment on Atlassian's Forge platform infrastructure — namely, the Customer's Jira and Jira Service Management data and the Application's own configuration data in Forge hosted storage. MassMod does not maintain a copy of, mirror, or otherwise replicate Customer Personal Data on its own systems. As a result:

(a) MassMod's "processing" of Personal Data primarily takes the form of providing software functionality that operates on Personal Data within Atlassian's infrastructure; (b) Personal Data is not transmitted to or stored on MassMod-controlled servers; (c) The Application's only network egress is to Atlassian's own product APIs (Jira and Jira Service Management, via the Atlassian Forge runtime); the Application makes no calls to non-Atlassian systems.

This architectural limitation does not reduce MassMod's responsibilities under GDPR or this DPA, but it does shape how those responsibilities are operationally fulfilled (see Sections 6, 7, and 9 below).

3. Details of Processing

3.1 Subject Matter

Software-as-a-service providing field and form governance for teams working in Atlassian Cloud Jira and Jira Service Management — an administrator-configured rules engine that sets, defaults, requires, hides, shows, restricts, relabels, validates, and locks fields on issue and request forms, and enforces required field values on issues written through Atlassian's APIs.

3.2 Duration

The duration of Processing aligns with the Customer's active subscription to the Services, plus any post-termination period required for legal compliance or completion of contractual obligations.

3.3 Nature and Purpose

  • Nature: Storage, retrieval, organization, structuring, modification, consultation, use, disclosure (only as directed by the Customer), restriction, erasure, and destruction of Personal Data.
  • Purpose: Enabling the Customer's administrators to define and enforce field- and form-governance rules across the Customer's Jira and Jira Service Management projects — defaulting and requiring values, making fields read-only, hiding or showing fields, restricting field options, relabeling fields and help text, validating and normalizing values, and applying rules conditionally or to specific audiences (users, groups, or project roles) — and to alert configured recipients when a governed value is changed, all at the Customer's direction and within the Customer's Atlassian products.

3.4 Categories of Data Subjects

  • Users who create or edit work items in the Customer's Jira projects, or who create or edit requests in the Customer's Jira Service Management portals, where a Formation rule applies to the form or field they are using — typically the Customer's employees and contractors, and, for Jira Service Management portals, the Customer's help-seekers or customers.
  • Individuals referenced within the Customer's Formation rules — for example, users configured as alert (@mention) recipients, users named in a rule's audience (include or exclude), and any specific user set as a field's required value.
  • Assignees, reporters, and other users referenced by the Jira and Jira Service Management fields the Application reads or writes at the Customer's direction.
  • Customer administrators who configure the Application.

3.5 Categories of Personal Data

  • Rule configuration authored by administrators: the field, project, issue-type, portal, and request-type selections, required/default values, labels and help text, alert-comment text, and enforcement settings that make up each rule. This configuration is authored by the Customer's administrators and stored in the Forge Key-Value Store. Most of it is not Personal Data, but where a rule references specific people it includes their Atlassian account IDs (a pseudonymous identifier, itself Personal Data) and, as entered by the administrator, display names.
  • Alert recipients: the Atlassian account IDs of users an administrator has configured to be @mentioned when a governed field is changed. Alerts are delivered as native Jira comments; Jira then sends the resulting notifications under the Customer's own notification scheme.
  • Rule audiences: where a rule is targeted to, or excluded from, specific users, groups, or project roles, the Application stores the Atlassian account IDs, group names, and role identifiers that define that audience.
  • User-field values: where a rule sets or requires the value of a user field (for example, defaulting an assignee), the Application stores the Atlassian account ID of the specified user, or a "current user" token that is resolved to the acting user's account ID at the time of use and is not persisted.
  • Viewer identity read at runtime: to evaluate audience-targeted rules, the Application's in-form component reads the acting user's Atlassian account ID, group memberships, and (where project-role audiences are used) project-role memberships from Atlassian's APIs at the time a form is rendered. This data is used transiently within the Atlassian-hosted runtime to decide whether a rule applies, and is not persisted by the Application.
  • Directory data surfaced for configuration: when an administrator builds a rule, the Application reads lists of users, groups, and project roles from Atlassian's APIs to populate pickers — including display names and account IDs. This data is read from Atlassian at the time of use and shown in the admin interface; it is not persisted except where the administrator selects a specific user, group, or role for a rule (as above).
  • Application diagnostic logs: operational logs emitted to the Atlassian Forge platform's logging, which may include Atlassian account IDs and field or rule identifiers (for example, enforcement and skip events). These logs reside within Atlassian's infrastructure; MassMod does not export, copy, or retain them on its own systems.
  • Data read from and written to Atlassian products at the Customer's direction: the values of governed fields on issues and requests (which may include user fields such as assignee and reporter), and comments the Application posts to Jira to alert on or record a governed change. Once written, this data resides in the Customer's Jira / Jira Service Management and is governed by those products.

3.6 Special Categories

The Services are not intended for the Processing of Special Categories of Personal Data (Article 9 GDPR — including health, religious, or biometric data). The Customer agrees not to use the Services for such data without separate written agreement with MassMod. Because the Application lets administrators author free-text values, labels, help text, and alert-comment text, and can set, require, or validate values on arbitrary Jira and Jira Service Management fields, the Customer should not configure rules that place Special Categories of Personal Data into those fields or messages. Governed field values are the Customer's own Jira / Jira Service Management data and remain subject to the Customer's own controls.

4. Processing Instructions

4.1 Documented Instructions

MassMod will process Personal Data only on the documented instructions of the Customer, which are constituted by:

(a) the Terms of Service and this DPA; (b) the Customer's configuration and operational choices within the Services; (c) any additional written instructions the Customer provides.

4.2 Unlawful Instructions

If MassMod considers an instruction to infringe GDPR or other applicable data protection law, MassMod will inform the Customer without undue delay.

4.3 Processing Beyond Instructions

MassMod will not process Personal Data for any purpose other than as instructed by the Customer or as required by law. If MassMod is required by law to process Personal Data beyond the Customer's instructions, MassMod will inform the Customer before such Processing unless legally prohibited from doing so.

5. Sub-processors

5.1 Authorized Sub-processors

The Customer hereby provides general authorization for MassMod to engage Sub-processors as required to provide the Services. The current list of Sub-processors is:

Sub-processor Purpose Location
Atlassian (Atlassian Pty Ltd) Forge platform hosting (Application execution + data storage) and the Jira and Jira Service Management products the Application operates on Global (per Atlassian's hosting model and the Customer's data-residency settings)

MassMod does not currently engage any other Sub-processor that processes Customer Personal Data on MassMod's behalf. As of the Effective Date, MassMod does not operate its own server infrastructure that processes Customer Personal Data.

5.2 Notice of New Sub-processors

MassMod will provide the Customer with at least 30 days' advance notice of the addition or replacement of any Sub-processor that processes Personal Data, by:

(a) updating this DPA's Sub-processor list, and (b) notifying customers by email or in-product notification.

The Customer may object to a new Sub-processor for reasonable data protection grounds by emailing privacy@massmod.app within the notice period. If the objection cannot be resolved, the Customer may terminate the Services per the Terms of Service.

5.3 Sub-processor Obligations

MassMod will impose data protection obligations on Sub-processors substantially equivalent to those in this DPA, by written contract, and will remain liable to the Customer for the acts and omissions of Sub-processors.

6. Security of Processing

6.1 Technical and Organizational Measures

MassMod implements appropriate technical and organizational measures ("TOMs") to ensure a level of security appropriate to the risk, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of Processing. These measures include:

Infrastructure security: - The Application runs on Atlassian's Forge platform, which holds SOC 2 Type II, ISO 27001, and ISO 27018 certifications. - The Customer's Personal Data resides exclusively within Atlassian's infrastructure — the Application's configuration data in Forge hosted storage, and the Customer's own Jira and Jira Service Management data. - The Application's only network egress is to Atlassian's own product APIs; it makes no calls to non-Atlassian systems.

Authentication and API access: - The Application accesses Jira and Jira Service Management exclusively through Forge's managed authentication (OAuth 2.0), scoped to the permissions the Customer consents to at installation. - The Application does not use, store, request, or transmit customer API keys, tokens, or passwords; authentication credentials are managed entirely by the Atlassian Forge platform.

Access controls: - Configuration of the Application — creating and editing rules — is available only through a Jira administration page, access to which is governed by Atlassian's own administrator permissions. Privileged operations (reading and writing configuration and reconciling form rules) run server-side through Forge resolvers under the Forge platform's managed authentication; rule enforcement is applied within Atlassian's infrastructure by an invisible Forge UI component at form-render time and by a Forge trigger on issue create/update. Access is not enforced by interface visibility alone. - MassMod personnel do not have operational access to Customer Personal Data.

Operational practices: - Source code is maintained under version control with peer review (when applicable). - Releases follow documented change management practices. - Security incidents are tracked and triaged through internal procedures.

6.2 Updates to TOMs

MassMod may update its TOMs from time to time. Updates will not materially decrease the level of protection of Personal Data.

7. Data Subject Rights

7.1 Customer Responsibility

Because Personal Data resides in the Customer's Atlassian environment and the Customer is the Controller, the Customer is primarily responsible for responding to Data Subject requests (access, rectification, erasure, restriction, portability, objection, etc.). The Customer has direct access to the relevant data through:

(a) Atlassian's own admin console (for account-level data); (b) the Application's admin interface, which allows the Customer to view, edit, and delete its Formation rules and configuration — including any account IDs, groups, or roles referenced in them; (c) deleting the relevant rules, or uninstalling the Application, which removes the Application's configuration data from Forge hosted storage in accordance with Atlassian's retention (see Section 12).

7.2 MassMod Assistance

Where the Customer cannot fulfill a Data Subject request using its own access to the data, MassMod will, taking into account the nature of the Processing and the information available, assist the Customer by appropriate technical and organizational measures, insofar as possible. The Customer may request assistance by emailing support@massmod.app.

7.3 Direct Requests to MassMod

If MassMod receives a Data Subject request directly, MassMod will:

(a) promptly inform the Customer of the request without undue delay; (b) not respond to the request on its own, unless required by law or specifically authorized by the Customer; (c) advise the Data Subject to contact the Customer (the Controller) directly.

8. Data Protection Impact Assessments and Prior Consultation

To the extent required by GDPR Articles 35 and 36, MassMod will provide the Customer with reasonable assistance, taking into account the nature of the Processing and the information available to MassMod, with:

(a) Data Protection Impact Assessments (DPIAs); (b) prior consultations with supervisory authorities.

Such assistance may take the form of providing documentation, answering questions, or facilitating audits as described in Section 11.

9. Personal Data Breach Notification

9.1 Definition

A "Personal Data Breach" is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed.

9.2 MassMod's Notification Obligation

Because Customer Personal Data resides in Atlassian's infrastructure and not on MassMod's own systems, the primary breach notification responsibility lies with Atlassian. However:

(a) If MassMod becomes aware of a Personal Data Breach affecting Customer Personal Data — whether through Atlassian's notification, a Customer report, or independent investigation — MassMod will notify the Customer without undue delay, and where feasible, within 48 hours of becoming aware.

(b) MassMod's breach notification will include (to the extent then available): - the nature of the breach, including categories and approximate number of Data Subjects and Personal Data records affected; - the likely consequences of the breach; - measures taken or proposed to address the breach; - the name and contact details of MassMod's privacy contact.

(c) MassMod will cooperate with the Customer in investigating the breach, mitigating effects, and (where applicable) notifying supervisory authorities and affected Data Subjects.

9.3 Limits of MassMod's Visibility

The Customer acknowledges that MassMod's visibility into Personal Data Breaches is limited by the fact that MassMod does not operate the infrastructure on which Customer Personal Data resides. MassMod relies on Atlassian's own breach detection and notification processes for the underlying Forge platform.

10. Cross-Border Data Transfers

10.1 Transfers Outside the EEA

Personal Data Processed under this DPA may be transferred to and stored in locations outside the European Economic Area ("EEA"), the United Kingdom, and Switzerland. These transfers occur primarily through:

(a) Atlassian's global Forge platform infrastructure (governed by Atlassian's own data residency and transfer mechanisms); (b) MassMod's principal place of business in the United States (to the extent MassMod personnel access Personal Data in order to provide support).

10.2 Transfer Mechanisms

For transfers of Personal Data from the EEA, UK, or Switzerland to MassMod in the United States, the parties agree to rely on:

(a) the EU Standard Contractual Clauses (Module 2: Controller-to-Processor) approved by Commission Implementing Decision (EU) 2021/914, which are incorporated by reference into this DPA; (b) the UK International Data Transfer Addendum to the EU SCCs, as published by the UK Information Commissioner's Office, for transfers subject to UK GDPR; (c) the Swiss Federal Data Protection Act equivalent provisions, for transfers from Switzerland.

The parties agree that: - the "data exporter" is the Customer; - the "data importer" is MassMod; - Module 2 (Controller to Processor) applies; - the optional docking clause does not apply; - the governing law for the SCCs is Ireland; - the supervisory authority is Irish Data Protection Commission (DPC).

11. Audits

11.1 Audit Rights

The Customer (or an independent auditor mandated by the Customer) has the right to audit MassMod's compliance with this DPA, subject to reasonable conditions:

(a) Frequency: No more than once per calendar year, unless required by a regulator or following a confirmed Personal Data Breach. (b) Notice: At least 30 days' advance written notice. (c) Scope: Limited to facilities, systems, records, and personnel directly relevant to the Processing of the Customer's Personal Data. (d) Cost: Each party bears its own costs, except that MassMod's reasonable costs of facilitating audits beyond the first annual audit may be charged to the Customer. (e) Confidentiality: Subject to the confidentiality provisions of the Terms of Service.

11.2 Audit Alternatives

The Customer's audit rights may be satisfied by MassMod providing copies of:

(a) the most recent SOC 2 / ISO 27001 reports of underlying infrastructure providers (e.g., Atlassian); (b) MassMod's most recent security questionnaire responses; (c) other relevant security documentation MassMod maintains.

12. Return and Deletion of Personal Data

12.1 At Termination

Upon termination of the Services, the Customer's Personal Data:

(a) Remains in the Customer's Atlassian environment — as the data resides in Atlassian's Forge hosted storage and in the Customer's Jira / Jira Service Management rather than on MassMod's systems, no transfer or extraction by MassMod is required; (b) Will be deleted by Atlassian in accordance with Atlassian's own data retention policies for uninstalled Forge apps; (c) Customer is responsible for retaining any Personal Data it wishes to keep — using the Application's admin interface or the underlying Jira / Jira Service Management records — prior to uninstallation.

12.2 MassMod's Records

MassMod's own records of the Customer relationship (license records, support communications) are retained per the retention schedule in MassMod's Privacy Policy and are not subject to deletion-on-termination under this Section, except to the extent the Customer is a Data Subject in those records.

13. Liability and Indemnification

The liability of each party under this DPA is subject to and limited by the limitation of liability provisions in the Terms of Service.

14. Term and Termination

This DPA takes effect on the Effective Date and remains in force for as long as MassMod Processes Personal Data on behalf of the Customer. Termination of the Terms of Service automatically terminates this DPA, except for provisions that by their nature survive termination (e.g., breach notification obligations relating to breaches that occurred before termination, post-termination data handling).

15. Miscellaneous

15.1 Order of Precedence

In the event of a conflict between this DPA, the Terms of Service, and the EU SCCs (where applicable), the order of precedence is:

(a) the EU SCCs (for matters they govern); (b) this DPA (for matters of GDPR/data protection generally); (c) the Terms of Service (for all other matters).

15.2 Modifications

This DPA may be modified only by written amendment signed by both parties, or by MassMod's updates to this DPA's published version with reasonable notice (consistent with Section 14 of the Terms of Service).

15.3 Governing Law

This DPA is governed by the same laws and venue as the Terms of Service, except where the EU SCCs require otherwise for transfers subject to GDPR.

16. Contact

For privacy and data protection matters relating to this DPA:

  • MassMod Privacy Contact: privacy@massmod.app
  • MassMod Postal Address: MassMod LLC, 2108 N St, Ste N, Sacramento, CA 95816

Note: MassMod has not appointed a GDPR Article 27 EU representative, relying on the Article 27(2) exemption. See the Privacy Policy and the internal Record of Processing Activities for the basis.

Version History

Version Effective Date Summary of Changes
1.0 July 30, 2026 Initial publication of the MassMod Formation Data Processing Agreement.