Data Processing Addendum

Last updated: June 4, 2026 · Applies to the Managed tier only

1. Parties, structure, and order of precedence

This Data Processing Addendum ("DPA") supplements and forms part of the agreement under which Aleks Asenov Asenov — a sole trader (individual) established in Sofia, Bulgaria, operating under the Spec2JIRA / Spec2Tickets brand ("we", "Processor") — provides the Spec2Tickets Forge application (the "App") to the customer that has enabled the Managed tier ("Customer", "Controller"). That underlying agreement is the Atlassian Marketplace end-user agreement applicable to the App (the "Principal Agreement").

• Processor: Aleks Asenov Asenov, a sole trader (individual) established in Sofia, Bulgaria, operating under the Spec2JIRA / Spec2Tickets brand.
• Registered address: Ovcha Kupel 2, Sofia, Bulgaria.
• Data-protection / privacy contact: privacy@spec2jira.com (security: security@spec2jira.com).
• EU/UK representative (Art. 27 GDPR): Not applicable — the Processor is established in the EEA (Bulgaria).

Order of precedence. This DPA applies only to the Customer's use of the Managed tier. In the event of a conflict between this DPA and the Principal Agreement on the subject of the processing of Personal Data, this DPA prevails. On all other matters the Principal Agreement prevails. Nothing in this DPA limits any rights the Customer has directly against Atlassian or Anthropic under their respective terms.

2. Definitions

Capitalised terms not defined here have the meaning given in the EU General Data Protection Regulation 2016/679 ("GDPR") and, where applicable, the UK GDPR and the Data Protection Act 2018.

• "Applicable Data Protection Law" — all data-protection and privacy laws applicable to the processing under this DPA, including the GDPR, the UK GDPR, and any implementing or successor legislation. This DPA is GDPR / UK-GDPR-first.
• "Controller", "Processor", "Sub-processor", "Data Subject", "Personal Data", "Processing", "Personal Data Breach" — as defined in the GDPR.
• "Customer Content" — the Confluence page content and any related text the Customer (through its authorised users) submits to the App for processing under the Managed tier, together with the Jira breakdown generated from it, to the extent any of the foregoing contains Personal Data.
• "Managed tier" — the App tier in which Spec2Tickets, using its own Anthropic account and API key, calls the Anthropic API to generate a breakdown from Customer Content (as distinct from the BYOK tier, in which the Customer uses its own Anthropic key).
• "Sub-processor" — any third party engaged by Spec2Tickets to process Customer Content on its behalf in connection with the Managed tier. The sole Sub-processor at the effective date is identified in Section 6 and at https://spec2jira.com/subprocessors.
• "Standard Contractual Clauses" / "SCCs" — (a) for EU transfers, the clauses approved by Commission Implementing Decision (EU) 2021/914 of 4 June 2021; and (b) for UK transfers, the UK International Data Transfer Addendum to the EU SCCs ("UK IDTA") issued by the ICO.

3. Roles of the parties

• The Customer is the Controller of Customer Content. The Customer determines the purposes and means of the processing (it decides which Confluence pages to submit and what they contain).
• Spec2Tickets is a Processor, processing Customer Content only on the Customer's documented instructions for the purpose of providing the Managed tier.
• Anthropic PBC is Spec2Tickets' Sub-processor for the Managed tier (AI inference). With respect to the content Spec2Tickets sends it under the Managed tier, Anthropic acts as a processor; Anthropic's own terms govern that relationship (Section 6).
• Where the Customer is itself a processor for an upstream controller, the Customer warrants it has the authority to engage Spec2Tickets as a sub-processor on those terms, and this DPA applies mutatis mutandis with the Customer in the processor role.

4. Subject-matter, nature, purpose, duration, and scope of processing

This Section is the Annex / Description of Processing required by Art. 28(3) GDPR.

5. Obligations of Spec2Tickets as Processor (Art. 28(3))

5.1 Processing on documented instructions

Spec2Tickets processes Customer Content only on the Customer's documented instructions, including with regard to international transfers, unless required to do otherwise by EU / Member-State or UK law to which Spec2Tickets is subject (in which case Spec2Tickets will inform the Customer of that legal requirement before processing, unless the law prohibits it on important grounds of public interest). The Customer's instructions are: (a) this DPA; (b) the Principal Agreement; and (c) the Customer's configuration and use of the App (each Managed-tier generation the Customer initiates is an instruction to process the selected content for that breakdown). Spec2Tickets will inform the Customer if, in its opinion, an instruction infringes Applicable Data Protection Law.

