Bank Negara Malaysia's Risk Management in Technology policy document (RMiT) is the binding technology and cyber risk rulebook for Malaysian banks, insurers, takaful operators and payment firms, and its latest version folds in fraud controls, cloud rules and the national critical information infrastructure code of practice. The current document, reference BNM/RH/PD 028-98, took effect on 28 November 2025 and the version on the Bank's site was updated on 25 September 2026. It supersedes the June 2023 RMiT and several electronic banking and fraud documents, and it sets hard numbers: four hours of cumulative unplanned downtime a year for critical systems, three-year log retention, annual intelligence-led penetration tests and a red team exercise at least every three years. This guide explains who RMiT applies to, its structure and key standards, the dates, how enforcement works, and what it means for privileged, service and AI agent identities. It is written for CISOs, technology risk and compliance teams at Malaysian financial institutions and their technology providers. For Singapore's equivalent, see the MAS Technology Risk Management Guide.
Key takeaways
- "S" paragraphs are binding: RMiT marks standards with "S", which must be complied with and where non-compliance may result in enforcement action, and guidance with "G".
- Availability has a number: critical systems may not exceed 4 hours of cumulative unplanned downtime affecting customer interfaces over a rolling 12 months, with a maximum tolerable downtime of 120 minutes per incident.
- Access control is prescriptive: deny all by default, least privilege, time-bound access, segregation of duties, credentials uniquely linked to a single user, MFA resistant to social engineering, and activity logs on critical systems kept at least three years.
- Testing is layered: quarterly vulnerability assessments of critical network components, annual intelligence-led penetration tests, a red team simulation at least every three years, and an annual cyber drill reported to the board.
- Cloud and emerging technology need the Bank's involvement: institutions consult the Bank before first-time adoption of public cloud or emerging technology for critical systems, with a risk assessment and an independent pre-implementation review.
Scope: who and what is covered
Paragraph 2.1 applies RMiT 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 e-money issuers, designated payment system operators, registered merchant acquirers and intermediary remittance institutions. Paragraph 2.2 carves some parts out for some categories; for example Part C and Appendices 6 and 7 do not apply to designated payment system operators, eligible e-money issuers, non-bank merchant acquirers or intermediary remittance institutions. Check paragraph 2.2 for your licence type before scoping.
The document is issued under sections 47 and 143 of the Financial Services Act 2013, sections 57 and 155 of the Islamic Financial Services Act 2013, sections 41 and 116 of the Development Financial Institutions Act 2002, and the Money Services Business Act 2011. It replaces six earlier documents, listed in paragraph 7.1.
| Superseded document | Date of superseded version |
|---|---|
| Risk Management in Technology (RMiT) | 1 June 2023 |
| Electronic banking guidelines, including paragraphs 21, 22 and 26 | 18 November 2019 |
| Measures against internet and mobile banking fraud | 31 May 2022 |
| Specifications on electronic banking fraud | 23 August 2022 |
| Additional guidance on customer information protection | 10 July 2023 |
| Specifications on Fraud Detection Standard | 27 March 2024 |
Key obligations
Part B holds the policy requirements and Part C the regulatory process. The table summarises the main standards by section, with paragraph numbers from the document on the Bank's site.
| Section | Key standards | Paragraphs |
|---|---|---|
| 8 Governance | Board approves technology risk appetite with risk owners and key risk indicators; IT and cybersecurity strategic plans for no less than three years; board-level committee with at least one member with technology experience; Board Audit Committee oversees technology audit | 8.1 to 8.7 |
| 9 Technology risk management | Technology risk management framework within enterprise risk management; independent technology risk function; a CISO with sufficient authority, independence and resources, independent from day-to-day technology operations and appropriately certified | 9.1 to 9.5 |
| 10 Technology operations | Cryptography with annual algorithm review and institution-controlled keys in an HSM, TEE or similar; data centre and network resilience with no single point of failure; network logs kept three years; downtime limits and stand-in processing; third-party management; cloud risk assessment; access control | 10.20 to 10.57 |
| 11 Cybersecurity | Cyber resilience framework covering identify, protect, detect, respond and recover, including zero trust and defence in depth; Appendix 5 controls; red team at least every three years; SOC; threat intelligence; cyber incident response plan; out-of-band communication; annual cyber drill; incident notification | 11.2 to 11.19 |
| 12 Digital services | Authentication and transaction authorisation controls; fraud detection updates; secure channels, including removing clickable links from SMS; a secure self-service kill switch for customers; customer notification and credential revocation after compromise | 12.1 to 12.9 |
| 13 to 15 Audit, assurance, awareness | Risk-based technology audit by certified staff; external data centre and network resilience assessments at least every three years; annual staff awareness and regular board training | 13.1 to 15.3 |
| 16 to 17 Regulatory process | Notify the Bank before new or enhanced digital services, with external assurance where the simplified route does not apply; consult before first-time public cloud or emerging technology for critical systems; notify on later adoptions | 16.1 to 17.2 |
Access control in detail (paragraphs 10.53 to 10.57)
- Policy: an access control policy is required (10.53).
- Principles: deny all by default, least privilege, time-bound access, segregation of incompatible functions, defined criteria for dual authorisation, and stronger authentication for remote access and critical activities (10.54(a) to (f)). Credentials must be uniquely linked to a single user (10.54(f)(iii)).
- MFA: multi-factor authentication resistant to social engineering, combining two or more factor types (10.55). Appendix 5 also requires MFA for all remote access sessions, through hardened endpoints, secure tunnels and gateway servers.
- Access matrix: a user access matrix that is periodically reviewed (10.56).
- Monitoring and logs: enterprise-wide access monitoring; user activities in critical systems logged, reviewed regularly and kept for at least three years (10.57).
See the Phishing-Resistant MFA Guide for options that meet a social-engineering-resistant standard.
Cybersecurity controls in Appendix 5
| Area | Requirement |
|---|---|
| DDoS | Mitigation services with clean pipe filtering, assessment of provider bandwidth expansion, geolocation controls, covering DNS-based, volumetric, protocol and application-layer attacks |
| Security operations centre | Log collection and correlation, incident response, threat hunting and intelligence, a monthly threat assessment report, 24x7 operation with disaster recovery, physically secure location |
| Vulnerability assessment | Quarterly for critical network components |
| Penetration testing | Annual intelligence-led tests of internal, external and digital services, plus tests before new systems go live |
| Compromise assessment | Independent compromise assessment of critical systems at least once every three years |
| Forensic readiness | Full network packet capture to reconstruct sessions |
| Server authentication | PKI-based server-to-server authentication |
Cloud and third parties
Before adopting cloud services, an institution performs a comprehensive risk assessment covering matters such as multi-tenancy, vendor lock-in and exit (10.50), considers the Appendix 10 controls for critical systems on public cloud (10.51), and keeps ownership, control and management of customer data and encryption keys (10.52, 10.21). For third parties, the institution remains accountable (10.46), runs due diligence before and during the engagement using Appendix 8 (10.47), puts regulator access, sub-contracting notice, disaster recovery and prompt incident disclosure into service level agreements (10.48), and monitors provider cybersecurity posture continuously (10.49). Outsourcing arrangements also follow the Bank's outsourcing policy document.
Appendices
The twelve appendices are: 1 removable media; 2 self-service terminals; 3 digital services; 4 mobile applications and devices; 5 cybersecurity controls; 6 simplified notification criteria; 7 risk assessment report and expectations on external parties; 8 IT and cyber risks of third-party providers; 9 guidance on emerging technologies; 10 cloud key risks and controls; 11 fraud detection standards; and 12 the code of practice for national critical information infrastructure entities designated by the Bank in the banking and finance sector. The Bank's page notes that Appendix 12 contains code of practice requirements endorsed by the National Cyber Security Agency (NACSA).
Timeline and current status
| Date | Event |
|---|---|
| 1 June 2023 | Previous RMiT version issued (now superseded) |
| 28 November 2025 | Current RMiT published and effective, except where the document states otherwise |
| 1 July 2026 | RMiT FAQ updated, per the Bank's page |
| 25 September 2026 | Updated policy document published on the Bank's page |
| 30 September 2027 | Early-warning mechanisms and stand-in processing under 10.31(a) and (c) due |
| 15 October 2027 | Quarterly service availability disclosure under 10.35(e) begins |
As of November 2026 the 28 November 2025 document, as updated on 25 September 2026, is current. The Bank's page does not describe what changed in the September 2026 update, so compare against your gap analysis and check the FAQ.
Enforcement and penalties
Paragraph 1.3 and the definition of "S" in paragraph 5.2 state that non-compliance with standards may result in enforcement or supervisory action. Because RMiT is issued under the Financial Services Act 2013, the Islamic Financial Services Act 2013 and the Development Financial Institutions Act 2002, the Bank's enforcement powers under those Acts apply; RMiT itself does not set penalty amounts, so consult the relevant Act and legal advisers for exposure. In practice, supervisory findings, required remediation plans and conditions on new digital services or cloud adoption under Part C are the most common consequences, and the 4-hour downtime limit creates a measurable compliance line. Incident notification runs through the Bank's operational risk reporting and business continuity management policy documents (11.18).
What it means for AI agents and non-human identities
- Unique credentials apply to machines too: the requirement that credentials be uniquely linked to a single user (10.54(f)(iii)) rules out shared generic IDs. Treat each service account, integration and AI agent as its own identity with a named owner. See the Service Account Security Guide.
- Least privilege and time-bound access fit automation: grant pipeline and agent credentials only the scopes their task needs, issue them for limited periods, and prefer short-lived tokens over static keys.
- Dual authorisation for critical actions: where an agent can initiate payments, change limits or alter configuration, the dual authorisation criteria in 10.54(e) suggest a human approval step for high-impact actions.
- Logs must attribute agent actions: three-year activity logging on critical systems is only useful if each automated actor has its own identity in the logs.
- Server-to-server PKI: Appendix 5 calls for PKI-based server authentication, which aligns with certificate-based workload identity and managed key storage under 10.22.
- AI is emerging technology: RMiT does not name AI, but paragraph 17.1 and Appendix 9 cover emerging technology. Using an AI model in a critical system is likely to need consultation with the Bank and a pre-implementation review. See Financial Regulators and AI.
Compliance steps
- Confirm applicability. Map each licensed entity to paragraph 2.1 and note any paragraph 2.2 carve-outs.
- Run a gap analysis. Compare current controls to every "S" paragraph and the appendices that apply, starting with access control, downtime and logging.
- Close identity gaps first. Remove shared IDs, enforce social-engineering-resistant MFA, implement deny-by-default and time-bound privileged access, and review the access matrix. See the Privileged Access Management Guide.
- Set log retention to three years. Cover critical system activity logs and network logs, with SOC correlation.
- Measure availability. Track cumulative unplanned downtime per critical system against 4 hours and 120 minutes per incident, and plan stand-in processing for the September 2027 date.
- Schedule testing. Quarterly vulnerability assessments, annual intelligence-led penetration tests, three-yearly red team and compromise assessment, annual cyber drill. See the Threat-Led Penetration Testing Guide.
- Review cloud and third parties. Refresh cloud risk assessments against Appendix 10, confirm key ownership, update service level agreements and plan consultations for new critical cloud or AI use.
- Brief the board. Confirm risk appetite, the three-year strategic plans and the cyber drill results are on the board agenda.
Metrics
- Unplanned downtime: cumulative hours per critical system over the rolling 12 months against the 4-hour limit.
- Shared or generic IDs: count of credentials not linked to a single user or owned service identity, target zero.
- MFA coverage: share of remote and critical access sessions using social-engineering-resistant MFA.
- Testing on schedule: quarterly assessments and annual tests completed on time.
- Finding closure: share of penetration test and red team findings closed within agreed timeframes.
Framework mapping
| RMiT area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Access control (10.53 to 10.57) | PR.AA-05 | AC-6, AC-2 |
| MFA (10.55) | PR.AA-03 | IA-2 |
| Log retention (10.57) | PR.PS-04 | AU-11 |
| Penetration and red team testing (11.6, Appendix 5) | ID.IM-02 | CA-8 |
| Third-party management (10.46 to 10.49) | GV.SC-07 | SA-9 |
| Cryptographic keys (10.20 to 10.22) | PR.DS-01 | SC-12 |
Common failure patterns
- Shared admin and service IDs: these break the unique credential rule and make three-year logs useless for attribution.
- Treating RMiT as an IT document: board-level duties such as risk appetite and the technology committee member are easy to miss.
- Late Part C engagement: starting a cloud or AI project for a critical system before consulting the Bank delays go-live.
- Measuring uptime, not downtime: a 99.9% availability target allows almost nine hours a year, more than double the RMiT limit.
- Working from the 2023 version: the June 2023 RMiT and the fraud specifications it replaced are superseded.
Practitioner checklist
- Keep the current RMiT document and FAQ from the Bank's site, with the version date recorded.
- Maintain a paragraph-by-paragraph compliance register for every "S" standard and applicable appendix.
- Eliminate shared credentials and assign every service account and AI agent a named owner.
- Enforce deny-by-default, least privilege and time-bound privileged access with periodic access matrix review.
- Retain critical system activity logs and network logs for at least three years.
- Track unplanned downtime per critical system against the 4-hour and 120-minute limits.
- Run quarterly vulnerability assessments, annual intelligence-led penetration tests and the three-yearly red team.
- Consult the Bank before first-time public cloud or emerging technology use in critical systems.
- Report cyber drill results and technology risk to the board.
Standards and references
- Bank Negara Malaysia: Risk Management in Technology (RMiT) Policy Document
- Bank Negara Malaysia: Policy Document on Risk Management in Technology (RMiT) announcement
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- NHI Mgmt Group: MAS Technology Risk Management Guide
- NHI Mgmt Group: Financial Services Cyber Regulation Map
Related NHI Mgmt Group resources: MAS Technology Risk Management Guide · Malaysia PDPA Guide · Financial Services Cyber Regulation Map · Financial Services Identity Security Guide. This guide summarises Bank Negara Malaysia's RMiT policy document and is not legal advice.