Data Processing Agreement (Art. 28 GDPR)

This agreement is concluded between blockworx GmbH as the processor and the organization that accepts it as the controller. It governs every processing of personal data that blockworx carries out on that organization's behalf while operating the venMan platform.

The base instrument is Commission Implementing Decision (EU) 2021/915 of 4 June 2021 — the standard contractual clauses between controllers and processors under Art. 28(7) GDPR. Those clauses are incorporated into this agreement by reference and apply in full, in the version published in the Official Journal of the European Union.

Read the official text on EUR-Lex

The clause text is deliberately neither reproduced nor paraphrased here. Clause 2(a) of that decision does not permit the clauses to be altered, and a restatement is exactly how a divergence between the accepted text and the official one gets introduced. This page fills in the four annexes that the clauses leave to the parties.

The clauses do not cover transfers of personal data to third countries (Recital 10 of the decision). Every subprocessor outside the EEA therefore carries a transfer basis of its own; it is stated in Annex IV.

An organization accepts a specific version of this agreement in the app under Settings → Data processing. The acceptance is recorded with the version, the language, the accepting person and the time. Records can neither be edited nor deleted afterwards; a new version has to be accepted again and is recorded alongside the earlier entry rather than replacing it.

Signature and date are the acceptance record described above. No separately signed copy is exchanged.

The measures below are the ones this platform implements and that can be traced in its own source code and database schema.

• Separation between organizations is enforced by the database, not by the interface. The tables that carry the controller's data are governed by row-level security policies that are enabled and forced, so they bind the role owning the table as well, and they resolve the acting person and organization from values that are set per request rather than from anything the browser sends. A small number of internal tables used to operate the platform sit outside this mechanism; they are listed explicitly in the platform's source code, so the exception stays visible instead of being assumed away.
• The application connects as a database role that holds no privileges of its own, cannot bypass row-level security and inherits no privileges automatically. A request that never enters an organization's context therefore runs with no privileges at all and is refused with a permission error, instead of quietly reading data it was never scoped to.
• Permissions are checked per action against a capability model that fails closed: an unknown person or an unknown organization is denied rather than allowed.
• Accounts can be secured with a second factor (time-based one-time passwords). Passwords, recovery codes and terminal PINs are stored only as hashes; the secret for the one-time passwords is stored encrypted.
• The access keys for the subprocessors named in Annex IV, and the platform's own encryption keys, are read from an OpenBao vault at runtime and are not stored in the source code repository. Credentials that an organization enters for its own third-party systems are a different matter: they are stored in the platform's database, under the same separation between organizations as the rest of that organization's data.
• Administrative access to another account is flagged on the request and recorded in the audit log before the access takes effect. The database puts such a session into read-only mode, so a write is refused by PostgreSQL itself rather than by the interface; the mutating actions that carry the additional guard in the application refuse even before they reach the database.
• Security-relevant actions are recorded in an audit log. Logged-in users have no path to change or delete an entry: the database only permits writes by the platform's system role and reads by administrators of the organization the entry belongs to.
• After a subscription is cancelled, the database itself switches the sessions of that organization to read-only: data stays readable and exportable, and no new data can be written.

This annex lists what is implemented and verifiable. Measures that are not listed are not claimed.

The controller gives general authorisation for the subprocessors below. blockworx informs controllers of intended changes to this list under Art. 28(2) GDPR, so that they can object.

The base instrument does not cover third-country transfers; each entry therefore carries a transfer basis of its own.

Providers that an organization brings itself — its point-of-sale, vending or payment system, for example — are not subprocessors of blockworx. venMan only reads data from them on the instruction of the organization; they act as independent controllers on the basis of that organization's own contracts.

Providers for which code paths exist in the platform but that are not in operation, because no credentials are provisioned for them, are not subprocessors and are therefore not listed here. Their classification is visible to signed-in administrators under Settings → Data processing.