5.2 Confidentiality

Spec2Tickets ensures that persons authorised to process Customer Content are bound by an appropriate duty of confidentiality. Everyone with access to the deploying Atlassian developer account and to the Managed Anthropic account is under a confidentiality obligation.

5.3 Security

Spec2Tickets implements appropriate technical and organisational measures under Art. 32 GDPR, as described in Section 8.

5.4 No special-category / prohibited data instruction

The Customer instructs Spec2Tickets to process only ordinary Personal Data. The Customer agrees not to submit special-category data (Art. 9), criminal-offence data (Art. 10), payment-card data, or any data subject to heightened regulatory regimes via the Managed tier, and to use the BYOK tier (or to redact) where such data may be present. Spec2Tickets does not inspect content for, and cannot guarantee detection of, such data.

5.5 Sub-processing

See Section 6.

5.6 Assistance with data-subject rights

See Section 10.

5.7 Assistance with controller obligations

Taking into account the nature of the processing and the information available to it, Spec2Tickets assists the Customer in ensuring compliance with Arts. 32–36 GDPR (security, breach notification, data-protection impact assessments, and prior consultation), as further described in Sections 8, 10, and 12.

5.8 Deletion or return at end of services

See Section 7.4.

5.9 Records and demonstrable compliance

Spec2Tickets makes available to the Customer the information necessary to demonstrate compliance with Art. 28 and contributes to audits as described in Section 11.

6. Sub-processors (Art. 28(2), 28(4))

6.1 General authorisation

The Customer provides a general written authorisation for Spec2Tickets to engage Sub-processors for the Managed tier, subject to the change-notice and objection rights below.

6.2 Current Sub-processors (effective date)

The authoritative, public Sub-processor list is maintained at https://spec2jira.com/subprocessors.

6.3 Flow-down

Spec2Tickets imposes on each Sub-processor data-protection obligations that are, in substance, no less protective than those in this DPA, to the extent applicable to the Sub-processor's role. For Anthropic, this is achieved through the Anthropic Commercial Terms and the DPA / SCCs incorporated therein. The Managed Anthropic account is on the Commercial / API terms, so the no-training default and the DPA / SCCs apply.

6.4 Change notice and objection

Spec2Tickets will give the Customer at least 30 days' prior notice (via the public Sub-processor list and/or email to the Customer's designated contact) before adding or replacing a Sub-processor. If the Customer reasonably objects on data-protection grounds within that period, the parties will discuss in good faith; if no resolution is reached, the Customer may terminate the Managed tier for the affected processing without penalty (the BYOK tier remains available as an alternative). Spec2Tickets remains liable for its Sub-processors' performance of their data-protection obligations.

7. Retention, transience, and deletion

This Section states the actual data lifecycle. It is deliberately honest about residual retention at the Sub-processor; it should not be read as a "zero-retention" guarantee.

7.1 Inside Atlassian Forge (storage Spec2Tickets controls)

• Customer Content (the submitted page content and the generated breakdown) is stored transiently in Atlassian Forge key-value storage (KVS) within the Customer's own Atlassian instance, only to drive the review-and-push workflow.
• The App removes the stored page content and breakdown when the Customer pushes the breakdown to Jira. A breakdown the Customer never pushes — including one regenerated away or left unattended — is automatically removed from the Customer's Forge instance after 7 days of inactivity by a scheduled cleanup; accessing a breakdown for review resets that inactivity timer. Until removal, content remains only in the Customer's own Forge instance.
• Honest current behaviour: the App performs an automatic, scheduled cleanup that removes a never-pushed breakdown (and its page-content snapshot) from the Customer's Forge instance after 7 days without access. This is an inactivity timer, not a fixed lifetime — opening a breakdown for review resets it, so content under active review is preserved. A breakdown is otherwise removed when pushed to Jira or when the App is uninstalled.
• Uninstalling the App removes its Forge-stored data for that instance.

7.2 At Anthropic (Sub-processor — the residual retention to disclose)

• The Managed tier uses the Anthropic Message Batches API. The Batches API is not eligible for Zero-Data-Retention (ZDR); inputs and outputs of batch jobs are retained by Anthropic for up to approximately 29 days, after which they are deleted in the ordinary course, per Anthropic's then-current retention policy.
• Accordingly, the honest framing is: Customer Content is not retained at rest by Spec2Tickets after the breakdown is returned and removed from Forge, except (a) for the ≤ ~29-day retention of batch inputs / outputs at Anthropic described above, and (b) any limited legal / safety / abuse-prevention retention described in Section 7.3.
• We do not claim "zero retention" for the Managed tier. A customer that requires zero retention should use BYOK and configure ZDR (if eligible) directly under its own Anthropic agreement, or avoid submitting the data.

