OrderToDock Data Processing Agreement

Version 1.1. Effective 10 November 2026.

This Data Processing Agreement ("DPA") forms part of the OrderToDock Terms of Service between OTD Technologies Pte. Ltd. ("OrderToDock") and the Customer. Capitalised terms not defined here have the meaning given in the Terms.

1. Roles and scope

1.1 This DPA applies to personal data in Customer Data that OrderToDock processes on the Customer's behalf in providing the Service ("Customer Personal Data").

1.2 The Customer is the organisation that determines the purposes for which Customer Personal Data is processed. OrderToDock processes it on the Customer's behalf and on the Customer's documented instructions, and for the PDPA is a data intermediary of the Customer. Where the GDPR applies (section 13), the Customer is the controller and OrderToDock is the processor.

1.3 The Terms and the Customer's configuration and use of the Service are the Customer's documented instructions. OrderToDock will tell the Customer if it believes an instruction breaches the PDPA or other data protection law.

1.4 Data OrderToDock controls. OrderToDock is responsible, as an organisation in its own right, for:

(a) Authorised Users' account and sign-in data, which OrderToDock needs to run accounts;

(b) mail and messages that reach OrderToDock but cannot be matched to any customer's Workspace, which OrderToDock holds outside every Workspace (section 7.4); and

Paddle, the Merchant of Record for purchases of the Service, handles purchase and payment data as an organisation in its own right, not on the Customer's instructions (section 10.6).

2. Data subjects, data and purposes

2.1 Data subjects.

(a) Supplier Contacts: people at the Customer's Suppliers who send or receive messages through the Service, and people who receive a truck-leg link because they arranged a truck.

(b) Authorised Users: the Customer's staff who use the Service.

(c) Other people named in Customer Data, for example a person mentioned in a Supplier's message or a delivery contact on an order.

2.2 Categories of personal data.

(a) Supplier Contact records: full name, job title, email addresses, telephone number, WhatsApp number, and postal addresses.

(b) Messaging identifiers: the email addresses messages are sent to and from, and, where the WhatsApp channel is enabled, the sender's WhatsApp telephone number.

(c) Message contents: the subject, body, sender name and headers of emails sent and received, including email authentication results (SPF, DKIM, DMARC), and the text of WhatsApp messages where enabled.

(d) Attachments and uploaded files, which may contain any personal data the sender included.

(e) Order data: purchase orders, order lines, dates, quantities, prices, delivery addresses, and the history of changes to them, including comments a Supplier types on the supplier page.

(f) Authorised User data: name, email address, profile image if provided by a sign-in provider, role, session records (including IP address and browser user agent), and actions recorded in the audit log.

(g) Truck-leg data: the email address and optional name of the person a truck-leg link was sent to, what they confirmed and when, and any photo they added. The Service does not ask for, read or store a location.

(h) Support requests: what the Customer's Authorised Users write to OrderToDock, and OrderToDock's answers.

2.3 Special categories. The Service is not designed to process sensitive personal data, such as health data, national identity numbers or financial account details. The Customer should not send it, and should ask Suppliers not to.

2.4 Purposes. OrderToDock processes Customer Personal Data only to:

(a) send orders and related messages to Supplier Contacts on the Customer's behalf;

(b) receive, file and display Suppliers' replies and attachments;

(d) import data the Customer uploads;

(e) suggest and complete postal addresses;

(f) keep an audit record of changes;

(g) secure, support, back up and troubleshoot the Service;

(h) where set up for the Customer, tell a system the Customer chose that an order has changed, without the order's contents; and

(i) comply with law.

2.5 Duration. For the term of the Terms and the post-termination periods in section 7.

3. PDPA obligations of the Customer

The Customer is responsible for meeting the PDPA's obligations that fall on the organisation, including:

(a) Consent and notification: obtaining any consent and giving any notification required for collecting Supplier Contacts' personal data and for disclosing it to OrderToDock and its sub-processors, including that messages are read with the help of AI Features and may be processed outside Singapore (section 10). The PDPA's data protection provisions do not apply to business contact information that a person provides for business purposes, but message contents and attachments may contain other personal data;

(b) Purpose limitation: using the Service only for purposes a reasonable person would consider appropriate in the circumstances;

(c) Access and correction: responding to individuals' requests to access or correct their personal data, with OrderToDock's help under section 8;

(d) Accuracy: taking reasonable steps to ensure that supplier and contact data it enters or imports is accurate and complete;

