RMiT in one minute
RMiT stands for Risk Management in Technology. It is a policy document from Bank Negara Malaysia (BNM), the central bank. The current version was issued on 25 September 2026 (reference BNM/RH/PD 028-98).
Who: banks, insurers, takaful operators, development financial institutions and certain e-money, payment, merchant-acquiring and remittance firms.
What: it sets "minimum requirements to improve financial institutions' management of technology risk", including cyber risk (RMiT paragraph 1.2). It covers board oversight, cyber security, system uptime and recovery, cloud, third-party vendors and how software is changed.
Why: a bank that goes down or gets breached hurts its customers and public confidence. RMiT asks institutions to prove, with evidence, that their technology is governed, secure and recoverable. Bigger and more digital institutions are expected to apply stronger controls (RMiT paragraph 1.2).
| Area | What it means in practice | Where in RMiT |
|---|---|---|
| Governance | The board sets the technology risk appetite and has a committee that understands technology. | Paragraphs 8.1 to 8.7 |
| Risk management | A technology risk framework that is part of company-wide risk management, run by an independent CISO. | Paragraphs 9.1 to 9.5 |
| Software change | A defined development life cycle, separate test and production, testing, and code review before changes go live. | Paragraphs 10.5 to 10.13 |
| Uptime and recovery | Critical systems built for high availability, tested backups and an isolated recovery environment. | Paragraphs 10.29 to 10.45 |
| Vendors | Due diligence on every technology provider and a contract with set minimum terms. | Paragraphs 10.46 to 10.49, Appendix 8 |
| Cloud | A full risk assessment before adopting cloud, and BNM consultation before the first public cloud for a critical system. | Paragraphs 10.50 to 10.52, 17.1 |
| Cyber security | A cyber resilience framework, the Appendix 5 controls, red teaming and an annual cyber drill. | Paragraphs 11.1 to 11.20, Appendix 5 |
| Audit and assurance | Specialist technology auditors, plus external data centre and network resilience reviews. | Paragraphs 13.1 to 14.2 |
| Gap analysis | Check your practices against the latest text and keep an annual compliance assessment ready for BNM. | Paragraph 18.1 |
Who RMiT applies to
The cover of the September 2026 document lists who it applies to:
- Licensed banks, investment banks and Islamic banks
- Licensed insurers and takaful operators, including professional reinsurers and retakaful operators
- Prescribed development financial institutions
- Approved issuers of electronic money
- Operators of a designated payment system
- Registered merchant acquirers
- Intermediary remittance institutions
Not every firm in these groups is caught. E-money issuers are covered when they are "eligible" (broadly, those with substantial market presence), and non-bank merchant acquirers and intermediary remittance institutions when they hold at least 5% of the market (RMiT paragraph 5.2). A few paragraphs do not apply to some of these firms (RMiT paragraph 2.2).
What if you sell software or services to a financial institution?
RMiT is addressed to the institution, not to you. But "the financial institution remains accountable for managing all risks" from its technology providers (RMiT paragraph 10.46), so the requirements reach you through due diligence and the contract. Cloud providers count as third party service providers too (RMiT paragraph 5.2). In practice, expect:
- Due diligence before you are onboarded and throughout the engagement, covering risks such as your secure development life cycle and how you vet third-party and open-source software (RMiT paragraph 10.47 and Appendix 8).
- A service level agreement with minimum terms: access rights for the regulator, notice before substantial sub-contracting, disaster recovery and backup arrangements, uptime objectives, exit arrangements and prompt notice of incidents (RMiT paragraph 10.48).
- If you build or maintain a critical system: notice before changes, proof you follow secure-by-design principles, and source code that stays accessible to the institution (RMiT paragraph 10.12).
- Ongoing monitoring of your cyber security posture by the institution (RMiT paragraph 10.49).
If you are not a financial institution or one of its suppliers, RMiT does not bind you. Many teams still use it as a well-written benchmark for running technology properly.
The main areas of RMiT, in plain English
RMiT is 113 pages. These are the six areas most teams spend their time on.
01Technology governance and board oversight
The board approves the technology risk appetite and IT and cyber security strategic plans covering at least three years. A board-level committee oversees technology, and it must include at least one member with technology experience. Management sets up a cross-functional technology committee, and the institution appoints a CISO who is independent from day-to-day technology operations. (RMiT paragraphs 8.1 to 8.7, 9.4)
02Cyber security
The institution keeps a cyber resilience framework that covers identifying, protecting, detecting, responding to and recovering from attacks. It must adopt the control measures in Appendix 5, run a realistic red team exercise at least once every three years, and run a cyber drill every year. Institutions designated as national critical information infrastructure must also follow NACSA's requirements under the Cyber Security Act 2024. (RMiT paragraphs 11.2 to 11.6, 11.16)
03System resilience and recovery
For critical systems that customers expect to work immediately, unplanned downtime must not exceed 4 hours in total over a rolling 12 months, with "a maximum tolerable downtime of 120 minutes per incident". Backups must be tested by actually restoring them, and the institution needs a tamper-proof backup and an isolated recovery environment. External specialists review data centre and network resilience at least once every three years. (RMiT paragraphs 10.32, 10.44, 10.45, 14.1, 14.2)
04Cloud and outsourcing
Before adopting cloud, the institution runs a full risk assessment covering things such as where the data sits, vendor lock-in and what happens on exit. It keeps ownership and control of customer data and the related encryption keys. Before the first use of public cloud for a critical system, it must consult BNM. Outsourcing arrangements also follow BNM's separate policy document on Outsourcing. (RMiT paragraphs 10.50 to 10.52, 17.1)
05Vendor and third-party management
The board and senior management oversee every provider of critical technology. The institution does due diligence before and during each engagement, signs a service level agreement with the minimum terms RMiT lists, and works towards continuous monitoring of each provider's cyber security posture. (RMiT paragraphs 10.46 to 10.49, Appendix 8)
06Software change management and code review
Software follows a defined development life cycle, with production kept separate from development and testing. Changes are tested before deployment. Changes to the source code of critical systems must be "subject to adequate source code reviews" before they go live, and system changes are independently reviewed and approved. Systems must not run with known security vulnerabilities. (RMiT paragraphs 10.5 to 10.11, 10.17)
What changed in the September 2026 reissue
BNM does not publish a marked-up comparison inside the document, so here is only what the reissued text itself confirms:
- It was issued on 25 September 2026 and states it came into effect on 28 November 2025, except where a paragraph sets its own date (RMiT paragraph 4.1).
- It supersedes several earlier documents, including the RMiT policy document issued on 1 June 2023, the e-banking guidelines and earlier fraud-measure documents (RMiT paragraph 7.1).
- It now carries a Fraud Detection Standards appendix and a Code of Practice for national critical information infrastructure entities in banking and finance (Appendices 11 and 12).
- Some measures carry their own deadline. For example, early-warning monitoring and stand-in processing for key digital services are due by 30 September 2027 (RMiT paragraph 10.31).
- Institutions that already submitted a gap analysis must identify any new gaps against the revised requirements and keep an updated annual assessment ready for BNM on request (RMiT paragraph 18.1).
Check bnm.gov.my for a newer issue before relying on these dates.
What auditors check
RMiT expects technology audits whose scope matches how critical and complex the systems are (RMiT paragraph 13.1). The yearly audit plan must cover critical technology services, third-party providers, material external interfaces and post-implementation reviews of new or materially changed services (RMiT paragraph 13.2). In practice, auditors ask for evidence like this:
- Board and committee minutes showing technology risk was discussed and the risk appetite approved.
- Your list of critical systems and how you classified them.
- For a sample of changes: the code review record, test results and an independent approval, all dated before go-live.
- Backup restore tests and disaster recovery results, with any failures and the fix.
- Downtime records for critical systems measured against the 4-hour and 120-minute limits.
- Vendor due diligence files and signed service level agreements.
- Cloud risk assessments, and BNM consultation records where they apply.
- Red team, penetration test and cyber drill reports, with remediation tracked to closure.
- Your latest gap analysis and action plan against the current RMiT.
If the evidence was not recorded at the time, for audit purposes the control usually did not happen.
Where do you stand? A quick checklist
Answer yes or no. Every "no" is a gap worth a closer look.
- We know whether we are a financial institution under RMiT, or a supplier to one.
- We have an up-to-date list of our critical systems.
- Our board has approved a technology risk appetite, and a board committee with technology experience oversees it.
- Every change to a critical system's code has a dated review record and an independent approval.
- We restored from backup in the last year and wrote down the result.
- We can show downtime figures for each critical system against the 4-hour and 120-minute limits.
- Our vendor contracts include the minimum terms in RMiT paragraph 10.48.
- We assessed the risks before moving any critical system to the cloud.
- We ran a cyber drill this year and reported the result to the board.
- Our gap analysis has been updated against the September 2026 text.
Three or more "no" answers usually means the audit will find them first.
How Anchor Sprint helps
We do the hands-on engineering work that produces RMiT evidence. Your compliance team stays in charge of the interpretation.
Code review evidence with SonarQube
As a Sonar reseller partner, we set up SonarQube so every pull request is analysed and gated, which gives you a dated review record for each change. It supports your evidence for paragraph 10.10; it does not make you compliant on its own.
Resilience testing
We test whether your critical systems actually survive: failure injection, load to failure, disaster recovery fail-over and service-level objectives, with findings mapped to RMiT.
RMiT does not name or approve any tool or provider.
Frequently asked questions
RMiT stands for Risk Management in Technology. It is a policy document issued by Bank Negara Malaysia that sets minimum requirements for how financial institutions manage technology and cyber risk. The current version was issued on 25 September 2026 (reference BNM/RH/PD 028-98).
It applies directly to banks, insurers, takaful operators, development financial institutions and some e-money, payment, merchant-acquiring and remittance firms. If you supply technology to one of them, it reaches you indirectly: the institution must do due diligence on you and put RMiT's minimum terms into your contract (RMiT paragraphs 10.46 to 10.48). Other companies are not bound by it.
Paragraphs marked "S" are mandatory for the institutions it covers, and BNM can take enforcement action for non-compliance (RMiT paragraphs 1.3 and 5.2). Paragraphs marked "G" are guidance that is encouraged but not required.
RMiT defines a critical system as an application system that supports critical banking, insurance, takaful, payment, investment or trading services, where a failure could significantly impair the institution's services, operations, finances, reputation or compliance (RMiT paragraph 5.2). Many of the strictest rules, such as code review and the downtime limits, apply to critical systems.
The September 2026 issue states it came into effect on 28 November 2025, except where a paragraph sets its own date (RMiT paragraph 4.1). Some measures have later deadlines, such as 30 September 2027 for parts of paragraph 10.31. Check bnm.gov.my for any newer issue.
Sources
- Bank Negara Malaysia, Risk Management in Technology (RMiT) policy documentIssued 25 September 2026, BNM/RH/PD 028-98. All paragraph numbers on this page refer to this document.