Data Processing Agreement

dekimu.com is a marketing website and collects no personal data of its own. This Data Processing Agreement (the “DPA”) does not govern dekimu.com. It is the ecosystem-wide canonical agreement that applies wherever Dekimu Labs S.L. (CIF B55431357, Spain — the “Processor”) processes personal data on behalf of a business customer (the “Controller”) through the Dekimu apps and services — for example Dekimu Hub and Invoice Up.

In those services, the Controller decides why and how end-user personal data is processed; Dekimu Labs S.L. processes it only to provide the service. This DPA forms part of, and is subordinate to, the terms of service the Controller accepts for each app. Where Dekimu Labs S.L. acts as controller in its own right (for example, account authentication, billing, or its own marketing), its Privacy Policy and Records of Processing apply instead — not this DPA.

This DPA gives effect to Article 28(3) of the EU General Data Protection Regulation (Regulation (EU) 2016/679, “GDPR”) and the Spanish implementing law (Ley Orgánica 3/2018, LOPDGDD). It applies to Controllers across the EU and EEA.

Subject-matter: the processing of personal data that the Controller submits to, or generates within, a Dekimu app while using it.

Duration: for as long as the Controller’s account or subscription for the relevant app is active, plus any post-termination period set out in Section 10.

Nature and purpose: hosting, storing, transmitting, and operating on personal data strictly to deliver the contracted features of the app — for example payment follow-up and reminders in Invoice Up, or workspace, client, and content management in Dekimu Hub. Dekimu Labs S.L. does not use Controller personal data for its own profiling, advertising, or model training.

These categories reflect Dekimu’s Records of Processing Activities (RoPA, GDPR Art. 30). The exact set depends on the app and how the Controller uses it.

Data subjects may include: the Controller’s own staff and authorised users; the Controller’s clients and contacts; and individuals named in records the Controller creates (for example, billing contacts or recipients of reminders).

Personal data categories may include:

• Identification — name, email address (email is also used for account sign-in and to send invoices)
• Contact — the Controller’s own business postal address, where it supplies one for its invoices or letterhead (not collected for the Controller’s clients or contacts)
• Financial — invoice amounts, tax identifiers, payment status (where the app handles this)
• Technical — login times, and (for external/auditor access) a hashed IP address and user-agent recorded in a workspace audit trail. Raw IP addresses are otherwise used only transiently to rate-limit requests and are not stored.

Dekimu processes only the personal data strictly necessary to deliver the contracted features. Certain content is encrypted in the Controller’s browser to its vault key and stored by Dekimu only as ciphertext (Section 5); that content is not accessible to Dekimu as readable personal data. This does not apply to all data: Section 5 lists what remains readable by Dekimu’s servers, and Dekimu processes that data in readable form, protected by encryption in transit and at rest. The app annexes below set out the detail for each app.

Dekimu’s services are not designed to process special categories of data (Art. 9). The Controller agrees not to submit special-category data unless a written addendum is agreed in advance.

Dekimu Labs S.L. will:

• process personal data only on the Controller’s documented instructions, including for international transfers, unless required to act otherwise by EU or Spanish law (in which case it will inform the Controller first, where legally permitted). The Controller’s instructions are this DPA and the app’s configuration and feature set;
• immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other data-protection law;
• ensure that everyone authorised to process the data is bound by a duty of confidentiality;
• not process the data for any purpose other than providing the service.

Dekimu Labs S.L. applies technical and organisational measures appropriate to the risk, including:

• Client-side encryption to the vault key, for certain content. Certain content is encrypted in the Controller’s browser to the Controller’s vault key (“sealed”) and stored by Dekimu only as ciphertext. This does not cover all data. Across the ecosystem, the account email, Tax ID, legal name, address and country remain readable by Dekimu’s servers, because they are needed for invoicing and identity. The IBAN is sealed. Per app:
  • Invoice Up — some flows receive fields in readable form instead of sealing them: invoice import, e-invoice intake, actions taken from Dekimu Hub, and the v1 API (including the Tax ID and the payment reference). Data arriving through those flows is protected by encryption in transit and at rest, not by client-side sealing.
  • Dekimu Hub — content is sealed only where the Controller’s vault is used. Accounts and paths without a vault are readable by Dekimu’s servers. The Backup Vault annex below sets out that module.
  • miniterms — document drafts saved with the Controller’s vault, and the subject details and notes of a data subject request once it is sealed to the vault, are encrypted to the vault key. Other miniterms data is readable by Dekimu’s servers.
• Encryption in transit — all traffic is served over HTTPS with HSTS.
• Access controls — scoped, authenticated access; per-app entitlement; signed session tokens; rate-limited authentication endpoints.
• Encryption at rest for credential material and stored records held by our infrastructure providers.
• Segregation and least privilege — operational access is limited to the people who need it, and is logged.

Where content is sealed to the vault key, an attacker reaching stored data finds ciphertext for that content. This does not extend to data that is readable by Dekimu’s servers as described above; a breach reaching that data will be treated as a breach of readable data under Section 8.

The Controller gives general authorisation for Dekimu Labs S.L. to engage sub-processors to deliver the service. Each sub-processor is bound by data-protection obligations no less protective than this DPA. As of the date above, the sub-processors are:

• Vercel (Vercel Inc., via Vercel International BV) — compute, hosting, content delivery, and edge logs · EU region
• Upstash — managed Redis data storage · EU region
• Resend — transactional and notification email delivery, including, in miniterms, the signer’s copy of a countersigned document, which contains the document’s full text · EU region
• Stripe (Stripe Payments Europe Ltd) — subscription payment processing · Ireland (EU). Card data never touches Dekimu infrastructure; Stripe tokenises it
• Accounting agent — bookkeeping and statutory tax filings (named in our vendor register, under a bilateral DPA) · Spain

We will give the Controller advance notice of any intended change to this list (addition or replacement of a sub-processor). The Controller may object on reasonable data-protection grounds within 14 days of notice. If we cannot resolve the objection, the Controller may terminate the affected service. Where any sub-processor is located outside the EEA, the transfer is covered by the EU Standard Contractual Clauses (see Section 12).

The Controller is responsible for responding to requests from data subjects (access, rectification, erasure, restriction, portability, objection). Taking into account the nature of the processing, Dekimu Labs S.L. will assist the Controller by appropriate technical and organisational measures — including the self-service export, edit, and deletion tools built into the apps — to help the Controller fulfil those requests. If a data subject contacts us directly about Controller data, we will redirect them to the Controller.

Dekimu Labs S.L. will notify the Controller without undue delay after becoming aware of a personal data breach affecting the Controller’s data — our internal target is within 48 hours. The notification will describe, as far as known, the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed. This helps the Controller meet its own 72-hour notification duty under Art. 33 where applicable. We will also reasonably assist the Controller in communicating with data subjects under Art. 34 where required.

Taking into account the nature of the processing and the information available to us, Dekimu Labs S.L. will provide reasonable assistance to the Controller with data protection impact assessments (Art. 35) and prior consultation with the supervisory authority (Art. 36) where the Controller’s use of a Dekimu service requires them.

On termination of the relevant service, and at the Controller’s choice, Dekimu Labs S.L. will return or delete all personal data processed on the Controller’s behalf, and delete existing copies, unless EU or Spanish law requires retention. Where the Controller does not make a choice, we will delete the data after a reasonable grace period that lets the Controller export it first. Some records may be retained for the periods required by Spanish accounting and tax law (for example, six years under Art. 30 of the Código de Comercio); those are held only for that legal purpose.

Dekimu Labs S.L. will make available to the Controller the information reasonably necessary to demonstrate compliance with Art. 28, and will allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates. In the first instance we will satisfy audit requests by providing documentation (this DPA, our security overview, sub-processor list, and relevant provider certifications). On-site inspections are subject to reasonable notice, confidentiality, and scheduling so as not to disrupt the service or other customers.

