Tracuto Data Processing Agreement (DPA)

Effective date: May 10, 2026 Legal bundle version: 2026-05-10

This Data Processing Agreement (“DPA”) forms part of the agreement between KOHA-TECH Sp. z o.o. with its registered office at ul. Nowy Świat 33/13, 00-029 Warszawa, Poland, KRS 0001183713, NIP 5253054129, REGON 542256381, share capital PLN 5,000 (fully paid in), operating under the trade name “Tracuto” (“Processor,” “we”), and the Customer (“Controller,” “you”) who uses the Tracuto Service under the Terms of Service. It applies to processing of personal data on Controller’s behalf and is binding on both parties when accepted at signup or executed separately. Transfer mechanisms are referenced in Schedule D.

1. Scope and roles

1.1 This DPA applies where Processor processes personal data contained in Customer Data on behalf of Controller under the Terms of Service.

1.2 For such processing, Controller is the controller (or business / data exporter, as applicable) and Processor is the processor (or service provider / data importer, as applicable).

1.3 Schedule A describes the subject matter, duration, nature and purpose, types of personal data, and categories of data subjects. Schedule B lists subprocessors. Schedule C summarises technical and organisational measures. Schedule D contains international-transfer mechanisms.

1.4 Account data. For dashboard account data (the relationship with Dashboard Users and account contacts) Processor is the controller; that processing is governed by the Privacy Policy, not this DPA.

2. Processor obligations

2.1 Documented instructions. Processor will process personal data only on documented instructions from Controller, including these Terms, this DPA, and in-product configuration. Processor will inform Controller (unless legally prohibited) if a Processor opinion is that an instruction infringes GDPR or applicable law (Art. 28(3) GDPR).

2.2 Confidentiality. Processor ensures persons authorised to process data are bound by written confidentiality obligations or appropriate statutory duties.

2.3 Security. Processor implements appropriate technical and organisational measures described in Schedule C and the public security summary at /security. Measures are reviewed at least annually and after material changes to the Service or the threat environment.

2.4 Subprocessors. Processor may engage subprocessors listed in Schedule B or added per Section 5. Processor enters into written agreements with each subprocessor imposing substantially the same data-protection obligations as in this DPA. Processor remains liable for subprocessors’ performance.

2.5 Assistance. Processor will assist Controller, taking into account the nature of processing and information available, in:

• (a) responding to data-subject requests under Chapter III GDPR (and equivalent rights), including by providing tooling in the dashboard to delete, export, or restrict Customer Data;
• (b) DPIAs and prior consultation under Art. 35–36 GDPR;
• (c) breach notification and communication under Art. 33–34 GDPR (see Section 4);
• (d) security, audit, and compliance obligations.

2.6 Return and deletion. On termination, Processor will delete personal data within 30 days (or return it on request and where technically feasible), subject to retention required by law (e.g. Polish accounting/tax retention for billing data — see Privacy Policy). Personal data inside operational backups is overwritten on rotation within 30 days.

2.7 Audits. Processor will make information necessary to demonstrate compliance available and allow audits (including inspections) once per year with 30 days’ prior written notice and at Controller’s cost, subject to confidentiality and security controls. Where Processor maintains a third-party audit report (e.g. ISO 27001, SOC 2), provision of that report may satisfy the audit right unless a competent supervisory authority instructs otherwise.

2.8 Cross-border transfers. Where Chapter V GDPR (or UK/Swiss equivalent) applies, Processor will use the mechanisms in Schedule D.

2.9 Government access. Processor will not disclose personal data to a government authority except where required by law and will, where lawfully possible, redirect the request to Controller, challenge unlawful requests, and publish statistics on government requests in an annual transparency report.

3. Controller obligations

Controller will:

• (a) have a lawful basis under Art. 6 GDPR (and Art. 9 GDPR if applicable) for the processing it instructs;
• (b) provide all notices required by law on Controller’s properties (e.g. ePrivacy/cookie banner, privacy notice) and honour data-subject rights as the controller;
• (c) not instruct Processor to process special-category data, health data, payment-card data, government IDs, biometric data, or other data that would require Controller-specific compliance programs (e.g. HIPAA, PCI) unless explicitly agreed in writing;
• (d) configure input masking and collection scope in the SDK / project settings to minimize Visitor data;
• (e) when using session replay on employee-facing or internal applications, comply with applicable employment-monitoring law (e.g. Art. 22³ Polish Labour Code requiring prior notice, purpose, and scope of monitoring);
• (f) keep ingest keys and project membership secure.

