Singapore's financial institutions have operated under a Technology Risk Management (TRM) Notice regime since 2014. The regime was reissued in 2024 as a family of 11 parallel Notices under the Financial Services and Markets Act 2022 - covering banking, insurance, payments, capital markets, credit bureaus, financial advisers, and trust companies. Every Notice in the family requires the institution it covers to identify its critical systems, keep unscheduled downtime for each critical system under four hours in any 12-month period, hold a recovery time objective of no more than four hours, validate that RTO through annual recovery testing, notify MAS within one hour of discovering a “relevant incident,” and follow up with a root cause and impact analysis report within 14 days.  

A “relevant incident” is triggered by either of two distinct events: an IT security incident, defined as a security breach such as hacking, intrusion, or denial of service OR a system malfunction, defined simply as a failure of the institution’s critical systems, with no reference to cause at all. A vendor software bug that takes a critical system down is a system malfunction. It hits the same one-hour notification clock and the same 14-day root cause report as an attack - whether the institution in question is a bank, an insurer, a payment operator, or an exchange. MAS doesn't require a cause to be established before the reporting clock starts - a system malfunction is defined purely by its effect on operations, with no reference to why it happened. That's already written into the Notices that have been in force since 2024.

The 10 June 2026 Consultation Paper proposes amendments to these 11 TRM Notices. The consultation window closed 31 July 2026. MAS proposes that the finalized requirements take effect 12 months after the revised Notices are published, so nothing below is enforceable yet, and firms should expect a transition period once MAS responds to feedback rather than an immediate deadline. 

The amendments touch eight areas: IT asset management, IT risk assessment and monitoring, capacity planning, change management controls, continuous system and security monitoring, immutable and offline data backup, incident management, and a clarification to how unscheduled downtime is computed. 

On change management, MAS states directly that it has observed a significant number of financial institution IT incidents attributed to poor change management, not to external attackers. The specific lapses MAS calls out: insufficient risk and impact assessment of changes, poor understanding of system dependencies, inadequate testing, and the absence of effective change recovery plans. The proposed fix is procedural - risk assessment before any change to a system, mandatory testing of all changes to critical systems before they reach production, and defined recovery measures if something goes wrong during or after implementation. 

On immutable and offline data backup, MAS’s rationale is even more direct. It names system bugs, cyber-attacks such as ransomware, and human error together, in that order, as the causes of the data loss and corruption the backup requirement exists to guard against. A software defect sits on equal footing with an attack in the regulator’s own stated reasoning for the rule. 

Two other details worth flagging, and both are proposed uniformly across all 11 Notices. First, the amendments would widen the “relevant incident” trigger itself: the current Notices define a system malfunction as a failure of a critical system specifically, but the draft broadens this to a failure of any system, critical or not, plus an explicit third trigger for incidents that compromise the confidentiality of customer information. Second, the proposed IT asset inventory requirement (Appendix A of each draft Notice) would require institutions to record, for every hardware, software, cryptographic, open-source, and third-party component, its model and version information, including current patch level, along with the systems it supports and who’s responsible for maintaining it. 

Separately, MAS has flagged that the existing 4-hour per-12-month unscheduled downtime ceiling has been applied inconsistently. Some firms, in MAS’s observation, excluded partial or intermittent disruptions from that computation. The proposed amendment makes explicit that partial and intermittent disruptions must be counted. 

Singapore isn't acting alone here. The EU's DORA, the UK's FCA SYSC 15A and forthcoming PRA SS1/26, and Canada's OSFI B-13 share the same underlying logic: operational resilience obligations are defined by the impact of a disruption on customers and market functioning, not by whether the root cause was adversarial. MAS's proposed emphasis on change management and non-security data loss sits squarely in that convergence. 

MAS's own stated rationale, and the fact that the cause-agnostic “relevant incident” definition is already in force across all eleven Notices, points to where supervisory attention already sits. Banks, insurers, payment providers, capital markets entities, and every other sector in the family of Notices have a practical window to get ahead of the eventual transition period: 

• Build an IT asset inventory that captures model, version, and patch level for third-party and open-source components specifically, not just internally built systems. This is the proposed Appendix A standard, not a nice-to-have. 

• Formalize change-risk assessment and pre-production testing as a documented, evidenced process. 

• Review how unscheduled downtime is currently tracked against the four-hour threshold, specifically whether partial or intermittent disruptions are captured. 

• Treat data backup immutability as a named, evidenced control distinct from general business continuity documentation. 

BugZero doesn't file a firm's compliance position - that's the firm's own risk and compliance function's call. What BugZero provides is visibility into the exact class of risk MAS's own rationale calls out by name: known defects, version and patch status, and risk exposure in the third-party vendor software running inside a firm's critical systems. For institutions building the IT asset inventory MAS is proposing, one that explicitly requires model, version, and current patch level for every third-party component, that visibility becomes a direct input and an evidence base a firm can draw on for its own risk management.