Data Processing Addendum

1. Status of this page

A useful DPA must match the actual parties, service configuration, data, people, purposes, locations, providers, and governing contract. Those facts can vary by merchant and may change during implementation. Gerai therefore confirms them during procurement rather than publishing fictional annexes or treating a generic template as universally applicable.

Gerai’s public Privacy Policy, Singapore PDPA Notice, and security information remain useful background, but they do not replace agreed contractual terms where a DPA is required.

2. When processing terms may be needed

Processing terms may be relevant when a merchant determines the purposes and essential means for handling buyer, staff, supplier, or other personal data and asks Gerai to process that data on documented instructions while providing the platform.

A separate DPA may not describe every interaction. For example:

• Gerai may handle corporate enquiry and account-administration data for its own legitimate service and legal purposes;
• the merchant is the seller and normally determines why buyer order data is collected and used for the sale;
• licensed payment services independently handle payment credentials and funds under their own roles and terms; and
• Gerai may have legal or security responsibilities that are not performed solely on the merchant’s instructions.

The parties should identify these role boundaries rather than labelling Gerai a processor for all data in all circumstances.

3. Roles and scope

A procurement review should establish at least:

• the legal names and contact details of the contracting parties;
• the principal services agreement or order to which processing terms relate;
• which activities the merchant controls and which Gerai controls independently;
• the merchant storefronts, countries, currencies, languages, and channels in scope;
• categories of individuals and personal data involved;
• special, regulated, or high-risk data that must not be supplied unless expressly agreed;
• the intended duration and frequency of processing; and
• any mandatory law or industry requirement the merchant needs Gerai to assess.

Gerai does not assume that an enterprise customer’s preferred template accurately describes the service. Proposed terms are reviewed against the verified architecture and commercial agreement.

4. Processing description

Subject to the agreed implementation, a processing schedule may cover activities such as receiving, organising, storing, displaying, transmitting, retrieving, updating, and deleting data needed to operate merchant storefront and order-management functions.

This table is illustrative procurement scoping, not a contractual processing schedule. The final description must remove categories that do not apply and add any verified categories required by the implementation.

5. Instructions and purpose limits

Where Gerai acts as a processor, proposed terms can address:

• processing personal data only on documented customer instructions and as needed to provide the agreed services;
• the documents that constitute valid instructions, such as the service agreement, configured product functions, and authorised written requests;
• what happens if Gerai believes an instruction conflicts with applicable data-protection law;
• how legally required processing or disclosure is handled, including notice where legally permitted;
• restrictions on using merchant-controlled personal data for unrelated purposes; and
• the customer’s responsibility for lawful instructions, notices, permissions, data accuracy, and use of the service.

Instructions must stay within the contracted service. A request for a new integration, location, data category, or materially different processing activity may require technical, legal, security, and commercial assessment before it can become an instruction.

6. People, security, and confidentiality

Contractual terms can describe appropriate confidentiality obligations for people authorised to handle customer personal data and reasonable technical and organisational measures matched to the verified service and risk.

Procurement topics may include:

• access authorisation and removal;
• account and administrative security;
• separation of merchant access and data;
• change, vulnerability, and dependency management;
• logging, monitoring, backup, recovery, and incident handling;
• secure development and operational practices; and
• staff and provider confidentiality.

Specific controls must be verified before they are placed in an annex. This page deliberately does not invent encryption standards, certifications, audit reports, testing frequency, recovery objectives, or control claims. Procurement teams may request current evidence that is appropriate and available for the engagement.

7. Service providers

Gerai may need service providers to deliver infrastructure, communications, diagnostics, security, payment connectivity, or other operational functions. Whether a provider is a subprocessor depends on whether it processes the customer-controlled personal data in scope on Gerai’s behalf.

A negotiated DPA can address:

• the applicable provider list and processing purpose;
• the countries or regions relevant to that provider’s processing;
• contractual data-protection obligations imposed on subprocessors;
• how material additions or replacements are communicated; and
• how a customer may raise a reasonable data-protection concern.

Gerai does not identify invented providers or present an unverified universal subprocessor list here. Current details are supplied for the service scope during procurement.

8. Rights and compliance assistance

Where Gerai acts as processor, the merchant remains responsible for receiving, assessing, and responding to requests from buyers or other individuals. Processing terms can describe how Gerai will provide assistance reasonably available through the service and relevant to the nature of processing.

Depending on agreed scope, assistance topics may include:

• locating, exporting, correcting, restricting, or deleting relevant records;
• forwarding a request received directly by Gerai to the customer;
• providing information reasonably needed for a data-protection assessment;
• supporting regulatory enquiries concerning the processor activity; and
• providing information reasonably needed to demonstrate compliance with agreed terms.

Any format, procedure, cost allocation, audit right, evidence package, or response time must be agreed rather than inferred from this page. Requests must not compromise another customer, Gerai’s security, privileged information, or unrelated confidential material.

9. Incidents

Proposed terms can address Gerai notifying the customer after becoming aware of a confirmed personal-data incident affecting customer personal data in scope, together with information reasonably available to help the customer assess its obligations.

Incident provisions should define:

• the event that triggers contractual notification;
• the designated contacts and secure communication channel;
• the information to be supplied as it becomes available;
• cooperation, containment, preservation, remediation, and update expectations;
• responsibility for regulatory and individual notifications; and
• how law-enforcement restrictions or confidential investigations are handled.

No incident-notification time, response time, or allocation of cost is promised by this procurement page. Those points must align with applicable law, technical feasibility, and the final written agreement.

10. International processing

The parties should identify where in-scope personal data may be accessed or processed and which transfer restrictions apply. Gerai serves Southeast Asia, but no universal data location should be assumed from that market focus.

Where required, negotiated terms may cover:

• specified processing locations and provider locations;
• the parties’ transfer roles and relevant legal mechanism;
• additional contractual or technical safeguards appropriate to the transfer;
• information needed to assess the transfer; and
• the process if a required mechanism becomes unavailable or inadequate.

This page does not claim use of Standard Contractual Clauses, an adequacy decision, a transfer impact assessment, local-only processing, or another transfer mechanism for every merchant. Any such mechanism must be confirmed and executed for the relevant transfer.

11. Return, deletion, and end of service

A DPA can specify what happens to customer personal data when the relevant service ends, including available export, return, deletion, backup handling, verification, and lawful retention. The workable approach depends on the service, data, system design, merchant obligations, and principal agreement.

Merchants should identify records they must retain for orders, tax, consumer protection, disputes, or other legal purposes and obtain them before access ends. Gerai may need to retain limited information where required by law or reasonably necessary for security, fraud, disputes, or legal claims, subject to appropriate restrictions.

No fixed return window, deletion period, backup cycle, retention period, or deletion certificate is promised on this page. Those commitments require technical verification and written agreement.

12. Procurement request

To discuss processing terms, email hello@gerai.shop and include:

• the prospective merchant’s legal name and primary contact;
• the Gerai service and storefront scope being evaluated;
• countries in which relevant individuals, merchant teams, and operations are located;
• the categories of people and personal data expected;
• any special, regulated, or prohibited data the merchant believes may be involved;
• required processing locations or transfer constraints;
• the merchant’s proposed DPA or mandatory clauses, if any; and
• the desired contracting sequence and decision stakeholders, without assuming a response time.

Gerai can then identify the information and review needed for the actual engagement. Do not send live buyer data, payment credentials, access secrets, or unnecessary identity documents as part of an initial procurement enquiry.