Data Processing Agreement

The customer decides what personal data to record in Data Accommodation and why. For that data, the customer is the controller (or, where it acts for another business, a processor) and we are its processor (or subprocessor).

This DPA does not cover personal data we handle for our own purposes — for example, the account details of the people who sign in, billing contacts, enquiries and our security logs. That is described in our Privacy Policy.

“Data protection law” means the privacy and data-protection laws that apply to the processing in question. Which laws apply depends on where the customer, its guests and its staff are; for a customer in Nepal this includes Nepal’s Individual Privacy Act, 2075 (2018). Where the EU or UK General Data Protection Regulation (“GDPR”) applies to the customer’s processing, section 11 also applies.

We process customer personal data only to provide, secure and support the service, and otherwise only on the customer’s documented instructions. The customer’s use and configuration of the service, the Terms of Service, this DPA and written requests from the account owner are its instructions. Instructions that would need work outside the service are agreed separately in writing.

We will tell the customer if, in our opinion, an instruction breaks data protection law, and we may decline to follow it. We may also process data where the law requires us to; where allowed, we will tell the customer first.

Data subjects

• Guests and the people staying or travelling with them; booking contacts; restaurant and room-service customers.
• The customer’s staff, contractors and other users of the platform.
• Contacts at the customer’s corporate clients, travel agents, suppliers and other business contacts.

Categories of personal data

• Identity and contact: names, email addresses, phone numbers, addresses, nationality, language.
• Reservations and stays: dates, rooms, rates, guest counts, arrival times, special requests, preferences, notes, and digital check-in records including signatures.
• Identity documents: document type, number (stored encrypted), issuing country and expiry; visa details; date of birth; and document images if the customer uploads them.
• Restaurant and room service: orders, tables or rooms, charges to the room, and dietary notes recorded by staff.
• Financial: folios, invoices, payments, refunds, deposits, company accounts and tax details. Card and wallet payments are made on the payment provider’s own page; we receive the result and reference, not card numbers.
• Inventory and purchasing: supplier contacts and the staff who recorded stock movements.
• Staff and users: names, roles, schedules, assigned tasks, sessions and the actions they take.
• Messages: email and SMS messages sent to guests through the service.
• Records of activity: audit-log entries and technical logs, including IP addresses and device information.

Nature, purpose and duration

Hosting, storing, organising, displaying, calculating with, transmitting (for example, to channels and payment providers the customer connects), backing up, exporting and deleting customer data, so that the customer can run its hotel, restaurant and related operations. Processing continues for as long as the customer uses the service and afterwards until the data is returned or deleted under section 12.

Only personnel who need access to provide, secure or support the service may access customer personal data, and they are bound by confidentiality obligations. Access by our support staff inside a customer account requires a recorded reason, uses a time-limited session and is written to the customer’s audit log.

We implement and maintain technical and organisational measures designed to protect customer personal data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access, taking into account the state of the art, the cost of implementation and the risks to individuals. They currently include:

• separation of each customer’s data enforced in the data layer, with automated tests for cross-customer access;
• role-based permissions checked on every request, including a separate permission to reveal identity numbers;
• passwords hashed with argon2id, optional time-based two-factor authentication for customer users, account lockout and rate limiting, and mandatory two-factor authentication for our own platform staff;
• encryption of identity-document numbers and two-factor secrets with AES-256-GCM, and of data in transit over HTTPS;
• an append-only, hash-chained audit log of sensitive actions, protected against changes by the database;
• validation of all input, security headers and CSRF protection on the web application;
• documented backup and restore procedures.

More detail is on our security page. We may update these measures as long as the overall level of protection is not reduced. We do not currently hold SOC 2, ISO 27001 or PCI DSS certification.

• The customer must have a lawful basis for the personal data it records, give guests and staff the notices the law requires, and obtain any consents needed — including for marketing messages.
• The customer is responsible for configuring the service appropriately: the roles it grants, enabling two-factor authentication, keeping credentials secure and deciding which integrations to connect.
• The service is designed to hold identity-document details where a hotel needs them. The customer must not enter payment card numbers or security codes, online banking credentials, or health or other sensitive data beyond what it genuinely needs and is permitted to record.
• The customer is responsible for notifications to authorities and individuals that the law requires of a controller, including after a security incident.