(e) Data breach notification: assessing and notifying the Personal Data Protection Commission ("PDPC") and affected individuals as section 9 describes; and

(f) Accountability: appointing its own data protection officer and handling complaints from individuals.

4. OrderToDock's obligations

As data intermediary, OrderToDock will:

(a) Process only on instructions: process Customer Personal Data only for the purposes in section 2.4 and on the Customer's instructions, unless the law requires otherwise, in which case it will tell the Customer first where the law allows;

(b) Protection: make reasonable security arrangements to protect Customer Personal Data against unauthorised access, collection, use, disclosure, copying, modification or disposal, and against loss of any storage medium, as described in section 6;

(c) Retention limitation: keep Customer Personal Data no longer than the Customer instructs or the Terms allow, as described in section 7;

(d) Breach notification: notify the Customer of a data breach as described in section 9;

(e) Confidentiality of personnel: ensure that everyone it authorises to process Customer Personal Data is bound by a duty of confidentiality;

(f) Accuracy support: process Customer Personal Data as received and not alter it except as the Service's documented functions or the Customer's instructions require; and

(g) No sale: never sell Customer Personal Data or use it for marketing.

5. How the Service handles data

This section describes what the Service actually does. It is part of the Customer's instructions.

5.1 Stored as received. Messages, raw inbound payloads and files are stored as they arrived. Formatting, removal of quoted email history, and other display rules are applied when data is shown, not when it is stored, so that the original record is never altered.

5.2 Messages are a record. The application cannot delete an email or message once stored, because it is the record of what a Supplier was told and what they replied. Messages are deleted when the Workspace is deleted (section 7.3) or on the Customer's specific instruction (section 7.2).

5.3 Event history without names. The order timeline refers to a Supplier Contact by an internal identifier and looks up the name when it is displayed. When a contact record is removed, the timeline shows those events anonymously. The exceptions are listed in section 7.2.

5.4 AI Features. The text sent to the language model is described in the sub-processor list. The AI Features never receive attachments. They receive message text limited to 8,000 characters per reading, and for spreadsheet imports only the sheet names, the header row and up to 20 sample rows with each cell cut to 200 characters.

6. Security measures

OrderToDock maintains the following measures. It may change them only in ways that do not reduce the overall level of protection.

6.1 Separation between customers.

(a) Each Workspace's data is separated by the database itself, not only by application code. Every table that holds customer data carries the Workspace's identifier and is protected by PostgreSQL row-level security, enabled and forced, so that a query can only see the rows of the Workspace it is running for.

(b) The application connects to the database with a role that cannot bypass row-level security. A query run without a Workspace context fails with an error instead of returning another customer's data.

(c) Platform data such as accounts and sign-in records is held separately, under a different database role that cannot read Workspace tables.

(d) Every change to the software must pass automated checks before it can be merged. These include a lint of the database's isolation rules, tests that try to read one Workspace's data from another for every table and every web route, and a test that an empty Workspace stays empty.

6.2 Access control within a Workspace.

(a) Every action that changes data checks the user's role in the Workspace, read from the database on each request.

(b) Sessions expire after 30 days.

(c) Sign-in is by email and password or, where enabled, a third-party sign-in provider. A user can turn on two-factor sign-in with an authenticator app.

6.3 Supplier access.

(a) Suppliers never sign in. A supplier link carries a 256-bit random code, which is stored only as a SHA-256 hash. The copy we keep of the email that delivered the link holds the code only until our email provider has accepted the email; after that the code is replaced in our copy with a note of which link was sent. A Supplier's reply that quotes our email usually contains the link; when we file the reply, the code is replaced in the same way in the copy we keep in the database. A copy of the database therefore yields no working supplier link, other than one that a Supplier's own mail security service rewrote before the Supplier quoted it back to us. The original of each reply, exactly as it arrived, is kept in private storage as the record of what the Supplier sent; it is not shared publicly or through any link, and a supplier link inside it stops working when it expires or is replaced. Invitation links for Authorised Users, password-reset links and truck-leg links are handled in the same way.

(b) A supplier link or truck-leg link expires after 30 days and can be revoked. An invalid, expired, revoked or used link shows the same page, so it reveals nothing about whether an order or shipment exists.

(c) Reply addresses carry a 128-bit random code, which can attach a message to an order's thread for review but cannot by itself change the order. The address, code included, appears in every email to and from the Supplier, and we keep it with the emails we send so that later emails on the same order use the same address.