4. Personal data breach

4.1 Notice. Processor will notify Controller without undue delay and in any case within 48 hours after becoming aware of a personal data breach affecting Customer Data, with information required under Art. 33(3) GDPR where feasible as it becomes available.

4.2 Channel. Notification is sent to the billing/owner email of the affected organisation and to any additional security contact the Controller has set in dashboard settings.

4.3 No admission. Notification is not an acknowledgment of fault.

5. Subprocessor changes

5.1 Notice. Processor maintains the public list at /subprocessors. Processor will give 30 days’ prior notice by email and in-product banner before adding or replacing a subprocessor that processes personal data.

5.2 Objection. Controller may object in writing on documented data-protection grounds within 30 days of notice.

5.3 Resolution. Where parties cannot resolve the objection, Controller may terminate the affected portion of the Service and receive a pro-rata refund of prepaid fees for the unused period for that portion. Termination of the Service as a whole is a remedy of last resort where the objected subprocessor cannot be substituted.

5.4 Emergency change. Where a subprocessor change is required for security or by law, Processor may make the change immediately with prompt post-change notice and an opportunity to object as above.

6. Liability

Liability of the parties under this DPA is subject to the Limitation of Liability in the Terms of Service, without limitation of liability under Art. 82 GDPR or other mandatory law.

7. Term and termination

This DPA takes effect on the earlier of (a) acceptance at signup, or (b) the first processing of Customer Data containing personal data, and remains in effect for the duration of the Terms. Sections 2.6 (Return and deletion), 4 (Breach), 6 (Liability), and 8 (Misc.) survive termination.

8. Miscellaneous

8.1 Order of precedence. In case of conflict between (i) the Terms, (ii) this DPA, and (iii) any executed order form for the same subject matter, the DPA prevails for personal-data processing topics.

8.2 Governing law and venue. Polish law governs; venue is as set in the Terms of Service §14.

8.3 Severability. If a provision is invalid, the remainder is enforceable to the maximum extent permitted by law.

8.4 Updates. Material changes to this DPA are notified per the Terms of Service §9; the legal-bundle version is bumped.

Schedule A — Processing details (Art. 28(3) and Art. 30 GDPR)

Schedule B — Subprocessors

The current public list is at /subprocessors. The entries below are correct as of the Effective date. Material changes are notified per Section 5.

B.1 Production infrastructure (EEA processing of Customer Data)

The database and other storage layers are operated by KOHA-TECH itself within infrastructure provided by the subprocessors above and are therefore not separate subprocessors.

B.2 Billing

B.3 Pending / planned (added with Section 5 notice before activation)

• Observability / error tracking — vendor and region disclosed before activation.
• Customer-support tooling — vendor and region disclosed before activation.
• AI / LLM provider for AI features — disclosed before activation, with a contractual clause prohibiting use of Customer Data to train third-party models, and opt-in by Controller.

Schedule C — Technical and organisational measures (Art. 32 GDPR)

This Schedule states the level of protection Processor commits to provide. The exact configurations, vendor consoles, code paths, and numerical thresholds are deliberately not disclosed to preserve operational security; they are documented internally and are subject to the audit right in Section 2.7. A high-level public summary is at /security.

C.1 Governance

• A documented information-security policy and acceptable-use policy apply to all staff and contractors.
• Measures are reviewed at least annually and after material changes to the Service or the threat environment.
• Every new subprocessor goes through a documented vendor review (data-flow inventory, signed DPA, region check) before activation.

C.2 Access control

• Multi-factor authentication is enforced for all administrative access to production systems and vendor consoles.
• Access follows the principle of least privilege; administrative credentials are not shared between persons.
• Customer accounts are protected with industry-standard password hashing, rate limiting, and protection against credential stuffing.
• Session cookies are configured with secure attributes appropriate to the deployment environment, with a sliding expiry.
• Optional federated login (e.g. Google OAuth 2.0) is available for Dashboard Users with state and replay protection.

