Policy

Data Processing Addendum

Between the Atlassian customer that installs the Apps ("Customer", the controller) and Stanki Guild sp. z o.o. ("Processor", "we").

Applies to: Approval Flow for Jira and Attestation Flow for Confluence (the "Apps").

Effective date: 12 October 2026 · Version: 1.0

This Addendum forms part of the Atlassian Marketplace standard End User Licence Agreement selected on the app's Marketplace listing (the "Agreement") between the parties and applies whenever we process personal data on the Customer's behalf in connection with the Apps. It is written to satisfy Article 28(3) GDPR and, where applicable, the UK GDPR.

It is offered as a standing, pre-signed addendum: by installing and using the Apps under the Agreement, the Customer accepts it, and no counter-signature is required. If the Customer's procurement process requires a signed copy, or requires its own paper, contact privacy@stankiguild.com.

Where this Addendum conflicts with the Agreement on the subject of personal-data processing, this Addendum prevails.

Terms used here (personal data, processing, controller, processor, sub-processor, data subject, personal data breach, supervisory authority) have the meanings given in the GDPR.

The Customer is the controller and Stanki Guild sp. z o.o. is the processor for all personal data processed by the Apps. The Customer determines the purposes and means: which work items and pages carry an approval requirement or an acknowledgement policy, who is named on them, and how long the records are kept.

Where the Customer is itself a processor for a third-party controller, this Addendum is entered into on that controller's behalf, and references to the Customer's instructions include the instructions the Customer has received.

We act as an independent controller only for support correspondence the Customer sends us and for the licence and contact details Atlassian gives us for each licence (company, country and region, site hostname and cloud ID, and the name, email address, phone number and postal address of the technical and billing contacts), as described in the Privacy Policy §6. That is outside the scope of this Addendum.

Atlassian is not our sub-processor. Atlassian is the Customer's own provider, processing the Customer's data under the Customer's separate agreement with Atlassian, on infrastructure the Customer already selected. See §7.

Subject matter: the provision of the Apps as Atlassian Forge apps installed on the Customer's Atlassian Cloud site.

Nature of the processing: storage, retrieval, structuring, display and deletion of records created by the Customer's own users inside the Customer's Atlassian site, using Atlassian's hosted compute and storage. No processing takes place on any system operated by us.

Purpose:

Processing continues for as long as the App is installed on the Customer's site. It ends on uninstall, subject to the deletion terms in §10.

• The Customer's employees, contractors and other authorised users of its Atlassian site who interact with an App: as an author of a policy, as a named or eligible approver, as a required reader, or as a person who signs off, rejects or acknowledges something.
• Any individual whose personal data the Customer's users choose to type into free-text fields inside an App.

Processed by both Apps:

• Atlassian account IDs: the opaque identifier Atlassian assigns to a user.
• Timestamps of user actions.
• Free text entered by the Customer's users (approval requirement text, mandatory rejection reasons, template names). We do not request personal data in these fields; any that appears is at the Customer's discretion.

Additionally:

• Display names. Attestation Flow stores the acknowledging user's display name as a snapshot inside each acknowledgement receipt, so that the compliance record remains legible if the person is later renamed or deactivated. Approval Flow resolves display names at render time only and does not store them.
• Group and project-role identifiers naming required readers or eligible approvers (Approval Flow, Attestation Flow).
• Delegation records (Approval Flow): the account ID of a delegator, the account ID of their out-of-office substitute, and the validity window.
• Jira issue keys and Confluence page IDs and version numbers, as the objects the records attach to.

Not processed by any App: email addresses; passwords, API tokens or any other credential; special categories of personal data under Article 9 GDPR (not by design and not requested: the Customer must not use free-text fields for them); criminal-conviction data under Article 10; payment data; location data; device identifiers; cookies or tracking identifiers.

Not read at all: the body of a Confluence page, and the description or comments of a Jira issue. No App holds a scope that would allow it.

An exact, per-record enumeration is published in the Privacy Policy §5 and forms part of this Addendum by reference.

We will:

1. Process only on documented instructions from the Customer, including as to transfers. The Customer's instructions are: this Addendum, the Agreement, the documented functionality of the Apps, and the configuration the Customer makes inside them. We will not process the personal data for any purpose of our own, in particular not for analytics, profiling, product research, advertising or the training of machine-learning models.
2. Tell the Customer if an instruction appears to infringe the GDPR or other applicable data-protection law, and may suspend that processing until it is resolved (Article 28(3), final paragraph).
3. Bind everyone we authorise to process the personal data to confidentiality, whether by contract or statutory duty, and limit access to those who need it. In practice our personnel have no technical access to the Customer's data at all (§9).
4. Implement appropriate technical and organisational measures under Article 32, as described in §9.
5. Not engage a sub-processor except as provided in §7.
6. Assist the Customer as described in §11 and §12.
7. Delete the personal data on termination as described in §10.
8. Make available the information needed to demonstrate compliance with Article 28, and submit to audits, as described in §13.
9. Maintain a record of processing carried out on behalf of the Customer, as required by Article 30(2), and make it available to a supervisory authority on request.

We engage no sub-processors for the Apps. There is no analytics provider, no error-tracking provider, no hosting provider, no CDN, no email platform and no outsourced support in the processing chain.

This is architectural, not merely contractual. The Apps declare no external permissions, no Forge remotes and no web triggers; they have no outbound network path, so there is no third party to which data could flow. The Forge platform enforces this.

Atlassian is not our sub-processor. All compute and storage used by the Apps is Atlassian's, on the Customer's own Atlassian Cloud site, under the Customer's own agreement with Atlassian. Atlassian processes that data for the Customer, not for us; we do not appoint Atlassian, cannot instruct it, and have no contract with it covering the Customer's data. Treating Atlassian as our sub-processor would misdescribe the relationship. Customers who need Atlassian named in their own records should do so as their provider, and refer to Atlassian's own data-processing terms.

If this changes. The Customer gives general written authorisation for future sub-processors under Article 28(2), subject to: we will publish the intended sub-processor in the Privacy Policy and give the Customer at least 30 days' notice before that sub-processor begins processing; the Customer may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Customer may terminate the affected App without penalty. Any sub-processor we engage will be bound by data-protection obligations no less protective than these, and we remain fully liable for its performance.

The Apps store and process personal data exclusively within Atlassian's platform for the Customer's own site. No transfer of personal data to a third country or international organisation takes place as a result of our processing, and accordingly no transfer mechanism (Standard Contractual Clauses, adequacy decision or derogation) is required or invoked.

Any cross-border processing within Atlassian's platform is governed by the Customer's agreement with Atlassian and by the data-residency configuration the Customer has chosen there. Because all in-scope data is held in persistent Forge hosted storage, the Apps inherit that configuration automatically.

We are established in Poland, within the EEA. If we ever introduce processing outside the EEA, §7 applies and appropriate safeguards under Chapter V GDPR will be put in place before it begins.

The measures applying to this processing are set out in full in our Security Policy, which forms Annex II to this Addendum. In summary:

The Customer acknowledges that these measures are appropriate to the risk given the nature of the data (identifiers and timestamps, no special categories, no credentials) and the architecture (no infrastructure operated by the processor).

What we do not have (no ISO 27001, no SOC 2, no CSA STAR, no independent penetration test, no bug bounty) is stated plainly in the Security Policy §11 and is not to be inferred from this Addendum.

On uninstall, each App's Forge preUninstall handler runs a clean-up that deletes that App's stored data:

• Approval Flow: all approval records including sign-off and rejection receipts, all policy templates, all delegation records, the auto-apply map and the app settings.
• Attestation Flow: all acknowledgement receipts (every page and every version), all page policies, all space defaults, the reminder digest and the policy index.

Platform window. Independently of our purge, Atlassian's platform retains Forge hosted storage data for 28 days after uninstallation, per the Forge storage reference: "Forge hosted storage retains data for 28 days after uninstallation. However, when a customer reinstalls an app that uses Forge hosted storage, data from the previous installation is not automatically restored." (https://developer.atlassian.com/platform/forge/storage-reference/). If the clean-up cannot finish, the remaining data is held only in that Atlassian retention window. We do not control that window, cannot shorten it and cannot read data within it. With the Customer's consent, Atlassian can re-link an earlier installation's data to a reinstalled App if we ask within 21 days of uninstallation; because the clean-up deletes the App's data at uninstall, the Customer should treat the deletion as final.

Return of data. Because the data resides on the Customer's own Atlassian site throughout, there is nothing for us to return: the Customer has continuous possession of it. With a paid licence, each App offers a CSV export (Attestation Flow: the compliance report and the per-user record; Approval Flow: the Approval health view, up to 200 work items per view). Without a paid licence, records can be read in the App but not exported. On request made before uninstall, we will explain how to export a given record set.

