Legal
Data Processing Agreement
Version 1.1, effective 2026-10-21. This DPA forms part of the agreement between Ryan Gilford, sole proprietor doing business as Alt Datum and each organization that installs TestWarden from Atlassian Marketplace. It states how customer personal data is processed, secured, transferred, retained and deleted, grounded in the app as actually shipped.
1. Parties and effective date
This Data Processing Agreement ("DPA") is entered into between Ryan Gilford, sole proprietor doing business as Alt Datum ("Alt Datum", "we", "us"), the provider of the TestWarden app for Jira Cloud (the "Service"), and the organization that installs or subscribes to the Service through Atlassian Marketplace ("Customer", "you"). Alt Datum and Customer are each a "party".
Legal identity of Alt Datum. The Provider is Ryan Gilford, sole proprietor doing business as Alt Datum. The public business mailing address is 1522 Buena Vista, Apt B, San Clemente, CA 92672, United States. The same Provider identity is stated in the Terms. Questions about the Provider or this DPA may be sent to [email protected].
Effective date. This DPA (version 1.1) is effective from 2026-10-21 for Customers who first install or subscribe to the Service on or after that date, and otherwise from the date on which Customer accepts, or is given notice of, the Agreement that incorporates it. It remains in effect for as long as Alt Datum processes Customer Personal Data on Customer's behalf.
Who may enter into this DPA. The person installing or subscribing to the Service on behalf of Customer represents that they are authorized to bind Customer to this DPA. Customer may enter into this DPA on behalf of its affiliates that use the Service through Customer's Jira Cloud site; those affiliates are then included in "Customer" for the purposes of this DPA.
2. Relationship with the TestWarden customer Terms
The "Agreement" means the terms under which Customer licenses the Service, namely: (a) the end user agreement presented on the TestWarden Atlassian Marketplace listing at the time Customer first installs or purchases the Service, including any Provider-Specific Terms published with it; and (b) the TestWarden Provider and website terms, to the extent they apply to Customer. This DPA is a data processing addendum to the Agreement and is incorporated into it by reference.
Where the Marketplace end user agreement is the Atlassian Marketplace standard end user agreement (Bonterms Standard End User Agreement, Version 1.0), this DPA is the "Data Protection Addendum (DPA)" identified in the Provider-Specific Terms for the purposes of its Section 3.3, and Annex B of this DPA describes the "Security Measures" referred to in its Section 3.2.
If this DPA conflicts with the Agreement regarding the processing of Customer Personal Data, this DPA prevails to the extent of the conflict. If this DPA conflicts with the Standard Contractual Clauses or another transfer instrument that applies under Section 16 to 18, that instrument prevails for the transfer it governs. Nothing in this DPA limits or excludes the parties’ rights and obligations under Atlassian’s own agreements with Customer, which govern Atlassian’s processing of data in Customer’s Jira Cloud site.
3. Definitions and interpretation
Capitalized terms not defined here have the meaning given in the Agreement. In this DPA:
- "Applicable Data Protection Law" means all laws and regulations applicable to the processing of Customer Personal Data under this DPA, including, where applicable, the EU GDPR, the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection (FADP), the California Consumer Privacy Act as amended by the California Privacy Rights Act (together, "CCPA") and its regulations, and other US state privacy laws.
- "Atlassian" means Atlassian Pty Ltd and its affiliates, the operator of Jira Cloud, Atlassian Forge and Atlassian Marketplace.
- "Customer Data" means all data, content and materials that Customer and its Users submit to, create in, or cause the Service to collect, including data read from Customer’s Jira Cloud site through the scopes the Service declares.
- "Customer Personal Data" means Personal Data contained in Customer Data that Alt Datum processes on behalf of Customer in providing the Service, as further described in Annex A.
- "Data Subject", "Controller", "Processor", "Personal Data", "Personal Data Breach", "processing", "Supervisory Authority" and similar terms have the meanings given in the EU GDPR; for the CCPA, "Personal Data" includes "personal information", "Controller" includes a "business", "Processor" includes a "service provider", and "Data Subject" includes a "consumer".
- "EU GDPR" means Regulation (EU) 2016/679; "UK GDPR" means the EU GDPR as it forms part of the law of England and Wales, Scotland and Northern Ireland by virtue of the European Union (Withdrawal) Act 2018 and amended by the Data Protection Act 2018.
- "Forge" means the Atlassian Forge platform on which the Service runs, including Forge hosted storage (Forge SQL and Forge Object Store), Forge functions, Forge Async Events and Forge platform logging.
- "Installation" means an installation of the Service on a Customer Jira Cloud site, which has its own Forge installation identity and its own Forge hosted storage.
- "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914, as amended or replaced from time to time.
- "Sub-processor" means a third party engaged by Alt Datum to process Customer Personal Data on Customer’s behalf in connection with the Service.
- "UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.
- "User" means an individual who accesses the Service through Customer’s Jira Cloud site, or whose Atlassian account is referenced in Customer Data.
Headings are for convenience only. "Including" means "including without limitation". References to a law include that law as amended or replaced. If a provision of this DPA is held unenforceable, the remaining provisions remain in effect and the unenforceable provision is to be applied to the fullest extent permitted by law.
4. Roles of the parties
Customer as Controller; Alt Datum as Processor. For Customer Personal Data, Customer is the Controller (or, where Customer processes Customer Personal Data on behalf of its own customers, a Processor acting on the instructions of those customers), and Alt Datum is Customer’s Processor (or Sub-processor). Where Customer is itself a Processor, Customer warrants that its instructions to Alt Datum are consistent with the instructions of the relevant Controller and that it is authorized to enter into this DPA on that Controller’s behalf.
Atlassian as Sub-processor. The Service runs entirely on Forge. Atlassian hosts the Service’s compute and storage and processes Customer Personal Data as Alt Datum’s Sub-processor under the Forge data processing terms between Atlassian and Alt Datum. Atlassian separately processes the data in Customer’s Jira Cloud site as Customer’s own Processor under Customer’s agreement with Atlassian; that processing is outside this DPA.
Alt Datum as an independent Controller for limited business data. Alt Datum is an independent Controller, not Customer’s Processor, for: (a) business contact details of Customer’s personnel that Atlassian Marketplace provides to Alt Datum for licensing, billing and partner reporting; (b) correspondence that Customer’s personnel send to Alt Datum support, security or privacy mailboxes or through the testwarden.me contact form; and (c) Alt Datum’s own records of the commercial relationship. That processing is described in the Privacy Policy and is not governed by this DPA, except that Section 8 (confidentiality) and Annex B apply to Customer Data contained in support correspondence.
5. Subject matter, nature, purpose and duration of processing
Subject matter. The provision of the Service to Customer: test management and independent software-change verification inside Customer’s Jira Cloud site, as described in the Documentation.
Nature of processing. Storage, retrieval, organization, display, versioning, snapshotting and evaluation of Customer Data in Forge hosted storage; creation of Jira issues in Customer’s own Jira site when a User explicitly requests it; import of test assets from files Customer uploads; ingestion of verification evidence that Customer’s CI systems submit through the TestWarden App REST API; deterministic evaluation of that evidence into quality decisions; attribution of actions to Atlassian account IDs for ownership, execution and audit history; and weekly reporting of stored Atlassian account IDs to Atlassian under the Forge personal data reporting lifecycle.
Purpose. To provide, secure, support and maintain the Service for Customer under the Agreement and Customer’s documented instructions. Alt Datum does not process Customer Personal Data for advertising, for selling or sharing with third parties, for profiling Data Subjects, or for training shared or cross-customer machine-learning models.
Duration. For the term of the Agreement for each Installation, plus the period for which Forge retains the Installation’s data after uninstallation (Section 20), and any longer period required by law.
Annex A sets out the processing details in the form required by Article 28(3) GDPR and by the SCCs.
6. Categories of Data Subjects and Personal Data
Data Subjects. Customer’s employees, contractors and other Users of Customer’s Jira Cloud site; and any other individuals whose Personal Data Customer or its Users choose to include in Customer Data (for example, names appearing in test steps, comments, imported files or CI reports).
Categories of Personal Data. (a) Atlassian account IDs (opaque identifiers assigned by Atlassian) recorded as owners, creators, assignees, testers, actors and approvers; (b) Personal Data that Customer or its Users author or upload into free-text fields, imported files and CI evidence reports; (c) Jira issue keys and issue summaries that Users link to tests and defects; (d) Personal Data that Users include in Jira issues they create from the Service. The Service does not request the Jira user-profile scope and does not retrieve or store User names, email addresses, avatars or other profile attributes.
Special categories. The Service is not designed for, and Customer agrees not to submit, special categories of Personal Data (Article 9 GDPR), Personal Data relating to criminal convictions, payment card data, government identifiers, health data or children’s data. The Service does not technically prevent a User from typing such data into a free-text field; Customer is responsible for its Users’ use of the Service.
Annex A lists each category of Customer Data, where it is stored and how long it is retained.
7. Customer instructions and processing restrictions
Documented instructions. Alt Datum will process Customer Personal Data only on Customer’s documented instructions, including with regard to transfers of Personal Data to a third country or an international organization, unless required to do so by European Union, Member State, UK, Swiss or other law to which Alt Datum is subject. In that case Alt Datum will inform Customer of that legal requirement before processing, unless the law prohibits doing so on important grounds of public interest. Customer’s complete instructions are: (a) the Agreement and this DPA; (b) Customer’s and its Users’ use of the Service’s features and configuration; and (c) any further written instructions agreed between the parties.
Unlawful instructions. Alt Datum will inform Customer without undue delay if, in its opinion, an instruction infringes Applicable Data Protection Law. Alt Datum is not obliged to carry out a legal analysis of Customer’s instructions and may suspend the affected processing until Customer confirms or withdraws the instruction.
Restrictions. Alt Datum will not: (a) sell or share Customer Personal Data; (b) retain, use or disclose Customer Personal Data for any purpose other than the purposes in Section 5, including any commercial purpose other than providing the Service; (c) retain, use or disclose Customer Personal Data outside the direct business relationship between Customer and Alt Datum; (d) combine Customer Personal Data with Personal Data that Alt Datum receives from or on behalf of another person or collects from its own interaction with a Data Subject, except as permitted by Applicable Data Protection Law for the purposes of providing the Service; or (e) use Customer Personal Data to train, fine-tune or evaluate any machine-learning model that is shared across customers. Product improvement is limited to aggregated or de-identified information that does not identify Customer or any Data Subject and is not Personal Data.
Customer responsibilities. Customer is responsible for: (a) the lawfulness of the Personal Data it and its Users submit to the Service, including having a lawful basis and giving any notices required; (b) its Users’ compliance with the Agreement; (c) the accuracy of the instructions it gives; (d) configuring its Jira Cloud site, Jira permissions and the Service’s roles appropriately; (e) safeguarding the credentials Atlassian issues to its Users and the authorizations it grants to CI systems; and (f) keeping its contact details with Atlassian Marketplace and Alt Datum current so that notices under this DPA reach it.
8. Confidentiality and authorized personnel
Alt Datum will ensure that every person it authorizes to process Customer Personal Data (including its owner, employees and any contractors) is bound by a contractual or statutory obligation of confidentiality, has been informed of the confidential nature of Customer Personal Data, and processes it only as instructed and only to the extent needed to perform their role.
Alt Datum personnel do not have a general administrative interface for reading Customer Data in Forge hosted storage. Operational access is limited to (a) the Service’s own code running on Forge under the scopes Customer approved at installation, (b) Forge platform logs and developer tooling that Atlassian provides for operating the Service, and (c) information that Customer chooses to send to Alt Datum support. Alt Datum will treat Customer Data as Customer’s Confidential Information under the Agreement and will not disclose it to any third party except as permitted by this DPA.
Alt Datum will not request, and Customer should not send, Atlassian passwords, API tokens, session cookies, private keys or exports of unrelated Customer Data in support requests. Where a narrow reproduction is sufficient, Alt Datum will not ask for a full dataset.
9. Technical and organizational security measures
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 of varying likelihood and severity for the rights and freedoms of natural persons, Alt Datum will implement and maintain appropriate technical and organizational measures to ensure a level of security appropriate to the risk, as required by Article 32 GDPR. Those measures are described in Annex B and include the measures of the Forge platform on which the Service exclusively runs.
Alt Datum may update Annex B from time to time, provided that updates do not materially reduce the overall level of protection of Customer Personal Data during the term of the Agreement. Alt Datum will make the current Annex B available at the DPA’s public URL.
Customer acknowledges that the Service runs on infrastructure operated by Atlassian, that Alt Datum does not operate its own servers, data centers or networks for the Service, and that the physical, environmental, network and platform-level controls that protect Customer Data at rest and in transit are those Atlassian implements and documents for Forge and Atlassian Cloud. Alt Datum does not represent that it has independently audited those controls. No security measure is absolute. Alt Datum does not promise that Customer Data can never be accessed without authorization, lost or corrupted; it promises the measures in Annex B and the breach obligations in Section 11.
10. Authentication, authorization and tenant isolation
- Authentication. Users authenticate to Customer’s Jira Cloud site through Atlassian. The Service maintains no user database and never collects or stores Atlassian passwords. CI systems that submit evidence authenticate through Atlassian OAuth 2.0 (3LO) using the Service’s own custom scopes, which a Customer site administrator grants; the Service does not store third-party OAuth credentials or API tokens.
- Authorization. The Service maps each User’s Jira permissions to a role (Viewer, Tester, QA Manager, QA Admin) on the server side on every request. Operations that create or change data are checked against the Customer’s license state and the User’s role before any handler runs; unclassified write operations fail closed to the Admin role. User-interface display conditions are never treated as authorization.
- Tenant isolation. Each Installation has its own Forge SQL database and its own installation-scoped Object Store keys; Atlassian segregates Forge hosted storage so that an app installed on one site cannot read another site’s data. In addition, the Service derives the Installation identity exclusively from the Forge runtime context (never from a value supplied by the browser or an API caller) and binds that identity on every data access path as defense in depth.
- Least privilege. The Service requests only the Jira scopes its features require (
read:jira-work,write:jira-work) and the Forge platform scopereport:personal-dataused to report stored Atlassian account IDs to Atlassian. It does not request the Jira user-profile scope. - Immutability and provenance. Verification evidence, quality decisions, approval records and audit events are append-only. Exact retries are idempotent and conflicting evidence is never overwritten. An automated producer (including an AI coding agent) cannot clear its own change or bypass a required human approval.
11. Personal Data Breach identification, response and notification
Internal detection and assessment. Alt Datum maintains a written security incident response runbook covering severity classification, containment, evidence preservation, tenant-isolation investigation, fix verification, recovery and post-incident review. Suspected incidents are recorded, classified and investigated under that runbook. Atlassian notifies Alt Datum of incidents affecting Forge hosted storage under the Forge data processing terms, and Alt Datum treats such notices as incident reports under its runbook.
Notification to Customer. Alt Datum will notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data, and in any event within 72 hours after Alt Datum has confirmed that a Personal Data Breach affecting Customer Personal Data has occurred. Notice will be sent to the administrator or technical contact details available to Alt Datum through Atlassian Marketplace for Customer’s Installation and to any additional contact Customer has given under Section 25. Customer is responsible for keeping those contacts current.
Content of notice. To the extent known at the time, the notice will describe the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed to address the breach and mitigate its effects, and a contact point. Where the information cannot all be provided at the same time, Alt Datum will provide it in phases without undue further delay and will not withhold an initial notice because the investigation is incomplete.
Regulatory and Data Subject notification. Customer, as Controller, is responsible for determining whether a Personal Data Breach must be notified to a Supervisory Authority or to Data Subjects and for making those notifications. Alt Datum will provide reasonable assistance and the information in its possession to enable Customer to meet those obligations. Alt Datum will notify Atlassian of security incidents affecting the Service as required by the Atlassian Marketplace Partner Agreement and Atlassian’s security requirements. Alt Datum’s notice to Customer is not an admission of fault or liability.
Remediation and post-incident communication. Alt Datum will take reasonable steps to contain the breach, to remediate its root cause, to verify the fix before redeployment under its fail-closed release process, and to update its public security and privacy documentation if the shipped behavior changed. Customer will not publicly identify Alt Datum in connection with a breach without first consulting Alt Datum, except as required by law.
12. Cooperation with Customer’s privacy obligations
Taking into account the nature of the processing and the information available to Alt Datum, Alt Datum will assist Customer, by appropriate technical and organizational measures, in: (a) responding to requests from Data Subjects exercising their rights (Section 13); (b) ensuring compliance with Customer’s obligations on security of processing, Personal Data Breach notification, data protection impact assessments and prior consultation with Supervisory Authorities under Articles 32 to 36 GDPR and equivalent provisions of other Applicable Data Protection Law; and (c) responding to inquiries from a Supervisory Authority concerning the Service.
Assistance consists primarily of making this DPA, the Privacy Policy, the Security page, the Documentation and Atlassian’s published Forge platform documentation available, answering reasonable written questions, and performing actions that the Service’s features or the Forge platform make possible. Alt Datum may charge reasonable fees for assistance that goes materially beyond this, at rates agreed in advance, except where the assistance is required because of Alt Datum’s breach of this DPA.
13. Data Subject access, correction, deletion and portability
Requests received by Alt Datum. If Alt Datum receives a request from a Data Subject relating to Customer Personal Data, it will not respond directly (other than to acknowledge receipt and refer the Data Subject to Customer) and will forward the request to Customer within five business days, unless the law requires otherwise.
Self-service capabilities. Customer’s site administrators and Users can, within the Service and subject to their role: view and edit test cases, steps, comments and execution records; archive and restore tests and cycles; delete test steps, saved repository filters, tags and requirement or project links; cancel a migration job; and export a cycle’s execution results as CSV. Jira issues created from the Service live in Customer’s Jira site and are managed there. Verification receipts, quality decisions, approval records, execution history, raw uploaded migration files and raw evidence reports are retained as an immutable record for the life of the Installation (Section 20).
Requests to Alt Datum. A site administrator may ask Alt Datum, at [email protected], for assistance with access, correction, deletion or export of Customer Personal Data that the self-service capabilities do not cover. Alt Datum will verify that the request comes from an administrator of the affected Installation and will respond within a reasonable time, normally within ten business days. Because Alt Datum has no direct administrative access to Customer’s Forge hosted storage, record-level deletion that the Service does not expose may require a product change or may be achievable only by uninstalling the Service (which triggers the platform deletion lifecycle in Section 20). Alt Datum will tell Customer which of these applies.
Closed Atlassian accounts. Independently of Customer requests, the Service reports every stored Atlassian account ID to Atlassian on a weekly cycle. When Atlassian reports an account as closed, the Service removes that account ID from every place it is stored (test, cycle, execution, evidence, audit, history and decision records are kept with the identifier removed) and deletes that account’s personal saved filters. This erasure is recorded in the audit trail under a one-way digest of the ID.
15. Sub-processor contractual obligations
Alt Datum will impose on each Sub-processor, by written contract, data protection obligations that provide in substance the same level of protection for Customer Personal Data as this DPA, including obligations to implement appropriate technical and organizational measures, and will ensure that Sub-processors are engaged only for the purposes described in Annex C. For Atlassian, those obligations are the Forge data processing terms between Atlassian and Alt Datum, which include EU Standard Contractual Clauses and the UK Addendum for transfers.
Alt Datum remains fully liable to Customer for the performance of each Sub-processor’s obligations under this DPA, to the extent Alt Datum is liable for its own performance under the Agreement. On request, Alt Datum will provide Customer with a summary of the data protection terms applicable to a Sub-processor, redacted for confidential commercial information.
16. Cross-border data transfers
Where Customer Data is stored. The Service stores Customer Data only in Forge hosted storage. Atlassian places Forge hosted storage for an Installation in the data residency location of the Jira Cloud site on which the Service is installed: if Customer has pinned its Jira site to a location that Atlassian supports, the Installation’s Forge SQL database and Object Store objects are located there and move with the site if Customer migrates it; if the site is not pinned, Atlassian selects the location. Section 19 describes this further.
Where Alt Datum is located. Alt Datum operates from the United States. Operational access by Alt Datum (Section 8) and Forge platform logs available to Alt Datum may therefore involve access to Customer Personal Data from the United States, which is a transfer to a third country for Customers subject to the EU GDPR, the UK GDPR or the Swiss FADP, even where the Installation’s storage is located in the EEA, the UK or Switzerland.
Transfer mechanism. Customer authorizes those transfers, and any transfers to Sub-processors in Annex C, provided that Alt Datum complies with Sections 17 and 18 and Annex D. Alt Datum does not rely on the EU-US Data Privacy Framework and does not represent that it is certified under it. Alt Datum will not claim that an EEA, UK or Swiss storage location by itself prevents every transfer.
Onward transfers. Transfers from Alt Datum to Atlassian are governed by the Forge data processing terms between Atlassian and Alt Datum, which incorporate the SCCs (Module 3, processor to processor) and the UK Addendum. Atlassian’s onward transfers to its own infrastructure sub-processors are governed by Atlassian’s agreements with those sub-processors.
17. EU Standard Contractual Clauses
To the extent Customer Personal Data subject to the EU GDPR is transferred to Alt Datum in a country that the European Commission has not found to provide adequate protection, the parties enter into the SCCs, which are incorporated into this DPA by reference and completed as set out in Annex D. In summary: Module Two (controller to processor) applies where Customer is a Controller, and Module Three (processor to processor) applies where Customer is a Processor; Customer is the "data exporter" and Alt Datum is the "data importer"; Clause 7 (docking clause) is included; under Clause 9, Option 2 (general written authorization) applies with the 30-day notice period in Section 14; the optional language in Clause 11(a) is not included; under Clause 17, Option 1 applies with the governing law stated in Annex D; and under Clause 18 the courts stated in Annex D have jurisdiction. Annex I and Annex II of the SCCs are completed by Annex A and Annex B of this DPA respectively, and Annex III of the SCCs by Annex C.
The SCCs are a stand-alone instrument. Nothing in this DPA modifies the text of the SCCs, and if the SCCs conflict with this DPA the SCCs prevail for the transfer they govern. The SCCs are designed for data importers whose processing is not itself subject to the EU GDPR; to the extent Alt Datum’s processing of a particular transfer is directly subject to the EU GDPR, the parties nevertheless adopt the SCCs as contractual safeguards to the fullest extent permitted. If the European Commission adopts a new or amended set of standard contractual clauses that applies to the transfers under this DPA (including clauses for importers directly subject to the GDPR), the parties will replace the SCCs with that set and complete it consistently with Annex D. The SCCs are published by the European Commission at https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en.
18. UK and Swiss transfer provisions
United Kingdom. To the extent Customer Personal Data subject to the UK GDPR is transferred to Alt Datum, the SCCs as completed in Annex D apply as amended by the UK Addendum, which is incorporated by reference. Annex D completes Tables 1 to 4 of the UK Addendum. The mandatory clauses of Part 2 of the UK Addendum apply as published by the UK Information Commissioner and are not modified by this DPA. Either party may end the UK Addendum as set out in its Section 19 where the Information Commissioner issues a revised Addendum.
Switzerland. To the extent Customer Personal Data subject to the Swiss FADP is transferred to Alt Datum, the SCCs as completed in Annex D apply with the following adaptations, which are intended to reflect the guidance of the Swiss Federal Data Protection and Information Commissioner (FDPIC): (a) references to the GDPR are read as references to the FADP; (b) the FDPIC is the competent Supervisory Authority under Clause 13 insofar as the transfer is governed by the FADP; (c) the term "Member State" is read so as not to exclude Data Subjects in Switzerland from the possibility of enforcing their rights in their place of habitual residence under Clause 18(c); and (d) where a transfer is governed solely by the FADP, the governing law under Clause 17 is Swiss law and the forum under Clause 18 is the courts of Switzerland, as set out in Annex D.3. Where both the FADP and the EU GDPR apply, the GDPR selections in Annex D.1 apply to the transfer under the GDPR and the FDPIC supervises the transfer under the FADP in parallel.
19. Data residency and storage locations
All Forge hosted storage capabilities the Service uses (Forge SQL and Forge Object Store) are data-residency enabled by Atlassian. The Service declares no storage outside Forge hosted storage and no external egress, so its in-scope data follows the data residency location of Customer’s Jira Cloud site under Atlassian’s data residency program. Customer, not Alt Datum, controls that location through Atlassian’s administration tools, and Atlassian, not Alt Datum, performs any migration of data between locations.
Alt Datum makes no representation about data residency beyond Atlassian’s current published documentation for Forge, which Customer should consult for the list of supported locations and their status. Forge platform logs are retained by Atlassian under Atlassian’s own platform policies and may be stored outside the Installation’s location; the Service is designed so that those logs contain operational identifiers and error details, not test content or evidence payloads.
20. Retention, return, export and deletion
During the term. Customer Data is retained in Forge hosted storage for as long as the Service is installed on Customer’s site and Customer keeps it. The Service is designed to preserve history: verification receipts, quality decisions and approval records are append-only, executions snapshot the test version they ran against, and tests and cycles are archived rather than hard-deleted. The Service applies no automatic time-based purge to Customer Data except the removal of closed-account identifiers in Section 13. If Customer’s subscription becomes inactive, the Service becomes read-only and Customer Data remains readable and unchanged.
Export and return. At the end of the provision of the Service, and at Customer’s choice, Alt Datum will return or delete Customer Personal Data as follows. During the term, Customer may export cycle execution results as CSV from the Service, retrieve quality decisions through the TestWarden App REST API, and work with the Jira issues it created in its own Jira site. On written request before uninstalling, Alt Datum will provide reasonable assistance with export of Customer Data in a commonly used, machine-readable format within the capabilities of the Service and the Forge platform. Deletion occurs through the uninstall lifecycle below.
Deletion on uninstall. Uninstalling the Service from a Jira site removes the Service’s access to that site and places the Installation’s Forge hosted data (Forge SQL and Object Store) into Atlassian’s uninstall lifecycle: Atlassian soft-deletes the data, retains it for Atlassian’s published retention period for Forge hosted storage (currently 28 days after uninstallation according to Atlassian’s Forge storage documentation) and then destroys it. Reinstalling the Service creates a new Installation and does not reconnect the previous data; within 21 days of uninstallation, and only with Customer’s consent, Alt Datum can ask Atlassian to relink the previous Installation’s data to the new Installation. Alt Datum holds no separate copy of Customer Data to delete after uninstall, other than Customer Data contained in support correspondence (Section 4), which Alt Datum deletes on request. Deletion of a whole Jira site is governed by Atlassian’s site deletion process, which deletes associated app data.
Retention required by law. Alt Datum may retain Customer Personal Data to the extent required by law, and will protect it under this DPA and process it only for that purpose. Alt Datum will confirm deletion in writing on request, within the limits of the information Atlassian makes available to it.
These timings are Atlassian’s platform behavior, which Alt Datum does not control and which Atlassian may change. Alt Datum will update this Section when Atlassian’s published lifecycle changes.
21. Audit and compliance information rights
Information. Alt Datum will make available to Customer all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and this DPA. Alt Datum satisfies this primarily through this DPA and its Annexes, the public Security and Privacy Policy pages, the Documentation, written responses to Customer’s reasonable security and privacy questionnaires (at most once per 12 months unless a Personal Data Breach or a Supervisory Authority requires more), and references to Atlassian’s published platform documentation and compliance reports, which Customer may obtain directly from Atlassian under Atlassian’s terms. Alt Datum maintains a record of the categories of processing it carries out on behalf of Customers, as required by Article 30(2) GDPR, and will make the relevant extract available to Customer or a Supervisory Authority on request.
Audits. Alt Datum will allow for and contribute to audits, including inspections, conducted by Customer or an independent auditor mandated by Customer and reasonably acceptable to Alt Datum, subject to the following: (a) at most once in any 12-month period, unless required by a Supervisory Authority or following a Personal Data Breach affecting Customer Personal Data; (b) on at least 30 days’ written notice describing the scope; (c) during normal business hours, remotely where practicable, and without unreasonable disruption; (d) limited to Alt Datum’s processes, documentation and controls relating to the Service and not extending to Atlassian’s premises, systems or infrastructure, which are audited by Atlassian’s own independent auditors; (e) subject to the auditor’s written confidentiality undertaking; and (f) at Customer’s cost, except where the audit reveals a material breach of this DPA by Alt Datum. Customer will share the audit findings with Alt Datum, and Alt Datum will remediate verified non-conformities within a reasonable period.
22. California service-provider terms
This Section applies to the extent Customer is a "business" under the CCPA and Customer Personal Data includes "personal information" that Customer discloses to Alt Datum. In that case Alt Datum is engaged as Customer’s service provider, and the parties intend this DPA to satisfy the contract requirements of Cal. Civ. Code § 1798.100(d) and § 1798.140(ag) and Cal. Code Regs. tit. 11, § 7051. In addition to Section 7, Alt Datum:
- is engaged for the specific business purposes described in Section 5 and Annex A only, namely providing, securing, supporting and maintaining the Service for Customer;
- will not sell or share personal information;
- will not retain, use or disclose personal information for any purpose other than the business purposes specified in this DPA, or outside the direct business relationship between Alt Datum and Customer, including for any commercial purpose other than the business purposes;
- will not combine personal information received from Customer with personal information received from or on behalf of another person, or collected from Alt Datum’s own interaction with a consumer, except as the CCPA regulations permit for service providers;
- will comply with the obligations applicable to service providers under the CCPA and provide the same level of privacy protection as the CCPA requires of Customer;
- grants Customer the right to take reasonable and appropriate steps to help ensure that Alt Datum uses personal information in a manner consistent with Customer’s obligations under the CCPA, including through the information and audit rights in Section 21;
- will notify Customer within ten business days if it determines that it can no longer meet its obligations under the CCPA;
- grants Customer the right, upon notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of personal information;
- will notify Customer of its engagement of any sub-service-provider as set out in Section 14 and bind it to a written contract meeting the CCPA’s requirements (Section 15);
- will cooperate with Customer in responding to verifiable consumer requests (Section 13);
- will cooperate with Customer’s cybersecurity audits, risk assessments and automated decisionmaking technology obligations under the CCPA regulations to the extent they concern the Service, through the information rights in Section 21, and will not misrepresent any fact relevant to them; and
- certifies that it understands the restrictions in this Section and will comply with them.
No automatic status. Whether Alt Datum actually qualifies as a service provider for a given Customer depends on facts outside this DPA: that Customer meets the CCPA’s thresholds for a "business"; that the data is "personal information" of California residents; that Alt Datum in fact adheres to the restrictions above; and that Customer itself provides the notices the CCPA requires. This DPA creates the contractual conditions but does not by itself establish that status. Other US states. To the extent other US state privacy laws apply, this DPA is intended to set out the processor obligations those laws require (including instructions, confidentiality, deletion or return, information to demonstrate compliance, assessments and sub-contracting), and the terms of this DPA apply to the corresponding concepts under those laws.
23. Government and legally compelled disclosures
If Alt Datum receives a legally binding request from a public authority, court or law enforcement body for access to or disclosure of Customer Personal Data, Alt Datum will: (a) promptly notify Customer of the request, unless legally prohibited; (b) if notice is prohibited, use reasonable efforts to obtain a waiver of the prohibition and, where permitted, provide as much information as it can; (c) review the legality of the request and challenge it where it has reasonable grounds to consider it unlawful under the law of the country of destination or applicable international obligations, including by seeking interim measures to suspend its effect; (d) disclose only the minimum amount of information required; and (e) document each request and make that documentation available to Customer on reasonable request, subject to legal restrictions.
Because Customer Data is held in Forge hosted storage operated by Atlassian, a request may be directed to Atlassian rather than to Alt Datum; Atlassian’s handling of government requests is described in Atlassian’s own published policies. Alt Datum will not voluntarily provide Customer Personal Data to any public authority. As of the effective date of this DPA, Alt Datum has not received any such request relating to the Service.
24. Conflicts, precedence, amendments, liability and termination
Precedence. In the event of conflict, the following order applies: (1) the SCCs, UK Addendum or other mandatory transfer instrument, for the transfers they govern; (2) this DPA, for the processing of Customer Personal Data; (3) the Provider-Specific Terms and the Marketplace end user agreement; (4) the Provider and website terms; (5) the Documentation.
Liability. Each party’s liability arising out of or related to this DPA is subject to the exclusions and limitations of liability in the Agreement, including, where the Marketplace standard end user agreement applies, its treatment of breaches of the DPA as Enhanced Claims. Liability under this DPA and under the Agreement is aggregate and not additive, so that a single cap applies to all claims under both. Nothing in this DPA limits either party’s liability to the extent it cannot be limited under applicable law, or a Data Subject’s rights as third-party beneficiary under the SCCs.
Amendments. Alt Datum may update this DPA by publishing a new version at its public URL with a new version number and effective date. Updates that are required by Applicable Data Protection Law, by a change in Atlassian’s platform or Marketplace terms, or that do not reduce the protection of Customer Personal Data take effect on publication. Other updates take effect for existing Customers 30 days after Alt Datum gives notice through the Atlassian Marketplace listing’s version notes or by email to the contacts described in Section 11. A Customer who objects to such an update on reasonable data-protection grounds may uninstall the Service before the update takes effect. Each published version and its change summary is listed at the end of this document, and prior versions are available from [email protected]. No other amendment is effective unless in writing and signed or expressly accepted by both parties.
Termination. This DPA terminates automatically when the Agreement terminates for the last Installation and Alt Datum has ceased processing Customer Personal Data, including after expiry of the Forge retention period in Section 20. Sections 8, 11, 20, 23 and 24 survive termination to the extent Alt Datum continues to hold or has an obligation regarding Customer Personal Data.
Platform dependencies and force majeure. The Service depends on Jira Cloud, Forge and Atlassian Marketplace, which Alt Datum does not control. Alt Datum is not in breach of this DPA to the extent its performance is prevented by an Atlassian platform outage, Atlassian policy change, or an event beyond its reasonable control, provided it uses reasonable efforts to mitigate the effect and resumes performance as soon as practicable; this does not excuse the breach notification obligations in Section 11.
Governing law. This DPA is governed by the law that governs the Agreement, and disputes are subject to the dispute resolution provisions of the Agreement, except that (a) the SCCs and UK Addendum are governed as stated in Annex D, and (b) where Applicable Data Protection Law requires a particular governing law for processor terms, that law applies to the extent required.
Intellectual property. As between the parties, Customer owns Customer Data, and Alt Datum and its licensors own the Service, including its software, verification policy engine, documentation, trademarks (TestWarden, The Warden and the Verification Gate mark), designs and all improvements. This DPA grants Customer no rights in the Service’s source code, models, architecture or other intellectual property, and grants Alt Datum no rights in Customer Data beyond the limited right to process it under this DPA and the Agreement.
25. Contact information and acceptance
| Purpose | Contact |
|---|---|
| Privacy, data-protection and DPA questions; Data Subject requests; Sub-processor notice subscription | [email protected] |
| Security reports and Personal Data Breach correspondence | [email protected] |
| General support and account questions | [email protected] or the contact form |
| Postal address | 1522 Buena Vista, Apt B, San Clemente, CA 92672, United States |
How this DPA is accepted. This DPA is a standard-form agreement that applies without signature. Customer accepts it by (a) installing or purchasing the Service through Atlassian Marketplace under an end user agreement whose Provider-Specific Terms identify this DPA, or (b) otherwise accepting the Terms, or (c) continuing to use the Service after receiving notice of this DPA. The version of this DPA in force on the date Customer first accepts it, and each later version that takes effect under Section 24, forms part of the Agreement.
Signed copies. A Customer that requires a signed copy of this DPA, or of the SCCs and UK Addendum completed with its own party details, may request one from [email protected]. Alt Datum will return the signed document, completed with its legal entity details, without charge. The signed copy does not vary this DPA unless both parties expressly agree the variation in writing.
Customer contact for notices. Customer may designate an additional email address for notices under Sections 11, 14 and 24 by writing to [email protected] from an administrator of the affected Jira site. Absent such designation, notices will be sent to the contacts available through Atlassian Marketplace and announced in the Marketplace listing’s version notes.
Document identity. TestWarden Data Processing Agreement, version 1.1, effective 2026-10-21. Canonical URL: https://testwarden.me/dpa. Downloadable copy: https://testwarden.me/legal/testwarden-dpa-v1-1.md.
Annex A. Processing details and data categories
This Annex completes Annex I of the SCCs (Sections B and C) and Table 1 and Table 3 of the UK Addendum insofar as they describe the processing. Party details (Annex I, Section A) are in Annex D.
A.1 Description of the processing
| Item | Description |
|---|---|
| Categories of Data Subjects | Users of Customer’s Jira Cloud site (employees, contractors, agents); individuals referenced in Customer Data by Customer or its Users. |
| Categories of Personal Data | Atlassian account IDs (opaque identifiers); Personal Data in customer-authored text (test cases, steps, expected and actual results, comments, approval reasons, tags, filter names, cycle, release and environment labels); Personal Data in files Customer uploads for migration (CSV exports from Xray, Zephyr Scale or spreadsheets); Personal Data in CI evidence reports (JUnit XML, SARIF, JSON) and their metadata (repository, commit, build, environment, run and producer identifiers); Jira issue keys and summaries linked to tests and defects. |
| Sensitive data | None intended. Customer agrees not to submit special categories of Personal Data (Section 6). |
| Frequency of transfer | Continuous, for as long as the Service is installed. |
| Nature of the processing | Storage, retrieval, organization, display, versioning, snapshotting, evaluation, attribution and reporting of account IDs to Atlassian, as described in Section 5. |
| Purpose | Provision, security, support and maintenance of the Service to Customer. |
| Duration | Term of the Agreement for each Installation plus Atlassian’s retention period after uninstall (Section 20). |
| Sub-processor transfers | To Atlassian for Forge hosting of the Service (Annex C); subject matter, nature and duration as above. |
A.2 Data inventory by category
Each row describes the Service as shipped in the production Marketplace candidate. "Installation-scoped" means the data is held in the Installation’s own Forge SQL database or under the Installation’s Object Store key prefix and is removed with the Installation under Section 20.
| Data | Where stored | Personal Data? | Retention |
|---|---|---|---|
| Test cases, steps, folders, tags, priority and status, saved repository filters | Forge SQL (installation-scoped) | Author-entered text may contain Personal Data; owner and filter-owner account IDs | Until archived/edited by Customer; archived tests recoverable; filters deletable; removed with the Installation |
| Test version history and immutable test snapshots | Forge SQL (index) and Forge Object Store (snapshots) | Actor account ID; snapshot content as authored | Life of the Installation |
| Project associations, requirement links, defect links | Forge SQL | Jira issue key and summary as authored in Jira; creator account IDs | Until unlinked by Customer; life of the Installation |
| Cycles, assignments, executions, attempts, step results, tester comments | Forge SQL | Creator, assignee and tester account IDs; comment text | Life of the Installation; cycles archivable; executions preserved as history |
| Change Sets, verification contracts and policy versions, verification receipts, quality decisions, observed evidence sources, CI run announcements | Forge SQL | Producer, run and build identifiers; repository and commit references | Append-only for the life of the Installation |
| Raw CI evidence reports (JUnit XML, SARIF, JSON; up to 256 KiB per submission) | Forge Object Store (installation-scoped) | Whatever Customer’s CI includes (test names, output, author names) | Immutable; life of the Installation; no separate purge |
| Human approval and revocation records | Forge SQL (append-only ledger) | Actor account ID, role and reason text | Life of the Installation |
| Migration jobs, per-row outcomes and content fingerprints | Forge SQL | Creator account ID; bounded source context in outcome reasons | Life of the Installation |
| Raw uploaded migration files | Forge Object Store (installation-scoped) | Whatever the uploaded CSV contains | Retained for resume and verification; life of the Installation; no separate purge |
| Audit events (entity, action, actor, correlation ID, bounded metadata) | Forge SQL | Actor account ID | Life of the Installation; never purged |
| Jira issues created from the Service | Customer’s Jira site (not Forge app storage) | As entered by the User; the issue description includes test and step context and the tester’s account ID | Governed by Customer’s Jira configuration |
| Forge platform logs | Atlassian Forge logging (Atlassian-controlled) | Installation IDs, correlation IDs, error details; designed to exclude test content, account IDs and evidence payloads | Atlassian’s platform log retention |
| Support correspondence sent by Customer to Alt Datum | Alt Datum’s support mailbox (Microsoft 365) | As sent by Customer | For the support relationship; deleted on request |
A.3 Data the Service does not collect or store
- Atlassian passwords, Jira personal access tokens, session cookies or other shared secrets.
- User names, email addresses, avatars or other Atlassian profile attributes (the Jira user-profile scope is not requested).
- Third-party OAuth credentials, CI secrets or API tokens.
- IP addresses or browser telemetry of Users (the Service contains no analytics or tracking).
- Payment card data (billing is performed by Atlassian Marketplace).
Annex B. Technical and organizational security measures
This Annex completes Annex II of the SCCs and the "Security Measures" of the Marketplace standard end user agreement. It distinguishes measures implemented by Alt Datum in the Service from measures provided by Atlassian as the Forge platform operator. Alt Datum relies on, but has not independently audited, the Atlassian measures; Atlassian publishes its own compliance reports and certifications for Atlassian Cloud and Forge, which are Atlassian’s and are not claimed by Alt Datum.
B.1 Measures implemented in the Service by Alt Datum
- Platform confinement. The Service runs exclusively on Forge-hosted compute and storage. Its manifest declares no external egress, no Forge Remote, no third-party analytics, logging or AI processors and no additional storage, and is verified as such on every deployment.
- Least-privilege scopes. Only
read:jira-work,write:jira-workandreport:personal-dataare requested; the feature reason for each is published on the Security page. Custom OAuth scopes protect the App REST API and grant no policy-editing or approval authority. - Server-side authorization. Every data-changing operation is checked for license state and User role on the server before the handler runs; unclassified writes fail closed; display conditions are never authorization.
- Tenant isolation by construction. Installation identity is taken only from the Forge runtime context and bound on every SQL query and Object Store key; API callers and browsers cannot supply it. Automated tests cover cross-installation access attempts, and a confirmed cross-tenant defect is a release blocker.
- Input validation and injection controls. All SQL uses prepared statements with bound parameters; dynamic SQL fragments come only from server-side allowlists; request bodies, uploads and pagination are bounded (evidence submissions at most 256 KiB and 20 observations; migrations at most 10,000 rows and 10 MB); untrusted input is never passed to shell commands.
- Integrity and provenance. Evidence receipts record producer identity, version, run, exact repository, commit, build and environment, and a SHA-256 content digest with an immutable raw-report reference; exact retries are idempotent; conflicting evidence is never overwritten; quality decisions, approvals and audit events are append-only; history is never rewritten.
- No secrets in the Service. The Service stores no Atlassian passwords, API tokens or third-party credentials; the repository is scanned for secrets; no secret material is committed to source control.
- Logging discipline. Resolver and job logs are designed to contain installation and correlation identifiers, counts and error details, not test content, account IDs, request bodies, uploaded files or evidence payloads. Customer-facing error messages are sanitized.
- Secure development and release. Changes are reviewed, linted and tested in continuous integration; production dependency trees are audited for known vulnerabilities on every build with high and critical findings blocking release; deployment is performed only through a fail-closed script that stops on any failed check; the Service’s own changes are gated by TestWarden’s verification loop; Forge lint and Atlassian’s Runs on Atlassian eligibility are checked before release.
- Vulnerability and incident management. A published security contact receives reports; a written incident response runbook defines severity, containment, evidence preservation, tenant-isolation investigation, fix verification, recovery, customer and Atlassian notification and post-incident review; security fixes follow Atlassian’s Marketplace security bug-fix timelines.
- Personnel and access. Access to the source repository, the Atlassian developer console and Forge deployment credentials is restricted to Alt Datum personnel bound by confidentiality, who are the only people able to deploy the Service. Alt Datum personnel have no general administrative read access to Customer Data in Forge hosted storage (Section 8).
- Personal data lifecycle. Stored Atlassian account IDs are reported to Atlassian weekly; closed accounts are anonymized in place; the inventory of account-ID storage locations is a single policy module cross-checked by tests against the database schema so that a new storage location cannot ship unreported.
- Data minimization. Only metadata needed for the workflow is stored; profile attributes are not retrieved; binary content is never stored in SQL; Customer is told in the product which migration data is not imported.
B.2 Measures provided by Atlassian for Forge (per Atlassian’s published documentation)
- Encryption of data at rest in Forge hosted storage and encryption in transit over public networks using TLS 1.2 or higher, as described in Atlassian’s Forge shared responsibility model and Forge data processing terms.
- Segregation of Forge hosted storage so that an app installed on one Atlassian site cannot request data from an installation on another site; a dedicated Forge SQL database per Installation.
- A managed, patched runtime for Forge functions; Alt Datum does not operate servers, operating systems or networks for the Service.
- Data residency placement of Forge hosted storage in the location of the host Jira site (Section 19).
- Platform-level logging, monitoring, backup and the uninstall data lifecycle described in Section 20.
- Atlassian’s own security program, certifications and audit reports for Atlassian Cloud and Forge, available from Atlassian.
B.3 Measures not claimed
Alt Datum does not hold SOC 2, ISO/IEC 27001, HIPAA, PCI DSS, FedRAMP or similar certifications for the Service and does not claim Atlassian certification, approval or endorsement. Alt Datum does not implement application-level encryption of Customer Data beyond the platform measures above, does not offer customer-managed encryption keys, and does not promise an uptime service level. The runtime isolation of Forge functions is per app, not per Customer; the Service is designed to keep no Customer Data in process memory across invocations.
Annex C. Sub-processors and infrastructure providers
This Annex completes Annex III of the SCCs. It is current as of the effective date of this version and is updated under Section 14.
C.1 Sub-processors engaged by Alt Datum for the Service
| Sub-processor | Purpose | Data processed | Location of processing | Safeguards |
|---|---|---|---|---|
| Atlassian Pty Ltd and its affiliates, including Atlassian, Inc. (atlassian.com; legal notice details as published at https://www.atlassian.com/legal) | Operation of Atlassian Forge: hosted compute, Forge SQL, Forge Object Store, Forge Async Events, platform logging, personal data reporting, Marketplace distribution and licensing | All Customer Data held by the Service | The data residency location of Customer’s Jira Cloud site (Section 19); Atlassian’s hosting regions as published by Atlassian | Forge data processing terms between Atlassian and Alt Datum, including SCCs and UK Addendum; Atlassian’s published security program |
| Microsoft Corporation (microsoft.com), Microsoft 365 | Hosting of Alt Datum’s support, security and privacy mailboxes | Only Customer Data that Customer chooses to send to Alt Datum in support, security or privacy correspondence | United States (Microsoft 365 commercial tenant) | Microsoft Products and Services Data Protection Addendum, including SCCs |
No other Sub-processor processes Customer Data. In particular, no analytics, error-tracking, logging, AI or model provider, email-marketing, CRM or source-code hosting service receives Customer Data from the Service.
C.2 Infrastructure sub-processors of Atlassian
Atlassian uses its own sub-processors to operate Atlassian Cloud and Forge, principally Amazon Web Services, Inc. as cloud hosting provider in the regions Atlassian publishes. Atlassian’s current list, including locations and the notification subscription for changes, is published by Atlassian at https://www.atlassian.com/legal/sub-processors. These entities are engaged by Atlassian, not by Alt Datum, and changes to them are governed by Atlassian’s process.
C.3 Service providers that do not process Customer Data
The following providers support Alt Datum’s business or the testwarden.me website and are described in the Privacy Policy, but they do not receive Customer Data from the Service and are not Sub-processors under this DPA: Cloudflare, Inc. (website delivery, Web Analytics and Turnstile abuse prevention on the website contact form, when enabled); Elastic Email Inc. (delivery of website contact-form messages); GitHub, Inc. (source code hosting and continuous integration for the Service’s own code, which never contains Customer Data). Alt Datum does not use any AI or large-language-model provider to process Customer Data.
Annex D. International transfer provisions
This Annex completes the SCCs (Section 17) and the UK Addendum (Section 18). Where a selection depends on Customer’s own details, Customer’s details are those it provides to Atlassian Marketplace when installing or purchasing the Service, and Customer may ask Alt Datum to issue a completed and signed copy under Section 25.
D.1 Standard Contractual Clauses: completion
| Clause | Selection |
|---|---|
| Module | Module Two (controller to processor) where Customer is a Controller; Module Three (processor to processor) where Customer is a Processor. |
| Clause 7 (docking) | Included. |
| Clause 9(a) (sub-processors) | Option 2: general written authorization; at least 30 days’ prior notice (Section 14). |
| Clause 11(a) (redress) | The optional independent dispute resolution body language is not included. |
| Clause 13 (supervision) | The competent Supervisory Authority is determined under Clause 13(a) by the data exporter’s establishment or, where the exporter is not established in the EU, by its Article 27 representative or the Member State in which the Data Subjects are located. |
| Clause 17 (governing law) | Option 1: the law of Ireland, unless the Provider-Specific Terms on the Marketplace listing or a signed copy under Section 25 specify the law of another EU Member State that allows third-party beneficiary rights. |
| Clause 18 (forum) | The courts of Ireland, unless specified otherwise as above. |
| Annex I.A (parties) | Data exporter: Customer, in the role of Controller (Module Two) or Processor (Module Three), with the name, address and contact details Customer provided to Atlassian Marketplace. Data importer: Alt Datum, in the role of Processor, with the legal entity details stated in the Terms and Provider-Specific Terms; contact: [email protected]. |
| Annex I.B (description of transfer) | Annex A of this DPA. |
| Annex I.C (competent Supervisory Authority) | As determined under Clause 13 above. |
| Annex II (security measures) | Annex B of this DPA. |
| Annex III (sub-processors) | Annex C of this DPA. |
D.2 UK Addendum: completion of Tables 1 to 4
| Table | Completion |
|---|---|
| Table 1: Parties | Exporter: Customer (details as provided to Atlassian Marketplace). Importer: Alt Datum (details as in D.1). Key contact: [email protected]. The start date is the date Customer first accepts this DPA. |
| Table 2: Selected SCCs, Modules and Selected Clauses | The version of the Approved EU SCCs which this Addendum is appended to, with the module and selections set out in D.1, including Clause 7 and Clause 9(a) Option 2 with 30 days’ notice. Clause 11 optional language: not included. |
| Table 3: Appendix Information | Annex 1A: Annex D.1 of this DPA. Annex 1B: Annex A. Annex II: Annex B. Annex III: Annex C. |
| Table 4: Ending this Addendum when the Approved Addendum changes | Either party may end this Addendum as set out in Section 19 of the UK Addendum. |
The Part 2 Mandatory Clauses of the UK Addendum, as published by the Information Commissioner (version B1.0, in force 21 March 2022), apply without modification.
D.3 Switzerland
The adaptations in Section 18 apply. For transfers governed solely by the FADP: the competent authority under Clause 13 is the FDPIC; the governing law under Clause 17 is the law of Switzerland; and the forum under Clause 18 is the courts of Switzerland. For transfers governed by both the FADP and the EU GDPR, the selections in D.1 apply to the GDPR transfer and the FDPIC supervises the FADP transfer in parallel. In all cases, Data Subjects habitually resident in Switzerland may bring proceedings in Switzerland under Clause 18(c).
D.4 No reliance on adequacy decisions for Alt Datum
Alt Datum is not certified under the EU-US Data Privacy Framework, its UK Extension or the Swiss-US Data Privacy Framework. Should Alt Datum become certified, it will update this Annex and the SCCs will remain in place as a fallback mechanism.
Version history
| Version | Effective | Change |
|---|---|---|
| 1.1 | 2026-10-21 | Completes the owner-confirmed legal provider identity and public business address, and clarifies Cloudflare website services. The frozen V1 app processing terms are unchanged. The v1.0 Markdown download remains available. |
| 1.0 | 2026-10-08 | First published version. Drafted against the frozen TestWarden V1 Marketplace candidate (Forge production version 3.0.0): Forge SQL and Forge Object Store only, no external egress, three Atlassian scopes, weekly Atlassian personal-data reporting. |
The current version is always published at https://testwarden.me/dpa. The downloadable copy at https://testwarden.me/legal/testwarden-dpa-v1-1.md contains the same text as this page. Prior versions are available from [email protected].