MSG/EML Email Viewer for Confluence Data Processing Addendum

Effective 19 August 2026

Status of this document

This Data Processing Addendum ("this Addendum") is published by Cloudscript Pty Ltd (ABN 14 700 662 362) ("Cloudscript", "we", "us") for customers of MSG/EML Email Viewer for Confluence (the "App") whose procurement, vendor-assurance or internal governance processes require a data processing document from every software supplier, irrespective of that supplier's role under data protection law.

Cloudscript's assessed position for this App is that it is a supplier of software and is neither a controller nor a processor of personal data within the meaning of Articles 4(7) and 4(8) of the General Data Protection Regulation (EU) 2016/679 ("GDPR"), and is neither a business nor a service provider within the meaning of the California Consumer Privacy Act as amended ("CCPA"). The reasoning is set out in "Roles of the parties" below. This Addendum is provided as a description of what the App actually does and of the commitments Cloudscript can actually meet. It is not an acknowledgement, admission or acceptance that Cloudscript is a processor, a service provider, or a controller in respect of the App, and it must not be construed as one. Where this Addendum uses language drawn from Article 28 of the GDPR, it does so because the procurement processes this document serves are organised around that article, and each such clause records plainly whether it has any operative content on these facts.

Nothing in this Addendum limits or varies any right a customer has under the Australian Consumer Law or under any other law that cannot lawfully be excluded.

1. Parties, scope and interpretation

This Addendum applies between Cloudscript and the organisation that has installed the App into its Atlassian Confluence Cloud site (the "Customer"). It supplements the Terms of Use and is read with the Privacy Policy for the App. Where a statement of fact in this Addendum differs from a statement of the same fact in either of those documents, the difference is an error and should be reported to support@cloudscript.io; the three documents describe one set of facts and are intended to agree.

This Addendum deliberately does not label the Customer as "Controller" or Cloudscript as "Processor". Those labels carry legal consequences that the characterisation set out below does not support, and using them as convenient shorthand would contradict the substance of the document.

The Terms of Use for the App are issued as Provider-Specific Terms supplementing the Bonterms Standard End User Agreement, Version 1.0 (the "Standard Agreement"), and identify this Addendum as the Data Protection Addendum for the App. This Addendum forms Schedule 1 to those Provider-Specific Terms. It takes effect on the date the Customer installs the App or on the effective date stated above, whichever is later, and continues for as long as the App remains installed in the Customer's Confluence site.

2. Roles of the parties

The Customer determines which email files are attached to which Confluence pages, which macro instance displays which attachment, who may view the pages that carry them, and for what purpose the Customer's organisation keeps that correspondence. Cloudscript determines none of those things and has no independent purpose for any of the data. On that basis Cloudscript is not a controller for the App.

Cloudscript is also not a processor for the App, because it performs no processing operation on the Customer's behalf. The App is software that the Customer installs into infrastructure the Customer already holds under its own agreement with Atlassian, and that executes in the Customer's users' own browsers and on Atlassian's own Forge platform. Cloudscript operates no server, database, proxy, cache, log destination or analytics endpoint in the App's path, and the App's Forge manifest declares no outbound network access to any host. Cloudscript receives no email content, cannot enumerate what a given installation holds, and has no technical route by which it could obtain any of it. A supplier whose product is executed on the customer's own systems and who receives no data is ordinarily neither a controller nor a processor, and the App is an unusually clean instance of that position because there is no Cloudscript-operated infrastructure at all.

Two facts qualify that description and are stated here rather than left for a reviewer to discover. First, the App declares the Forge scope write:confluence-file and does write: an author can upload an email file through the macro's configuration screen, and on Save that file is created as an ordinary Confluence page attachment. The write is initiated by the Customer's own user, is deferred until Save, executes under that user's own Confluence permissions, and produces a file indistinguishable from one the user attached by hand. Nothing leaves the browser before Save. Second, on every non-PDF export path Confluence invokes a function that Cloudscript authored and that runs on Atlassian's Forge platform. That function reads the macro's configured attachment file name and display label in order to return a configuration-only card. A file name can itself be disclosive. The function performs no storage call, makes no product API call, sends nothing onward, and declines PDF export outright by returning nothing, so that PDF export is served by Confluence's own browser-render capture of the card already displayed on the page. The App is therefore not purely client-side, and this Addendum does not describe it as such.

Under the CCPA, Cloudscript is neither a business nor a service provider for the App. The statutory thresholds in Civil Code §1798.140(d) were confirmed as not met on 19 August 2026, and Cloudscript does not process consumers' personal information on any business's behalf, because none is disclosed to it.

