The data processing agreement — and how it maps to PDPA 2010.

We are a processor, not a controller

minidesk processes the data our customers put in. The customer is the controller. We act on their instructions and only on their instructions — that is the deal.

We do not use customer data to train a shared model

The AI runtime scopes every retrieval and every memory write to the asking membership. There is no shared training step and there will not be one. Customer data stays inside the customer's data plane.

Sub-processors are listed, and changed only with notice

Vercel (hosting), Supabase (Postgres + auth), and the LLM provider are sub-processors. The list is published below; changes are announced 30 days in advance, and customers can object in writing.

Data residency is regional

MY customer data is stored in the Supabase region closest to MY (Singapore). Cross-region replication is for durability, not processing. Customer data does not leave the regional cluster.

Deletion is on demand, in days, not months

Customer-initiated deletion purges the company's data plane, plugin data, and any derived state within 30 days. Hard deletion on termination of the agreement: 30 days from notice.

Security is audited and reportable

Penetration test, infrastructure diagram, and the signed-off data-residency report are available under NDA on request. The full report ships with the first major customer.

PDPA 2010 compliance is built in, not bolted on

The Personal Data Protection Act 2010 (Malaysia) sets out seven data-principles we have to meet — notice, consent, disclosure, security, retention, integrity, and access. This agreement is the contract that says we meet them, in writing, for every customer. The full set of customer rights (access, correct, delete, limit) is in the Privacy Policy; the regulator's complaint channel is the Jabatan Perlindungan Data Peribadi (JPDP), and the contact for raising a concern with us first is on /contact.