Skip to main content

Data Processing Agreement

Last updated: 2026-05-22

⚠️ LEGAL REVIEW REQUIRED — This draft Data Processing Agreement must be reviewed by a qualified GDPR practitioner or solicitor before use with customers. Items requiring specific legal or operational input are marked inline. This agreement is structured to satisfy the mandatory content requirements of GDPR Art. 28(3).


This Data Processing Agreement ("DPA") is entered into between:

Data Controller: The organisation that installs and administers the Attestsys apps in their Atlassian Jira workspace ("Controller", "you")

Data Processor: Kettasys Ltd, operator of the Attestsys suite of Jira apps ("Processor", "Attestsys", "we")

⚠️ MANUAL REVIEW REQUIRED — Insert Kettasys Ltd registered company number and registered address once the legal entity is established.

This DPA forms part of, and is incorporated into, the Terms of Service between the Controller and the Processor. By installing an Attestsys app, the Controller agrees to this DPA.


Article 1 — Definitions

For the purposes of this DPA:

  • "GDPR" means Regulation (EU) 2016/679 of the European Parliament and of the Council (the General Data Protection Regulation), as may be amended or superseded.
  • "Personal Data", "processing", "data subject", "controller", "processor", "sub-processor", and "supervisory authority" have the meanings given in the GDPR.
  • "Attestsys Service" means the Tamper-Evident Audit Log for Jira, GitHub Evidence Pack for Jira, and/or Signed Approvals for Jira apps, and the associated backend infrastructure operated by the Processor.
  • "Sub-processor" means any third party engaged by the Processor to process Personal Data on behalf of the Controller.

Article 2 — Subject matter, nature, and purpose of processing

Subject matter: Personal data included in Jira activity events captured and cryptographically signed by the Attestsys Service within the Controller's Jira workspace.

Nature of processing: Collection (via Atlassian Forge event forwarding), transmission, storage, cryptographic signing, hash-chaining, timestamping, and export of Jira event data.

Purpose of processing: To provide the Attestsys Service — specifically, to create and maintain a tamper-evident, cryptographically-signed, independently verifiable audit record of Jira activity on behalf of the Controller, as described in the Terms of Service.

Duration of processing: For the duration of the Controller's subscription to the Attestsys Service, and for up to 30 days following termination (to allow evidence bundle export), unless a longer retention period is required by law or agreed in writing.


Article 3 — Types of personal data and categories of data subjects

Types of personal data processed:

  • Atlassian accountId values (opaque identifiers assigned by Atlassian to individual Jira users, linked to the account of the individual who performed each captured Jira action)
  • Jira event metadata: event type, issue key, changed field names and values, event timestamp
  • Jira workspace identifier (cloudId)

⚠️ MANUAL REVIEW REQUIRED — Confirm the exact data fields in each Jira webhook event payload captured by the Attestsys apps and update this list accordingly.

What is NOT processed:

  • Jira user names or email addresses (the Processor uses accountId only)
  • Jira issue descriptions, comment text, or attachment content beyond what the Jira event webhook payload contains

