Schedule 1 — Data Processing Addendum
1. Purpose, structure and definitions
This Data Processing Addendum (the "DPA") is Schedule 1 to the Provider-Specific Terms for the Page Sharing for Confluence app, and forms part of the Agreement as contemplated by Section 3.3 of the Standard Agreement and Section 7 of the Provider-Specific Terms. Capitalised terms defined in Section 2 of the Provider-Specific Terms (including "Agreement", "App", "Customer", "End User", "Provider", "Producer Site" and "Consumer Site") have the same meanings in this DPA, and terms defined in the Standard Agreement but not in this DPA or the Provider-Specific Terms have the meanings given there. In addition, in this DPA:
"Data Protection Laws" means all laws applying to the Processing of Personal Data under the Agreement, including (to the extent applicable) the Privacy Act 1988 (Cth) and the Australian Privacy Principles ("APPs"), Regulation (EU) 2016/679 (the "GDPR"), the GDPR as incorporated into United Kingdom law (the "UK GDPR"), the Swiss Federal Act on Data Protection, and any equivalent law of another jurisdiction that applies to a party's Processing of Personal Data under the Agreement.
"Personal Data", "Controller", "Processor", "Data Subject", "Processing" (and "Process"), "Personal Data Breach" and "Supervisory Authority" have the meanings given in the GDPR, and where the Privacy Act 1988 (Cth) applies, "Personal Data" includes "personal information", a Personal Data Breach includes an "eligible data breach", and references to a Data Subject include an "individual", each as defined in that Act.
"Customer Personal Data" means Personal Data contained in Customer Data that is Processed by the App on the Customer's behalf under the Agreement. Consistent with Additional Term 8(a) of the Provider-Specific Terms, content written into a Consumer Site is, as between the Provider and the Customer operating that Consumer Site, that Customer's Customer Data under that Customer's own Agreement.
"Sub-processor" means a third party engaged by the Provider to Process Customer Personal Data.
2. Roles and the App's architecture
For the purposes of the GDPR and equivalent Data Protection Laws, the Customer is the Controller of Customer Personal Data (or, where the Customer acts as a Processor for another Controller, the Customer warrants that it is authorised to instruct the Provider as contemplated by this DPA, and the Provider acts as that Controller's sub-processor), and the Provider is a Processor. The parties record, because it shapes how each obligation in this DPA operates, that the Provider operates no server, database or storage system of its own for the App: the App executes entirely on Atlassian's Forge platform, its operational records reside in Forge storage within each Customer's own Confluence Cloud site, and the only network destination the App can contact is its own Atlassian-hosted Forge web-trigger host, which is how one Confluence site's installation of the App communicates with another's. The Provider's Processing therefore consists of providing and operating the App's software, which acts automatically on the Customer's instructions given through the App's controls, and does not involve Customer Personal Data being received or held on any system operated by the Provider.
Where a Customer operating a Producer Site directs the App to share a page with a Consumer Site operated by a different organisation, that direction is a disclosure of the content by the producing Customer to that other organisation, which receives it as an independent Controller (or under whatever arrangement exists between the two organisations). The Provider is not a party to that arrangement, and the transmission the App performs in executing the direction is Processing on the producing Customer's documented instruction rather than sub-processing engaged by the Provider. The producing Customer is responsible for ensuring it has a lawful basis for that disclosure, including where the receiving organisation or its Confluence site is in a different jurisdiction.
3. Details of Processing
The subject matter, duration, nature and purpose of the Processing, the types of Personal Data Processed and the categories of Data Subjects are set out in Annex 1, which forms part of this DPA and constitutes the documented record required by Article 28(3) of the GDPR.
4. The Provider's obligations as Processor
(a) Documented instructions. The Provider will Process Customer Personal Data only on the Customer's documented instructions, including with regard to transfers of Personal Data to a third country, unless required to do otherwise by a law to which the Provider is subject (in which case the Provider will inform the Customer of that legal requirement before Processing, unless that law prohibits doing so on important grounds of public interest). The parties agree that the Customer's complete instructions at the date of the Agreement are: (i) the Agreement, including this DPA; and (ii) the Customer's configuration and use of the App's controls, each use of which (enabling or disabling a space for sharing, approving a page, adding or removing a partner site from the allow-list, approving or denying a subscription request, issuing or revoking a subscription link, subscribing, unsubscribing, and stopping sharing) constitutes a documented instruction that the App executes automatically. The Provider will inform the Customer if, in the Provider's opinion, an instruction infringes the GDPR or other Data Protection Laws, though the Provider is not obliged to review the Customer's instructions for legal compliance.
(b) Confidentiality. The Provider will ensure that any person it authorises to Process Customer Personal Data (in practice, the Provider himself, as an Australian sole trader with no employees, and any future personnel or contractors) is committed to confidentiality under a binding obligation or is under an appropriate statutory obligation of confidentiality. The Provider will not access Customer Personal Data except where necessary to provide the App and Support, at the Customer's request, or as required by law.
(c) Security. The Provider will implement and maintain the technical and organisational measures set out in Annex 2, which the parties agree are appropriate to the risk presented by the Processing described in Annex 1, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the Processing (Article 32 of the GDPR). The Provider may update those measures from time to time, provided the protection they afford does not materially diminish during a Subscription Term.
(d) Sub-processors. The Customer provides general written authorisation for the Provider's engagement of the Sub-processor listed in Section 5, and of replacement or additional Sub-processors subject to this paragraph. The Provider will give the Customer at least 30 days' notice of any intended addition or replacement of a Sub-processor (by updating the Sub-processor information published at the Provider's website and, where the Provider has contact details for the Customer, by direct notice), and the Customer may object on reasonable data-protection grounds within that period. If the parties cannot resolve the objection, the Customer may terminate the Agreement in respect of the App and receive a pro-rata refund of prepaid, unused fees for the remainder of the Subscription Term. The Provider will impose on each Sub-processor, by contract, data-protection obligations providing materially the same level of protection as this DPA, and remains fully liable to the Customer for the Sub-processor's performance.
(e) Assistance with Data Subject requests. Taking into account the nature of the Processing, the Provider will assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer's obligation to respond to Data Subjects exercising their rights under Chapter III of the GDPR (or equivalent rights under other Data Protection Laws, including access and correction under APPs 12 and 13). Because the App's records and the content it replicates reside in the Customer's own Confluence sites, those measures consist principally of the App's own controls: shared content is corrected by editing the source page (the correction propagates to every synced copy on the next push), erasure of a synced copy is effected by withdrawing sharing or unsubscribing (which moves the synced page to the receiving site's trash), and the App's management screens show which pages are shared, with which sites, and who took each action. In addition, the identifiers of closed Atlassian accounts are removed from the App's records automatically, through the reporting and erasure flow described in Section 8. If a Data Subject request is made directly to the Provider, the Provider will forward it to the Customer promptly and will not respond to it except on the Customer's documented instruction or where required by law.
(f) Assistance with security, breach notification and impact assessments. Taking into account the nature of the Processing and the information available to the Provider, the Provider will assist the Customer in ensuring compliance with the Customer's obligations under Articles 32 to 36 of the GDPR (and, where the Privacy Act 1988 (Cth) applies, the notifiable data breaches scheme in Part IIIC of that Act), including by making available the documentation described in Section 4(h) for the Customer's own security and impact assessments.
(g) Personal Data Breach notification. The Provider will notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data, and will provide the Customer with the information reasonably available to the Provider about the nature of the breach, the categories and approximate numbers of Data Subjects and records concerned, the likely consequences, and the measures taken or proposed to address it, supplementing the notification as further information becomes available. Because the App runs on infrastructure operated by Atlassian, the Provider's awareness of a platform-level incident may depend on Atlassian's notification to the Provider under Atlassian's own terms; the Provider will pass on such notifications without undue delay. The Provider's notification is not an acknowledgement of fault or liability.
(h) Demonstrating compliance; audits. The Provider will make available to the Customer the information necessary to demonstrate compliance with the obligations laid down in Article 28 of the GDPR and this DPA, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer, as follows. The Provider maintains, and will provide on request: the App's manifest-declared permissions and egress destinations; the App's privacy policy; the network architecture documentation describing every ingress and egress path; the most recent independent security review of the App's source code; and written responses to the Customer's reasonable data-protection and security questionnaires. Given that the Provider operates no premises, infrastructure or systems that hold Customer Personal Data (the App's execution environment and storage are operated by Atlassian, whose own compliance programs, including SOC 2 and ISO 27001 coverage of the Forge platform, are documented by Atlassian), the parties agree that audits will in the first instance be satisfied by that documentation, and that an inspection beyond it (conducted remotely, on at least 30 days' notice, no more than once in any 12-month period, at the Customer's cost, and subject to reasonable confidentiality obligations) may be required only where the documentation is demonstrably insufficient to evidence compliance, where a Supervisory Authority requires it, or following a Personal Data Breach affecting the Customer.
5. Sub-processor
The Provider's sole Sub-processor is Atlassian (Atlassian Pty Ltd and its relevant corporate affiliates), which operates the Forge platform on which the App executes and the storage in which the App's records reside. The Provider's engagement of Atlassian is governed by Atlassian's Forge Terms and the Forge Data Processing Addendum, which Atlassian applies to developers hosting apps on Forge and which includes Standard Contractual Clauses between the Provider and Atlassian covering cross-border transfers of Personal Data to Atlassian. The Customer separately has its own direct agreement with Atlassian for Confluence Cloud, under which the Customer's site (including pages the App creates or maintains) is hosted; nothing in this DPA alters that agreement. The Provider engages no other Sub-processor: the App uses no third-party analytics, no content delivery network, and no external service beyond the pinned Atlassian-hosted endpoint described in Annex 2. For clarity, support correspondence that the Customer or an End User sends to the Provider is Processed by the Provider as an independent Controller under the App's privacy policy, resides with the Provider's email provider, and is not Customer Personal Data Processed by the App, so it sits outside this DPA and the Sub-processor list above.
6. International transfers
The Provider does not itself transfer Customer Personal Data across borders: the App's records reside in the Forge storage associated with the Customer's Confluence site, whose physical location is determined by Atlassian's hosting and data-residency arrangements under the Customer's own agreement with Atlassian, and the Provider, an Australian sole trader, does not receive the data in Australia or anywhere else. Cross-border movement of Personal Data can nonetheless occur in two ways. First, where the Customer directs the App to share a page with a Consumer Site hosted in another jurisdiction, the resulting transfer is made by the Customer, as Controller, to the organisation operating that site, and the Customer is responsible for ensuring a lawful transfer mechanism exists where one is required (including under APP 8.1 where the Privacy Act applies to the Customer). The App gives the Customer the controls to make that decision deliberately: sharing requires the recipient site to be individually allow-listed or expressly approved, and the allow-list records which administrator added each site. Secondly, transfers of Personal Data to Atlassian as the platform operator are addressed by the Standard Contractual Clauses incorporated in the Forge Data Processing Addendum between the Provider and Atlassian, and by whatever transfer mechanisms apply under the Customer's own agreement with Atlassian. To the extent that, notwithstanding the foregoing, a transfer of Customer Personal Data from the Customer to the Provider subject to Chapter V of the GDPR (or the equivalent provisions of the UK GDPR or Swiss law) is found to occur, the parties agree that the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor) or Module Three (processor to processor) as applicable, supplemented by the UK International Data Transfer Addendum or Swiss amendments as applicable, are incorporated into this DPA by reference, with the Customer as data exporter, the Provider as data importer, Annex 1 of this DPA serving as Annex I.B of those clauses, and Annex 2 of this DPA serving as Annex II. For that incorporation the parties select the following options within those clauses: the docking clause (Clause 7) is included; the option under Clause 9(a) is general written authorisation, with the notice period in Section 4(d) of this DPA; the governing law under Clause 17 is the law of Ireland (or, where the UK International Data Transfer Addendum applies, the law of England and Wales); the courts under Clause 18 are the courts of Ireland (or of England and Wales, as applicable); and the competent supervisory authority under Clause 13 is determined by the data exporter's establishment or, where the exporter is not established in the EEA, by the location of its representative under Article 27 of the GDPR or of the Data Subjects concerned, as those clauses provide.
7. Deletion and return of Customer Personal Data
Consistent with Additional Term 8(c) of the Provider-Specific Terms: Customer Personal Data Processed by the App resides in the Customer's own Confluence sites, and the Provider holds no separate copy from which to return or delete it. At the end of the provision of the App's services, deletion is effected as follows, at the Customer's choice exercised through the App and Confluence: withdrawing sharing or unsubscribing moves synced pages to the relevant site's trash (subject to that site's own trash and retention arrangements, which the receiving site's administrators control); uninstalling the App from a site causes the App's operational records in that site's Forge storage to be removed by Atlassian in line with Atlassian's platform data-retention lifecycle; and export is available at any time through Confluence's own export facilities. The delete instruction the App sends to subscribing sites on withdrawal of sharing is sent once, on a best-effort basis, and is not queued for retry if a site is unreachable at that moment, though no further content is pushed to that subscriber because the producer re-verifies authorisation before every push, and a subscriber can always effect removal locally by unsubscribing. The Provider will, on written request, delete Personal Data the Provider actually holds on its own systems in connection with the Agreement (in practice, support correspondence) within 60 days, unless a law to which the Provider is subject requires its retention, in which case the Provider will inform the Customer and protect it from further Processing.
8. Atlassian account identifiers and platform privacy flows
The App stores Atlassian account identifiers in its operational records (the who-did-what audit trail described in Annex 1), and resolves them to display names only on demand, when an administrator views a management screen, without storing the resolved name. The App participates in Atlassian's personal data reporting flows for Marketplace apps: on a daily cycle (well within Atlassian's default reporting interval), the App reports each account identifier it stores to Atlassian's personal data reporting API, and where Atlassian indicates that an account has been closed, the App replaces every occurrence of that account's identifier in its records with a non-identifying marker (shown to administrators as "Account removed"), so that the audit record of the historical action is retained without continuing to identify the individual. Because the App stores account identifiers only, and never stores names, contact details or other profile attributes, a profile-update notification from Atlassian requires no action. The App's records themselves are removed with the App's storage on uninstallation as described in Section 7.
9. Australian Privacy Act
To the extent the Privacy Act 1988 (Cth) applies to Personal Data Processed under the Agreement, the Provider will not do or omit anything that would cause the Customer to breach the APPs, will handle personal information in a manner consistent with the APPs that apply to the handling of personal information by an organisation (whether or not the Provider is itself an APP entity at the relevant time), and will notify the Customer without undue delay of any actual or suspected eligible data breach affecting Customer Personal Data so that the Customer can meet its own obligations under Part IIIC of that Act. The parties acknowledge that where the App is used to disclose personal information to a recipient outside Australia, that disclosure is made by the Customer through the controls described in Section 6, and APP 8 compliance for it rests with the Customer.
10. Liability, duration, precedence and governing law
This DPA takes effect on the effective date of the Agreement and continues for as long as the Provider Processes Customer Personal Data under it, surviving termination of the Agreement to that extent. Each party's liability arising out of or related to this DPA is subject to the limitations and exclusions in Section 14 of the Standard Agreement, and the parties note that under Section 14.5 of the Standard Agreement a breach of this DPA is an Enhanced Claim subject to the Enhanced Cap. In the event of a conflict between this DPA and the remainder of the Agreement concerning the Processing of Customer Personal Data, this DPA prevails; the order of precedence in Section 9 of the Provider-Specific Terms otherwise applies. This DPA is governed by the Governing Law specified in Section 4 of the Provider-Specific Terms, except where the incorporated Standard Contractual Clauses mandate otherwise for the matters they govern.
Annex 1 — Details of Processing
Subject matter. The Processing performed by the Page Sharing for Confluence app in providing its service to the Customer: sharing designated Confluence pages from a Producer Site to one or more Consumer Sites, maintaining synced read-only copies of those pages, and keeping the operational and audit records needed to govern that sharing.
Duration. The Subscription Term of the Agreement, and thereafter until the App is uninstalled from the Customer's site(s) and the App's stored records are removed under Atlassian's platform data-retention lifecycle, as described in Section 7 of this DPA.
Nature and purpose. Automated, software-driven Processing, executed on the Customer's instructions given through the App's controls: reading the body and title of a page approved for sharing; reducing that content to a fixed allow-list of standard Confluence content types; transmitting it to the Consumer Sites the producing Customer has authorised; writing and updating the synced copy as a page in the receiving site; applying an edit restriction and replica marker to that page; moving it to trash when sharing ends; verifying, server-side, the authorisation of each person who operates the App's controls; and recording the operational and audit records described below. The purpose is solely the provision of the App's page-sharing functionality; the Provider performs no analytics, profiling, enrichment, marketing or other secondary Processing, and no automated decision-making producing legal or similarly significant effects.
Categories of Personal Data. (i) Atlassian account identifiers of the Customer's administrators and End Users who operate the App, held in the App's operational records in the Forge storage of the relevant site: the administrators who enable or disable spaces for sharing, approve or stop sharing of pages, manage the allow-list, create or revoke subscription links, approve or deny subscription requests, and end subscriptions; and the users on a Consumer Site who subscribe to or unsubscribe from a page; in each case together with timestamps of the action. Display names are resolved from identifiers on demand for display to administrators and are not stored. (ii) Partner-site records: each partner site's Atlassian cloudId (a tenant identifier, not personal data of an individual) with an optional human-readable site label and URL. (iii) Shared page content: the title and permitted body content of each page the producing Customer shares, as a sanitised replica in the native Confluence format, which may incidentally contain any Personal Data the Customer's page text contains (names, contact details, opinions, or other information the Customer has chosen to put in the page); the categories and sensitivity of that embedded Personal Data are determined solely by the Customer. (iv) Operational security material associated with subscriptions (per-subscription secrets, endpoints, tokens), which is not Personal Data but is recorded here for completeness of the stored-record description.
Special categories of Personal Data. None is required by or collected for the App's operation. Special category data (or sensitive information within the meaning of the Privacy Act) is Processed only if and to the extent the Customer includes it in the text of a page the Customer chooses to share, which is within the Customer's control and responsibility; the App applies no Processing specific to such data.
Categories of Data Subjects. The Customer's administrators and End Users who operate the App; and any individuals whose Personal Data appears in the text of pages the Customer chooses to share (which may include the Customer's personnel, clients, suppliers or other third parties, as determined by the Customer's content).
Frequency and retention. Processing is continuous while sharing is active: a push occurs when a shared page is updated, and on subscription. Subscription and sharing records, including ended subscriptions, are retained as the App's audit trail until the App is uninstalled from the relevant site; synced pages persist in the receiving site (in its page tree or trash) under that site's own arrangements; pending subscription requests expire automatically after 14 days if not actioned. Where Atlassian reports an account as closed through the flow described in Section 8, the identifiers of that account held in the App's records are replaced with a non-identifying marker on the next daily reporting cycle, while the record of the action and its timestamp are retained.
Annex 2 — Technical and organisational measures
The measures below reflect the App as shipped, are verified against the App's manifest, source code and independent security review, and are maintained by the Provider. Where a measure is provided by the Atlassian Forge platform, that is stated, because the platform enforces it independently of the App's code.
Hosting and isolation (platform). The App executes entirely on Atlassian Forge, within Atlassian-operated infrastructure covered by Atlassian's published compliance programs (including SOC 2 and ISO 27001 coverage of the Forge platform, per Atlassian's documentation). Each installation's storage is a private, per-site namespace with platform-enforced tenant isolation; no CloudScript.io-operated system exists in the Processing chain. Encryption in transit and at rest for Forge execution and storage is provided and managed by Atlassian.
Egress control (platform-enforced). The App declares exactly one permitted external destination, its own Atlassian-hosted Forge web-trigger host (e0dc6603-9fc0-4811-ac03-a102e9206634.hello.atlassian-dev.net), and the Forge platform blocks any undeclared egress. In code, the App additionally validates that any subscriber endpoint it is asked to store or call sits on the Forge web-trigger host family, as defence in depth against endpoint manipulation. Data therefore cannot be routed to the Provider or to any third party.
Access control and authorisation. Every privileged operation is authorised server-side against the role it requires, using platform-asserted identity that the caller cannot spoof, and the checks fail closed: organisation-administrator rights for instance trust (allow-list, approvals, space enablement), space-administrator rights for sharing pages, and page-creation permission for subscribing. Administrative user-interface panels sit in Confluence's admin-gated settings areas.
Cross-site authentication. Enrolment of a subscriber requires possession of an unguessable, revocable subscription link (144-bit token, use-counted). A subscription is granted immediately only where the requesting site is on the allow-list and proves its identity through an HMAC-based attestation of its platform-provided site identifier, verified before the claimed identity is trusted; requests that are not both allow-listed and validly attested are held for administrator approval, in a queue that is capped (25 outstanding requests per link) and expires (14 days). Every content push is authenticated by a per-subscription 256-bit secret compared in constant time, and a receiving site accepts a push only against a subscription it created. The attestation trust anchor is held as an encrypted Forge environment variable with rotation support.
Content sanitisation. Page content is reduced to a fixed allow-list of standard Confluence content types before it leaves the Producer Site, and independently re-validated against the same allow-list before it is written on the Consumer Site, failing closed on unparseable content; link marks are restricted to web and email links. Images, attachments, macros and app content, mentions and embedded media are removed before transmission.
Secrets handling and minimisation. Subscription secrets and internal endpoints are confined to server-side storage and the authenticated wire exchange; every response surfaced to a browser passes through projections that strip them, enforced by regression tests. The App stores account identifiers rather than names or contact details, resolves display names on demand without storing them, and internal error detail is not echoed across the site-to-site boundary.
User-privacy automation (app-enforced). On a daily schedule, the App reports each stored account identifier to Atlassian's personal data reporting API and replaces the identifiers of accounts Atlassian marks closed with a non-identifying marker, as described in Section 8; the erasure is idempotent, a failed cycle is retried the following day, and failures are logged as counts only, so the logging path itself stores no identifiers.
Secure development and verification. The App is developed in strictly type-checked TypeScript with an automated test suite (171 tests at the current release, including dedicated security regression suites for secret redaction, authorisation gating, content sanitisation and attestation, and a dedicated test suite for the personal-data reporting and erasure flow). Before release the App underwent independent adversarial security review with static analysis (reviews dated 30 June 2026 and 3 July 2026), which found no unresolved Critical, High or Medium severity vulnerability; identified low-severity findings were remediated and re-verified, and the review artefacts are available to Customers under Section 4(h) of this DPA. Dependencies are monitored, and the Provider maintains the App under the Atlassian Marketplace security requirements applicable to Forge apps, including its vulnerability-management obligations.
Organisational measures. The Provider operates as a sole trader. Access to the Marketplace vendor account, the Forge developer console and the source repository is limited to the Provider and a small number of authorised individuals bound by the same access rules, each protected by strong authentication (two-step verification, which is mandatory for Marketplace partners), with no shared credentials. The Provider maintains the App's documentation (privacy policy, network architecture, security review) so that the measures above remain accurate as the App changes, and updates this Annex where a release materially changes them.