BNM RMiT · issued 28 November 2025Published by Bahwan CyberTek

Data residency and RMiT compliance are two different questions.A Malaysian Region only settles one.

RMiT does not require in-country hosting. What it does require, for any critical system on public cloud, is a set of documents and controls that a Region change leaves exactly where they were.

Written for CISOs, Heads of IT Risk and cloud architects at Malaysian banks, insurers, takaful operators, DFIs and payment operators running critical systems on public cloud.
What it covers The six RMiT obligations a Region change does not touch, each with its paragraph reference, and a short self-check so you can see where your own evidence stands.
Recent enforcement

On 20 January 2026 BNM imposed a RM1 million administrative monetary penalty on Bank Kerjasama Rakyat Malaysia Berhad, after an external threat actor gained unauthorised access to its IT infrastructure. The failures cited were cybersecurity controls and incident response under the RMiT and MCIPD policy documents. Data location was not among them. BNM has not published a technical root cause, so none is assumed here.

01The distinctionWhat a Region settles, and what it leaves open 02The three gatesDocuments BNM expects before the build 03The controlsKeys, logs and availability, with paragraphs 04Your positionA six-question self-check, in your browser

Same Region. Two different questions.

Hover the governance nodes
The residency view One question, answered. Critical system, in-country WHERE: SETTLED WHO CONTROLS IT: STILL OPEN The governance view Four obligations wrapped around the same workload. CRITICAL SYSTEM Key custody S 10.22 · 10.52 Audit trail S 10.57 Availability S 10.32 Consultation S 17.1 EACH ONE NEEDS A DOCUMENT
01 · The distinction

What an in-country Region settles, and what it leaves open

Same workload, two different questions. The second one is what gets examined.

Data residency

Answers one question

  • Physical location of storage and processing
  • One input to the cloud risk assessment
  • Who holds and manages the keys
  • Whether the logged can delete the logs
  • Whether BNM was consulted first
Governance

Answers what is examined

  • Board and senior management accountability
  • Custody and management of keys S 10.52
  • Separation of actor from record S 10.57
  • Documented Appendix 10 position G 10.51
  • The document you hand an examiner
Correction
RMiT contains no blanket data localisation requirement.

Location of cloud infrastructure appears in paragraph 10.50(c) as a risk to assess, alongside geo-political and legal risk. Offshore hosting is treated as a jurisdiction risk to manage, not a prohibition. Region-locking may be a sound choice for your own risk position. It is not the regulator's demand.

02 · The gates

Three documents BNM expects before the architecture discussion

Each produces a dated document. In practice these get asked for before anything about the architecture does.

Path to a critical system on public cloud

S 17.1 → S 17.2
Risk assessment 10.50 + Appendix 10 · Appendix 7 Part A Readiness confirmation CISO or board chair · Appendix 7 Part B Pre-implementation review Third party · Appendix 7 Part C Consult BNM First-time adoption · S 17.1 No concerns raised Proceed with adoption Subsequent Notify only · S 17.2 Gate not passed 17.2 route unavailable The roadmap for cloud adoption also goes into the annual outsourcing plan · S 17.5
S 17.1

Consult before the first one

Required before your first public cloud adoption of a critical system. Skip it and every later workload stays on the consultation route instead of the faster notification route under 17.2.

G 10.51

Own your deviations in writing

If you depart from any Appendix 10 measure, you must be able to show BNM your alternative is at least as effective. Write that comparison now, not when it is asked for.

S 18.1

The gap analysis was due

Your gap analysis and action plan against this revision were due to BNM within 90 days of 28 November 2025. The action plan then has to show movement against its own milestones.

03 · Controls and evidence

Three controls that carry most of the exposure

RMiT does not use the term Tier-1. Its term is critical system, defined at paragraph 5.2. If your internal tiering does not map to that definition, fix the mapping first.

S 10.22 · S 10.52

Three key custody models, all defensible

Key storage and crypto computation must sit in an HSM, a TEE, or similarly secured devices, commensurate with risk. Separately, you must retain ownership, control and management of cloud-hosted data including key management.

