A PDPA checklist for teams moving workloads to the cloud

Under the Personal Data Protection Act 2010, an organisation that processes personal data carries obligations that do not disappear when the processing moves to a cloud provider. The contract changes; the accountability does not. This checklist is written from the provider side, and it is the list we would want a customer to bring to us before signing anything. It is not legal advice, and it does not replace your own advisers.

The seven principles in plain terms

PDPA 2010 is built on seven principles, and they cover the same ground whether data sits on a server you own or one you rent. They govern how personal data is collected, how notice is given, how it is used, how it is disclosed, how it is kept secure, how long it is kept, and how individuals can access and correct it. Cloud changes where those duties land, not whether they apply.

The cloud does not move a principle from your column to your provider column. It changes who you have to ask. If you cannot describe where a record lives and who can reach it, you cannot answer the principles that depend on that knowledge, and no clause in a contract fills that gap on its own. The work is describing your own processing accurately.

Six questions worth answering before you sign

Where is the data physically processed, and can that be evidenced?
Who is the data processor and who is the data controller in the contract?
What is the breach notification path, and in what timeframe?

How is data returned or destroyed at end of contract?
What sub-processors are involved, and are they disclosed?
What access logs exist, and who can retrieve them?

Data residency and cross-border transfer

If the answer to the first question is that your team is not sure, the remaining five are difficult to answer credibly. Running on domestic infrastructure does not automatically satisfy PDPA, but it makes the residency question answerable with a document rather than a promise. A residency statement you can point at is worth more than an assurance in a slide.

Residency is not only about where the primary copy sits. It covers replicas, backups, snapshots, support access and the path data takes when it moves between any of them. A workload can be hosted in Malaysia and still send telemetry or backups elsewhere, and that detail is the one most often missing from a procurement review. Ask for the full path, not the primary location. A path you can draw is easier to defend than a location you can name.

A transfer is not limited to moving a database between countries. Remote administrative access from outside Malaysia, a support engineer viewing a record, or a backup written to a foreign bucket are all processing somewhere else. Where a transfer is unavoidable, the usual controls are a documented purpose, a contractual basis for it, and a record of what moved and when. The point is not to prohibit transfers but to be able to describe them.

The obligation follows the data, not the contract.

Breach notification, access control and encryption

Breach notification is a process question before it is a legal one. Who decides that a breach has occurred, who informs affected individuals, who informs the regulator, and how quickly? A provider that cannot answer those questions in order will improvise during the worst week of your year. Ask for the sequence, not the policy statement.

Our own commitments are simple to state. An incident affecting customer data is acknowledged within fifteen minutes, tracked under a single incident record, and followed by a written review within five business days of resolution. Notification is a decision made jointly with you, and we prepare the technical facts you need to make it. We do not notify your customers on your behalf.

Encryption is the control most teams assume rather than verify. In practice it has to be specific: data encrypted at rest on volumes, snapshots and backups, traffic encrypted in transit for replication and management, and keys managed separately from the data they protect. Each of those is a separate question with a separate answer, and only one of them is answered by the word encrypted.

Encryption at rest on volumes, snapshots and backups
Encryption in transit for replication and management traffic
Named accounts with no shared logins
Key rotation and revocation with a documented process

Least privilege is easier to promise than to operate. In practice it means named accounts rather than shared logins, roles scoped to a task rather than to a team, administrative access that is time-bound and approved, and a record of who used it. The test is not whether access is restricted in policy. It is whether you can show who had access to a given record last month.

Logs, retention and data subject rights

Access logs are the part of PDPA work that teams under-invest in, because logs are generated by default and read only during an incident. Know what is recorded, where it is stored, how long it is kept, and who can query it. A log you cannot retrieve within your audit window is a log that does not exist.

Access logs with actor, action, time and source address
Retention long enough to cover your audit cycle
Log storage inside Malaysia, consistent with the data
Export in a format your auditor can read

Retention is a decision rather than a default. Personal data should live for as long as the purpose requires and no longer, and deletion should be evidenced rather than assumed. We document retention periods in the service schedule and delete or return data at the end of the contract, including copies held in backups as their retention windows expire. Ask any provider how deletion is proven. A deletion process you can describe is easier to accept than one you have to trust.

Data subject rights are the customer obligation and the provider tooling problem. Under PDPA, individuals can request access to and correction of their personal data, and can limit processing for direct marketing. Requests reach you, not us, because you are the controller. What we owe you is the ability to export a complete record set and to delete it on instruction, within a documented timeline.

Processor, controller and audit readiness

The distinction between processor and controller decides who answers an individual request. For customer data we act as the processor and you act as the controller, which is why a data subject request arrives with you rather than with us. For data we process for our own account, such as billing and support, we are the controller and the same duties apply to us. Get this written down before an incident, not after.

Audit readiness is mostly documentation that already exists. We can provide a residency statement naming the facility, the sub-processor list referenced in your service schedule, a summary of encryption in transit and at rest, and extracts from access logs covering the period under review. What we cannot provide is a certificate we do not hold, and we will say so rather than imply otherwise. Ask for the documents, not the badge. The list should be short enough to read and complete enough to be useful.

Two more habits make audits easier. Keep a dated record of the documents you were given and when, because an auditor asks what you knew at a point in time rather than what you know today. And decide in advance who inside your organisation answers a data subject request, so that a request arriving on a Friday afternoon does not become a decision made on Monday.