Personal data is processed within the EU/EEA wherever possible; our application-layer infrastructure and primary sub-processors are configured for EU regions. Where any sub-processor processes personal data outside the EEA, Dekimu Labs S.L. relies on the European Commission’s Standard Contractual Clauses (SCCs) as the transfer mechanism, supplemented by additional safeguards where needed. Transactional emails necessarily reach recipient mail servers that may be located anywhere; that routing is necessary to perform the contract (Art. 49(1)(b)).

Each party is liable for its own breaches of the GDPR and of this DPA, in accordance with Art. 82. Liability caps and exclusions in the app’s terms of service apply to this DPA. This DPA is governed by the laws of Spain. The competent supervisory authority is the Agencia Española de Protección de Datos (AEPD), without prejudice to the Controller’s right to engage its own lead supervisory authority. Disputes are subject to the courts of Spain, without prejudice to mandatory rules of the Controller’s jurisdiction.

Data-protection matters and DPA requests: Dekimu Labs S.L. (CIF B55431357) · legal@dekimu.com. To request a countersigned copy of this DPA, email the same address.

If we make material changes — including completing external legal review or updating the sub-processor list — we will update the “Last updated” date at the top of this page and, for sub-processor changes, give notice as set out in Section 6.

This annex governs the Backup Vault module of Dekimu Hub. It supplements the sections above for that module; where it is more specific, it prevails for the module’s processing. Like the rest of this DPA, it is published for transparency under the review-pending notice at the top of this page.

D.1 Subject-matter and purpose. The module lets the Controller keep an independent daily backup of its own data held at external SaaS vendors. The Controller connects its GitHub account (OAuth) and/or its own Stripe account (a pasted restricted key). A daily scheduled job pulls one snapshot per connected vendor — for GitHub, the Controller’s owned repositories and issues metadata; for Stripe, the Controller’s own customers, subscriptions and invoices — encrypts each snapshot to the Controller’s workspace vault public key, and stores only the ciphertext. Restore is client-side decryption by the Controller; Dekimu has no server-side decryption path for snapshot content.

D.2 Roles and instruction. The Controller is the controller of its vendor accounts and of the data in them. Dekimu processes as processor, on the standing documented instruction constituted by the Controller’s act of connecting a vendor together with this annex.

D.3 Lawful basis — Controller’s warranty. The Controller warrants a valid legal basis for the backup — ordinarily its legitimate interest (Art. 6(1)(f)) in an independent, vendor-outage-surviving backup of its own operational data — and warrants that its basis extends to the third parties whose data appears inside snapshot content (D.4). Snapshot content reaches Dekimu only as ciphertext, so Dekimu cannot itself assess what the snapshots contain.

D.4 Data subjects. Primarily the Controller itself. Secondarily, third parties inside snapshot content — the Controller’s own Stripe customers (names, emails, billing records) and GitHub issue participants — whose data reaches Dekimu only as ciphertext Dekimu cannot read.

D.5 Held vendor credentials — express statement. This module is the only Dekimu service surface on which Dekimu holds server-usable credentials to the Controller’s accounts at third-party vendors, and an unattended scheduled job unseals and uses them, by design. The parties agree the following as fact, not as marketing:

• (a) GitHub. The held OAuth token carries GitHub’s classic scopes repo, read:org, read:user. The classic repo scope grants read and write on repository contents, and no read-only classic scope exists — so the held credential is write-capable, even though the module only ever calls read endpoints.
• (b) Stripe. The Controller supplies a restricted key (rk_) for its own Stripe account. Restricted does not mean read-only: the key’s permissions are chosen by whoever creates it, and Dekimu cannot verify that a pasted key is read-only — the connection check proves the key can read; no check can prove it cannot write. The Controller is instructed to create the key with read permissions only, and warrants that it has done so and will not widen the key’s permissions while it is held.
• (c) Custody. Credentials are sealed at rest with a dedicated server-held key (field-level encryption that fails closed — an un-sealed value is refused, not passed through) and are unsealed server-side by the scheduled job each time a snapshot is taken.
• (d) The honesty line. Because snapshot content is encrypted to the Controller’s workspace key, Dekimu cannot read the Controller’s stored backups. Because the held credentials are server-usable, Dekimu does not claim to have no access to the Controller’s data: the credentials could re-fetch equivalent data from the vendor at any time. Dekimu commits that the module’s software uses the credentials solely to take the snapshots described in D.1, and will not repurpose them without amending this annex and giving notice as set out in Section 6.

