Data Processing Addendum (DPA)

Version 2026-10-01 · Omer ERP, operated by Peluve (Pty) Ltd (registration 2021/406050/07, South Africa).

This DPA forms part of the Terms of Service between Peluve (Pty) Ltd (“we”, the “Operator” under POPIA and “Processor” under GDPR/UK GDPR) and the customer (“you”, the “Responsible Party” / “Controller”). It applies wherever we process personal information on your behalf.

1. Roles

You are the Responsible Party / Controller of the personal information in your workspace: your customers, suppliers, leads, staff and anyone else appearing in your records. We are your Operator / Processor and process it only on your documented instructions — which are the Terms, this DPA, and what you do inside the Service.

For the account details of your users, and for our own billing records, we are the Responsible Party / Controller in our own right; the Privacy Policy covers that.

2. Outside users you invite into your workspace

The Service lets you invite people who do not work for you — typically a contract manufacturer's staff — into a restricted portal. This is a disclosure of your data to a third party, made by you, and it needs to be understood clearly:

• You decide. You choose who is invited and exactly what they may see. They are shown only the areas you grant and only the product recipes you tick; prices, costs, margins and stock values are withheld from them by the software in every case. Some pages they can be granted show customer names against orders and deliveries.
• You remain the Responsible Party. Inviting someone does not transfer that role to us or to them. You must have a lawful basis for the disclosure, and, where the person's employer will use the information for its own purposes, you are responsible for having the necessary agreement with that employer. This DPA does not create or replace that agreement.
• What we do. We hold the invitation details you enter (name, email, mobile, company) and the access you granted; we send the invitation by email; we create the account only when the invited person opens the link and sets a password, which is what proves the address is theirs; and we refuse, rather than merely hide, anything outside what you granted. Withdrawing access takes effect on that user's next request.
• Consent gap to note. The Service currently records acceptance of the Terms and Privacy Policy for the person who signs up a workspace, but not for team members or outside users added afterwards.

3. Our obligations

We will: process personal information only on your documented instructions, and tell you if an instruction appears to breach applicable data-protection law; ensure the people we authorise to process it are bound by confidentiality; keep the technical and organisational measures in Annex B; assist you, so far as the Service allows, with data-subject requests and with your own security, breach-notification and impact-assessment obligations; make available the information needed to show we have complied; and delete or return personal information as set out in clause 7.

Where a data subject contacts us directly about records inside your workspace, we will not answer for you — we will pass the request on to you.

4. Sub-processors

You authorise us to engage the sub-processors listed, in full and by name, in section 4 of the Privacy Policy, which states what each one receives and where it sits. That list is part of this DPA. We remain responsible for their performance, and we impose data-protection obligations on them no less protective than those in this DPA.

Change notice. We will publish any addition or replacement on the Privacy Policy page and notify workspace administrators by email at least 30 days before the new sub-processor begins processing. If you reasonably object on data-protection grounds within that period, we will work with you to find an alternative; if none is workable, you may terminate the affected part of the Service and receive a pro-rata refund of fees paid in advance.

Where you connect an integration yourself — accounting, your own email provider, webhooks or API keys — the recipient is your choice and your sub-processor, not ours.

5. International transfers

The Service runs in Frankfurt, Germany; its database is provisioned separately and is intended to sit in the same region [to be confirmed before publication], and in no case in South Africa. Further processing takes place with the providers named in the Privacy Policy.

For customers in South Africa this is a transfer out of the Republic and is governed by section 72 of POPIA. We rely on the grounds that the recipients are subject to laws or binding corporate rules or agreements that uphold principles for lawful processing substantially similar to POPIA, and that the transfer is necessary for the performance of the contract between us. Germany is in the EEA and subject to the GDPR.

For customers in the EEA or UK, hosting remains in the EEA and the database is intended to; onward transfers to providers outside it rely on those providers' own transfer mechanisms, including Standard Contractual Clauses where applicable. The exact mechanism for each provider is [to be confirmed before publication], and the SCC modules and annexes to be executed with this DPA are still to be settled.

6. Security and breach notification

We keep the measures in Annex B, which satisfy section 19 of POPIA and Article 32 of the GDPR, and we review them as the Service changes.