We will notify the customer without undue delay after becoming aware of a breach of our security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, customer personal data. The notice will describe what we know at the time — the nature of the incident, the data and people likely affected, its likely consequences and the steps taken or proposed — and we will update it as we learn more. We will take reasonable steps to contain the incident and cooperate with the customer’s investigation. Unsuccessful attempts that do not compromise data, such as failed sign-ins or blocked scans, are not incidents for this purpose.

The service gives the customer tools to answer requests from guests and staff: it can find, correct and export the data held about a guest, and anonymise a guest profile once their stays are complete, while keeping financial records the law requires.

If we receive a request directly from an individual about customer data, we will pass it to the customer (unless the law prevents us) and tell the individual to contact the customer. Taking into account the nature of the processing and the information available to us, we will give the customer reasonable help with requests it cannot answer with the tools in the service, with security, and with any data protection impact assessment or consultation with a regulator the law requires of it. We may charge for help that requires significant work beyond the service; we will agree any charge in advance.

The customer authorises us to use the subprocessors below. We require each subprocessor, by contract, to protect personal data to a standard no lower than this DPA requires for the service it provides, and we remain responsible for their performance.

Before adding or replacing a subprocessor, we will update this list and email the account owner. The customer may object on reasonable data-protection grounds within 15 days of that notice; we will then work with it in good faith to find a solution, and if we cannot, the customer may end its subscription and receive a refund of fees prepaid for the time after termination.

Services the customer chooses to connect

When the customer connects a service of its own choosing — a payment provider such as eSewa, Khalti, Fonepay or Stripe; a channel manager or online travel agency through Channex or a calendar feed; Nepal’s Inland Revenue Department (CBMS) for invoice reporting; or its own SMS or email provider — we send that service the data needed for the connection on the customer’s instruction. Those services act under their own agreements with the customer and are not our subprocessors.

Customer data is stored in Singapore. Some subprocessors listed above are based in, or process data in, the United States and other countries, so personal data may be processed outside the customer’s own country, including in countries whose data protection laws differ from it. Where the law requires a specific safeguard for such a transfer, we will put it in place with the relevant provider or, if that is not possible, tell the customer.

If the EU GDPR or UK GDPR applies to the customer’s processing of personal data in the service, the following also apply:

• We meet the processor obligations of Article 28 of the GDPR, as reflected in this DPA.
• Where a transfer of personal data from the customer to us is a restricted transfer, the parties agree that the standard contractual clauses approved by the European Commission (Decision (EU) 2021/914) — Module Two where the customer is a controller and Module Three where it is a processor — and, for the UK, the UK International Data Transfer Addendum, apply and are incorporated into this DPA, with section 3 completing their annexes and section 5 describing the security measures. A completed copy is available on request.
• The customer may audit our compliance as set out in section 13.

Details for customers subject to the GDPR (governing law of the clauses and competent supervisory authority) — to be confirmed

During the subscription, the customer can export its data at any time from Settings, in CSV, Excel or JSON format. An expired or cancelled subscription makes the account read-only; data is not deleted because a subscription lapses.

When the customer asks us to close its account, we will confirm the request with the account owner, allow time to export, and then delete or anonymise the customer’s personal data within the deletion period — to be confirmed, except data we must keep by law, which we keep protected and use only for that legal purpose until it can be deleted. Copies in backups are deleted as the backups expire.

We will make available to the customer the information reasonably necessary to demonstrate compliance with this DPA, and answer reasonable security questionnaires. Where the law requires it, or a regulator asks the customer for it, the customer may audit our compliance once a year (or more often if a regulator requires it), on at least 30 days’ written notice, during business hours, at its own cost and under a confidentiality agreement. An audit may not give access to other customers’ data or compromise the security of the service.

We do not use customer personal data to train, fine-tune or improve artificial-intelligence models, and we do not allow our subprocessors to do so. The optional operations assistant sends the question asked and the figures needed to answer it to the AI provider listed above, which processes them only to produce the answer. The assistant does not make decisions about guests or staff; its answers are suggestions for the customer’s staff to check.

This DPA lasts for as long as we process customer personal data. If it conflicts with the Terms of Service on data protection, this DPA prevails; if standard contractual clauses apply and conflict with it, they prevail. The limits of liability in the Terms of Service apply to this DPA, except where the law does not allow them to.

We may update this DPA to reflect changes in law or in our subprocessors, without reducing the protection it gives. We will notify account owners of material changes in advance.

Provider: Data Doodles Tech Pvt Ltd, registered address — to be confirmed. Data protection contact: contact form (choose “Privacy, data and legal requests”) or email support@datadoodlestech.com.