Policy
Privacy Policy
Applies to: Approval Flow for Jira and Attestation Flow for Confluence, the Atlassian Forge apps published by Stanki Guild sp. z o.o., and the website stankiguild.com (see §14).
Effective date: 12 October 2026 · Last updated: 12 October 2026
1. Who we are
#Stanki Guild sp. z o.o., a company registered in Poland, registered office at ul. Adama Mickiewicza 13/4, 82-300 Elbląg, Poland, KRS 0001264778, NIP 5783187890 ("we", "us").
- General and privacy enquiries: privacy@stankiguild.com
- Support: support@stankiguild.com
- Security: security@stankiguild.com (see our Security Policy)
We have not appointed a statutory Data Protection Officer under Article 37 GDPR, because our processing does not meet the criteria that require one. privacy@stankiguild.com is our designated data-protection contact and is monitored.
2. The one thing that matters most: our apps run entirely inside Atlassian
#Both apps are Forge apps built to meet the criteria of Atlassian's Runs on Atlassian programme. In practice this means:
- We operate no servers, no databases, no hosting and no infrastructure of our own for these apps. All compute and all storage are Atlassian's.
- The apps declare no external permissions (
permissions.external), no Forge remotes, and no web triggers. There is no network path out of the Atlassian platform, and the Forge platform enforces this: it is not a promise about our intentions, it is a property of the deployed manifest. - Consequently there is no analytics, no telemetry, no error-reporting service, no CDN, no marketing pixel and no third-party API in either app.
- We cannot read your data. We have no access to your content, no export of it and no back door into your site. We hold no copy of your instance's data. The only way we ever see any content from your site is if you send it to us yourself in a support request.
Two direct consequences for privacy law:
- No international transfer of your data takes place because of our apps. Your data stays where Atlassian keeps it, under Atlassian's own data-residency arrangements for your site. We never move it.
- We use no sub-processors. See §7.
3. Our role: processor, not controller
#For everything the apps store on your Atlassian site, you (the Atlassian customer) are the controller and we are the processor within the meaning of Article 4 GDPR. You decide which pages and work items get an approval requirement or an acknowledgement policy, and who is named on them. We only process that data to make the app work for you, on your instructions, which are given through the app's own configuration and use.
We do not sell personal data, do not share it with anyone, and do not use it for advertising, profiling, model training or any purpose of our own.
Lawful basis. As a processor we do not establish the lawful basis for processing your end users' personal data: you do, as the controller. Our processing is governed by Article 28 GDPR and by our Data Processing Addendum, which forms our documented instructions. In a normal B2B deployment the controller's basis will be its legitimate interest in operating and auditing its own work processes, or its compliance with a legal obligation where the app is used for regulatory sign-off or policy attestation, but that determination is yours.
We act as an independent controller only for the limited data described in §6 (support correspondence, and the licence contact details Atlassian gives us) and §14 (this website).
4. Where the data lives, and what "storage" means here
#The apps store data exclusively in Forge hosted storage (the Forge Key-Value Store, KVS), Atlassian's own storage service, inside the Atlassian platform, scoped to your app installation on your site.
Because all in-scope end-user data is held in persistent Forge hosted storage, the apps inherit Atlassian's data-residency behaviour for your site automatically ("PINNED"), with no configuration by you or by us.
5. What each app processes, and why
#Across both apps, the personal data actually involved is narrow:
- Atlassian account IDs: the opaque identifier Atlassian assigns to a user. This is how the apps record who did what.
- Display names: only as described below, and only where a name has to be shown to a human reading a compliance record.
- Timestamps of user actions.
- Free text that your users type: approval requirement text, rejection reasons and policy template names (Approval Flow); notes on page requirements and space defaults (Attestation Flow). We do not ask for personal data there; whether any appears is entirely under your control.
The apps never process email addresses, passwords, API tokens or any other credential. They never read the body of a Confluence page or the description or comments of a Jira issue.
5.1 Approval Flow for Jira
Scopes: storage:app, read:jira-work, read:jira-user.
Stored in Forge hosted storage:
| Record | Contents |
|---|---|
Approval requirements per work item (ap:<issueKey>) | Requirement text, quorum, the account ID of the person who added the requirement (createdBy) and when (createdAt), the account IDs of named approvers, approver groups and project roles (each stored as { id, name }), plus: sign-off receipts { account ID of the signer, ISO timestamp } and, where a delegation applies, the account ID of the person the sign-off is credited to (onBehalfOf); rejection receipts { account ID, ISO timestamp, the mandatory reason text }, and who cleared a rejection and when (clearedBy, clearedAt). Where the signer was eligible through a group or a project role rather than by name, the receipt also records that source (via, for example group:<name>). |
Approval policy templates (tpl:<id>, tpl:index) | Template name and, for each requirement, its text, Required flag and quorum. No account IDs. |
Out-of-office delegations (dlg:<accountId>) | The delegating user's account ID (as the key), the substitute's account ID, and the validity window. |
App settings and auto-apply map (settings:app, autoapply:index) | Whether configuration is locked to project admins, a staleness threshold, and issue-type → policy mappings. No personal data. |
Read but never stored: the work item's key, summary and issue type; the current user's group memberships and project-role membership (to decide whether they are an eligible approver); the result of a Jira permission check; and approver display names, resolved at render time so the audit trail reads as names rather than IDs.
Why: to record who is required to approve what, to capture an auditable sign-off with separation of duties and quorum, and to block a workflow transition until sign-off is complete.
5.2 Attestation Flow for Confluence
Scopes: storage:app, read:confluence-user, read:confluence-content.summary, read:page:confluence, read:confluence-groups.
Stored in Forge hosted storage:
| Record | Contents |
|---|---|
Acknowledgement receipts (ack:<pageId>:<version>:<accountId>, plus renewal receipts) | { account ID, page ID, page version number, timestamp, display name }. The display name is a deliberate snapshot taken at the moment of acknowledgement and stored with the receipt, so that a compliance record remains legible years later even if the person is renamed or deactivated. It is empty when the name could not be resolved. Receipts are written once and never modified: immutability is the point of the record. |
Page policies (pol:<pageId>) | The account IDs of required readers, the group IDs of required reader groups, an optional due date, an optional re-attestation interval, an optional note typed by the author, whether the policy is active, the account ID of the person who created it (createdBy) and of the person who last changed it (updatedBy) with the time of that change (updatedTs), and the last page version the app observed. |
Policy index (polidx) | Page IDs and space IDs that carry a policy. No personal data. |
Space defaults (tpl:<spaceId>) | A space's default policy: required readers and groups, due date, re-attestation interval, note, createdBy, updatedBy and updatedTs, as above. |
Latest reminder digest (digest:latest) | Per page: the page ID and the account IDs of readers still outstanding, plus counts. Overwritten on each scheduled run. |
Read but never stored: a page's title, current version number and space ID (via Confluence's v2 pages endpoint); the list of pages carrying a given label, for the bulk "apply this policy to every labelled page" action; the current members of a required group, expanded live at the moment a report is computed and never cached; and display names for the auditor-facing dashboard and report.
The body of a page is never requested, never stored and never transmitted. The app reads page metadata only.
Why: to record that a named person confirmed they read a specific version of a specific page, to re-arm that requirement when the page is edited, and to show an auditor what is outstanding.
6. Data we handle as controller: support correspondence and licence contacts
#When you contact us at support@stankiguild.com, security@stankiguild.com or privacy@stankiguild.com, we process your name, your email address, and whatever you choose to put in the ticket, including any screenshots or logs you attach. Here we are the controller. Our lawful basis is our legitimate interest (Article 6(1)(f) GDPR) in supporting our customers, and where you are contracting with us, performance of that contract (Article 6(1)(b)).
Please do not send us production data, personal data or credentials in a support ticket unless we have specifically asked for a redacted sample and you have confirmed you may share it. See Support for what to include instead.
We keep support correspondence for as long as the ticket is open and for 24 months afterwards, so we can recognise a recurring fault, then delete it.
Outgoing support email. Our replies are sent through Resend (Plus Five Five, Inc., United States), using its EU sending region (eu-west-1, Ireland). Resend therefore receives the recipient's email address and the content of the reply, and processes them for us under Resend's Data Processing Addendum, which incorporates the EU Standard Contractual Clauses. Incoming email to our addresses is received on a server we operate in Poland.
Licence and contact details from Atlassian. Your commercial relationship for a paid app is with Atlassian, which is the merchant of record and processes your payment. For each licence of our apps, the Atlassian Marketplace reporting service gives us: the licensee's company name, country and region, the hostname and cloud ID of the site, and the name, email address, phone number and postal address of the technical contact and of the billing contact. We receive this data from Atlassian, not from you (Article 14 GDPR). We use it to administer licences, to provide support and to send service notices about our apps, on the basis of our legitimate interest (Article 6(1)(f) GDPR) in running and supporting the apps we sell. We keep it for the life of the licence and for 24 months after it ends, then delete it. Atlassian's own handling of this data is governed by Atlassian's privacy policy.
7. Sub-processors: none
#We engage no sub-processors for these apps. There is no analytics provider, no error-tracking provider, no hosting provider, no CDN, no email-marketing platform and no offshore support desk in the path of your data.
This is a direct consequence of the architecture described in §2: the apps have no way to send data anywhere, so there is nobody to send it to. Atlassian itself is not our sub-processor: Atlassian is your own provider, processing your data under your existing agreement with Atlassian, on infrastructure you already chose. We are a tenant of that platform in the same sense that the app is.
If this ever changes, we will publish the new sub-processor here and give you at least 30 days' notice before it starts processing, so you can object as provided in our DPA.
8. International transfers: none caused by us
#Because the apps store and process data exclusively within Atlassian's platform for your own site, our apps cause no transfer of personal data to a third country. There is no transfer mechanism to disclose (no Standard Contractual Clauses, no adequacy decision, no derogation) because there is no transfer.
Any cross-border processing that occurs within Atlassian's platform is governed by your agreement with Atlassian and by the data-residency settings you have chosen there.
Support correspondence (§6) is stored by us in Poland, within the EEA. Our outgoing support replies are sent through Resend, a United States company (see §6); that transfer is made under Resend's Data Processing Addendum (Standard Contractual Clauses).
9. Retention and deletion
#While the app is installed. Records are kept for as long as the underlying object exists and you keep them:
- Approval Flow: sign-off and rejection receipts are retained as the audit trail (that is their purpose) until the record is deleted in the app.
- Attestation Flow: acknowledgement receipts are retained as compliance history, including receipts for older page versions, and are deliberately not deleted when a page is edited or a policy changes; the reminder digest is overwritten on each run.
On uninstall. Each app registers a Forge preUninstall handler that runs a clean-up on uninstall and deletes the app's stored data:
- Approval Flow deletes every approval record (
ap:), every policy template (tpl:), every delegation (dlg:), the auto-apply map and the app settings. - Attestation Flow deletes every acknowledgement receipt (
ack:), every page policy (pol:), every space default (tpl:), the reminder digest (digest:) and the policy index.
The platform window. Independently of our purge, Atlassian's platform behaviour is, quoting 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. To recover this data for a customer, app developers must: Get customer consent to restore data. Submit a recovery request within 21 days of uninstallation."
(https://developer.atlassian.com/platform/forge/storage-reference/)
So the honest statement is: each app deletes its own stored data when it is uninstalled. If the clean-up cannot finish, the remaining data is held only in Atlassian's 28-day retention window. We have no control over that window and cannot read data in it. With your 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, treat the deletion as final and export what you need first (paid edition).
Deletion on request. You can delete approval records, delegations and templates from within the app at any time, and deactivate a page policy; acknowledgement receipts are never modified once written and are removed on uninstall. Uninstalling removes everything. If you need a deletion we cannot perform from our side (we generally cannot, because we have no access), tell us at privacy@stankiguild.com and we will tell you exactly which in-app action achieves it.
10. Requests from individuals (data-subject rights)
#If you are an end user of one of our apps at your employer or another organisation, that organisation is the controller of your data, not us. Please direct any request to exercise your rights under Articles 15-22 GDPR (access, rectification, erasure, restriction, portability, objection) to them. In Approval Flow they can delete a requirement, with its receipts, inside the app. In Attestation Flow, acknowledgement receipts are a write-once compliance record, 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. Where it applies, the controller may rely on Article 17(3) GDPR. Controllers who need help with such a request can contact privacy@stankiguild.com.
If you contact us instead, we will not act on the request ourselves. We will tell you so, and, where we can identify the customer, forward the request to them without undue delay. This is not evasion: acting on your data without the controller's instruction would itself be a breach of Article 29.
For data we hold as controller (§6, support correspondence), contact privacy@stankiguild.com and we will respond within one month.
You always have the right to lodge a complaint with a supervisory authority. In Poland this is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, https://uodo.gov.pl); you may also complain to the authority where you live or work.
11. Security
#Summarised: the apps run inside Atlassian's Forge sandbox with no egress; user identity is always taken from the trusted Forge context and never from anything the browser sends; and every record the apps write is scoped to your own installation. The full statement (including how we handle vulnerability reports, what our response targets are, and an explicit list of what we do not have) is in our Security Policy.
To report a security issue: security@stankiguild.com.
12. Children
#Our apps are business tools sold to organisations. They are not directed at children and we do not knowingly process the data of anyone under 16.
13. Changes to this policy
#If we change this policy we will update the date at the top and, for any change that materially affects how your data is handled, give notice through the Atlassian Marketplace listing and, where a change requires it under our DPA, at least 30 days in advance.
14. This website
#stankiguild.com is a static website. It sets no cookies, runs no analytics and loads no resources from other servers. The web server records the IP address, time, requested URL and user agent of each request in its logs, for security. The logs are rotated daily and kept for 14 days, then deleted. We are the controller of this data; our lawful basis is our legitimate interest (Article 6(1)(f) GDPR) in operating a secure website. The site is hosted on a server we operate in Poland.
15. Contact
#| Purpose | Contact |
|---|---|
| Privacy, data protection, DPA requests | privacy@stankiguild.com |
| Security vulnerabilities | security@stankiguild.com |
| Product support | support@stankiguild.com |
| Documentation | https://stankiguild.com/docs/ |
| Postal | Stanki Guild sp. z o.o., ul. Adama Mickiewicza 13/4, 82-300 Elbląg, Poland |