3. Subject matter and duration of the processing

The subject matter is the display, inside the Customer's own Confluence pages, of .msg and .eml email files that the Customer's own users have attached to those pages, together with the author-initiated upload of such a file as a page attachment.

Processing of email content occurs only while a page carrying the macro is being rendered for a user who is permitted to view it. On each render the attachment bytes are read fresh from the Customer's own Confluence attachment storage, parsed in the viewing user's browser, displayed, and discarded. There is no processing between renders, and Cloudscript retains nothing at any point. Duration is therefore governed entirely by the Customer's own decisions about how long the page and its attachments exist, and by how long the App remains installed.

4. Nature and purpose of the processing

The purpose is to make an email file attached to a Confluence page readable in place, so that the file itself remains the record. The operations the App performs are:

• listing the attachments of the page the macro sits on, and reading the bytes of the selected .msg or .eml file, both through Atlassian's own Confluence APIs under the Forge scope read:attachment:confluence;
• parsing those bytes in a Web Worker in the viewing user's browser under a 15,000 millisecond deadline, and rendering the result as an email card showing the subject, sender, recipients, date, body, inline images and a list of the email's own attachments;
• sanitising the email's HTML before it is drawn, and blocking remote content referenced by the email unless the viewing user chooses to load it for that render;
• on request, downloading a listed attachment of the email to the viewing user's own device, in the browser, without any further server call;
• writing three values (the Confluence attachment identifier, the attachment file name, and a display label chosen by the author) into the macro's own configuration, which Confluence holds inside the page's own content;
• on the author-initiated upload path, creating the uploaded email file as an ordinary Confluence page attachment under the Forge scope write:confluence-file, on Save; and
• on a non-PDF export path, returning a configuration-only card built from the stored attachment file name and display label, as described in "Roles of the parties" above.

The App declares no Forge scope beyond the two named above, and its test suite pins that allowlist exactly. It declares no remotes block and no external fetch permission, and the shipped source contains no direct network call of any kind.

5. Categories of personal data and of data subjects

The App imposes no restriction on what an email may contain, so the categories below describe what an email file can carry rather than a set Cloudscript selects or limits.

• Email header data: sender name and address, recipient names and addresses (including copied and blind-copied recipients where the file records them), date and time, and subject line.
• Email body content: free text and HTML, including whatever personal data the correspondents chose to write, and inline images.
• Attachment data: the file names, sizes and bytes of the email's own attachments, including any nested or embedded message, which the App lists and can download but never opens or renders in place.
• Attachment reference data: the Confluence attachment identifier, the attachment file name, and the author's chosen display label.

Special category data within the meaning of Article 9 of the GDPR may be present in any of the above, because organisations attach correspondence about human resources matters, health, incidents and legal disputes to Confluence pages. The App applies no classification, redaction or filtering, and this Addendum does not suggest otherwise.

Data subjects are the senders, the recipients and any other individual referred to in an email file that the Customer's own users attach to a Confluence page, together with those users themselves.

6. Instructions

Structurally satisfied. No instruction channel exists or is needed. The App has no configuration by which Cloudscript could give it an instruction, no channel by which Cloudscript could receive one from the Customer, and no behaviour that responds to anything other than the actions of the Customer's own users inside the Customer's own Confluence site. Every read, every render, every download and every upload happens because a user of the Customer's site clicked something, under that user's own Confluence permissions. Cloudscript cannot cause the App to process anything, and cannot cause it to stop, other than by publishing a new version of the App through the Atlassian Marketplace, which the Customer is free to decline or to uninstall.

A commitment to process only on the Customer's documented instructions would therefore describe a relationship that does not exist. The equivalent factual assurance is this: the App processes only what the Customer's own users point it at, and Cloudscript has no means of directing it otherwise.

7. Confidentiality of personnel

Structurally satisfied. No Cloudscript person can access the data. No person at Cloudscript can read an email rendered by the App, enumerate the email files held in a Customer's site, retrieve a Forge function invocation payload, enable logging of one, or obtain any of the data described in this Addendum by any technical route. There is no support tooling, no impersonation facility, no administrative console and no data export path, because there is no Cloudscript-operated system holding any of it. A confidentiality undertaking binding personnel who might access personal data has nothing to bind, since no such access is possible.