(d) Supplier pages and truck-leg pages ask search engines not to index them, set no cookies of their own, cannot be framed by other sites, and send no referrer.

6.4 Inbound mail and messaging.

(a) The endpoints that receive mail and WhatsApp messages refuse every request unless it carries the provider's shared secret or a valid signature, compared in constant time. If the secret is not configured, they refuse everything.

(b) Mail that matches no Workspace is held outside every Workspace and never delivered to a guessed one.

6.5 Files.

(a) Files are served only through the application, to signed-in members of the Workspace, as downloads that the browser is told not to interpret or run. No public or shareable file link is issued.

(b) Files that Suppliers send are scanned for known malware after they are filed, by software OrderToDock runs itself, so files do not leave its infrastructure for scanning. Scanning catches known threats, not every threat. If the scanner is unavailable, the file is marked as not scanned and checked again later.

6.6 Audit. Every change applied to an order records who made it (a user, a Supplier Contact, or the AI Features), how it arrived (the web application, email or another channel), and the evidence (the message and the AI reading it was based on).

6.7 Encryption.

(a) Data travels between users and the Service over HTTPS, and between the application and the database over TLS.

(b) Data at rest in the managed database, its backups and object storage is encrypted by the hosting provider, as that provider's published documentation describes.

6.8 Secrets and release process.

(a) No credential is stored in source code. Production credentials are held in the deployment system's encrypted secret store and supplied at deploy time. The application refuses to start if a required secret is missing.

(b) Releases are built from version tags. A release reaches production only when a person starts that deployment, and only after the same tagged build has deployed successfully to a separate staging environment.

6.9 Rate limits and usage caps.

(a) Supplier page and truck-leg page actions are limited per link and per client address.

(b) Address lookups are capped per Workspace per month.

(c) Failed sign-in attempts are limited per client address and per account, and two-factor attempts and sign-ups are also limited.

6.10 Error reports. Error reports sent to the error-monitoring sub-processor are stripped of cookies, of any header or field whose name indicates a token, secret, password, key or authorisation, of the code in a supplier, invitation, truck-leg or password-reset link, and of a failed database query's values and email addresses, before they leave the Service. They are configured not to include users' IP addresses or personal identifiers by default. An error message can still contain other data values.

6.11 Backups and recovery. The production database runs with a standby node and is backed up daily by the hosting provider, with point-in-time recovery inside a 7-day backup window. Before OrderToDock accepts Customer Personal Data in production, stored files will be versioned, so that a deleted or overwritten file can be recovered for 30 days, and copied nightly to a second region under a credential the Service itself does not hold. OrderToDock maintains a documented restore procedure for the database and for files. It will complete a restore drill before it accepts Customer Personal Data in production, and repeat one at least every three months after that.

6.12 People. Access to production systems and data is limited to the company's directors and engineers it authorises, and is used only to operate, support and secure the Service or on the Customer's instructions.

(a) OrderToDock staff use a separate administration area that requires two-factor sign-in and records every page viewed. By default it shows facts about a Workspace, such as its plan, its state and counts, together with the support requests the Customer has sent.

(b) Staff read other content of a Workspace only through support access, which is read-only and needs a stated reason and a time limit of at most 72 hours. Every administrator of the Workspace is emailed at once, the Workspace shows a notice while it lasts and can end it, and the Workspace's audit log records it opening, what was viewed and it ending. A Workspace administrator can turn on a setting that makes support access wait for an administrator's approval.

6.13 Review. OrderToDock reviews the security of the Service's public entry points and records the findings and their fixes.

7. Retention, deletion and return

7.1 During the term. Customer Personal Data is kept for as long as the Workspace exists, unless the Customer removes it. What the Customer can remove in the Service, and what it cannot, is set out below.