D.6 Snapshot content is ciphertext to Dekimu. Content is encrypted to the workspace vault public key before storage and stored as a private object; the decrypting private key belongs to workspace members and the server never holds it. Server-readable per snapshot is metadata only: date, vendor, timestamp, storage path, ciphertext size, object count, an integrity hash of the plaintext for post-restore verification, encryption mode and key id, and status.

D.7 Breach posture — content and credentials diverge. For snapshot content, Section 8 applies to what Dekimu holds: ciphertext. For the held credentials, a ciphertext-based low-severity position does not apply: a breach reaching the sealed credentials together with the sealing key exposes server-usable — and per (a)–(b) above, possibly write-capable — credentials to the Controller’s vendor accounts. In that event Dekimu’s breach notice will say so, will not characterise the compromise as low-risk on ciphertext grounds, and will identify the affected vendor connections so the Controller can revoke the credentials at the vendor — vendor-side revocation is the effective containment step and only the Controller can exercise it.

D.8 Sub-processors for this module. Vercel (compute, hosting and object storage for snapshot ciphertext, EU region) and Upstash (sealed credentials, snapshot metadata, work queue and pending-deletion list, EU region). Only these two — the other sub-processors listed in Section 6 do not process personal data for this module.

D.9 Outbound use of the credential. Each daily pull transmits the held credential to the Controller’s own vendor API (api.github.com, api.stripe.com — fixed destinations). This is Dekimu performing the Controller’s standing instruction inside the Controller’s pre-existing vendor relationship, using the credential the Controller supplied for exactly that purpose; the vendor processes the Controller’s data under the Controller’s own vendor terms, not on Dekimu’s behalf. It is neither a sub-processor engagement nor an international transfer by Dekimu. No other data leaves.

D.10 Retention and deletion. One snapshot per vendor per day (a same-day re-run overwrites in place), retained under the Controller’s plan cap. Disconnecting a vendor purges that vendor’s ciphertext and snapshot metadata and removes the sealed credential. Deletion also operates through retention pruning and the account-deletion cascade, which removes sealed credentials, snapshot metadata, queue entries and all ciphertext. Section 10 applies on termination. The vendor remains the primary record holder throughout.

D.11 Credential lifecycle. Credentials are held until vendor disconnect or revocation. No automatic credential rotation exists today. Dekimu’s target — approved internally, not yet shipped — is a 12-month maximum held-credential age with a re-authentication prompt. This is stated as an intent, not an existing measure.

D.12 No AI processing. Snapshot content is not used for profiling, advertising or model training (Section 2) — and could not be: it is ciphertext to Dekimu.

This annex governs miniterms (miniterms.com). It supplements the sections above for miniterms; where it is more specific, it prevails for miniterms’ processing, including over the description of encryption in Sections 3 and 5. Like the rest of this DPA, it is published for transparency under the review-pending notice at the top of this page.