The controls that do apply to Cloudscript's developer and publishing accounts, which are the accounts from which a new version of the App is built and shipped, are described in the site-wide Security Policy at https://cloudscript.io/security and summarised in Annex 2.

8. Sub-processors

The list of sub-processors is empty, and this section explains why rather than leaving that as a bare assertion.

Cloudscript engages no third party to process personal data in connection with the App. There is no hosting provider, no cloud account, no database, no content delivery network, no analytics service, no error-reporting service, no logging service and no support platform in the App's data path, because Cloudscript operates no infrastructure that this App uses. The App's Forge manifest declares no outbound destination of any kind, so there is no host whose operator could be named.

Atlassian is not Cloudscript's sub-processor for the App, and naming it as one would misdescribe the arrangement. In a conventional sub-processing chain a vendor engages its own hosting provider, pays that provider, and stands behind it contractually. Here the Customer contracts with Atlassian directly, chose Atlassian before it chose the App, and would continue to hold the same email files in the same Confluence site if the App were uninstalled today. Cloudscript engages nobody, pays nobody for the hosting of any of this data, and holds no contractual lever over Atlassian in respect of it. Atlassian's role here is that of the Customer's own existing platform provider, governed by the Customer's own agreement with Atlassian, not by anything Cloudscript has put in place.

If Cloudscript ever introduces a destination outside the Atlassian platform for this App, that change would require an addition to the App's Forge manifest and the release of a new App version. Cloudscript will update this Addendum to name the recipient and its role before any such version is released.

9. Data location and residency

Cloudscript holds no data in any location, so it has no processing location to disclose and no residency option to offer, support or vary. The email files, the macro's attachment reference and any file uploaded through the macro all reside in the Customer's own Confluence site, and their location follows the Customer's existing data-residency arrangement with Atlassian rather than anything Cloudscript provides.

What can be stated precisely about the route is this: attachment bytes travel from Confluence's own attachment storage, through Atlassian-operated platform machinery, into the viewing user's browser, and are written to no store at any point on that route. No hop on it is Cloudscript's. This Addendum does not claim that email content "never leaves the browser" or that the App "never transmits email content", because the bytes do travel to the browser and both statements would be false.

The data-residency position recorded for the App on the Atlassian Marketplace is that residency is not applicable, because the App does not store End-User Data. Atlassian's vendor console offers no residency setting for the App, and Cloudscript accordingly has none to configure, support or vary on the Customer's behalf.

10. International transfers

Cloudscript does not receive, host or transfer personal data in any country in connection with the App, so it effects no restricted transfer out of the European Economic Area, the United Kingdom or any other jurisdiction. Where the Customer's Confluence site sits, and from where the Customer's users read it, are arrangements between the Customer and Atlassian.

This position is recorded as contestable rather than presented as settled. A reviewer who took the view that the Forge export function's receipt of a stored file name amounts to a transfer to Cloudscript would find no Standard Contractual Clauses in place as a fallback, because none have been entered into. Cloudscript's position is that no transfer occurs and that no transfer mechanism is therefore engaged. A customer whose own assessment differs should raise it at support@cloudscript.io before installing the App.

11. Security measures

Cloudscript operates no store and no transmission path of its own for this App, so the security measures that exist are measures in the App's own code and in the way it is built and published, rather than measures protecting a Cloudscript-held copy of the Customer's data. They are set out in Annex 2. The encryption, access control, resilience and physical security of the systems the data actually sits on are Atlassian's, under the Customer's own agreement with Atlassian, and Cloudscript makes no representation about them.

12. Personal data breach

Inapplicable as an obligation on Cloudscript, with a real commitment in its place. A notification obligation of the shape Article 28(3)(f) contemplates assumes the supplier holds data that could be breached and has visibility that could generate a notification. Cloudscript holds none of the Customer's data and has no logs, telemetry or monitoring of any Customer's installation, so it could not detect a breach of the Customer's data, and a promise to notify the Customer within any period would be a promise it has no mechanism to keep.

What Cloudscript can and does commit to is the handling of vulnerabilities in the App itself. Suspected vulnerabilities can be reported to security@cloudscript.io, and are handled through the disclosure and remediation process described in the site-wide Security Policy at https://cloudscript.io/security. Where Cloudscript becomes aware of a vulnerability in the App that could have exposed Customer data, it will publish a fix and describe the issue in the App's release notes.

A breach of the Customer's Confluence site, its attachments or its user accounts is a matter between the Customer and Atlassian, and the Customer's own notification obligations under the GDPR, the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth), or any other applicable regime are unaffected by this Addendum.

