Data Processing Agreement (template).

How to read this template.

The processing covered differs by deployment mode, so the template carries two scopes rather than two documents:

• Scope A — Vendor-hosted (self-serve): TensorPlane operates the platform on EU infrastructure and, in the course of running reviews, processes customer code and prompts, which may contain personal data. Heavier processor role.
• Scope B — Customer-operated (enterprise): the platform runs on the customer's own infrastructure; customer code and model traffic never transit TensorPlane. TensorPlane processes licensing telemetry only. Narrow processor role.

The distinction is load-bearing: a term correct for Scope A is meaningless for Scope B, where that data never reaches us. The two are not merged.

Parties and roles.

Controller: [CUSTOMER LEGAL ENTITY] (“Customer”), the controller of the personal data processed under the Agreement.

Processor: Blockforo s.r.o., company ID / IČO 21654093 (VAT DIČ CZ21654093), registered seat Rybná 716/24, Staré Město, 110 00 Praha 1, Czech Republic (“TensorPlane”), processing personal data on the Customer's documented instructions. [Attorney: confirm the entity against ARES before execution.]

This DPA forms part of, and is subject to, the Master Services Agreement between the parties. On any conflict about personal-data processing, this DPA prevails. Governing law and jurisdiction follow the Agreement (see the governing-law clause).

Subject matter, duration, nature and purpose.

Instructions, confidentiality, and security.

§3 — Documented instructions (Art. 28(3)(a)). TensorPlane processes personal data only on the Customer's documented instructions, including on international transfers, unless required by Union or Member State law; in that case it informs the Customer before processing unless the law prohibits it. The Agreement, this DPA, and the Customer's configuration constitute the complete documented instructions. TensorPlane informs the Customer if, in its opinion, an instruction infringes data-protection law.

§4 — Confidentiality (Art. 28(3)(b)). Persons authorised to process the personal data are committed to confidentiality or under an appropriate statutory obligation.

§5 — Security of processing (Art. 28(3)(c) / Art. 32). TensorPlane implements the technical and organisational measures in Annex 2 to ensure a level of security appropriate to the risk.

Sub-processors (Art. 28(2) and (4)).

TensorPlane has the Customer's general authorisation to engage the sub-processors listed in Annex 3. It informs the Customer of any intended addition or replacement at least 30 days in advance [proposed; attorney to confirm], giving the Customer the opportunity to object on reasonable data-protection grounds.

TensorPlane imposes on each sub-processor, by written contract, data-protection obligations no less protective than those in this DPA, and remains fully liable for the sub-processor's performance.

Model providers reached under the Customer's own keys and contracts are the Customer's own controllers/processors, not TensorPlane sub-processors, in both scopes. Annex 1 and Annex 3 state this precisely — it is a defining feature of the product and must not be misdescribed.

Assistance, breach notice, and audits.

§7 — Data-subject rights (Art. 28(3)(e)). Taking into account the nature of the processing, TensorPlane assists the Customer, insofar as possible, in responding to requests to exercise data-subject rights under Chapter III of the GDPR.

§8 — Breach, security, DPIA (Art. 28(3)(f) / Arts. 32–36). TensorPlane notifies the Customer without undue delay and in any event within 48 hours after becoming aware of a personal-data breach affecting the Customer's data [proposed 48h so the Customer retains margin within its own Art. 33 72-hour deadline; attorney to confirm], with the information the Customer needs to meet its Article 33/34 obligations, plus assistance with DPIAs (Art. 35) and prior consultation (Art. 36) where applicable.

§9 — Audits (Art. 28(3)(h)). TensorPlane makes available the information necessary to demonstrate Article 28 compliance, and allows for and contributes to audits, subject to 30 days' prior written notice, no more than once per 12 months (and additionally after a personal-data breach or where a supervisory authority requires it), during business hours, under confidentiality, at the Customer's cost [proposed; attorney to confirm]. Available assurance includes each sub-processor's third-party security assurance reports where offered.

Return or deletion at end of processing (Art. 28(3)(g)).

At the Customer's choice, TensorPlane deletes or returns all personal data after the end of the services, and deletes existing copies unless Union or Member State law requires storage — notably the 10-year Czech retention of financial and tax records (VAT Act 235/2004; AML Act 253/2008), which is exempt from erasure for that period. The deletion/return period for non-retained classes is 30 days [proposed; attorney to confirm].

International transfers, liability, and precedence.

§11 — International transfers. Where personal data is transferred outside the EEA, the transfer is made under an appropriate Article 46 safeguard (Standard Contractual Clauses) or an adequacy decision. Scope A (vendor-hosted) asserts EU data residency, so intra-EEA processing is the design intent; any exception is listed in Annex 1 with its transfer mechanism. Onward transfers arise mainly from our operational suppliers — Stripe (billing), GitHub (vendor-hosted source control), and Cloudflare (transactional email) — each under the EU-US Data Privacy Framework where certified, otherwise EU Standard Contractual Clauses. [Attorney to confirm the basis per route.]

§12 — Liability, term, and precedence. Governed by the Agreement. [Cross-reference the Agreement's liability cap and term clauses; confirm no conflict with this DPA's §10 survival.]

Description of processing (select the applicable scope).

Technical and organisational measures (Art. 32).

The following measures are implemented and tested — nothing aspirational is listed:

• Tenant isolation: forced PostgreSQL row-level security with a per-organisation policy, a transaction-bound tenant context, and a restricted application database role. Cross-tenant read/write and missing-context tests enforce it.
• Credential custody at rest: provider credentials are sealed before storage with AES-256-GCM under KMS-wrapped data-encryption keys; readback exposes only masked metadata.
• Access control: console access is authenticated with server-validated sessions and a WebAuthn second factor, with secure cookies, exact-origin and CSRF protection, and request-rate controls; tenant permissions cannot authorise staff operations.
• Audit: covered security-sensitive operations are recorded as redacted, append-only events that the application role cannot update or delete.
• Encryption in transit (stated subset): the production public API uses TLS ≥1.2; tenant-scoped HTTP egress requires HTTPS with certificate verification; the network-accessible custody seam requires mutual TLS.

Not claimed (not implemented, only partial, or gated — kept out of this Annex until shipped and verified): completed data erasure (execution gated — see §10); customer data export / portability (built as a core, not yet reachable); universal at-rest or universal in-transit encryption; continuously hash-linked or externally-witnessed audit; sandbox / guest isolation; backup / RPO-RTO guarantees. [Attorney + engineering to confirm this list against the deployed configuration before execution.]

Authorised sub-processors.