Data processing agreement (DPA)
Stand / last updated: 2026-09-03
Agreement under Art. 28 GDPR between the bakery (controller) and ZeroCrumb (processor).
1. Why this agreement is required
Cash-register receipts can contain personal data of the bakery’s customers. Since 6 September 2026 the customer name, VAT ID and address are DISCARDED AT INGESTION and never reach storage; existing records were deleted. Only product, quantity, price, time and payment method are processed. The bakery is the controller for receipt data; ZeroCrumb processes it solely on instruction.
2. Subject matter and duration
The subject matter is the provision of journal, import and forecasting functionality. Processing lasts for the term of the main agreement and at most until account deletion, subject to the statutory retention duties in section 7.
3. Categories of data and data subjects
| Category | Data subjects |
|---|---|
| Receipt data without customer identity: product, quantity, price, time, payment method, receipt number | Customers of the bakery |
| Cashier name on receipts, where the register supplies it | Employees of the bakery |
No special categories under Art. 9 GDPR are processed.
4. Processing on instruction
ZeroCrumb processes the data solely on the controller’s documented instructions and never for its own purposes. In particular, one bakery’s data is never used to train another bakery’s model — forecasting models are trained per business in isolation.
5. Sub-processors
The sub-processors listed in the privacy policy are used. Changes are announced with reasonable notice and the controller may object. See the list.
Place of processing: the application and the database are operated at netcup GmbH (Emmy-Noether-Straße 10, 76131 Karlsruhe, Germany) in the Vienna, Austria datacentre. No processing takes place outside the EU and no transfer to a third country is envisaged.
6. Technical and organisational measures (Art. 32)
The following measures are implemented in the system and have been verified:
- Tenant isolation at the database layer. Row-level security is enabled and forced (ENABLE + FORCE) on the data-bearing tables with a per-table isolation policy. Access without a valid tenant context returns nothing.
- Separated database roles with least privilege. Four separate roles. The ingestion role has no read access whatsoever to receipt data and reaches it only through narrowly defined procedures that verify the tenant themselves. Its single direct read grant is on the import review-status table, which holds no personal data and is tenant-isolated in the same way.
- Encryption of third-party credentials. Cash-register access tokens are stored encrypted with AES-256-GCM; the plaintext never appears in the database, in logs, or in responses.
- Separation of personal receipt data. Data minimisation at the boundary: customer name, VAT ID, address and the cashier’s name are discarded on import and never stored. The selection is an allow-list, so a field a provider adds later is discarded by default. A database CHECK constraint rejects any attempt to store the cashier’s name. The in-app receipt viewer returns non-personal fields only.
- Encryption in transit. TLS on all public endpoints.
- Auditability of imports. Register receipts are stored immutably. A rollback does not delete; it marks records with a timestamp and reason and is reversible.
- Two-factor authentication (TOTP). Available per user account via an authenticator app. Changing the password signs out every session on every device. Implemented and verified in the running system on 6 September 2026.
The following measures are decided but NOT yet fully implemented, and are deliberately declared as outstanding: the backup and restore procedure is built and has been rehearsed, but is not scheduled in production until the server migration; central logging of security events is prepared at the database level, but no events are written yet. This agreement must be updated once they are in place.
7. Deletion and retention
On termination all of the controller’s data is deleted, or exported beforehand on request (Art. 28(3)(g) GDPR). Deletion includes imported register receipts.
An important delimitation: the RKSV tax retention duty (roughly seven years) rests with the controller and is satisfied by the controller’s own cash register. ZeroCrumb holds only a working copy and is NOT the statutory record of retention — the controller must not rely on ZeroCrumb to discharge that duty.
During the term, rolled-back imports are not deleted but marked as voided with a timestamp and reason, so the import history remains auditable.
8. Assistance and notification
ZeroCrumb assists the controller with data-subject requests and reports personal-data breaches without undue delay after becoming aware, so the controller can meet its Art. 33 GDPR deadline.
9. Execution
This agreement is concluded together with the main agreement. A signed copy is available from [datenschutz@…]