Data Processing Agreement

This page is an Order Form. The substantive obligations on Ticketize.it as data processor are set out in the Bonterms Standard Data Processing Agreement (v1.0), an open-standard SaaS DPA maintained by Bonterms. The terms below are the customer-specific overlay — they identify the parties, the categories of data processed, the approved sub-processors, the security measures applied, and the international-transfer mechanisms in use.

Customers may countersign by emailing a signed copy to [email protected]. Until countersigned, the terms set out below apply to all processing of Customer Personal Data on the Ticketize.it Service by operation of our Terms of Service.

A. Parties

Processor. devops team srl, a limited-liability company organised under the laws of Romania, with registered office in Romania (the “Processor” or “Ticketize.it”), doing business via the Ticketize.it service at app.ticketize.it. Contact for data-protection matters: [email protected].

Controller. The customer entity that has agreed to Ticketize.it’s Terms of Service and is using the Service to mirror issues between its Jira workspace(s) (“Customer” or “Controller”).

B. Subject matter and duration of processing

The Processor will process Customer Personal Data for the duration of the Customer’s subscription to the Service, plus any retention period specified in section H below. Processing terminates upon the earlier of (i) deletion of the Customer’s account, or (ii) the Customer’s written instruction to delete its data.

C. Nature and purpose of processing

The Processor processes Customer Personal Data for the sole purpose of providing the bidirectional Jira-to-Jira issue synchronization service described in the Terms of Service — specifically, reading issues, comments, and attachments from the Customer’s connected Jira workspaces and writing them to the Customer’s designated target workspaces in accordance with the sync rules the Customer configures.

The Processor does not use Customer Personal Data for any other purpose, including: training machine-learning models, generating anonymous or aggregated analytics for resale, advertising, or secondary marketing.

D. Categories of data subjects

Customer Personal Data may relate to the following categories of data subjects:

• The Customer’s employees, contractors, and agents who use the Customer’s Jira workspace(s)
• The Customer’s end users or external collaborators identified in Jira issues, comments, or attachments (e.g. reporter, assignee, comment author)
• The Customer’s administrator who authenticates with Ticketize.it to configure the integration

E. Categories of personal data

The following categories of personal data are processed:

• Identifiers: Atlassian accountId, display name, email address, avatar URL
• Issue content: Summary, description, status, priority, labels, assignee, reporter, attachment metadata (filename, MIME type, size — not file bytes), created / updated timestamps
• Comment content: Comment body (Atlassian Document Format), author, timestamps
• Authentication tokens: Jira OAuth 2.0 access and refresh tokens (encrypted at rest with AES-256-GCM envelope encryption)
• Operational metadata:Sync attempt timestamps, error messages, source IP of the Customer’s administrator at login (used for the new-device sign-in alert feature)

Not processed:payment card data (collected directly by Stripe Checkout; the Processor never sees or stores it), special categories of personal data under GDPR Article 9 (unless the Customer chooses to include such data in Jira issue content, which is the Customer’s decision and outside the Processor’s control), file-attachment bytes (the Processor re-uploads attachment bytes directly between Jira instances without persistent storage).

F. Approved sub-processors

The Processor engages the following sub-processors. Each sub-processor is bound by data-protection obligations no less protective than those set out in this Order Form and the Bonterms Standard DPA.

Sub-processor change notice: The Processor will notify the Customer at least thirty (30) days in advance of engaging any new sub-processor or replacing an existing one, by email to the Customer’s registered administrator address. Within fifteen (15) days of the notice the Customer may object on reasonable data-protection grounds; if the Customer objects and the parties cannot agree on a resolution, the Customer may terminate the affected portion of the Service.

G. Security measures (Annex II of the SCCs)

The Processor implements the following technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access:

• Encryption at rest: AES-256-GCM envelope encryption for OAuth tokens and webhook signing secrets, with a per-environment Key Encrypting Key managed outside the database
• Encryption in transit: TLS 1.2+ on every network hop, with HSTS preload and X-Content-Type-Options nosniff headers enforced
• Tenant isolation: PostgreSQL Row-Level Security policies enforced at the database engine, on a runtime database role with NOBYPASSRLS — no application-level bug can result in cross-tenant data access
• Authentication: bcrypt password hashing; httpOnly + Secure + SameSite=Lax session cookies; per-account lockout after 10 consecutive failed logins; new-device sign-in alerts to the account holder
• Network controls: Per-IP rate limiting on authentication endpoints (10 requests/minute); optional IP allowlist for administrative endpoints
• Audit logging: Sync attempts logged with timestamp, direction, status, and error context; access logs scrub webhook path-secrets before persistence
• Backups: Daily encrypted backups to access- scoped object storage; retained per the schedule in section H
• Vulnerability management: Dependency-audit CI jobs (pip-audit + npm audit) gating deploys on high-severity findings; security patches applied on rolling releases
• Key rotation: Zero-downtime KEK rotation via a two-key window — credentials remain decryptable under both keys during rotation; documented procedure

Full technical detail of the security architecture is available on request via [email protected].

H. Retention and deletion

The Processor retains Customer Personal Data for the duration of the active subscription, with the following category-specific limits:

• Full raw Jira issue payloadsare automatically NULLed thirty (30) days after the issue’s last update. The core synced fields (summary, status, etc.) are retained as long as the sync rule is active.
• Audit logs and sync historyare retained according to the Customer’s plan tier (Free: 7 days, Starter: 30 days, Pro: 90 days, Business / Enterprise: configurable).
• Pending OAuth connection rows expire one (1) hour after creation if not completed.
• Backups are retained for thirty (30) days on a rolling basis.

Deletion on request:The Customer may request full deletion of its account at any time via the “Delete my account” action in Settings → Connection & data, or by emailing [email protected]. Deletion completes within thirty (30) days of the request and includes (a) cascade deletion of the tenant record and all associated data in the primary database, (b) removal from subsequent backup snapshots by rotation (full backup-set removal within thirty days), and (c) optional cleanup of attribution markers from the Customer’s Jira tickets via the “Disconnect & clean up” action.

I. Data subject rights and Controller assistance

The Processor will assist the Controller in responding to data- subject rights requests under GDPR Articles 15–22 (access, rectification, erasure, restriction, portability, objection, automated decision-making). The Customer may exercise rights on behalf of its data subjects via [email protected].

Standard requests will be responded to within ten (10) business days; requests requiring data export or complex search may take up to thirty (30) days.

J. International transfers

Primary Customer Personal Data storage is within the European Economic Area (a single Romania-based Kubernetes cluster). Limited transfers to a country outside the EEA occur only via the sub-processors identified in section F, and exclusively under one of the following mechanisms:

• EU Commission Standard Contractual Clauses (Decision 2021/914), Module 2 (controller-to-processor) or Module 3 (processor-to-processor) as applicable, where the recipient is in a country without an EU adequacy decision
• An EU adequacy decision under GDPR Article 45, where one exists

K. Personal data breach notification

The Processor will notify the Customer’s registered administrator address without undue delay and in any event within seventy-two (72) hours of becoming aware of a personal data breach affecting Customer Personal Data, providing the information required under GDPR Article 33(3) to the extent then known. Updates will follow as the investigation progresses.

L. Audit rights

The Customer may, on reasonable advance written notice and no more than once per twelve-month period (except where required by a regulator or following a personal data breach), audit the Processor’s compliance with this Order Form and the Bonterms Standard DPA. Audits are performed by qualified independent auditors under reasonable confidentiality commitments and at the Customer’s cost, unless they uncover material non-compliance.

M. Order of precedence

In the event of any conflict between this Order Form and the Bonterms Standard DPA, the Bonterms Standard DPA controls except where this Order Form explicitly supplements or modifies it. Both documents control over the Terms of Service with respect to processing of Customer Personal Data.

N. How to countersign

Customers requiring a countersigned copy of this Order Form may email [email protected] with their company details. We will return a signed PDF within five (5) business days. By using the Service the Customer is deemed to have accepted the terms of this Order Form for the duration of its subscription, whether or not a countersigned copy has been exchanged.

O. Changes to this Order Form

Material changes — including the addition or replacement of sub-processors, changes to security measures, or changes to the categories of personal data processed — will be notified to the Customer’s registered administrator address at least thirty (30) days in advance. The “Last updated” date above will always reflect the most recent revision.