Technical and organisational measures

Effective: [privacy.effectiveDate.en]

This description of the technical and organisational measures under Art. 32 GDPR applies to all systems of [company.name] [company.legalForm] ("Handl"): the API, the website with the provider portal, partner console and admin console, the "Handl Orders" app and the "Handl" app. It is Annex 1 to the data processing agreement for businesses. Handl reviews the measures regularly and adapts them to the state of the art without reducing the level of protection.

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

1.1 Physical access control

Handl runs no data centres of its own. Servers, databases and file storage run on Google Cloud (in the European Union), whose data centres are certified to ISO/IEC 27001 and have access controls, video surveillance and security staff. Handl's offices contain no servers holding personal data.

1.2 System access control

• Providers, partners and Handl staff sign in through Firebase Authentication with email address and password; passwords are stored only as hashes.
• Customers sign in with a one-time code valid for ten minutes. Code requests are limited per IP address and per email address.
• Partners access the API with keys. Secret keys are stored only as SHA-256 hashes and shown only once; they can be revoked and replaced at any time. Publishable keys shipped in apps only allow reading the catalogue and customer sign-in.
• An invalid key is rejected and never treated as anonymous access. Failed attempts are limited per IP address.
• Consequential actions, such as closing an account, require a sign-in no older than five minutes.
• Signed-out or revoked console sessions are blocked server-side.
• Administrative access to the cloud infrastructure is restricted to named individuals and protected by two-factor authentication.

1.3 Data access control

• Every access is checked server-side. The principle is "deny unless explicitly allowed": every API endpoint is closed until it is assigned to a role, a partner scope or a signed-in customer.
• Roles: administration, provider (with the team roles owner, manager and staff), partner, customer. A provider's staff see only orders and the calendar, no amounts.
• Data is queried separately per provider, partner and customer; access to someone else's record is answered as if the record did not exist.
• Customers receive only their own orders and addresses; partners only orders from their app.

1.4 Separation control

• Test and live operation are separate: the test environment (sandbox) uses its own database and test keys; payments there are only simulated.
• Tenants (providers, partners) are separated logically by the assignment of every record.
• Development does not use live data.

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

• All connections to the website, API and apps are encrypted with TLS.
• Data in databases, file storage and backups is encrypted at rest by the cloud provider.
• Webhooks to partners and providers are signed with a secret key so the recipient can verify their origin.
• Customer sessions use signed access tokens; payment card data never reaches Handl, it is captured directly by the payment service provider.
• Deleted customer accounts are anonymised; orders that must be kept for tax reasons retain only the details required by law.

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

2.1 Transfer control

• Transmission is encrypted only (TLS).
• Fetching external calendars and delivering webhooks go through a check that prevents connections to internal or private network addresses.
• Partners and providers receive only the data required for the respective order.

2.2 Input control

• Every API request is logged with time, endpoint, response code and the partner concerned.
• Orders store their status history and changes to address or appointment with time and originator (customer, partner, provider or administration).
• Who accepted, declined, refunded or assigned an order is traceable.
• Input is validated server-side; unknown fields are rejected.

3. Availability and resilience (Art. 32(1)(b) and (c) GDPR)

• Operation on a managed cloud platform with automatic scaling and multiple instances; scheduled jobs are locked against running twice.
• Daily automatic database backups with point-in-time recovery within the backup retention period (seven days).
• API requests are limited per partner and per device to prevent overload.
• Retryable requests are executed only once via idempotency keys.
• Failed webhook deliveries and payouts are retried automatically.
• An outage of email or push services does not prevent an order.

4. Process for regular review (Art. 32(1)(d) GDPR)

• Data protection management: Handl keeps a record of processing activities and reviews it at least once a year and on every significant change.
• Data protection by default (Art. 25 GDPR): no analytics, tracking or advertising cookies; location in the app only on explicit request and only in the foreground; push notifications only after consent.
• Deletion: a daily automatic job deletes data when its period expires (including sign-in codes, ended sessions, request and webhook logs after 400 days, rejected applications after six months). Closed provider and partner accounts are cleaned up after 30 days.
• Software changes are tested automatically (unit and integration tests) and reviewed before release.
• Security incidents: Handl has a process for detecting, assessing and reporting personal data breaches within 72 hours (Art. 33 GDPR) and for notifying data subjects (Art. 34 GDPR).
• Processor control: service providers are engaged only after checking their guarantees and with a contract under Art. 28 GDPR (see recipients and subprocessors).
• Staff are bound to confidentiality and trained in data protection; access is revoked without delay when they leave.