Data Processing Addendum
Why this document exists
Your visitors never sign our Terms. They hand their name and number to your receptionist, in your lobby. Under Singapore's Personal Data Protection Act that makes you the organisation accountable for their data, and us your data intermediary — we hold it, but only because you told us to, and only to do what you asked.
This document is what your security reviewer or auditor will ask for. It sets out exactly what we do with visitor data, what we will never do, and what happens if something goes wrong.
Before you publish this
Complete every highlighted field, confirm the hosting region in clause 6 is accurate, and have this reviewed by a Singapore-qualified lawyer.
1. Parties and scope
1.1 This Addendum is between [LEGAL ENTITY NAME] (UEN [UEN]) (“Provider”) and the customer organisation (“Customer”), and applies whenever the Provider processes personal data on the Customer's behalf through the Service.
1.2 It forms part of the Terms of Service. Where this Addendum conflicts with those Terms on the subject of personal data processing, this Addendum prevails.
1.3 “PDPA” means the Personal Data Protection Act 2012 of Singapore. “Visitor Data” means personal data of the Customer's visitors, hosts and staff processed through the Service.
2. Roles
2.1 The Customer is the organisation with control over Visitor Data. The Customer decides what is collected, for what purpose, how long it is kept, and to whom it is disclosed.
2.2 The Provider is a data intermediary processing Visitor Data solely on the Customer's behalf and on its documented instructions.
2.3 The Customer's instructions are constituted by the Terms, this Addendum, and the configuration the Customer sets within the Service. The Provider will notify the Customer if it considers an instruction to breach the PDPA.
3. What we process
| Item | Detail |
|---|---|
| Subject matter | Providing a visitor check-in, host notification and visit-log service |
| Duration | For the term of the subscription, plus the 30-day export window |
| Nature | Collection, recording, storage, retrieval, transmission to an SMS provider, erasure |
| Purpose | Only to provide the Service. No other purpose. |
| Categories of individual | Visitors; the Customer's staff acting as hosts; the Customer's administrators |
| Categories of data | Name; company; mobile number; email; host; purpose of visit; check-in and check-out times; badge number; any notes the Customer enters |
| Sensitive data | None. The Service has no field for identity numbers, biometrics, photographs or health data, and the Customer must not enter them. |
4. Our obligations
The Provider will:
- process Visitor Data only on the Customer's documented instructions;
- not use Visitor Data for its own purposes, including product development, analytics sold to third parties, advertising, or training machine-learning models;
- not sell, rent or licence Visitor Data to anyone;
- implement and maintain the security measures in clause 7;
- ensure personnel with access are bound by confidentiality obligations;
- restrict access to those who need it to operate or support the Service;
- assist the Customer, at the Customer's reasonable request and cost, with access and correction requests, breach handling and regulatory enquiries; and
- delete Visitor Data in accordance with clause 11.
5. Your obligations
The Customer will:
- ensure it has a lawful basis under the PDPA for all Visitor Data it processes;
- give clear notice to visitors at the point of collection — what is collected, why, and who to contact — and obtain consent where required;
- configure retention periods appropriate to its own legal and business needs;
- keep the staff directory accurate, including host mobile numbers;
- secure its kiosk devices physically and revoke pairing for devices it no longer controls;
- appoint its own Data Protection Officer as required by the PDPA;
- not enter sensitive personal data into the Service; and
- respond to its visitors' access and correction requests, as the accountable organisation.
6. Sub-processors and transfers
6.1 The Customer authorises the Provider to engage the sub-processors below. The Provider remains responsible for their performance of the obligations in this Addendum.
| Sub-processor | Purpose | Location |
|---|---|---|
| Supabase | Database, authentication, serverless functions | [REGION — currently ap-northeast-1, Tokyo] |
| Customer's SMS provider | Message delivery | Selected and contracted by the Customer |
| Customer's web host | Serving application files | Selected by the Customer |
6.2 The Provider will give at least 30 days' notice before adding or replacing a sub-processor. The Customer may object on reasonable data-protection grounds; if the parties cannot resolve the objection, the Customer may terminate the affected Service and receive a pro-rata refund of the unused prepaid term.
6.3 Overseas transfer. Where Visitor Data is stored or processed outside Singapore, the Provider will take reasonable steps to ensure the recipient is bound by legally enforceable obligations providing a standard of protection comparable to the PDPA, as required by section 26 of the PDPA.
6.4 The SMS provider is contracted directly by the Customer. The Provider transmits the recipient number and message text to it on the Customer's instruction and is not responsible for that provider's handling of the data.
7. Security measures
The Provider maintains the following measures, which it may improve but will not materially weaken during the term:
| Measure | Implementation |
|---|---|
| Tenant isolation | Row-level security enforced inside the database, filtering every query by workspace. Isolation does not depend on application code being correct. |
| Encryption in transit | TLS for all connections |
| Encryption at rest | Provided by the hosting platform |
| Credential storage | SMS provider credentials held in an encrypted secrets vault, decryptable only server-side and never returned to any browser |
| Kiosk trust boundary | Lobby devices hold a revocable device token, not a database key. A kiosk can create a check-in; it cannot read the visit log, export staff contact details, or reach another tenant. |
| Authentication | Email and password with salted hashing; session tokens with expiry and refresh |
| Access control | Owner, admin and staff roles; administrative settings restricted to owners and admins |
| Audit logging | Meaningful events recorded with timestamp, actor and severity |
| Retention enforcement | Customer-configured periods, with automatic purging |
8. Breach notification
8.1 The Provider will notify the Customer without undue delay after becoming aware of a data breach affecting the Customer's Visitor Data, and in any event in time to allow the Customer to meet its own obligations.
8.2 The notification will describe, so far as known: the nature of the breach, the categories and approximate number of individuals and records affected, the likely consequences, and the measures taken or proposed.
8.3 The Customer is responsible for assessing whether the breach is notifiable under the PDPA and for notifying the Personal Data Protection Commission and affected individuals. Under the PDPA a breach is notifiable where it is likely to result in significant harm, or where it affects 500 or more individuals; the Commission must be notified within 3 calendar days of the organisation determining the breach is notifiable.
8.4 The Provider will provide reasonable assistance with the Customer's assessment, notification and remediation.
8.5 Nothing in this Addendum limits the Provider's own statutory duties as a data intermediary, which cannot be contracted out of.
9. Access and correction requests
9.1 Requests from individuals about Visitor Data should be directed to the Customer, which is the accountable organisation.
9.2 If the Provider receives such a request directly, it will not respond substantively. It will refer the individual to the Customer and notify the Customer promptly.
9.3 The Provider will provide the tools and reasonable assistance necessary for the Customer to locate, correct, export or delete the relevant records.
10. Audit
10.1 On reasonable written notice and no more than once per year — or following a breach affecting the Customer — the Provider will supply information reasonably necessary to demonstrate compliance with this Addendum.
10.2 Where the Customer reasonably requires an on-site or technical audit, the parties will agree scope, timing and cost in advance. Audits must not compromise the confidentiality or security of other customers' data.
11. Retention and deletion
11.1 Visitor Data is retained for the period the Customer configures, after which it is purged automatically.
11.2 On termination, the Customer may export its data for 30 days. After that, the Provider will delete it from active systems.
11.3 Data in backups is purged on the ordinary backup cycle, normally within 30 days of deletion from active systems.
11.4 The Provider may retain data where required by law, and will keep it confidential and process it only for that purpose.
12. Liability
12.1 The limitations and exclusions of liability in the Terms of Service apply to this Addendum and to any claim arising from the processing of personal data.
12.2 The indemnity at clause 14 of the Terms applies to claims arising from the Customer's instructions, configuration and failure to give notice to or obtain consent from individuals.
12.3 Clauses 12.1 and 12.2 do not limit either party's own statutory liability under the PDPA, which is not capable of being contracted out of.