Our legal posture.
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 hold ourselves to a common set of data protection principles: lawful collection, purpose limitation, proportionate storage, and accountability for how personal data is processed. Where we operate, we also meet the specific statute that applies, including Malaysia's Personal Data Protection Act 2010 and its 2024 Amendment, and we configure each workflow to satisfy it.
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.
We treat breach notification as a duty, not a courtesy: where a personal data breach occurs, we notify the relevant regulator and tell affected individuals 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 whatever window the applicable law requires, and we treat any access we hold to your data as in scope for that duty.
Data subjects also have 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. 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 Workflow 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 Workflow 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. Audit is not a feature we turn on at the end; it is part of how the workflow is operated.
We can report that record back to you. The format and the cadence of audit reporting are agreed during the Workflow 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. Claudine Ng. Email privacy@scellus.com or text +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.