7.3 Limited legal / abuse retention at the Sub-processor

Even where ordinary retention limits apply, Anthropic may retain content that is flagged for trust-and-safety, legal, or abuse-prevention reasons for a longer period (up to approximately 2 years), as described in Anthropic's policies. This is outside Spec2Tickets' control and is disclosed for transparency.

7.4 Deletion or return at end of services

On termination of the Managed tier, or on the Customer's written request, Spec2Tickets will delete the Customer Content it holds in Forge (or, at the Customer's option and where technically feasible, return it), save to the extent retention is required by law. Residual copies held by Anthropic are deleted on Anthropic's retention schedule (Sections 7.2–7.3); where a customer requires expedited deletion of batch-job data at Anthropic, see the data-subject-rights caveat in Section 10.3.

8. Security measures (Art. 32)

Spec2Tickets relies on Atlassian Forge's platform security and applies the following technical and organisational measures appropriate to the risk.

Platform and architecture

• The App runs entirely on Atlassian Forge's managed runtime (nodejs24.x); there is no separate Spec2Tickets-operated server, VM, container, or database for the Managed flow.
• The only external egress declared in the Forge manifest is https://api.anthropic.com.
• For the Managed tier, the call to Anthropic uses Spec2Tickets' own Anthropic API key, stored in Forge encrypted secret storage and accessible only to the backend resolver (never returned to the browser). The Managed key is provisioned via Forge encrypted storage and is never logged.

Encryption

• In transit: TLS / HTTPS for all Atlassian API calls and for the call to api.anthropic.com.
• At rest: Forge storage is encrypted and managed by Atlassian; secrets use Forge encrypted secret storage.

Access control and tenant isolation

• The App inherits Forge tenant isolation; data is stored within the Customer's own instance.
• Confluence reads and Jira writes act under the signed-in user's own Atlassian permissions (asUser()), not a shared service account, so users can only act on content they may already access.
• Managed-tier generation and push remain gated behind an active license or trial.
• Administrative access to the Atlassian developer account that deploys the App and to the Managed Anthropic account is restricted to authorised personnel and protected by multi-factor authentication (MFA).

Data minimisation and logging

• The App is designed so that end-user content is not written to Forge application logs (log statements record lengths, identifiers, and status, not content).
• Customer Content is held only transiently and removed per Section 7.

Telemetry

• The App collects no separate analytics or behavioural telemetry on end users.

Certifications

Spec2Tickets does not claim SOC 2, ISO 27001, or other independent certification for its own operations and does not represent that it holds any. The App inherits the security posture of the Atlassian Forge platform; Anthropic maintains its own certifications as published at trust.anthropic.com.

9. No training on Customer Content

• Spec2Tickets does not use Customer Content to train, fine-tune, or improve any machine-learning model.
• For the Sub-processor: under the Anthropic Commercial Terms, Anthropic does not train its models on customer content submitted via the commercial / API services by default; Anthropic's Privacy Center confirms this for commercial / API use. The Managed account is on commercial / API terms so this default applies, and no optional data-sharing or model-improvement setting is enabled on the account.

10. Data-subject rights and assistance (Arts. 12–23, 28(3)(e))

10.1 Forwarding requests

If Spec2Tickets receives a request from a Data Subject relating to Customer Content (access, rectification, erasure, restriction, portability, or objection), Spec2Tickets will, unless legally prohibited, not respond directly (except to confirm the request was received and will be routed) and will forward it to the Customer without undue delay so the Customer, as Controller, can respond.

10.2 Assistance

Taking into account the nature of the processing, Spec2Tickets provides reasonable assistance — by appropriate technical and organisational measures, insofar as possible — to help the Customer fulfil its obligation to respond to Data-Subject requests. Because Customer Content in Forge is held transiently and stored within the Customer's own instance, the Customer can often satisfy access / erasure requests directly (e.g. by editing or removing the source page; the stored breakdown is removed when it is pushed to Jira, when the App is uninstalled, or automatically after 7 days of inactivity if it is never pushed).

10.3 Caveat — deletion of data held by the Sub-processor

