Data Processing Agreement

Auftragsverarbeitungsvertrag (AVV) pursuant to Art. 28(3) GDPR, between the hotel as controller and Closewise as processor.

Version 2026-09-08

This is the standard text we offer. To put it in force, send a countersigned copy to our contact address. Until it is signed, the demo will not accept files containing real guest data, and the import screen requires confirmation that the file holds none.

1. Parties and scope

Controller: the hotel or hotel group that creates a Closewise account and imports data (referred to as “you”).

Processor: the operator identified in the Impressum (“Closewise”, “we”).

This agreement governs all processing of personal data we carry out on your behalf. It takes precedence over our Terms of Use for anything concerning such data.

2. Subject matter and details of the processing

The details Art. 28(3) requires the contract to set out:

2.1 Subject matter

Automated reconciliation of a food and beverage night close: matching point-of-sale checks against terminal settlements, drawer counts and the adjustment log, and presenting the resulting exceptions.

2.2 Duration

For the term of your use of Closewise. This agreement ends when your account is deleted or the business relationship ends, subject to section 4.8 on return and deletion.

2.3 Nature and purpose

Collection by upload, parsing, computation, temporary storage in memory and display back to your authorised users. The purpose is limited to producing the reconciliation you requested. We do not use your data for any purpose of our own, and specifically not to train models.

2.4 Categories of personal data

Server and staff names, and their roles, from the POS export.
Guest names and room numbers, where a check is posted to a room.
Truncated payment card data: scheme, last four digits and the acquirer approval code. Full card numbers are rejected on import.
Transaction detail: check identifiers, timestamps, amounts, table and cover counts, discount, comp and void records.
Account data of your users: name, business email, company, telephone, job role.

2.5 Categories of data subjects

Your guests, where their name or room number appears on a check.
Your employees: servers, supervisors and duty managers.
Your users of the Closewise application.

2.6 Special categories

No processing of special categories of data under Art. 9 GDPR is intended or required. You undertake not to import such data.

3. Your instructions

We process personal data only on your documented instructions. Your instructions are given by this agreement, by your configuration of the application, and by the files you choose to import. Further instructions must be in text form and are subject to agreement where they exceed the scope of the service.

We will tell you without delay if, in our opinion, an instruction infringes the GDPR or other Union or Member State data protection law (Art. 28(3), second subparagraph). We may suspend the processing concerned until the instruction is confirmed or withdrawn.

Where we are required by Union or Member State law to process beyond your instructions, we will inform you of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest.

4. Our obligations

The duties set out in Art. 28(3)(a) to (h), in the order the article lists them.

4.1 Processing only on instruction, including transfers (a)

We process only on your documented instructions, including for transfers to a third country, unless required otherwise by law as described in section 3. Our current sub-processors and the transfer mechanisms that apply to them are listed at Sub-processors.

4.2 Confidentiality (b)

Every person authorised to process your data is bound to confidentiality in writing, or is under an appropriate statutory duty of confidentiality. The obligation survives the end of their engagement.

4.3 Security of processing (c)

We implement the technical and organisational measures required by Art. 32 GDPR, set out in the annex below. We may change individual measures provided the level of protection is not reduced.

4.4 Sub-processors (d)

You grant a general authorisation for the sub-processors listed at Sub-processors. We will inform you at least 30 days before adding or replacing one, and you may object on reasonable data protection grounds within that period. If we cannot accommodate your objection, you may terminate the affected services without penalty.

Every sub-processor is bound by data protection obligations no less protective than those in this agreement. Where a sub-processor fails to fulfil them, we remain fully liable to you for the performance of that sub-processor’s obligations (Art. 28(4)).

4.5 Assistance with data subject rights (e)

Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as possible, in fulfilling your obligation to respond to requests under Chapter III GDPR. Because imported file contents are not retained beyond the session, most requests concerning guest data are answered from your own systems. Where a request reaches us directly, we will not respond to it ourselves but will forward it to you without undue delay.

4.6 Assistance with Articles 32 to 36 (f)

We assist you in ensuring compliance with the obligations in Art. 32 to 36 GDPR, taking into account the nature of the processing and the information available to us. In particular:

Personal data breach. We notify you without undue delay after becoming aware of a breach affecting your data, and in any event within 24 hours, so that you can meet your own 72-hour deadline under Art. 33(1). The notification describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences and the measures taken.
Data protection impact assessment. We supply the information about our processing that you need for an assessment under Art. 35 and any prior consultation under Art. 36.

4.7 Audit and information (h)

We make available all information necessary to demonstrate compliance with Art. 28, and allow for and contribute to audits, including inspections, conducted by you or another auditor you mandate.