We keep no copies. We hold no backup, archive or replica of Customer personal data. Where we are required by Union or Member State law to retain something, we will tell the Customer, retain only what the law requires, and continue to protect it.

The Apps give the Customer, as controller, in-product access to the records: the Customer can read them, can change or remove approval records (with their receipts), delegations and templates, and can deactivate page policies, at any time, without our involvement. In Attestation Flow, acknowledgement receipts are a write-once compliance record: they are never modified, and there is currently no in-app action that erases one person's receipts. Full removal means uninstalling the App, which deletes all of its data (§10). Where applicable, the Customer may rely on Article 17(3) GDPR. For assistance with such a request, contact privacy@stankiguild.com.

We will not act on a data subject's request ourselves. If a data subject contacts us directly, we will not respond substantively, will tell them to contact the Customer, and will notify the Customer without undue delay where we can identify them.

Taking into account the nature of the processing, we will assist the Customer by appropriate technical and organisational measures: in practice, by identifying precisely which records relate to a given account ID and which in-product action satisfies the request (Article 28(3)(e)). Requests: privacy@stankiguild.com.

We will assist the Customer, taking into account the nature of the processing and the information available to us, with:

• Security of processing (Article 32): by maintaining and publishing the measures in §9.
• Breach notification (Articles 33-34): see below.
• Data protection impact assessments and prior consultation (Articles 35-36): by providing the architecture, data-flow and retention information the Customer needs. The Privacy Policy and Security Policy are written to be usable as DPIA source material; we will answer specific questions at privacy@stankiguild.com.

Personal data breach. We will notify the Customer without undue delay after becoming aware of a personal data breach affecting personal data processed under this Addendum, and in any event promptly enough for the Customer to meet its own 72-hour obligation under Article 33(1). The notification 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, and a contact point (to the extent known, with further information supplied as it becomes available rather than withheld until the picture is complete). We will not notify a supervisory authority or data subjects on the Customer's behalf unless the Customer instructs us to.

Report or enquire about a suspected breach: security@stankiguild.com.

We will make available to the Customer all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates (Article 28(3)(h)).

In practice:

1. First, documentation. We will answer reasonable written security and privacy questionnaires (including the Customer's own) within 20 business days, and provide our current dependency-audit and test evidence on request. For most customers this is sufficient, because we operate no infrastructure to inspect.
2. Then, if that is not sufficient, an audit or inspection may be conducted on 30 days' written notice, no more than once in any 12-month period (unless required by a supervisory authority or following a personal data breach), during business hours, subject to confidentiality, and in a manner that does not disrupt our operations or the confidentiality of other customers' data.
3. Scope limit. An audit can cover only our own processing and our own systems. The Atlassian platform is outside our control and cannot be audited through us; the Customer should exercise its rights against Atlassian directly under its own agreement.
4. Cost. We bear the cost of responding under (1). A Customer-initiated on-site audit under (2) is at the Customer's expense, save where the audit reveals a material breach of this Addendum by us, in which case we bear our own reasonable costs.

Liability under this Addendum is governed by, and subject to, the limitations and exclusions of liability in the Agreement, namely the Atlassian Marketplace standard End User Licence Agreement selected on the app's Marketplace listing. This Addendum does not create any separate or additional liability cap.

Nothing in this Addendum limits or excludes any liability that cannot be limited or excluded under applicable law, including a data subject's rights under Article 82 GDPR or the powers of a supervisory authority.

This Addendum is governed by the laws of Poland, and the parties submit to the courts specified in the Agreement, without prejudice to any mandatory right of a data subject or supervisory authority to proceed elsewhere.

We may update this Addendum where required by law, by a change to the Apps, or to improve clarity. Material changes are announced at least 30 days in advance through the Marketplace listing and the published version of this document. The version and date at the top identify the current text; superseded versions are available from privacy@stankiguild.com.

Stanki Guild sp. z o.o. ul. Adama Mickiewicza 13/4, 82-300 Elbląg, Poland · KRS 0001264778 · NIP 5783187890

Signed for and on behalf of Stanki Guild sp. z o.o.: Bartosz Stankiewicz, President of the Management Board (Prezes Zarządu), 12 October 2026

Annex I: Details of processing

Sections 2 (subject matter, nature, purpose), 3 (duration), 4 (categories of data subjects) and 5 (categories of personal data) of this Addendum constitute Annex I, together with Privacy Policy §5, which enumerates every stored record per App.

Annex II: Technical and organisational measures

Section 9 of this Addendum and the Security Policy constitute Annex II.

Annex III: Sub-processors

None. See §7.