Categories of data subjects:

  • Jira users (employees, contractors, or other individuals acting within the Controller's Jira workspace) whose actions generate Jira events captured by the Attestsys Service.

Article 4 — Obligations of the Processor

The Processor shall:

4.1 Documented instructions

Process Personal Data only on the documented instructions of the Controller — including with regard to transfers outside the EEA — unless required to do so by EU or Member State law, in which case the Processor shall inform the Controller before processing (unless that law prohibits such notification on important grounds of public interest).

4.2 Confidentiality

Ensure that persons authorised to process Personal Data are bound by a duty of confidentiality (whether contractual or statutory).

4.3 Security measures

Implement appropriate technical and organisational security measures to protect Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access. These measures include:

  • Encryption in transit: TLS 1.2 or higher on all connections between the Atlassian Forge platform and the Attestsys backend.
  • Encryption at rest: AES-256-GCM encryption of all stored data. LUKS full-disk encryption on the host server.

⚠️ MANUAL REVIEW REQUIRED — Confirm LUKS is provisioned before this DPA is published or provided to customers.

  • Cryptographic audit chain: ECDSA secp256k1 signing (RFC 6979 deterministic) and SHA-256 hash chaining of all audit entries, making any modification of stored records mathematically detectable.
  • Access controls: Principle of least privilege on all internal systems; multi-factor authentication (MFA) on administrative access.
  • Credential security: HMAC ingestion credentials stored with AES-256-GCM envelope encryption; compared using constant-time comparison to prevent timing attacks; zeroized from memory after use.

4.4 Sub-processors

Engage sub-processors only as set out in Article 6 of this DPA, and impose data protection obligations on sub-processors equivalent to those in this DPA.

4.5 Data subject rights

Assist the Controller in responding to data subject requests under GDPR Arts. 15–22, taking into account the nature of the processing. Requests should be directed to the Processor at privacy@attestsys.com.

4.6 Security and breach notification

Notify the Controller without undue delay (and in any case within 72 hours of becoming aware) after becoming aware of a Personal Data breach. Notification shall include: the nature of the breach; categories and approximate number of data subjects and records affected; name and contact details of the data protection contact; likely consequences; measures taken or proposed to address the breach.

4.7 Data protection impact assessments

Assist the Controller (where requested) in carrying out data protection impact assessments and prior consultation with supervisory authorities, taking into account the nature of the processing and the information available to the Processor.

4.8 Deletion and return

Upon termination of the Attestsys Service, at the Controller's choice, delete or return all Personal Data and delete existing copies, unless EU or Member State law requires storage of the Personal Data.

Note on deletion of cryptographic audit chain entries: Deletion of individual audit chain entries would destroy the cryptographic integrity of the chain and is therefore technically impossible within the design of the service. Upon termination, the Processor will tombstone the tenant's signing key (appending a signed tombstone entry to the chain) and will delete all data beyond the 30-day post-termination window. This approach preserves chain continuity while enabling data deletion compliance. This limitation is inherent to the tamper-evident nature of the service and is disclosed in the Privacy Policy.

4.9 Audit and demonstration of compliance

Provide the Controller with all information necessary to demonstrate compliance with the obligations in Art. 28 GDPR, and allow for and contribute to audits (including inspections) conducted by the Controller or an auditor mandated by the Controller — on reasonable notice and subject to confidentiality obligations.


Article 5 — Obligations of the Controller

The Controller shall:

  • Ensure it has a lawful basis for processing the Personal Data it instructs the Processor to process
  • Ensure it has provided data subjects with appropriate privacy notices disclosing the processing carried out by the Processor on its behalf
  • Not instruct the Processor to process Personal Data in a manner that would breach GDPR or any other applicable law
  • Promptly notify the Processor of any data subject request received directly by the Controller that relates to Personal Data processed by the Processor on its behalf

Article 6 — Sub-processors

The Controller provides general written authorisation for the Processor to engage the following sub-processors:

Sub-processorRoleLocation
Hetzner Online GmbHCloud infrastructure (compute, storage, networking)Nuremberg, Germany (EU)

⚠️ MANUAL REVIEW REQUIRED — Add any email provider, monitoring tool, logging service, or other sub-processor used in production before providing this DPA to customers.

The Processor shall:

  • Notify the Controller of any intended changes concerning the addition or replacement of sub-processors, giving the Controller the opportunity to object to such changes. Notice will be given by updating this DPA on the Attestsys website and by email notification to the Controller's registered contact email (where available).
  • Impose data protection obligations on each sub-processor equivalent to those imposed on the Processor under this DPA.

Article 7 — International transfers

The Processor does not transfer Personal Data outside the European Economic Area (EEA). All processing is carried out on Hetzner Cloud infrastructure in Nuremberg, Germany (EU).

⚠️ MANUAL REVIEW REQUIRED — If any sub-processor added in future involves non-EEA processing, appropriate transfer mechanisms (Standard Contractual Clauses or equivalent) must be put in place and documented here before the sub-processor is engaged.


Article 8 — Data subject rights — special provision for the audit chain

Due to the insert-only, hash-chained design of the Attestsys cryptographic audit record:

  • Erasure (Art. 17 GDPR): Individual audit chain entries cannot be deleted without breaking the cryptographic chain. Upon an erasure request, the Processor will: (a) append a signed redaction marker to the chain noting the erasure request and the data subject's accountId; (b) tombstone the tenant's private signing key if full tenant erasure is requested (under Art. 17 or upon termination). The chain entries remain but cannot be extended under the erased key. The Processor will provide the Controller with a written record of the erasure action taken.
  • Rectification (Art. 16 GDPR): Audit chain entries record facts as they occurred and are not amenable to retrospective correction. Corrections or clarifications are appended as new chain entries, with a reference to the original entry being corrected.
  • Access (Art. 15 GDPR): Evidence bundle exports (ZIP) are available from the Attestsys admin page and contain all audit chain entries for the relevant tenant.

Article 9 — Atlassian Personal Data Reporting API

As required by Atlassian's Marketplace requirements, the Processor acknowledges and implements the Atlassian Personal Data Reporting API. Personal data linked to a specific Atlassian accountId can be identified and reported within a cycle of at most 7 days. To submit a request, contact privacy@attestsys.com.


Article 10 — Governing law

⚠️ LEGAL REVIEW REQUIRED — Confirm governing law consistent with the Terms of Service once the legal entity is registered.

This DPA is governed by the same law as the Terms of Service.


Article 11 — Contact and signed copies

This DPA is provided in electronic form at attestsys.com/dpa and is incorporated into the Terms of Service by reference.

For customers who require a separately executed DPA (for example, for Enterprise contracts or internal procurement processes), contact legal@attestsys.com to request a signed copy.

⚠️ MANUAL REVIEW REQUIRED — Confirm the legal@attestsys.com email address is set up and monitored, and that a process is in place to turn around signed DPA requests within a reasonable timeframe (typically 5 business days).


Annex I — Security measures (Art. 32 GDPR)

A description of the technical and organisational security measures implemented by the Processor is set out in the Security Statement, incorporated into this DPA by reference.

Key measures include:

MeasureImplementation
Encryption in transitTLS 1.2+ with HSTS
Encryption at restAES-256-GCM + LUKS FDE
Infrastructure certificationHetzner Cloud: BSI C5 Type 2, ISO 27001:2022
Cryptographic signingECDSA secp256k1 (RFC 6979 deterministic)
Tamper detectionSHA-256 hash chain — any modification is mathematically detectable
Trusted timestampingRFC 3161 (FreeTSA free tier; QuoVadis Trustlink B.V. NL + GlobalSign nv-sa paid tiers)
Key managementAES-256-GCM envelope encryption of private keys at rest; in-memory key zeroization after use
Access controlsPrinciple of least privilege; MFA on administrative access
Breach notification72-hour notification commitment to Controller
Vulnerability managementAtlassian Security Bug Fix Policy SLA (Critical 10 days, High 4 weeks, Medium 12 weeks, Low 25 weeks)

⚠️ MANUAL REVIEW REQUIRED — Confirm LUKS is provisioned before this annex is published.