Data	Kept	Can the Customer remove it in the Service?
Supplier contact record (name, job title, phone, email addresses, postal addresses)	Until removed	Yes. A Workspace administrator can remove a contact. This removes the contact record and the email addresses and postal addresses held under it.
Emails and WhatsApp messages sent and received, raw inbound payloads	For the life of the Workspace	No. Removed on Workspace deletion, or by OrderToDock on instruction under section 7.2.
Attachments and uploaded files	For the life of the Workspace	No. Removed as above.
Orders and order lines	For the life of the Workspace	Orders can be cancelled, not deleted.
Order timeline and audit log	For the life of the Workspace	No. These are append-only records.
Email suppression list (addresses whose recipient reported the Service's mail as spam)	For the life of the Workspace, including after the contact is removed	No. Kept so the Service never mails that address again.
AI reading records	For the life of the Workspace	No. These hold a fingerprint of the input, not the input itself, plus the model's output.
Truck-leg links, what they recorded, and photos	For the life of the Workspace	No. Removed on Workspace deletion, or by OrderToDock on instruction under section 7.2.
Support requests and answers	For the life of the Workspace	No. Removed on Workspace deletion, or by OrderToDock on instruction under section 7.2.
Authorised User sessions (including IP address and user agent)	Until the session expires (30 days) or the user signs out	Not applicable.

7.2 Erasure of an individual's data. When the Customer removes a Supplier Contact in the Service, the contact record is deleted and the order timeline shows that person's past events anonymously. The following remain after removal, and OrderToDock will delete or redact them within 30 days of the Customer's written instruction:

(a) messages to and from the person's email address or phone number, and their attachments;

(b) the person's name, job title and phone number as recorded in earlier audit entries for edits to the contact;

(d) the person's email address on the suppression list, unless the Customer instructs that it should stay there so the person is not emailed again.

7.3 On termination. On termination of the Terms:

(a) A Workspace administrator can export the Workspace in the Service at any time during the term: one file holding its records in a common machine-readable format (JSON, with CSV for orders, order lines, suppliers and contacts), every message as it arrived, and the original files. The file can be downloaded once, by the administrator who asked for it, within 24 hours, after which it is deleted. On request made within 30 days of termination, OrderToDock will give the Customer the same export.

(b) After those 30 days, OrderToDock will delete the Workspace, its database records and its stored files from the live Service within a further 30 days, and will confirm deletion in writing on request.

(c) Deleted database records remain in encrypted database backups until they expire in their normal cycle of 7 days. Deleted files can remain as earlier versions in storage and its second-region copy for up to 90 days.

(d) OrderToDock will keep the message record or other Customer Personal Data longer only where the law requires it or the Customer asks in writing for a specified retention period, and this DPA continues to apply to it.

7.4 Unmatched mail. Mail and messages that reach OrderToDock but match no Workspace are held outside every Workspace for up to 90 days, so that misaddressed mail can be investigated and abuse detected, and are then deleted, together with the stored copy of what arrived. Mail that reached OrderToDock but could not be processed for seven days is held the same way, for the same period. The second-region backup copy of stored files (section 6.11) keeps an item deleted from the Service, including this mail, for up to 120 days before it removes it.

7.5 Idle Workspaces. If a trial has ended or a paid plan has lapsed, and no plan has been chosen since, OrderToDock will delete the Workspace, its database records and its stored files 12 months after that trial or plan ended, on the Customer's standing instruction under this DPA. It will email the Workspace's administrators 30 days and 7 days before the deletion, and choosing a plan before then cancels it. Section 7.3(c) applies to what remains in backups.

8. Assistance

8.1 OrderToDock will, taking into account the nature of the processing, help the Customer respond to individuals' requests to access or correct their personal data, or (where the GDPR applies) to exercise their other rights. OrderToDock will forward to the Customer, without undue delay, any such request it receives directly about Customer Personal Data, and will not respond to it itself except to direct the individual to the Customer.

8.2 OrderToDock will give the Customer reasonable information needed for the Customer to carry out data protection impact assessments and to respond to the PDPC or another regulator.

8.3 OrderToDock may charge a reasonable fee for assistance that requires substantial manual work, such as repeated exports or redactions, and will tell the Customer the fee in advance.

9. Data breaches

9.1 OrderToDock will notify the Customer without undue delay, and in any event within 48 hours, after it has credible grounds to believe that a data breach affecting Customer Personal Data has occurred.

9.2 The notice will include, as far as known at the time:

(a) what happened and when;

(b) the categories and approximate number of individuals and records affected;

(d) the steps OrderToDock has taken or proposes to take; and

(e) a contact for further information.

OrderToDock will send further information as it becomes available.

9.3 The Customer is responsible for assessing whether a breach is notifiable under the PDPA. Under the PDPA, the Customer must:

(a) complete that assessment within 30 calendar days of having credible grounds to believe that a breach has occurred;

(b) notify the PDPC as soon as practicable and no later than 3 calendar days after determining that the breach is notifiable; and

OrderToDock will give the Customer the information and help it reasonably needs to meet those timelines.

9.4 OrderToDock will take reasonable steps to contain the breach and reduce its effects, will keep a record of it, and will not notify affected individuals or a regulator about Customer Personal Data on the Customer's behalf without the Customer's agreement, unless the law requires it.

10. Sub-processors and transfers outside Singapore

10.1 The Customer authorises OrderToDock to use the sub-processors named in its sub-processor list.

10.2 OrderToDock will:

(a) before a sub-processor receives Customer Personal Data, bind it by written contract to data protection obligations that give Customer Personal Data a standard of protection at least comparable to that under the PDPA and this DPA;

(b) give each sub-processor only the data it needs for its function; and

10.3 OrderToDock publishes its sub-processor list at https://www.ordertodock.com/subprocessors.html and will give the Customer at least 30 days' notice by email before adding or replacing a sub-processor. If the Customer objects on reasonable data protection grounds within that period and the parties cannot agree a solution, the Customer may terminate the affected part of the Service and receive a pro rata refund of prepaid Fees.

10.4 Where data is held. Customer Data is stored in Singapore, in DigitalOcean's Singapore region. The backup copy of stored files in section 6.11 (raw messages and attachments) is kept in DigitalOcean's Frankfurt region in Germany, with the same sub-processor. Traffic to and from the Service passes through the network of DigitalOcean's content delivery provider on the way. Some sub-processors process data outside Singapore, as the sub-processor list shows, principally in the United States.

10.5 PDPA transfer limitation. For each transfer outside Singapore, OrderToDock will ensure that the recipient is bound by legally enforceable obligations, in contract or otherwise, to protect the data to a standard comparable to the PDPA, as the Personal Data Protection Regulations 2021 require.

10.6 Paddle. Paddle is the Merchant of Record for purchases of the Service. It receives the Customer's purchase and payment details directly from the person buying, and an identifier for the Workspace from OrderToDock. It does not receive messages, orders or Supplier data.

11. Audits and information

11.1 OrderToDock will make available to the Customer, on written request no more than once in any 12-month period (or after a data breach, or when a regulator requires it), the information reasonably necessary to demonstrate compliance with this DPA. This includes written answers to a reasonable security questionnaire and copies or summaries of OrderToDock's security review and restore procedure.

11.2 Where that information is not enough to demonstrate compliance, the parties will agree a further review at the Customer's cost, conducted by an independent auditor bound by confidentiality, on reasonable notice, during business hours, and without access to other customers' data.

12. Liability

Each party's liability under this DPA is subject to the limitations in section 15 of the Terms.

13. GDPR compatibility

13.1 Where the Customer's processing of Customer Personal Data is subject to the EU General Data Protection Regulation or the UK GDPR, for example because a Supplier Contact is in the European Economic Area and the GDPR applies to the processing, this section also applies.

13.2 Sections 1 to 11 are intended to meet Article 28(3) of the GDPR. In particular:

(a) OrderToDock processes only on documented instructions;

(b) its personnel are bound by confidentiality;

(d) it engages sub-processors only as section 10 provides;

(e) it assists with data subject rights and Articles 32 to 36;

(f) it deletes or returns data at the end of the Service as section 7.3 provides; and

(g) it makes available information to demonstrate compliance as section 11 provides.

13.3 Singapore does not have an adequacy decision from the European Commission. Where Customer Personal Data subject to the GDPR is transferred to OrderToDock, the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 apply and are incorporated by reference. Module Two (controller to processor) applies where the Customer is a controller, and Module Three (processor to processor) applies where the Customer is itself a processor. For those clauses:

(a) clause 7 (docking) applies;

(b) clause 9 option 2 (general authorisation, with the notice period in section 10.3) applies;

(d) clauses 17 and 18 select the law and courts of Ireland;

(e) Annex I is completed by section 2 of this DPA and the parties' details in the Terms;

(f) Annex II is section 6; and

(g) Annex III is the sub-processor list published under section 10.3.

For transfers subject to the UK GDPR, the UK International Data Transfer Addendum applies in the same way.

13.4 Under the GDPR, OrderToDock will notify the Customer of a personal data breach under section 9.1, which allows the Customer to meet its 72-hour notification duty under Article 33.

14. Contacts

OrderToDock's data protection officer can be reached at [email protected]. Questions about this DPA can also be sent to [email protected].