Erasure of Customer Content that resides in Anthropic's batch-job storage during the ≤ ~29-day retention window is not within Spec2Tickets' direct technical control. Where a Data-Subject erasure request requires expedited deletion of such residual data, Spec2Tickets will, on the Customer's documented request, submit a corresponding deletion request to Anthropic and pass back Anthropic's response, but cannot guarantee a deletion timeline shorter than Anthropic's processes allow, and cannot delete content Anthropic is required to retain for legal or abuse reasons (Section 7.3). For use cases that demand guaranteed, controller-driven erasure, BYOK is the appropriate tier.

11. Audit (Art. 28(3)(h))

• On the Customer's reasonable written request (no more than once per 12 months, except following a Personal Data Breach affecting the Customer or where required by a supervisory authority), Spec2Tickets will make available the information necessary to demonstrate compliance with Art. 28 — including this DPA, the public Sub-processor list, the security summary in Section 8, and relevant Atlassian Forge / Anthropic platform documentation and any third-party attestations those providers publish.
• Given the no-backend architecture, Spec2Tickets' own auditable surface is limited; much of the relevant assurance derives from Atlassian's and Anthropic's published security documentation and attestations, which Spec2Tickets will help the Customer locate.
• On-site audits or detailed questionnaires beyond the above will be handled on reasonable notice, during business hours, and subject to confidentiality.

12. Personal Data Breach (Arts. 33–34)

• Spec2Tickets will notify the Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Content processed under the Managed tier, and in any event within 72 hours of becoming aware, providing the information reasonably available to enable the Customer to meet its own notification obligations.
• The notification will, to the extent known, describe the nature of the breach, likely consequences, and measures taken or proposed.
• The security / incident contact is security@spec2jira.com, behind which there is a defined internal incident-response process.
• Breaches occurring within Atlassian's or Anthropic's platforms are subject to those providers' own notification commitments to Spec2Tickets; Spec2Tickets will relay relevant information to the Customer.

13. International transfers (Chapter V)

• The Managed tier transfers Customer Content to Anthropic PBC in the United States (and potentially other regions per Anthropic's sub-processor list). This is a restricted / third-country transfer under the GDPR and UK GDPR.
• Transfer mechanism — SCCs. The transfer is covered by the EU Standard Contractual Clauses (Commission Decision 2021/914) and, for UK data, the UK International Data Transfer Addendum (IDTA), as incorporated into the Anthropic Commercial Terms / Anthropic DPA between Spec2Tickets and Anthropic. The Spec2Tickets→Anthropic transfer uses Module Three (processor-to-processor); where Spec2Tickets contracts directly with an EU/UK customer, Module Two (controller-to-processor) applies to the Customer→Spec2Tickets leg.
• Transfer impact / supplementary measures. Spec2Tickets maintains a Transfer Impact Assessment reflecting the data categories (low-risk business page content, customer-controlled, no special categories instructed), the ≤29-day Sub-processor retention, encryption in transit, and the no-training default, together with the supplementary measures described in this DPA.
• Atlassian Forge stores data within the Customer's chosen Atlassian region; data residency for the App's Forge-stored data follows the Customer's instance (Section 8). The transfer that leaves the Atlassian boundary is the Anthropic call described above.

14. Liability

Each party's liability arising out of or related to this DPA is subject to the limitations and exclusions of liability set out in the Principal Agreement (the Atlassian Marketplace end-user agreement), and counts toward those limits, except where Applicable Data Protection Law does not permit such limitation.

15. Term and termination

• This DPA takes effect when the Customer enables the Managed tier and continues for as long as Spec2Tickets processes Customer Content under that tier.
• It terminates automatically on termination of the Principal Agreement or when the Customer ceases using the Managed tier.
• On termination, Section 7.4 (deletion / return) applies. Provisions which by their nature should survive (confidentiality, liability, governing law) survive.

16. Governing law and jurisdiction

This DPA is governed by the laws of Bulgaria, and the courts of Sofia, Bulgaria have exclusive jurisdiction, without prejudice to any mandatory provisions of Applicable Data Protection Law and to the governing-law and forum requirements of the SCCs.

17. Acceptance

This DPA is accepted by click-through and incorporation by reference from the Atlassian Marketplace listing and the Principal Agreement when the Customer enables the Managed tier. It is published at a stable URL (this page) and applies without a separate signature.

Document control

• Scope: Managed tier only. BYOK is unaffected and remains the privacy-maximising option.
• Source of facts: Anthropic Commercial Terms, Anthropic Privacy Center / trust.anthropic.com, Anthropic Message Batches API retention (non-ZDR, ≤ ~29 days; flagged content up to ~2 years), and the App's actual Forge KVS behaviour (content removed on push, automatically after 7 days of inactivity for never-pushed breakdowns, and on uninstall).
• Last updated: June 14, 2026.