Cloud Compliance in Malaysia 2026: Cyber Security Act, RMiT, PDPA

Four separate instruments shape a Malaysian cloud architecture, and they arrive from four different directions: the Cyber Security Act 2024 for designated critical infrastructure, Bank Negara Malaysia’s RMiT policy document for licensed financial institutions, the Personal Data Protection Act 2010 as amended in 2024, and the National Cloud Computing Policy for national direction. Aqvantiq is a multi-cloud AI system integrator in Kuala Lumpur; this is the map we hand clients before a design review, with every claim linked to the primary document. We are engineers, not your legal counsel — but a design cannot be produced until somebody has written down which of these bind you.

Which Malaysian rules actually govern a cloud deployment?

Start by working out which of the four apply to you. Most organizations are caught by one or two, not all four.

What does the Cyber Security Act 2024 require?

It creates a designation regime rather than a universal one. The Cyber Security Act 2024 (Act 854) came into operation on 26 August 2024, and it “outlines the duties and powers of the Chief Executive of NACSA, as well as the functions and duties of the National Critical Information Infrastructure (NCII) sector leads and NCII entities” (NACSA). It also “includes provisions to regulate cyber security service providers through licencing”.

The practical question comes first: has your organization been designated as an NCII entity? If yes, incident handling, control ownership and the evidence you can produce stop being internal preferences and start being obligations — which is what pushes log retention, access boundaries and audit trails into the design phase rather than into a remediation project. If no, the Act still matters commercially: designation does not flow through a supply chain, but customers who are designated will impose corresponding security requirements on their suppliers by contract.

The eleven NCII sectors are listed in the Act’s own Schedule — government, banking and finance, transportation, defence and national security, information, communication and digital, healthcare services, water, sewerage and waste management, energy, agriculture and plantation, trade, industry and economy, and science, technology and innovation. Whether your organization is designated within one of them is a decision made under the Act, and that answer should come from your sector lead or counsel, not from a consultancy blog.

What does BNM RMiT require before a bank adopts public cloud?

Consultation first, and a documented risk assessment before that. Bank Negara Malaysia issued the current Risk Management in Technology (RMiT) policy document (ref BNM/RH/PD 028-98) on 28 November 2025, and it came into effect the same day. It applies to licensed banks, licensed investment banks, licensed Islamic banks, licensed insurers including professional reinsurers, licensed takaful operators including professional retakaful operators, prescribed development financial institutions, approved issuers of electronic money, operators of designated payment systems, registered merchant acquirers and intermediary remittance institutions (RMiT).

Five provisions shape the architecture more than the rest — the first three are requirements, the last two Appendix 10 guidance (“should”, not “must”):

1. A risk assessment before adoption. Paragraph 10.50 requires a financial institution to “fully understand the inherent risk of adopting cloud services” and to “conduct a comprehensive risk assessment prior to cloud adoption”. Its assessment factors include “location of cloud infrastructure including potential geo-political risks and legal risks that may impede compliance with any legal or regulatory requirements” and “vendor lock-in and application portability or interoperability”.
2. Consultation, then notification. Paragraph 17.1 requires the institution to “consult the Bank prior to the first-time adoption of a public cloud or emerging technology for critical systems”, demonstrating the risks have been addressed to the Bank’s satisfaction. Paragraph 17.2 requires it to “notify the Bank on any subsequent adoption”. The word is “consult”, but read the whole clause: the risks must be addressed to the Bank’s satisfaction in order to proceed — plan it as a gate in your programme, not as a filing.
3. A pre-implementation review for higher-risk services. Paragraph 17.1(c) points at a third-party pre-implementation review for “higher-risk services, such as those involving the processing or storage of customer information, or cross-border data transmission”.
4. An exit plan, written while you are still arriving. Appendix 10 states that an institution “should establish a robust cloud exit strategy as part of its cloud risk management framework to prepare for extreme adverse events such as the unplanned failure or termination of cloud service providers”, supported by “an appropriate and proportionate exit plan that establishes the operational arrangements to facilitate an orderly exit”.
5. Concentration risk, with multi-cloud named. Appendix 10 asks institutions to “progressively adopt appropriate mitigating controls to ensure service availability and mitigate concentration risk”, and expressly contemplates a “multi-cloud strategy, with the use of services from different cloud service providers to mitigate concentration risks and geopolitical risks”.

Two administrative deadlines are easy to miss. Paragraph 17.5 requires the cloud adoption roadmap to sit inside the annual outsourcing plan submitted to the Bank. Paragraph 18.1 required a gap analysis against the policy, with an action plan, submitted “no later than 90 days after the issuance date” — that deadline fell on 26 February 2026, so an institution that has not yet submitted one is overdue, not early.

Does RMiT require you to keep data in Malaysia?

No, and this is the most common misreading we meet. RMiT contains no data residency or in-country storage requirement. It treats location as a risk to be assessed: “Jurisdiction risk may arise because cloud service providers operate regionally or globally in nature and may be subject to the laws and regulatory requirements of its home country […]” It plainly contemplates offshore data, asking institutions to “ensure CIRP is ready to manage cross-border incidents where the data resides in a foreign jurisdiction”. Offshore cloud arrangements are governed by cross-reference to BNM’s separate Outsourcing policy.