In practice: we answer written questions and provide this documentation on request. On-site inspection is available during business hours with at least 14 days’ notice, no more than once a year absent a specific cause such as a breach or a supervisory authority instruction, and subject to confidentiality undertakings covering our other customers’ data.

4.8 Deletion or return at the end (g)

At your choice, we delete or return all personal data at the end of the provision of services, and delete existing copies, unless Union or Member State law requires storage.

In practice, deletion is largely already complete: imported file contents live only in memory for at most 60 minutes and are never written to disk. Deleting your account removes the remaining account and import metadata immediately. Encrypted backups held by our database provider are overwritten on their own rolling cycle, during which the data remains subject to this agreement.

5. Liability

Art. 82 GDPR governs liability towards data subjects. As between us, each party bears the share of any compensation corresponding to its part of the responsibility for the damage.

6. Term and amendment

This agreement runs for as long as we process personal data on your behalf. It may be amended in text form. Where a change in law or a supervisory authority decision requires an amendment, the parties will agree one in good faith without delay.

7. Severability and governing law

Should any provision be invalid, the remainder is unaffected; the parties will replace the invalid provision with one that comes closest to its commercial and data protection purpose. This agreement is governed by the law of the Federal Republic of Germany.

Annex — Technical and organisational measures (Art. 32 GDPR)

Structured on the categories used by the Datenschutzkonferenz in Kurzpapier Nr. 13, which is the framing German supervisory authorities expect.

Pseudonymisation and encryption (Art. 32(1)(a))

TLS 1.2 or higher for all connections, with HSTS enforced.
Database encrypted at rest by the provider (AES-256); connections require SSL.
Passwords stored only as bcrypt hashes at cost factor 12; never in clear text or reversibly.
Verification and password reset tokens stored only as SHA-256 hashes, so the stored value cannot be used.
Application logs identify people by opaque user id, never by email address; card-shaped and address-shaped values are redacted before a log line is written.
Full payment card numbers are refused on import, so cardholder data never enters the system.

Confidentiality (Art. 32(1)(b))

Physical access: no own data centre. Hosting and database run in providers’ certified facilities (ISO 27001 / SOC 2); staff work on encrypted devices with full-disk encryption.
System access: individual accounts, no shared logins. Administrative access to the hosting and database consoles requires multi-factor authentication. Sign-in is throttled per IP and per account.
Data access: every query is scoped to the authenticated account; authorisation is enforced in the server-side data access layer rather than at the network edge. The application connects to Postgres as a least-privilege role with no schema-modification rights.
Separation: production, staging and development use separate databases and separate credentials. Development never uses production data.

Integrity (Art. 32(1)(b))

Transfer control: TLS everywhere; no personal data in URLs or query strings; a strict referrer policy so tokens cannot leak through a Referer header.
Input control: an append-only audit trail records sign-ins, failures, password changes, data exports and deletions, with the acting user id, the source address and a timestamp.
Validation: every request body, query string and path parameter is schema-validated at the boundary; database access is parameterised throughout, so input cannot alter a query.

Availability and resilience (Art. 32(1)(b))

Managed Postgres with automated daily backups and point-in-time recovery.
Restores are tested, not merely configured; an untested backup is not a backup.
Managed hosting with automatic restart and health checks.
Rate limiting on authentication and import endpoints to resist resource exhaustion.

Restoration of availability (Art. 32(1)(c))

Point-in-time recovery to any moment within the provider’s retention window.
Infrastructure is reproducible from the repository, so the application can be redeployed from source.
Documented breach response runbook with named responsibilities and the Art. 33 deadline.

Regular review (Art. 32(1)(d))

Dependency vulnerability scanning on every build; automated update pull requests.
Secret scanning over the repository and its history.
Content Security Policy and the other security headers monitored in report-only mode before enforcement.
These measures are reviewed at least annually and after any significant change to the processing.

Data minimisation and purpose limitation

Imported file contents are held in memory only, for at most 60 minutes, and are never written to disk.
Only import metadata is persisted: file name, row count, timestamp, column mapping.
Published retention periods are enforced by a scheduled purge, not by intention.
Deleting an account removes all dependent records in the same operation.
No third-party analytics, tracking or advertising code, and no third-party fonts or CDNs.

Sub-processors at the date of this version

Railway (Railway Corp., United States) — Application hosting and runtime logs; EU region (Amsterdam) where selected; control plane in the US.
Supabase (Supabase, Inc., United States) — Managed PostgreSQL database and backups; eu-west-1 (Ireland).
Resend (Resend, Inc., United States) — Transactional email (address verification, password reset); United States, with an EU region available.
Cloudflare (Cloudflare, Inc., United States) — Turnstile bot protection on the sign-up form; Global edge network; EU data localisation available.