Our legal posture under Malaysian law.
We treat client data as the most sensitive layer of the work. Every workflow we operate is built around three questions: who can see the data, where it is stored, and what is recorded when it is touched. This page answers those questions in plain language.
We operate under the Personal Data Protection Act 2010 and the 2024 Amendment. These set the rules for how any organisation in Malaysia collects, processes, stores, and protects personal data. We hold ourselves to them, and we configure each workflow to meet them.
We appoint a Data Protection Officer responsible for data-handling questions and data subject requests. You can reach our DPO directly, and the contact route is at the foot of this page.
The 2024 Amendment introduced a breach notification duty: where a personal data breach occurs, the Personal Data Protection Commissioner must be notified, and affected individuals must be told where the breach is likely to cause significant harm. We design our workflows to surface incidents quickly so that this obligation can be met within the required window, and we treat any access we hold to your data as in scope for that duty.
The Act also gives data subjects the right to access their data, to correct it, and to move it. We build workflows so that the records we hold for you can be located, exported, and corrected when a request comes in. Under PDPA, removing names or obvious identifiers from a document does not make it stop being personal data. We treat pseudonymised and redacted records with the same care as the originals.
Where your data sits.
We process and store client data in AWS regions, using Singapore or Malaysia depending on the workflow's requirements. Which region applies is decided per project, not assumed by default, and it is confirmed with you during the Operations Review before anything goes live.
We do not claim that your data never leaves Malaysia. That would not be true for every workflow, because some processing steps and some providers operate from other regions. What we do instead is tell you exactly where each part of a workflow runs, which data stays in region, and which steps, if any, send data elsewhere.
If your operation requires in-country-only processing, we configure the workflow to meet that constraint and we confirm it with you in writing.
What we send to AI and service providers.
We build workflows on a defined set of providers: Anthropic, Cloudflare, Google, Microsoft, Neon, OpenAI, Supabase, and Vercel. We use them for processing, hosting, delivery, and the AI steps inside a workflow. Which providers a given workflow touches is a per-workflow decision, not a fixed list applied to everyone.
For each workflow, we decide what is sent to a provider and what is withheld. Where data is sensitive, we reduce what leaves your environment through pseudonymisation, redaction, or in-region deployment of the relevant component. We will not pretend this removes all exposure. Under PDPA, pseudonymised data is still personal data, so we treat it that way and we do not rely on redaction alone as a safeguard.
You see this before it goes live. During the Operations Review we map exactly which providers a workflow uses and what each one receives, and you confirm that scope before we operate anything.
Access and audit.
We limit access to client data to the people operating your workflow. Access is role-based, granted for the work that requires it, and removed when it is no longer needed.
We log access. Every workflow we operate preserves a traceable record of what was done, by whom, and when, because an audit trail is built into the workflow itself rather than added afterwards.
We can report that record back to you. The format and the cadence of audit reporting are agreed during the Operations Review, so the reporting matches how your team actually reviews compliance rather than a schedule we impose.
Notes by sector.
Different industries carry obligations that sit on top of PDPA. We account for them in how we scope and operate.
- Legal services. Client confidentiality and Bar Council obligations apply alongside PDPA. We treat matter data as privileged and we restrict access accordingly.
- Professional services. Client engagement data and financial records are handled under PDPA, with consent capture built into intake where the workflow collects personal data at the point of inquiry.
- Logistics and trading. Supplier and customer data, along with customs and trade documentation, are handled with the same access and residency discipline as any other client data.
What stays under your control.
You grant and revoke access to your own systems. You name a process owner and a data point of contact on your side. Where a workflow ingests personal data belonging to your own clients, customers, or staff, you remain responsible for the consent and notice obligations to those data subjects. And you control internal access discipline within your team.
We handle the data inside the workflow we operate. You control who in your organisation can reach it and on what terms.
Data protection contact.
Our Data Protection Officer handles data subject access requests and any question about how we hold your data.
Data Protection Officer. Izma Kadir. Email privacy@scellus.com or call +6012 272 3270.
When a data subject request reaches us, we locate the relevant records, confirm the request, and respond within the timeframe the request requires under PDPA. For questions about how this website handles visitor data, rather than client data inside a workflow, see our privacy policy.
Updates.
From time to time we update this page. We will post a notice at the top of this page when changes are substantial. Continued use of the site means you accept the latest version.