What it does not say: no paragraph mandates hold-your-own-key or an external key store. Paragraph 10.21 expressly contemplates an institution that does not generate its own keys. Any vendor calling one architecture "the requirement" is describing a product.
10.22HSM, TEE or equivalent
10.52Retained control of key management
WHERE KEY MATERIAL LIVES CLOUD BOUNDARY Provider-managed Model A Needs 10.21 controls Customer-managed Model B Dedicated HSM cluster External custody Model C Adds latency and availability coupling All three can satisfy 10.22. What changes is the document you produce.
S 10.57

Engineers must not be able to delete their own trail

Activity in critical systems must be logged, retained at least three years, and reviewed regularly. Anomalies must be flagged for prompt investigation.

Common miss: MCIPD governs customer information handling and permitted disclosure. It does not prescribe access architecture and should not be cited as if it does.
3 yearsMinimum activity log retention
DenyDelete path, from the recorded identity
WRITE PATH vs RECORD PATH Engineer identity Workload critical system Audit store separate boundary act write delete: explicit deny 36 months retention floor
S 10.32

Two ceilings, not one

For critical systems with a reasonable expectation of immediate service: cumulative unplanned downtime on the customer or counterparty interface of not more than 4 hours on a rolling 12 months, and a maximum tolerable downtime of 120 minutes per incident.

The one that gets quoted is the easy one. The rolling annual figure is cumulative and does not reset with a good quarter. Both are proven from the incident register, not from a design document.
120 minPer incident
4 hoursRolling 12 months
TWO CEILINGS PER INCIDENT 120 min single event tolerance ROLLING 12 MONTHS, CUMULATIVE 4 hours Each block is one incident. Four clean incidents can still breach the annual ceiling. Evidence: incident register with duration per event and rolling total
04 · Position check

Six questions, answered from what you could produce this week

Runs in your browser. Nothing is recorded or sent. Answer for the evidence that exists today, not what is on the roadmap.

01
S 17.1

Consultation on record

Was BNM consulted before your first public cloud adoption of a critical system, with Appendix 7 Parts A, B and C complete?

02
G 10.51

Appendix 10 mapping

Do you hold a current written mapping with a justification for every measure you have departed from?

03
S 18.1

Gap analysis tracked

Was the gap analysis against the 28 November 2025 revision submitted, and is the action plan tracked to milestones?

04
S 10.22 · 10.52

Key custody documented

Can you show on paper who holds and manages the keys protecting critical-system data, and how control is retained?

05
S 10.57

Logs beyond reach

Retained three years, and the engineering identities recorded cannot alter or delete them?

06
S 10.32

Both ceilings proven

Can the incident register produce 120 minutes per incident and 4 hours cumulative on a rolling 12 months?

Answer the six above

For each one, BNM asks for a document rather than an explanation. Answer all six to see where yours are missing.

Sources and verification

Check any of it yourself

Primary

RMiT policy document

Bank Negara Malaysia, issued 28 November 2025. Ref BNM/RH/PD 028-98. Cited: 5.2, 10.7, 10.20, 10.21, 10.22, 10.32, 10.50, 10.51, 10.52, 10.57, 11.18, 17.1, 17.2, 17.5, 18.1, Appendix 7, Appendix 10.

Open the policy document →
Primary

MCIPD policy document

Bank Negara Malaysia, issued 31 October 2025, superseding the 3 April 2023 document. Cited here only for customer information handling and permitted disclosure.

Public record

Bank Rakyat enforcement

RM1 million administrative monetary penalty imposed 20 January 2026 under the RMiT and MCIPD policy documents. Settled 26 January 2026. No technical root cause published.

Numbering

Watch the edition

The November 2025 revision renumbered parts of section 10. Cryptography and HSM moved from 10.19 to 10.22. Cloud data control moved from 10.53 to 10.52. A document citing 10.19 for cryptography is citing the superseded edition.

© Bahwan CyberTek bahwancybertek.com