13. Assistance with data subject requests

Structurally satisfied. Cloudscript holds nothing to search, and the Customer already holds everything. Cloudscript cannot locate a data subject's personal data in connection with the App, because it holds none. The Customer, by contrast, can locate every byte of it, in its own Confluence site, using its own search and administration tools, without Cloudscript's involvement and without the App being installed. An assistance commitment would add nothing the Customer does not already have and could not be performed.

A request to access, correct, delete or export the personal data inside an email file rendered by the App should therefore be directed to the organisation that operates the Confluence site, which holds that content. Cloudscript will respond to questions from a customer about how the App handles data, and about what it does and does not touch, at support@cloudscript.io. The only personal data Cloudscript itself holds in connection with the App is the correspondence a customer sends to that address, which is covered by the Privacy Policy.

14. Deletion and return of data

Structurally satisfied. There is nothing for Cloudscript to delete or to return. Cloudscript holds no copy of any email file, any rendered email, any attachment reference or any other Customer data, at any point, so no deletion or return obligation can attach to it on expiry or termination. The App's manifest declares no Forge storage entitlement and its source contains no call to any Forge storage API, a position asserted by the App's own automated test suite on every build.

The two durable things the App causes to exist both belong to the Customer and stay with the Customer. The macro's attachment reference (the attachment identifier, the attachment file name, and the display label) is held as part of the Customer's own Confluence page content. Any email file uploaded through the macro is an ordinary Confluence page attachment. Both are the Customer's, in the Customer's own site, and both are unaffected by whether the App is installed.

Neither artefact is subject to a retention or deletion period set by the App, because the App sets none. It declares no Forge storage module and implements no uninstall lifecycle hook, so there is no app-operated store and no app-side step for a deletion or return obligation to act on, at uninstall or at any other time. Both follow Confluence's own attachment and page lifecycle rather than any lifecycle the App imposes, and the App neither controls nor varies that lifecycle. No deletion-or-return obligation can therefore attach to Cloudscript in respect of them, and none is promised in this Addendum.

15. Audit and information

Cloudscript operates no system that processes Customer personal data, so there is no facility, data centre, network or administrative environment for a customer to inspect. An audit right of the conventional shape would point at nothing, and stating one without qualification would suggest an infrastructure that does not exist. What can be examined is the App itself and the statements made about it in this Addendum, and the route to that is information first.

What Cloudscript will provide, on request to support@cloudscript.io, is information sufficient for a customer to verify the statements in this Addendum for itself:

• the Forge scopes the App declares, which the Customer's own Confluence administrator can also read on the App's installation and consent screens;
• confirmation that the App's manifest declares no outbound network destination, which a customer can corroborate independently by capturing the network activity of a page carrying the macro; and
• written answers to a security questionnaire or vendor-assessment form, subject to Cloudscript's capacity as a small vendor, together with the site-wide Security Policy at https://cloudscript.io/security.

Where that information does not answer a customer's reasonable concern, Cloudscript will contribute to an audit or inspection conducted by the Customer or an auditor it mandates, on reasonable written notice, no more than once a year unless a personal data breach affecting the Customer or a documented compliance failure gives cause for another, and subject to confidentiality. The audit reaches what there is to examine: the App's manifest and declared scopes, and the statements made in this Addendum. It does not reach a facility, data centre, network or administrative environment, because Cloudscript operates none for the App.

The Customer bears the full costs of any audit or inspection, including the annual one: its own costs, its auditor's costs, and Cloudscript's reasonable costs of contributing, at a reasonable rate agreed in writing before the audit begins. The one exception is this: where the audit follows a personal data breach caused by Cloudscript, or finds material non-compliance by Cloudscript with this Addendum, Cloudscript bears its own costs of contributing.

This provision is offered on the same basis as the rest of this Addendum, which is a commercial election rather than an admission. It is not an acknowledgement that Cloudscript is a processor, and it grants no right to inspect infrastructure that does not exist.

16. Liability and governing law

Liability under this Addendum is subject to the limitations and exclusions in the Terms of Use. This Addendum creates no separate or additional liability. Liability in connection with this Addendum is governed by the limitation provisions of the Standard Agreement and of the Provider-Specific Terms that supplement it, which are those Terms of Use, including the Standard Agreement's Enhanced Claims provisions where those provisions apply to a claim.

This Addendum is governed by the laws of New South Wales (NSW), Australia, following the governing-law position stated in the Terms of Use, and the courts of New South Wales have exclusive jurisdiction over any action arising out of or relating to it.