C.3 Tenancy and authorisation

• The Service is multi-tenant with strict logical separation between organisations and projects; caches and queries are scoped by tenant identifier to prevent cross-tenant access.
• Public ingest endpoints fail closed in production when project allow-lists are missing.
• Replay-asset retrieval validates outbound URLs against project-configured allow-lists, with mitigations against SSRF.

C.4 Encryption

• TLS 1.2 or higher is enforced for all public traffic, with HSTS.
• Encryption at rest is enabled for the data volume that stores Customer Data and for backups.
• Webhook integrations with the payment processor are verified using signed payloads and idempotency keys.

C.5 Network security

• Network ingress to production is restricted to a managed edge layer; internal services are not reachable from the public internet.
• A CDN/WAF layer provides volumetric mitigation, TLS termination and basic bot rules.
• The application correctly reflects the client IP when behind a proxy, for rate-limiting and security purposes.

C.6 Application security

• CSRF protection and modern cookie attributes on state-changing routes.
• Per-route rate limiting on authentication and abuse-sensitive endpoints.
• Fail-closed startup for misconfigured production environments (CORS allow-list, webhook secrets).
• Dependencies are reviewed against published security advisories.

C.7 Logging and monitoring

• Application logs are retained 30 days rolling and PII is minimised in logs.
• Authentication and authorisation events are logged with success/failure outcomes.
• Operational alerts are routed to a private channel with a no-PII rule, monitored by KOHA-TECH staff.
• Under exceptional load, the oldest Customer Data may be deleted earlier than the plan retention to maintain Service availability — disclosed in the Privacy Policy §5.

C.8 Backups and resilience

• Daily encrypted backups of the production database, retained for up to 30 days and overwritten on rotation.
• Restore is tested at least quarterly; a disaster-recovery plan is documented and reviewed annually.

C.9 Personnel

• Confidentiality obligations are part of every employment and contractor agreement.
• New staff complete a security-awareness review; refreshers are run annually.

C.10 Incident response

• A documented runbook covers detection → containment → eradication → notification → post-mortem.
• Breach-notification SLA to Controller: 48 hours from awareness.
• Public security contact: [email protected].

C.11 Data-subject rights tooling

• Controller can delete projects and individual records from the dashboard, which propagates to all storage layers.
• Bulk deletion or export is available on written request to [email protected] within the timelines required by GDPR Art. 12(3).

Schedule D — International-transfer mechanisms

D.1 Default position

Production processing of Customer Data takes place in the European Economic Area (currently in Germany). No Chapter V transfer is required for the default flow.

D.2 Payment processor (United States)

For billing, limited account data is transferred to our payment processor in the United States. The transfer relies on:

• Module 2 (Controller-to-Processor) of the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) as published in the importer’s DPA and incorporated by reference into this DPA;
• the UK International Data Transfer Addendum (where the data exporter is in the UK) and the Swiss FDPIC adaptation (where the data exporter is in Switzerland), as published by the importer;
• supplementary measures: encryption in transit, contractual confidentiality, and the importer’s transparency-report regime.

A transfer impact assessment (TIA) is maintained internally; Controller may request a summary by writing to [email protected].

D.3 Other transfers

For any other subprocessor that would process personal data outside the EEA, Processor will (a) execute the current EU SCCs with the appropriate Module, (b) add the UK / Swiss adaptations where applicable, and (c) carry out a TIA before activation. The subprocessor will be added to Schedule B under the Section 5 process.

D.4 No reliance on invalidated frameworks

Processor does not rely on any adequacy decision as a sole transfer mechanism without a fallback SCC instrument.

Contact

Processor: KOHA-TECH Sp. z o.o., ul. Nowy Świat 33/13, 00-029 Warszawa, Poland · KRS 0001183713 · NIP 5253054129 · REGON 542256381 · Share capital PLN 5,000

E-mail (DPA / privacy): [email protected] · Legal correspondence: [email protected] · Security: [email protected]