Data processing
Parties and scope
The provider is Timo Fitzner, individual provider established in Greece, Irinis 104, 15341 Agia Paraskevi, Greece. Privacy and security contact: tfitzner90@gmail.com, with the request portal as the intended case channel. The customer is the organisation identified in the applicable service agreement/order. The customer acts as controller or, where it processes for another controller, confirms that it has authority to appoint the provider as a sub-processor and passes down the relevant instructions. This addendum covers personal data processed on the customer’s behalf to provide Screen Self-Service for Jira and agreed technical assistance. Provider-controlled support and business correspondence is described separately in the Privacy Notice.
Instructions and responsibilities
The customer determines the purposes of its Jira administration and remains responsible for lawful instructions, appropriate notices, user authority and the information entered in free-text notes. The provider processes customer data only to operate the configured service, follow documented authorised instructions and comply with applicable legal duties. App installation, project settings and recorded actions form operational instructions within the agreed service scope. They are not permission for unrelated access, advertising, training AI models or reusing customer data for another purpose.
If an instruction appears unlawful, the provider informs the customer and pauses the affected processing where appropriate. A legally required disclosure is limited to the relevant duty; the customer is informed unless the law prohibits notice. Additional support access requires a defined site, purpose, permissions and duration. The provider has no automatic administrator access to customer Jira sites.
Processing schedule
Processing lasts for the agreed service period and the necessary return, deletion or legally required retention period. Operations include authorised configuration reads and writes, permission checks, storing change and audit records, privacy reporting, controlled history export/import and agreed support investigation.
The people concerned are authorised Jira users, administrators, reviewers, notification recipients and people identified in customer-supplied notes or support materials. Data includes account references, installation/project/issue-type/example-issue identifiers, group access settings, screen and field metadata, before/after layouts, decisions, timestamps, execution/recovery checkpoints and notification records. There is no app feature for bulk archiving issue descriptions or attachments. Customers should keep special-category data and unrelated issue content out of app notes and ordinary support cases.
Confidentiality and safeguards
Access is limited to authorised personnel who are subject to appropriate confidentiality obligations. Measures include server-side current permissions, installation-bound project setup, optional group restrictions that do not replace Jira project administrator rights, sealed plans, independent dependency checks, approval for new configuration, bounded execution, durable intent and acknowledgement records, pause controls and inspected recovery. Customer exports are encrypted in the browser using the customer’s passphrase. The provider cannot recover a forgotten passphrase.
The Security statement describes the implemented controls and limitations. The provider evaluates appropriate safeguards in light of the processing and risk. No provider ISO, SOC, independent penetration-test certification, automatic Jira rollback or unlimited capacity is asserted.
Service providers and locations
For the described beta processing, the proposed authorised infrastructure provider is Atlassian Pty Ltd, Australia: Forge hosting/storage and Jira APIs, plus Jira Service Management for support where customer data is processed on the customer's behalf. The Forge Data Processing Addendum addresses the developer/Forge relationship. The Atlassian Customer Agreement and Atlassian DPA address the provider's JSM service. The Product-Specific Terms identify the relevant contracting entity; the sub-processor list describes Atlassian's service-specific chain and locations. Processing may occur inside and outside the EEA; an EU-only location or app pinning is not promised.
Adopting this addendum grants general written authorisation for that described sub-processing, subject to the agreed service and transfer safeguards. It does not authorise unrelated services. The provider remains responsible for its appointed sub-processors' obligations for the processing covered by this addendum. The applicability of the linked platform contracts is recorded in the provider's service register; the customer's own Jira agreement remains separate.
The app uses Atlassian Forge and Jira APIs. Separately submitted support cases use the provider’s Jira Service Management service. The provider does not configure an external app backend, advertising endpoint or AI-processing endpoint. Atlassian’s role and contractual chain depend on the service the customer or provider has obtained; the appropriate agreements and applicable transfer safeguards must be recorded before customer use. This addendum does not designate every Atlassian entity as a subprocessor or adopt transfer clauses by reference alone.
Before appointing an additional provider or materially changing this provider-controlled arrangement, the provider supplies the customer with the identity, purpose, locations and safeguards at least 30 days in advance. The customer may raise a substantiated data-protection objection during that period. The provider works to resolve it before the changed processing begins; if it cannot be resolved, the affected service can end before that new processing starts. No unrelated processor or new transfer is approved by merely reading this page. A customer’s Forge region and Atlassian platform commitments do not establish a separate provider residency guarantee.
The separate documentation website uses Cloudflare for website delivery. That website traffic and provider-controlled correspondence are described in the Privacy Notice; this does not designate Cloudflare as a recipient of customer Jira workspace records.
Requests, incidents and assistance
The provider assists the customer with applicable data-subject requests, security obligations, assessments and regulator enquiries to the extent relevant to this service and the information available. Requests concerning customer workspace data are referred to the appropriate customer contact; the provider does not independently release another organisation’s records. Identity and authority are verified proportionately before disclosure or deletion.
On becoming aware of a personal-data breach affecting data processed for the customer, the provider informs the customer without undue delay and supplies known facts, likely effects, containment and contact information as they become available. The customer decides its own required authority and individual notifications; the provider cooperates and meets its own applicable duties. Ordinary support response targets do not postpone legal incident or privacy deadlines.
Return, deletion and separate copies
At the customer's choice, the provider assists with return or deletion of personal data processed on the customer's behalf at service end, unless retention is required by applicable law. The customer can export a compatible encrypted history file before terminating access. Configured retention can remove eligible completed records, and a Jira administrator can inspect and confirm an account-data deletion. Active work and uncertain results must first be resolved. App archives, imported history and recovery copies are included in the controlled deletion process. A recorded deletion generation blocks old backup imports into that installation while that generation marker remains.
Customer-owned backups, delivered emails and provider support records are separate copies. The customer removes or restricts obsolete copies under its control; the provider reviews copies it holds no later than 90 days after the relevant case closes, removes or minimises material no longer necessary, and records the purpose, access restriction and next review date for any justified further retention. Restricted retained data is not reused for ordinary service processing. Closing a support case, archiving a request or uninstalling the app must not be represented as immediate erasure of every copy. Forge-hosted data after uninstall follows Atlassian’s storage lifecycle. Created Jira screens and schemes require a separate Jira administrator decision and are not automatically rolled back.
Gmail and Cloudflare are not authorised destinations for customer Jira workspace records under this addendum. They are used for initial provider correspondence and website delivery as described in the Privacy Notice. Any exceptional confidential transfer or additional processing recipient requires a separately agreed scope and applicable safeguards before the transfer.
Evidence, review and agreement record
The provider makes information reasonably needed to demonstrate compliance available and cooperates with proportionate agreed review or audit, protecting other customers, secrets and platform security. Known processing limits and an unresolved deletion outcome are disclosed rather than reported as a completed purge. Changes to this addendum require the applicable agreement process and an identified version.
Before adoption, the agreement record must identify both parties, the chosen base agreement, effective date, processing duration, relevant platform contracts and providers, transfer safeguards if needed, authorised contacts and any additional customer instructions. The provider terms, privacy notice and support policy must be read together. No signature, independent legal review or customer acceptance is claimed by publishing this proposed addendum.