If we become aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal information we process for you, we will notify you without undue delay and in any event within 72 hours of becoming aware of it. The notice will describe, so far as we know it, the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed. We will keep you updated as we learn more, and we will assist you with your own notifications — under section 22 of POPIA to the Information Regulator and to affected data subjects, or under Articles 33 and 34 of the GDPR.

We will not notify the Information Regulator or your data subjects on your behalf without your instruction, except where the law requires us to notify in our own right.

7. Return and deletion

You can download the main tables of your workspace as CSV at any time from Setup → Export, including while a subscription is inactive. That download does not yet cover every table — section 9 of the Privacy Policy lists what is in it and what is not — and we will extract anything it leaves out on request, in a structured, commonly used and machine-readable format.

Ending the Service does not itself delete anything: your workspace and its contents remain stored, readable and exportable. On your written request we will delete the workspace and everything in it within 30 days. This is done manually by us — the Service has no self-service delete today. We may retain personal information where the law requires it, for as long as it requires, and it stays subject to this DPA while we hold it. Deleted data may persist in our database provider's automated backups until those roll off on that provider's schedule.

8. Audit

On reasonable written request, no more than once a year unless a breach or a regulator requires otherwise, and subject to confidentiality, we will make available the information necessary to demonstrate compliance with this DPA, including the sub-processor list, our security measures, and our answers to a reasonable security questionnaire. On-site audit rights are [to be confirmed before publication].

Annex A — Details of processing

• Subject matter. Provision of the Omer ERP inventory, manufacturing and stock-control Service.
• Duration. For as long as your workspace exists, and until deletion under clause 7.
• Nature and purpose. Hosting, storage, structuring, retrieval, display, export and transmission of your business records so that you can run stock, production, sales, purchasing, quality and lead management; sending email you initiate; pushing accounting documents where you have connected Xero.
• Categories of data subject. Your staff and users; the contacts at your customers and suppliers; sales leads and enquirers; the outside people you invite into your workspace.
• Types of personal information. Names and surnames; email addresses; telephone and mobile numbers; company and job context; postal and delivery addresses; login credentials in hashed form; role and permissions; the audit trail of who changed what and when; whatever else you choose to type into free-text fields such as notes, enquiry summaries and activity threads.
• Special personal information. Not required or expected by the Service. You should not enter it.

Annex B — Technical and organisational measures

• In transit: HTTPS on every request, with HSTS.
• At rest: managed PostgreSQL with the provider's encryption at rest and automated backups. The exact backup retention window is [to be confirmed before publication].
• Authentication: passwords stored only as salted scrypt hashes; a session identity bound to the password hash, so changing or resetting a password signs every existing session out; deactivating a user ends their access on the next request; rate limiting on sign-in and password reset.
• Session and browser: Secure, HttpOnly, SameSite cookies; CSRF protection on every state-changing form; X-Frame-Options, X-Content-Type-Options and a referrer policy set on every response; authenticated pages are never cached.
• Tenant isolation: every query against workspace data is filtered by workspace automatically at the database-access layer, and every new row is stamped with it, rather than relying on each page to remember.
• Access control: roles with least privilege; per-area permissions for restricted internal users; a fail-closed allowlist for outside users, so anything not explicitly granted is refused; prices and costs withheld from outside users by the software itself.
• Accountability: an append-only audit trail of every create, update and delete, recording who, what, from what to what, and when. The Service writes entries and never edits or erases them; it is not held on write-once storage.
• Payments: card data never reaches the Service; it is entered on the payment processor's own page. Payment webhooks are accepted only with a valid signature, and a plan is granted only on what the processor's own API confirms was paid.
• Secrets: our own keys and credentials — payment, email, accounting and error-reporting — are held in the hosting platform's environment, not in the source code. Credentials you enter into the Service are a different matter and are stated plainly: your own email API key or SMTP password, an accounting connection's OAuth tokens, your API keys and your webhook signing secrets are stored as ordinary fields in the database. They are covered by the database provider's encryption at rest and by the access controls above, and are not separately encrypted by the Service.
• Uploaded files: a spreadsheet you import is written to the application server's temporary storage between preview and confirmation and deleted when you confirm or cancel; an abandoned import can leave the file there until the server is replaced. There is no other file store — logos and generated documents are held in the database or built in memory.

Contact

DPA enquiries: admin@foodchem.co.za.