Annex 1: Description of the processing

Item	Position for MSG/EML Email Viewer for Confluence
Subject matter	Display of .msg and .eml files attached to the Customer's own Confluence pages, and author-initiated upload of such a file as a page attachment.
Duration	Per render, for the duration of a render. No processing between renders. Governed by the Customer's own page and attachment lifecycle.
Nature and purpose	Read, parse, sanitise, render, download on request, write a three-key macro configuration, and create an uploaded file as a page attachment. See section 4.
Categories of personal data	Email header data, body content, attachment data, and the attachment reference. Special category data may be present. See section 5.
Categories of data subjects	Senders, recipients and other individuals named in an attached email file, and the Customer's own Confluence users.
Data held by Cloudscript	None, at any point, other than support correspondence sent to Cloudscript directly.
Sub-processors	None. See section 8 for why the list is empty and why Atlassian is not one.
Processing locations	The Customer's own Confluence site and the viewing user's own browser. No Cloudscript location exists. See section 9, including the open item on the platform-internal hop and the Forge function execution region.
Transfers	None effected by Cloudscript. No Standard Contractual Clauses are in place, because none are engaged. See section 10.
Deletion on termination	Nothing held, so nothing to delete or return. The macro's attachment reference and any file uploaded through the macro are the Customer's own Confluence content and follow Confluence's own lifecycle, not one the App imposes. See section 14.

Annex 2: Technical and organisational measures

The measures below are the measures that actually exist. Each is a property of the App's code, its manifest, or the way it is built and published. Cloudscript makes no representation about the security of Atlassian's platform or of the Customer's Confluence site, both of which sit outside its control and are governed by the Customer's own agreement with Atlassian.

Architecture

• No Cloudscript-operated store or destination. The App's Forge manifest declares no storage entitlement and no outbound network destination, and the shipped source contains no storage call and no direct network call. An automated end-to-end scenario asserts that no request reaches a non-Atlassian host during a render, and a second asserts that no email content reaches any Forge storage API. Both run against staging on every release.
• Least privilege on scopes. The App declares exactly two Forge scopes, read:attachment:confluence and write:confluence-file. A test in the App's own suite pins that allowlist exactly, so adding a scope fails the build rather than passing unnoticed.
• Permission inheritance as the security boundary. Every read travels the acting user's own Confluence permissions, so what a given viewer can see is decided by Confluence rather than by the App. The App adds no access control of its own and bypasses none.

Handling of untrusted content

• Sanitisation before render. Email HTML is sanitised before it is drawn into the page.
• Remote content blocked by default. Content an email references from a remote host is blocked when the card is drawn. The viewing user can choose to load it for that render.
• Parse containment. Parsing runs in a Web Worker under a 15,000 millisecond deadline, so a malformed or hostile file yields an error card rather than an unresponsive page. One residual is accepted and recorded rather than claimed as closed: a memory-starved client can still exhaust the shared renderer process before the deadline expires, a limitation upstream of this App in the parsing library it uses.
• Size bound before retrieval. A 50 MiB (52,428,800 byte) cap is applied from the attachment listing's own metadata before any bytes are retrieved, with a second check on the bytes in hand as the authoritative backstop.
• Attachments are never opened. The email's own attachments, including any nested or embedded message, are listed and can be downloaded to the user's device, and are never rendered, executed or recursed into.
• Honest degradation. Where a file cannot be read or rendered, the App shows a card naming what happened, drawn from a frozen taxonomy of 27 states, rather than rendering a partial or misleading result.

Vendor and account controls

• Vulnerability reporting and handling. Reports to security@cloudscript.io, handled per the site-wide Security Policy at https://cloudscript.io/security.
• Release process. Each release is deployed to a staging site and exercised by an automated end-to-end suite before it is promoted to production.
• Account security. The accounts used to develop and publish the App, being the Atlassian developer and Marketplace account and the source-control repository from which the App is built and shipped, are protected by multi-factor authentication, and access to them is limited to the two people who operate Cloudscript. This is the account-control position stated in the site-wide Security Policy at https://cloudscript.io/security, which governs if the two ever diverge.

Contact

Cloudscript Pty Ltd (ABN 14 700 662 362)
Support: support@cloudscript.io
Security: security@cloudscript.io
App page: https://cloudscript.io/apps/email-viewer

This Addendum is published at https://cloudscript.io/apps/email-viewer/dpa. It is read with the Terms of Use and the Privacy Policy.