A MAS TRM compliance checklist works only if it runs in phases. Start by establishing which institution class you fall into and which Monetary Authority of Singapore Notices legally bind you, then build governance, then the binding cyber hygiene baseline, then operations, cyber security operations, incident management and third-party risk. Scope first, controls second — in that order, because scope determines what the rest of the list even says.
Most MAS TRM readiness programmes get this backwards. They open a copy of the Technology Risk Management Guidelines, start writing policies against the domains in order, and only later discover that half the effort went into expectations while a legally binding Notice sat unaddressed.
The distinction to internalise first: the TRM Guidelines are guidelines — not law in themselves, carrying no direct penalty, but MAS expects adherence and the degree of observance feeds its supervisory risk assessment of your institution. A MAS Notice is legally binding on the institutions it applies to. Treating the Guidelines as mandatory and a Notice as best practice has the relationship inverted, and it shows up in how a programme is prioritised.
What a MAS TRM Compliance Checklist Has to Cover
A usable MAS TRM compliance checklist covers eight phases, each producing a named artefact with a named owner. Not a flat list of controls but a sequence, because later phases depend on decisions made in earlier ones. You cannot write a meaningful technology risk management framework before you know which Notices bind you, nor scope third-party monitoring before you know which arrangements are material.
| Phase | What you produce | Who owns it |
|---|---|---|
| 1. Applicability | Regulatory applicability register: institution class, binding Notices, Guidelines standing | Head of Compliance |
| 2. Governance | Technology risk management framework, risk appetite statement, board reporting pack | Board and CIO/CTO |
| 3. Cyber hygiene baseline | Evidence pack for the six mandated measures, per system | CISO |
| 4. Operations | Access, cryptography, change, SDLC, service management and resilience procedures | Engineering leadership |
| 5. Cyber security operations | Threat intelligence process, test plan and schedule, monitoring use cases | Security operations lead |
| 6. Incident management | Incident response plan with notification runbook and out-of-hours roster | CISO and Head of Operations |
| 7. Third party and outsourcing | Materiality assessments, contract clause set, monitoring plan, exit plans | Procurement and risk owner |
| 8. Currency | Review calendar, attestation log, evidence freshness dashboard | Compliance lead |
Work them in order. Where resource constraints force parallel tracks, keep Phase 1 strictly ahead of everything else.
Phase 1: Establish What Actually Applies to You
Phase 1 establishes what actually applies to you, and it is the step teams skip. Your institution class determines which Notices bind you, and that determination changes the scope, the evidence and the consequences of everything in the seven phases after it.
Produce a single regulatory applicability register. It should state, in writing:
- Your institution class and licence. Bank, insurer, capital markets services licensee, payment services licensee, or another class. This is the input to everything else.
- Every MAS Notice that binds you, by its current reference. MAS restructured and renumbered notices in 2024, and some of what circulates online still cites cancelled numbers as current. Check against MAS's own site rather than a vendor summary.
- The standing of the TRM Guidelines for you. They are an expectation that shapes supervisory assessment, not a statute. Record that explicitly so nobody later argues the point in a steering meeting.
- Which business lines and entities are in scope, including any Singapore branch or subsidiary structure.
Two hours of work from someone who can read a licence condition saves a quarter of misdirected effort.
Phase 2: Governance and Board Accountability
Phase 2 builds governance and board accountability, which is where MAS looks first. The 2021 revision of the Guidelines notably expanded guidance on board and senior management responsibilities, and a supervisory conversation about technology risk almost always begins at that level rather than with a firewall rule.
Produce four things:
- A documented technology risk management framework. Identification, assessment, treatment and monitoring of technology risk across the estate. Owner: CIO or CTO, approved by the board.
- A technology risk appetite statement that says what level of technology risk the institution accepts, in terms someone can test a decision against. Owner: board.
- Defined roles and reporting lines, including who holds accountability for technology risk at senior management level and which committee receives it. Owner: Head of Compliance, ratified by the board.
- A board reporting pack and cadence. What goes up, how often, and in what form. Owner: CISO, presented by the accountable executive.
A MAS technology risk assessment is the operating core of this phase. The framework document is worth little unless assessments actually run against it: real systems rated, treatment decisions recorded with an owner and a date, residual risk accepted by someone with authority to accept it. Keep the assessment register as the live artefact and the framework as the description of how the register works.
Phase 3: The Binding Cyber Hygiene Baseline
Phase 3 is the binding cyber hygiene baseline, and it sits before operations deliberately. These measures are legal obligations under the Notice on Cyber Hygiene rather than supervisory expectations, so a gap here is a breach, not a finding.
The version for banks was issued as MAS Notice 655 on 6 August 2019 and took effect on 6 August 2020; it is now also referenced as FSM-N06 following the 2024 restructuring. Parallel notices apply to other classes of financial institution under their own numbers, which is another reason Phase 1 comes first.
The Notice mandates six baseline measures. For each one, the deliverable is evidence per system, not a policy statement:
- Administrative accounts. Secure every administrative account on any operating system, database, application, security appliance or network device, to prevent unauthorised access to or use of that account.
- Security patches. Apply security patches addressing vulnerabilities to every system within a timeframe commensurate with the risk each vulnerability poses. The Notice hands you no fixed number of days, so your own standard has to define how risk maps to urgency — and you have to meet it.
- Security standards. Establish and apply written security standards — hardening baselines — for every system.
- Network perimeter defence. Implement controls at the network perimeter to restrict unauthorised network traffic.
- Malware protection. Implement malware protection measures.
- Multi-factor authentication. Enforce MFA for administrative and privileged access, and for access through the internet to systems holding customer information.
The word doing the work in several of these is "every". A system inventory that is incomplete makes the measure unevidenceable, which is why the inventory is the first thing to fix in this phase. Our walkthrough of the cyber hygiene notice goes measure by measure.
Want a second read on your MAS TRM scope?
Share your work email and we'll map your institution class to the Notices that bind you and mark which of the eight phases your current evidence actually covers.
Phase 4: Operations and Control Discipline
Phase 4 covers operations and control discipline — the domains where the Guidelines expect financial-institution-grade practice rather than best effort. Six workstreams, each with an engineering owner rather than a compliance owner.
Access control. Authentication, authorisation, privileged access management and segregation of duties over systems holding customer or financial data. The deliverable is a current entitlement review with evidence of recertification, not an access control policy nobody has read.
Cryptography and key management. Approved algorithms, a defined key lifecycle covering generation, storage, rotation and destruction, and encryption in transit and at rest. Name the key custodians.
Change management. Risk-assessed changes, authorisation gates proportionate to impact, rollback plans, and emergency change handling that gets retrospective approval rather than none.
System development lifecycle. Design review, coding standards, source control, and security testing inside the pipeline rather than bolted on before release. What matters at review time is a sample of real changes traced end to end.
IT service management. Capacity, performance, availability and problem management for customer-facing services.
Resilience and availability. Recovery objectives per service, tested recovery rather than documented recovery, and a record of the last test with its result. An untested recovery plan is a document, not a capability.
Phase 5: Cyber Security Operations
Phase 5 builds cyber security operations: the detection and testing capability that tells you whether the controls in Phase 4 are holding. Three outputs, owned by whoever runs security operations.
Threat intelligence. A documented process for acquiring intelligence relevant to financial services in Singapore and converting it into detection rules, patch priorities or control changes. The test is whether a specific piece of intelligence in the last quarter changed something.
Security testing. Vulnerability assessment and penetration testing on a defined cadence, with scope tied to the systems that matter and remediation tracked to closure. Record the cadence and the justification for it; the reasoning in our note on penetration testing scope and cadence applies here with the FI estate substituted for the ISMS scope.
Monitoring. Logging coverage across in-scope systems, detection use cases mapped to the threats you actually face, and alert handling with defined response times. Coverage gaps are the common finding: logs from the platform but not the application, or not from the systems acquired last year.
Phase 6: Incident Management and the Notification Clocks
Phase 6 is incident management, and the notification clocks make it the phase most often found wanting. MAS requires a regulated institution to notify MAS of a relevant incident within 1 hour of discovery, and to submit a root cause and impact analysis report within 14 days.
A relevant incident is a system malfunction or IT security incident with a severe and widespread impact on the institution's operations, or one that materially impacts service to customers. Classification is a judgement call made under time pressure, which is why it has to be pre-decided rather than debated at 3am.
These obligations sat in MAS Notice 644, the technology risk management notice for banks issued on 21 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. Much online guidance still cites 644 as current; if your incident runbook does, it needs updating.
Produce:
- A classification rubric that lets a duty officer decide, without escalation, whether an incident is reportable.
- A notification runbook naming who drafts, who approves and who submits, with named deputies. One hour does not survive a single unanswered phone.
- An out-of-hours roster that has been tested. Run the drill at 2am on a weekend at least once, because that is when it will happen.
- A report template for the root cause and impact analysis, so the 14 days are spent on investigation rather than formatting.
The incident notification requirements deserve their own read before you write the runbook.
Free workbook
The MAS TRM Readiness Workbook
These phases worked through as an assessment you can fill in: the binding cyber hygiene baseline measure by measure with what evidences each, the one-hour notification clock as an operational test, a worked material outsourcing file, and governance and domain readiness. Enter your work email and we will send it.
Phase 7: Third-Party and Outsourcing Arrangements
Phase 7 covers third-party and outsourcing arrangements, where accountability does not transfer. The institution remains accountable for technology risk in an outsourced arrangement; outsourcing the function does not outsource the responsibility. MAS's expectations on outsourcing sit in a separate Guidelines on Outsourcing document, related to the TRM Guidelines but distinct from them, and cloud services are treated within this framework rather than under a cloud-only rulebook.
Four deliverables:
- A materiality assessment per arrangement. Material outsourcing carries higher expectations, so the classification drives everything downstream. Document the reasoning, not just the verdict.
- A contract clause set. For material arrangements, expectations include MAS's ability to exercise inspection rights over the arrangement and the service provider, which means audit and inspection rights have to be secured contractually. This is why MAS-regulated buyers press these clauses hard — see outsourcing obligations and vendor due diligence.
- A monitoring plan proportionate to materiality: what you review, how often, and what triggers an off-cycle review.
- An exit plan per material arrangement, with the practical question answered: could you actually move, and how long would it take?
Cloud concentration deserves separate attention. If three material arrangements run on the same provider in the same region, the exit plans have to acknowledge that; cloud computing under MAS TRM covers the shared-responsibility boundary.
Phase 8: Keep the Artefacts Current
Phase 8 keeps the artefacts current, because the artefacts that go stale between supervisory touchpoints are predictable. MAS supervisory review preparation is far easier when nothing has decayed since the last cycle, and the decay is always in the same places.
The reliably stale ones: the system inventory after a quarter of new deployments; entitlement reviews past their recertification date; the recovery test record where the last test predates the current architecture; vendor assessments where the vendor has since changed sub-processors; the board reporting pack when a committee cycle has been skipped; and the incident runbook's contact list after an org change.
Build a review calendar with an owner per artefact and a frequency tied to how fast that artefact decays, not to a uniform annual default. Attach an attestation log so each review leaves a trace. Then run a MAS TRM gap analysis against the eight phases at least annually and before any expected supervisory engagement, treating the output as a work queue rather than a report. Teams running ISO 27001 alongside this will find the gap assessment approach transfers, and the comparison with ISO 27001 shows where evidence can be reused.
MAS TRM Gap Analysis Questions Teams Ask
These are the MAS TRM gap analysis questions teams ask most often when they start sequencing a readiness programme.
No, not in the sense that a Notice is. The Technology Risk Management Guidelines are guidelines: not law in themselves and carrying no direct penalty for non-adherence. But MAS expects adherence, and the degree of observance is taken into account in MAS's supervisory risk assessment of the institution, so in practice they are the expected standard. The Notice on Cyber Hygiene is different — legally binding on the institutions it applies to, which is why its six measures sit early in this checklist.
Phase 1, always, and it is the cheapest of the eight. Establishing your institution class, the Notices that legally bind you and the standing of the Guidelines takes a few hours and scopes everything after it. Then Phase 3, the cyber hygiene baseline, because those measures are binding obligations rather than expectations. Phase 2 governance work can run in parallel if you have two owners available.
At least annually for the estate as a whole, plus on a trigger basis: a new material system, a significant architecture change, a new material outsourcing arrangement, or an incident that revealed a risk the register did not hold. Keep the assessment register live and let the annual exercise be a review of it rather than the only time anyone looks.
No. The measure requires security patches addressing vulnerabilities to be applied to every system within a timeframe commensurate with the risk posed by each vulnerability. There is no fixed day count, which puts the burden on your own written standard: define how vulnerability risk maps to remediation urgency, then show you met your own definition. Vendor blogs quoting a specific number of days are describing a convention, not the Notice.
Stale artefacts and missing scope, far more often than weak controls. The common pattern is a well-written framework document paired with an incomplete system inventory, so the binding cyber hygiene measures cannot be evidenced for every system. The second is an incident runbook citing cancelled notice numbers, with an out-of-hours contact list never tested against the one-hour clock.
Run the eight phases as tracked work, not a spreadsheet
Book a demo and we'll show how Konfirmity holds the MAS TRM phases, the cyber hygiene evidence per system, and the review calendar that keeps all of it current between supervisory touchpoints.
Book a demo
Work the Phases in Order
Work the phases in order, because the sequence is where the value sits. A checklist that lists controls alphabetically produces a programme that writes policies for expectations while a binding Notice goes unevidenced, and that is the gap most visible from the outside.
So: fix applicability in writing, put the board in the governance loop properly, evidence the six cyber hygiene measures system by system, then work outward through operations, security operations, incidents and third parties. Each phase hands the next one something it needs. Phase 8 exists because the hard part is not reaching readiness once but staying there through four quarters of change.
If you do one thing this week, do Phase 1 — then read the TRM Guidelines explained with your own applicability register in hand, and the domains will read as a work plan rather than a wall of text.
