Data processing agreement (DPA)
Last updated: Sep 3, 2026
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 logbook, 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.
- Backup and restorability. Nightly database backup with 30 days of retention. Once a week a backup is automatically restored into a separate database and reconciled against the live system — an untested backup does not count as a backup. Set up and verified in the running system on 8 September 2026 (Art. 32(1)(c) GDPR).
- Security event logging. Sign-in, password change, two-factor changes, data export and account deletion are logged — minimised to account identifier, event type and timestamp. IP addresses, email addresses and user-agent strings are NOT captured; the table has no column for them. The log is append-only to the application, which can neither modify nor delete entries. Implemented on 8 September 2026.
The following measures are decided but NOT yet implemented, and are deliberately declared as outstanding: backups currently reside only on the same server as the database; an off-site copy is not yet configured, so they would not survive total loss of the server. Automated uptime monitoring and central error tracking are not yet connected. The Content Security Policy is still running in report-only mode. 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@…]