That distinction matters commercially. “The regulator requires it” is a much weaker argument for in-country hosting than most tender documents assume, and treating it as settled removes a genuine design option. Where in-country hosting is the right answer — latency, contract terms, a customer’s own policy, or classification-driven public-sector procurement — it is now easy to satisfy: AWS opened its Asia Pacific (Malaysia) Region, ap-southeast-5, with three Availability Zones on 21 August 2024.

The clearest in-country requirement we can actually point at is procurement-side and classification-triggered. Under the government’s MyGovCloud@CFA process, agencies handling Maklumat Rahsia Rasmi (Restricted and Confidential) must run their market study with managed service providers “offering cloud services with data residency located within the country” (our translation of the Malay-language Jabatan Digital Negara FAQ). That is a rule about classified official information at the procurement stage — not a blanket national data-localisation law, and it should not be quoted as one.

What changed in Malaysia’s PDPA, and when?

The Personal Data Protection Act 2010 (Act 709) is still the governing statute. What changed is that the Personal Data Protection (Amendment) Act 2024 — Act A1727 — amended it in three tranches, commenced by gazette on 1 January, 1 April and 1 June 2025 (P.U. (B) 522).

Three details are worth getting right because they are widely misquoted.

Not every company needs a DPO. Section 12A reads broadly on its face, but the Commissioner’s appointment guideline confines mandatory appointment to processing that crosses a threshold: personal data of more than 20,000 data subjects, sensitive personal data — including financial information — of more than 10,000 data subjects, or activities involving regular and systematic monitoring of personal data (DPO appointment guideline, Feb 2025). Where one is appointed, the data controller must notify the Commissioner within 21 days — section 12A(3) puts that duty on the controller. The thresholds are the Commissioner’s to revise — re-check the current guideline before relying on being under them.

The 72-hour deadline is guidance, not statute. Section 12B says “as soon as practicable”. The 72-hour figure comes from the Commissioner’s data breach notification guidelines, which state that notification must be made as soon as practicable within seventy-two (72) hours of the breach occurring (Guidelines, Feb 2025). The same guidelines put “significant scale” at more than one thousand affected data subjects. Build to the guideline; cite the Act correctly.

Failing to notify is a criminal offence, not just a fine. Section 12B(3) provides for a fine not exceeding two hundred and fifty thousand ringgit, or imprisonment for a term not exceeding two years, or both.

Engineering consequences follow directly. A 72-hour clock is only survivable if you can answer which data was in that system quickly — which means data classification recorded per store, not per application. Data portability means an export path that is a feature, not a database dump. And a DPO who must be notified to the Commissioner needs an inventory that is maintained, not reconstructed.

What does the National Cloud Computing Policy change?

It sets direction rather than obligation. Malaysia’s Ministry of Digital launched the National Cloud Computing Policy on 13 August 2025, built on five pillars: Public Sector Transformation; Fostering Private Sector Growth; Secure Data Protection and Privacy; Digital Inclusivity; and Environmental Sustainability (Ministry of Digital).

Pillar 3 is the one that shows up in procurement language: it “strengthens data security frameworks, ensures compliance with data protection laws, and builds public trust in digital platforms”. On residency, be precise about which document you are reading. The launch announcement imposes no data residency rule. The policy document itself goes further: it describes a Data Sovereignty cloud stack intended to keep critical data within Malaysia’s borders, a Sovereign Cloud stack, and a four-tier data classification whose top tier — Confidential, including NCII data — is to be stored only in sovereign cloud zones within Malaysia. That tiering is recommended national policy, not statute, so the practical reading stands: the NCCP is the vocabulary your public-sector-facing customers will use and a clear signal of direction — including toward in-country hosting for the most sensitive classifications — rather than a statutory control you can evidence against.

What does all of this mean for the architecture?

Seven design decisions carry almost all of the compliance weight, and every one of them is cheaper to make before a migration than after one:

• Classification per data store, recorded where an engineer will see it — not in a spreadsheet a governance team owns.
• Region placement decided explicitly, including for backups, snapshots, log archives, disaster-recovery copies and non-production datasets. One log bucket in the wrong region undoes an entire residency claim.
• Key custody answered out loud: provider-managed, customer-managed, or externally held, and who can actually authorise a decrypt.
• Access boundaries that survive an audit: federated identity, least-privilege roles, no long-lived keys, break-glass credentials that stay with you.
• Log retention set to a stated period, because a retention rule nobody wrote down defaults to “forever”, which is both a cost problem and a privacy problem.
• Restores that have been executed, not merely configured. A backup nobody has restored is a hypothesis.
• Every infrastructure change through a merge request, so the audit trail is the git history rather than somebody’s memory of a console session.

That is the same list we build into every cloud architecture engagement, apply during a cloud migration, and keep honest afterwards under managed cloud services. If the workload is AWS-shaped, the region and residency half of the decision is covered in more depth on our AWS page and in the AWS Malaysia guide. If procurement is pointing you at Huawei Cloud for sovereignty reasons, the Huawei Cloud guide is the honest version of that comparison.

Every legal claim above is quoted from the primary document and linked to it. Regulations change and guidance is reissued — re-check the source before acting, and get your position in writing from whoever owns the risk. We are engineers, not your legal counsel: where we could not verify something against a primary source, we left it out rather than guessing.

Designing or auditing a Malaysian cloud estate against these? Talk to us — send the shape of the estate and which of the four instruments you think applies, and you will get a direct answer from the engineer who would do the work.