The MAS TRM Guidelines are the Monetary Authority of Singapore's technology risk management expectations for the financial institutions it regulates — banks, insurers, capital markets intermediaries and payment services licensees. They are guidelines, not law. MAS expects adherence, and the degree of observance feeds directly into its supervisory risk assessment of the institution, but non-adherence is not in itself a legal breach. The current revision was issued in January 2021.
That last point is where most coverage goes wrong, and it is the most useful thing to get straight before you build anything. The Guidelines set the expected standard; MAS Notices create binding legal obligations. Both matter to a regulated institution, but not in the same way, and they should not sit at the same place in your remediation queue.
What the MAS TRM Guidelines Are
The MAS TRM Guidelines are a published document covering how a MAS-regulated financial institution should govern, build, run and defend its technology. They apply to institutions under MAS supervision across the sector, and they reach vendors indirectly — an institution that depends on you for a regulated service has to demonstrate control over the technology risk you introduce.
There is no MAS TRM certificate. What exists instead is a supervisory relationship: MAS forms a view of your posture from your documented framework, control evidence, incident history, independent assessments and IT audit output. Alignment is a state you demonstrate on request, not a milestone you pass.
Read the Guidelines from the source. MAS publishes them, with the notices and circulars that refine expectations between revisions, at mas.gov.sg. Third-party write-ups are unusually unreliable here, partly because MAS restructured and renumbered its notices in 2024 and much of what circulates predates that.
Guidelines Versus Notices: The Distinction That Sets Priority
Guidelines and Notices differ in legal status, in the consequence of falling short, and in how each surfaces during supervision. Treat them as one pile of requirements and you will under-invest in the obligations that carry legal weight.
| TRM Guidelines | MAS Notice | |
|---|---|---|
| Legal status | Guidance. Not law in itself; no direct penalty for non-adherence. | Legally binding on the institutions it applies to, issued under the relevant statute. |
| Consequence of falling short | Weighed in MAS's supervisory risk assessment. Treated in practice as the expected standard. | Breach of a legal obligation, not a supervisory observation. |
| How it shows up | Expectations against which your framework, controls and governance are assessed. | Mandated measures you either comply with or do not. |
An institution that calls the TRM Guidelines "mandatory" and a Notice "best practice" has the relationship backwards, and that inversion shows up in real roadmaps. The binding items are narrower and more prescriptive, which makes them cheaper to close and more damaging to leave open.
Technology Risk Governance and Board Oversight
Technology risk governance in Singapore starts at the board. The Guidelines place specific responsibility on the board and senior management for oversight of technology risk, which means the governance layer is itself an area of expectation rather than a preamble to the technical controls.
What MAS expects: a board and senior management that understand the institution's technology risk, set its risk appetite, assign accountability to people with the relevant competence, and receive reporting frequently enough to act on it. Not a committee that exists on an org chart.
Show a charter for the forum where technology risk is discussed, with named members and a defined cadence; minutes that record decisions rather than attendance; an approved risk appetite statement someone can explain; and a board pack carrying current risk positions, open issues and incident history. Minutes recording "the report was noted" for four consecutive quarters tell a supervisor the forum is not doing the work.
The Technology Risk Management Framework
The technology risk management framework domain asks for a documented framework covering identification, assessment, treatment and monitoring of technology risk across the estate. This is the spine the other domains hang from.
What MAS expects: a defined method for finding technology risk, assessing it consistently, deciding what to do about it, and tracking whether the treatment worked. Consistency matters as much as sophistication — two teams assessing comparable risks should land in comparable places.
Show the framework document itself, with a version history and an owner; a system inventory the framework actually operates over, including anything inherited or outsourced; a risk register with ratings, named owners, treatment decisions and dates; and evidence the register moves. A register whose entries have not changed state in a year is a filing cabinet, not a control.
Keep the inventory honest. Most gaps found in assessment are not failures of control design — they are systems nobody put in scope.
Want your controls mapped against the TRM domains?
Share your work email and we'll send back a domain-by-domain read on where your current evidence supports a MAS TRM conversation and where it stops short.
Project Delivery, Change and the Development Lifecycle
Project delivery, change management and the system development lifecycle are treated as technology risk disciplines in their own right, because most outages in financial services are self-inflicted — they arrive through a change rather than an attacker.
What MAS expects: IT projects run with defined governance, requirements and quality review; software built through a lifecycle that includes security design and security testing rather than bolting both on at the end; and change managed with assessment, authorisation, testing and a route back.
Show governance gates with evidence they were applied, including post-implementation review; secure coding standards and test results proving they are enforced in the pipeline; a change record per production change with approval, risk assessment and rollback plan; and an emergency change path used sparingly and reviewed afterwards. An institution whose emergency changes outnumber its planned ones has a change process in name only. If you already run a mature secure development lifecycle, most of this evidence exists — the work is mapping it to the TRM framing.
Operations, Service Management and Resilience
Operations, service management and resilience cover how the institution runs its technology day to day and what happens when part of it fails. MAS expects availability to be engineered and proven, not hoped for: the operational disciplines — capacity, performance, availability, problem and incident management — running as defined processes, recovery objectives set for services supporting critical functions, and recovery capability tested rather than documented.
Show recovery time and recovery point objectives per service, agreed with the business rather than invented by IT; results from an actual recovery exercise, with the date, scope, what failed and what was fixed; capacity and availability monitoring with thresholds and escalation; and problem records showing recurring issues driven to root cause. A successful backup job is not evidence of recoverability — a restore test with a timestamp and a list of what broke is.
Access Control and Cryptography
Access control and cryptography are separate domains in the Guidelines and are worth treating separately in your evidence, because they fail in different ways. Access control fails through accumulation; cryptography fails through drift.
On access, MAS expects authentication and authorisation proportionate to risk, privileged access tightly controlled, and segregation of duties enforced where one person could otherwise both initiate and approve. Show a current inventory of privileged accounts with named owners; periodic access reviews with evidence of removals, not just sign-offs; joiner-mover-leaver records that reconcile against HR; and multi-factor authentication enforced where required. Clean access control evidence is mostly a reconciliation exercise — the gaps are in the deltas, not the policy.
On cryptography, MAS expects approved algorithms, encryption in transit and at rest where warranted, and a defined key lifecycle. Show where cryptography is used and with what algorithms; key generation, storage, rotation and destruction procedures with evidence they run; and a plan for replacing algorithms as they are deprecated. The agility question — what would you do if an algorithm you depend on were retired — is one institutions are increasingly asked and rarely ready for.
Cyber Security Operations and Testing
Cyber security operations and security testing ask whether the institution can see an attack and whether it has looked for its own weaknesses. MAS expects detection coverage over the systems that matter, informed by threat intelligence relevant to financial services, plus security testing with remediation tracked to closure.
Show log sources and coverage mapped against your critical systems, with the gaps named; alert definitions and timestamped evidence that alerts are triaged; threat intelligence feeding something — a detection, a priority, a patch decision — rather than arriving in an inbox; vulnerability assessment results on a defined cadence; and penetration test reports with findings tracked to remediation.
Testing evidence is judged on what happened after the report. A pen test with twelve open high findings from eighteen months ago is worse than no pen test, because it documents a known and unaddressed exposure.
Incident Management and the Notification Clock
Incident management carries the one hard clock in this whole picture, and it is not in the Guidelines — it is a binding notification obligation. MAS requires a regulated institution to notify MAS of a relevant incident within one hour of discovery, and to submit a root cause and impact analysis report within fourteen days.
A relevant incident is a system malfunction or IT security incident with a severe and widespread impact on the institution's operations, or which materially impacts its service to customers. Those obligations sat in MAS Notice 644 on technology risk management for banks, issued in June 2013. Notice 644 was cancelled with effect from 10 May 2024 and the framework now sits under the restructured notice referenced as FSM-N05 — worth knowing, because much online guidance still cites 644 as current.
Show a severity model that maps your incidents to the relevant-incident definition, so the one-hour decision is made by a rule rather than by debate at 2am; a named decision-maker and a tested escalation path; the notification record for any incident that met the threshold; and the fourteen-day analysis report. The incident notification obligations deserve their own runbook — one hour is not long enough to form a judgement from scratch, so pre-deciding the classification is the whole control.
Third-Party and Vendor Technology Risk
Third-party and vendor technology risk runs through the Guidelines, and the principle is short: the institution remains accountable for technology risk in outsourced arrangements. Outsourcing the function does not outsource the responsibility.
What MAS expects: due diligence proportionate to the risk the arrangement carries, contractual terms preserving the institution's ability to oversee and inspect, ongoing monitoring rather than a one-time assessment, and awareness of concentration where many services depend on one provider. Show a vendor inventory with criticality ratings and the services each supports; due diligence files with assessment dates and conclusions; contracts carrying the oversight terms the arrangement needs; and periodic reassessment with evidence it ran.
For material outsourcing arrangements expectations are higher, and include MAS's ability to exercise inspection rights over the arrangement and the service provider. Audit and inspection rights therefore have to be secured contractually, which is why MAS-regulated buyers push these clauses harder than buyers in other sectors — see vendor due diligence expectations for what those files look like from the buyer's side.
Cloud services are treated within this framework rather than by a separate cloud-only rulebook, which surprises teams expecting a dedicated cloud standard.
What the 2021 Revision Shifted
The 2021 revision changed where the weight sits rather than rebuilding the document. Two areas expanded: the responsibilities of the board and senior management, and third-party risk.
The governance expansion moves technology risk from a thing the CIO reports on to a thing the board owns, which raises the bar on reporting quality and on the competence of the people accountable. The third-party expansion reflects where financial-sector technology risk concentrated over the preceding decade — more of the estate is somebody else's. If your programme was built against an older reading of MAS expectations, start there.
How the Cyber Hygiene and Outsourcing Documents Fit
The Notice on Cyber Hygiene and the Guidelines on Outsourcing sit alongside the TRM Guidelines rather than inside them, and they have different legal characters. The Notice on Cyber Hygiene is binding and mandates baseline measures: securing administrative accounts, applying security patches within a timeframe commensurate with the risk each vulnerability poses, establishing written security standards for every system, restricting unauthorised traffic at the network perimeter, implementing malware protection, and enforcing multi-factor authentication for administrative and privileged access and for internet-facing access to systems holding customer information.
The version for banks was issued as MAS Notice 655 on 6 August 2019, taking effect 6 August 2020, with parallel notices for other classes of institution under their own numbers; it was renumbered as FSM-N06 in the 2024 restructuring. The baseline measures in Notice 655 are the shortest, most checkable list in the MAS technology risk management picture, which is why they go first. Note that the patching measure is risk-commensurate rather than a fixed number of days: any source quoting you a MAS patching SLA in days is inventing it.
MAS's outsourcing expectations sit in a separate Guidelines on Outsourcing document — related, but distinct. An institution's outsourcing governance has to satisfy both that document and the third-party domain of the TRM Guidelines, so build the vendor files to answer both.
Where ISO 27001 Gives You Genuine Reuse
An institution with ISO 27001 already in place gets genuine reuse against the TRM Guidelines. Be precise about where, because overstating the overlap is how teams end up surprised.
Real reuse: the risk management framework, since an ISMS already defines identification, assessment, treatment and monitoring; access control and cryptography evidence; operational and change management records; supplier security assessment, where third-party risk management already produces the due diligence files; internal audit discipline; and management review, which maps onto the governance reporting expectation.
Where it does not reach: the binding obligations. No ISO 27001 certificate evidences compliance with the Notice on Cyber Hygiene or the incident notification clock, because those are mandated measures assessed on their own terms. Nor does it cover the financial-services-specific depth — payment and customer-facing service security, resilience calibrated to a regulated institution's criticality, the inspection rights MAS expects over material outsourcing, and the board-level accountability the 2021 revision sharpened.
Build the ISMS, then layer the delta: one programme, two framings, one set of evidence. The control-level comparison between the two is worth reading before you scope that gap.
MAS TRM Compliance Questions Teams Ask
The MAS TRM compliance questions teams ask most often, once they realise the Guidelines and the Notices are different kinds of document.
Not in the legal sense. They are guidelines, not law in themselves, and no direct penalty attaches to non-adherence. But MAS expects adherence and the degree of observance is taken into account in its supervisory risk assessment of the institution, so in practice they function as the expected standard. The distinction is about mechanism, not about whether you can ignore them — what it buys you is sequencing.
No. There is no certification body, no audit scheme and no certificate against the TRM Guidelines. Alignment is demonstrated through artefacts: your documented framework, control evidence, independent assessment results such as an ISO 27001 certificate or a SOC 2 report, penetration test reports with remediation tracking, and IT audit output. Vendors selling to MAS-regulated institutions typically present an independent certification plus a mapping document covering each TRM domain.
Not directly — they apply to MAS-regulated financial institutions. But the institution remains accountable for technology risk in outsourced arrangements, so it flows the expectations to you through onboarding questionnaires, contractual terms and audit and inspection rights. For material outsourcing arrangements MAS can exercise inspection rights over the service provider, which is why those clauses are non-negotiable in practice.
Cloud services are treated within the existing outsourcing and technology risk framework rather than by a separate cloud-only rulebook. The analysis is the outsourcing analysis — due diligence proportionate to risk, contractual oversight and inspection rights, ongoing monitoring, concentration awareness — applied to a cloud delivery model. The practical difficulty is that standard cloud contracts are not written to give a financial regulator inspection access.
The binding items: the baseline measures mandated by the Notice on Cyber Hygiene, and a severity model that lets you decide within one hour whether something is a relevant incident, with a named person to make that call. Both are narrow, checkable and carry legal weight. Then stand up governance and the risk management framework, because every other domain produces evidence that has to land there.
Run MAS TRM and your existing ISMS as one programme
Book a demo and we'll show how Konfirmity maps one set of controls and evidence to the TRM domains and the binding Notice obligations at the same time, so you are not maintaining two parallel programmes.
Book a demo
Start With the Binding Obligations
The sequencing follows from the legal character. Start with the binding obligations — the baseline measures the Notice on Cyber Hygiene mandates, and the incident notification capability — because they are specific, checkable and carry legal consequence. Then work the Guidelines domain by domain as the standard you are supervised against.
Governance and the framework come next because they make the rest reportable. An institution with excellent controls and no framework cannot answer a supervisory question about its technology risk position; one with a working framework and visible gaps can, and a gap with an owner and a date beats an invisible one.
Pick one domain and test yourself against it this week — pull the evidence rather than the policy, and see how far it goes. To do that across every domain at once, the MAS TRM compliance checklist walks the same ground in a form you can work through with your team.
