Data Processing Agreement
Last updated: March 15, 2026
This Data Processing Agreement ("DPA") forms part of the agreement between the customer organization identified in the Atlassian Marketplace license ("Controller", "you") and Maciej Jezierski, trading as be4.software ("Processor", "we", "us") for the use of SealDoc for Jira ("the App").
This DPA is entered into pursuant to Article 28 of Regulation (EU) 2016/679 (General Data Protection Regulation, "GDPR") and supplements the Terms of Service and Privacy Policy.
| Processor | Maciej Jezierski, trading as be4.software |
| Address | ul. Krotka 1a / 18, 55-010 Radwanice, Poland |
| VAT ID | PL8961441465 |
| Contact | contact@be4.software |
1. Definitions
Terms not defined here have the meanings given in the GDPR. "Personal Data" means any personal data processed by the Processor on behalf of the Controller through the App. "Sub-processor" means any third party engaged by the Processor to process Personal Data.
2. Scope and Purpose of Processing
| Attribute | Description |
|---|---|
| Subject matter | Provision of electronic signature and audit trail functionality within Atlassian Jira and Confluence. |
| Duration | For the duration of the Controller's active Atlassian Marketplace license for SealDoc. Processing ceases upon uninstallation, subject to Atlassian's data purge timelines. |
| Nature of processing | Collection, storage, and retrieval of electronic signature records, audit trail entries, signing PIN hashes, and approval status. Computation of content hashes. Anonymization for GDPR erasure requests. |
| Purpose | To enable the Controller's users to electronically sign Jira issues and Confluence pages, maintain tamper-evident audit trails, and manage approval workflows. |
| Categories of data subjects | The Controller's employees and contractors who use the App to sign, approve, or review documents within the Controller's Jira and Confluence instance. |
| Categories of personal data | Atlassian account IDs, display names, signing PIN hashes (PBKDF2-SHA512), signer affirmation text (typed name), signature metadata (meaning, comment, timestamp), audit trail entries, and public keys (if PKI is used). |
3. Processor Obligations
The Processor shall:
- Process Personal Data only on documented instructions from the Controller, including with regard to transfers of Personal Data to a third country, unless required to do so by EU or Member State law — in which case the Processor shall inform the Controller of that legal requirement before processing, unless prohibited by law.
- Ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
- Take all measures required pursuant to Article 32 of the GDPR (security of processing). See Section 6 below.
- Respect the conditions for engaging sub-processors as set out in Section 5 below.
- Taking into account the nature of the processing, assist the Controller by appropriate technical and organizational measures, insofar as this is possible, for the fulfilment of the Controller's obligation to respond to requests for exercising data subject rights (Chapter III of the GDPR). See Section 8 below.
- Assist the Controller in ensuring compliance with Articles 32 to 36 of the GDPR, taking into account the nature of processing and the information available to the Processor.
- At the choice of the Controller, delete or return all Personal Data to the Controller after the end of the provision of services, and delete existing copies unless EU or Member State law requires storage. See Section 9 below.
- Make available to the Controller all information necessary to demonstrate compliance with this DPA, and allow for and contribute to audits and inspections. See Section 10 below.
- Immediately inform the Controller if, in the Processor's opinion, an instruction infringes the GDPR or other EU or Member State data protection provisions.
4. Controller Obligations
The Controller shall:
- Ensure that it has a lawful basis for processing Personal Data through the App.
- Provide documented processing instructions to the Processor where they go beyond the standard use of the App.
- Be responsible for the accuracy, quality, and legality of Personal Data provided to the Processor via the Atlassian platform.
- Fulfil its obligations to inform data subjects about the processing of their Personal Data through the App.
5. Sub-processors
The Controller provides general written authorization for the Processor to engage sub-processors, subject to the conditions in this section.
5.1. Current Sub-processors
| Sub-processor | Purpose | Location |
|---|---|---|
| Atlassian Pty Ltd | Infrastructure provider. All App data is stored in Atlassian Forge SQL and Forge Storage within Atlassian Cloud. The App runs on the Atlassian Forge serverless runtime. Atlassian's own DPA applies: Atlassian DPA. Note: Forge SQL data residency may differ from the Controller's Jira instance region — Atlassian determines Forge SQL hosting location independently of the Jira Cloud data residency setting. | Australia (HQ); data hosted in Atlassian Cloud regions per Atlassian's Forge infrastructure allocation (which may differ from the Controller's Jira data residency configuration). |
No other sub-processors are engaged. The App does not make external API calls, use third-party analytics, or transfer data outside the Atlassian Forge platform.
5.2. Changes to Sub-processors
The Processor shall inform 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 provided at least 30 days in advance via the Atlassian Marketplace listing or email to the Controller's Jira site administrator. If the Controller objects on reasonable grounds, the parties shall discuss the concern in good faith. If no resolution is reached, the Controller may terminate the agreement by uninstalling the App.
5.3. Sub-processor Obligations
Where the Processor engages a sub-processor, the Processor shall impose on the sub-processor, by way of a contract, the same data protection obligations as set out in this DPA. The Processor shall remain fully liable to the Controller for the performance of the sub-processor's obligations.
6. Security Measures
The Processor implements the following technical and organizational measures pursuant to Article 32 of the GDPR:
| Measure | Implementation |
|---|---|
| Encryption in transit | All communication between the App and Atlassian APIs uses HTTPS (TLS 1.2+). |
| Encryption at rest | Data stored in Atlassian Forge SQL and Forge Storage is encrypted at rest by Atlassian. See Atlassian Trust Center. |
| Pseudonymization | Signing PINs are stored as PBKDF2-SHA512 hashes (600,000 iterations) with unique salts. PINs are never stored in plaintext. |
| Access control | The App uses Atlassian-managed authentication (SSO/2FA/SAML). SealDoc adds permission groups (sign-sealdoc, audit-sealdoc, manage-sealdoc) scoped to Jira groups. |
| Data isolation | App data is isolated per Jira Cloud site. Each site has its own Forge SQL database and Forge Storage instance. No cross-site data sharing. |
| Integrity verification | Tamper-evident hash chain (SHA-256) on all audit trail entries. HMAC-SHA256 chain sealing for additional integrity assurance. |
| Sandboxing | The App runs within the Atlassian Forge sandbox, which restricts network access, file system access, and runtime capabilities. |
| Development practices | Version-controlled source code (Git), automated testing (unit and integration), TypeScript strict mode, code review before release. |
| No external data transfers | The App makes no outbound network calls to third-party services. All data communication occurs within Atlassian's infrastructure via Forge platform APIs (Jira REST API, Confluence REST API, Forge SQL, Forge Storage). No data is sent to external servers, analytics services, or third-party APIs. |
Note: SealDoc has not undergone an independent third-party security audit or penetration test. The Processor will inform the Controller if this changes.
7. Data Breach Notification
In the event of a personal data breach (as defined in Art. 4(12) GDPR) affecting Personal Data processed through the App, the Processor shall:
- Notify the Controller without undue delay, and in any event within 48 hours of becoming aware of the breach, via email to the Controller's Jira site administrator or the contact address on file.
- Provide the Controller with the following information (to the extent available): the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences of the breach, and the measures taken or proposed to address the breach.
- Cooperate with the Controller in investigating and remediating the breach.
- Not notify affected data subjects directly unless instructed to do so by the Controller or required by applicable law.
Note: Because the App runs entirely on Atlassian Forge infrastructure, data breaches at the infrastructure level are Atlassian's responsibility. Atlassian's breach notification obligations are governed by the Atlassian DPA. The Processor will promptly relay to the Controller any breach notifications received from Atlassian that may affect the App's data.
8. Data Subject Rights
The Processor shall assist the Controller in responding to data subject requests under GDPR Chapter III:
| Right | SealDoc Support |
|---|---|
| Right of access (Art. 15) | SealDoc provides a "My Data" export function in the admin page that returns all personal data associated with a Jira account ID (signatures, audit entries, PIN metadata). |
| Right to erasure (Art. 17) | SealDoc provides a GDPR erasure function that anonymizes display names in audit trail and signature records while preserving hash chain integrity. Certain pseudonymous fields (account ID, signer affirmation) are retained under Art. 17(3)(b)/(e) exemptions as described in the Privacy Policy. |
| Right to rectification (Art. 16) | Display names in SealDoc are sourced from the Atlassian user profile. Rectification of display names should be performed in Atlassian. SealDoc will reflect updated display names in future entries; historical audit entries retain the name recorded at the time of the action (required for audit trail integrity). |
| Right to data portability (Art. 20) | Audit trail data can be exported as CSV. The "My Data" function exports per-user data in a structured format. |
| Right to restriction / objection (Art. 18, 21) | The Controller can restrict a user's access by removing them from SealDoc permission groups. Administrators can force-expire a user's signing PIN to prevent further signing. |
9. Data Deletion and Return
Upon termination of the agreement (uninstallation of the App):
- All App data in Forge SQL and Forge Storage is scheduled for deletion by Atlassian. Atlassian's data retention and purge policies govern the actual deletion timeline.
- Data return is accomplished by exporting audit trail and signature data as CSV/PDF before uninstalling. The Controller should export all required data before uninstalling. The Processor will assist the Controller with export if needed.
- The Processor does not retain any copies of the Controller's data outside of the Atlassian Forge platform. There is no vendor-side data to delete.
10. Audits and Inspections
The Processor shall make available to the Controller all information necessary to demonstrate compliance with this DPA. The Processor shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller, subject to the following conditions:
- The Controller shall provide at least 30 days' written notice of an audit request.
- Audits shall be conducted during normal business hours and shall not unreasonably disrupt the Processor's operations.
- The Controller shall bear the costs of the audit. The Processor shall provide reasonable cooperation at no additional charge.
- Audit scope is limited to the Processor's processing activities under this DPA. The Controller acknowledges that the Processor cannot provide access to Atlassian's infrastructure or Forge platform internals — these are governed by Atlassian's Trust Center and compliance certifications.
- Where possible, the Processor will satisfy audit requests by providing relevant documentation (security measures, processing records, test results) rather than on-site inspection.
11. International Transfers
The Processor is established in the European Union (Poland). Personal Data processed through the App is stored within the Atlassian Forge infrastructure. The Processor does not transfer Personal Data outside the Atlassian platform.
Forge hosted storage (including Forge SQL) respects the data residency setting of the customer's Atlassian Cloud instance. For any transfers outside the EEA, the Controller relies on the transfer mechanisms in Atlassian's Data Processing Addendum, including Standard Contractual Clauses (SCCs). The Processor does not independently transfer Personal Data to third countries.
Atlassian's data hosting locations and transfer mechanisms are governed by the Atlassian DPA and the Controller's Atlassian Cloud configuration. Atlassian uses EU Standard Contractual Clauses (SCCs) for transfers of personal data outside the EEA where required — see Atlassian's DPA for current transfer mechanisms. The Controller is responsible for evaluating Atlassian's transfer safeguards as they relate to the Controller's data residency requirements.
12. Liability
Each party's liability under this DPA is subject to the limitations and exclusions set out in the Terms of Service. This DPA does not create additional liability beyond what is provided in the Terms of Service, except to the extent that the GDPR imposes direct obligations or liabilities on the Processor that cannot be contractually limited.
13. Term and Termination
This DPA takes effect when the Controller installs the App and remains in force for as long as the Processor processes Personal Data on behalf of the Controller. The Controller may terminate this DPA at any time by uninstalling the App. The obligations under Sections 7 (Data Breach), 9 (Deletion), and 10 (Audits) survive termination.
14. Governing Law
This DPA shall be governed by the laws of the Republic of Poland and applicable European Union regulations, consistent with the Terms of Service. Disputes relating to this DPA shall be subject to the exclusive jurisdiction of the courts in Wroclaw, Poland, without prejudice to the data subject's right to lodge a complaint with a supervisory authority or bring proceedings before the courts of the Member State where the data subject has habitual residence (Art. 79 GDPR).
15. Amendments
Non-material amendments to this DPA (e.g., updates to reflect changes in applicable law, sub-processor details, or contact information) will be communicated at least 30 days in advance via the Atlassian Marketplace listing or email. Material amendments to the processing scope, security measures, or Controller obligations require the Controller's explicit written consent. If the Controller does not consent to a material amendment, either party may terminate the agreement by uninstalling the App.
Contact
For questions about this Data Processing Agreement, please contact:
| Name | Maciej Jezierski |
| Address | ul. Krotka 1a / 18, 55-010 Radwanice, Poland |
| VAT ID | PL8961441465 |
| contact@be4.software |