M.1 What is encrypted to the Controller’s vault key, and what is not. In miniterms, the encryption on the user’s device described in Sections 3 and 5 applies to document drafts saved with the Controller’s vault, and to the subject details and notes of a data subject request once it is sealed to the vault. Dekimu’s servers refuse those drafts in readable form and store them only as ciphertext encrypted to the Controller’s vault key. Other miniterms data is readable by Dekimu’s servers, including: the issuer identity printed on documents (legal name, tax ID, registered address and contact emails, sealed at rest with a key Dekimu holds); the AI-use details and website address in the business profile; the subprocessor register; the clause library; records of processing; AI Act assessments; breach records; policy-change notices; cookie-policy text produced by the scanner; the status, type and deadlines of data subject requests at all times, and their full content until they are sealed to the vault (a request received through the public intake form is sealed only once the Controller has set up its vault); and the countersignature material described in M.2 to M.7. Drafts saved before the vault was required stay readable until they are moved into the vault.

M.2 Countersignature: what is processed. When the Controller sends a document for countersignature, Dekimu processes the email address the request is sent to and the text of the document the counterparty reads and signs. On signature it records the signer’s name, the email address they sign with, their IP address, the time of signature and the document’s SHA-256 fingerprint. The signature is an electronic signature within the meaning of Article 3(10) of Regulation (EU) No 910/2014; it is not an advanced or qualified electronic signature.

M.3 Readable copies, on the Controller’s instruction. Countersignature requires the counterparty to read what they sign, so the document text is readable by Dekimu’s servers in each case below. Anyone who holds the signature link can read the document while the link is active (up to 14 days).

• (a) Shared copy of a vault document. To send a document encrypted to its vault key, the Controller confirms in the dashboard that it wants to share a readable copy; its browser then decrypts the document and sends Dekimu that copy. This confirmation is the Controller’s documented instruction (Article 28(3)(a) GDPR) to hold the copy readable and to disclose it to the counterparty.
• (b) Readable document. A document still stored readable (saved before the vault was required and not yet moved into the vault) is sent from its stored text.
• (c) Signed record. When the counterparty signs, Dekimu keeps the text they signed, readable, together with the details in M.2, as the signed record, subject to M.4.

M.4 Retention and deletion.

• A shared copy that has not been signed is deleted immediately when the Controller cancels the request or replaces it with a new request for the same document, and no later than one day after the link expires unsigned.
• The signed record is kept while the Controller’s account exists, for up to six years from signature, and is deleted when the account is deleted.
• Saving the document again from the vault does not remove the signed text of a shared copy.
• Where a document was signed while stored readable and is later moved into the Controller’s vault (when the Controller saves it from the vault, or automatically when the Controller next unlocks its vault), Dekimu deletes its readable copy of the signed text if Dekimu’s records show that the signer’s copy was sent to them by email (M.5). Where they do not (the copy was not sent because of the sending limit, the send failed, or the signature predates that record), the signed text is kept on the terms above. The other details in M.2 are kept in every case.
• Cancelling a request cannot undo a signature already made or recall copies already emailed or downloaded.

M.5 Email. The invitation email carries a link, not the document. When the counterparty signs, Dekimu emails the full text of the signed document, with its fingerprint, to the email address the signer signed with, which may differ from the address the request was sent to. Where it differs, a daily sending limit applies per Controller; if the limit is reached or cannot be checked, or the send fails, the copy is not sent and the signature stands. The Controller is notified of the signature by an email that does not contain the document.

M.6 Export. Shared copies awaiting signature and signed records, including the signed text where it is kept and whether it was a shared copy, are included in the Controller’s data export, available from the dashboard at any time.

M.7 Security. The signature link can be used to sign only once, is stored only as a hash and expires after 14 days. A shared copy is written once and is accepted only if it matches the fingerprint the Controller’s browser recorded when the document was saved to the vault. The Controller’s audit log records each shared copy created, deleted and signed with identifiers and fingerprints only, never content. The countersignature material in M.3 is not encrypted to the Controller’s vault key; the encryption in transit and at rest in Section 5 applies. In a breach reaching this material, Dekimu’s notice under Section 8 will treat it as readable data, not as ciphertext.

M.8 Sub-processors for countersignature. Vercel (compute and hosting, EU region), Upstash (the records, links and copies, EU region) and Resend (delivery of the invitation, the Controller’s notification and the signer’s copy, which contains the full document text, EU region).