MAS Technology Risk Management Guide: TRM Guidelines and Cyber Hygiene

Singapore's financial regulator combines broad technology risk guidelines with short, legally binding notices, and the binding parts (a 1-hour incident notification, a 4-hour recovery objective and six cyber hygiene controls) are where supervisory findings land. The Monetary Authority of Singapore (MAS) issued its Technology Risk Management (TRM) Guidelines in January 2021, and in May 2024 replaced the old sector notices, including Notice 644 and Notice 655, with new notices under the Financial Services and Markets Act 2022. Business continuity and outsourcing rules were also rewritten in 2022 and 2024. This guide explains which instrument applies to which institution, what each requires, how access control and privileged access are treated, and how to build evidence that stands up to MAS inspection. It is for CISOs, technology risk and compliance teams, and engineers at MAS-regulated financial institutions and their service providers.

Key takeaways

• Notices bind, guidelines guide. The Technology Risk Management Notices and Cyber Hygiene Notices are legal requirements; the TRM Guidelines set out the practices MAS expects and assesses against.
• Notice numbers changed on 10 May 2024. For banks, Notice 644 became FSM-N05 and Notice 655 became FSM-N06; every sector has its own pair.
• The clocks are short. Notify MAS within 1 hour of discovering a relevant incident, submit a root cause and impact analysis within 14 days, keep critical system unscheduled downtime to 4 hours in any 12 months and recover within 4 hours.
• Privileged access is a hygiene requirement. Administrative accounts must be secured, and MFA is mandatory for administrative accounts on critical systems and for internet access to customer information.
• Resilience is service-centric. The 2022 BCM Guidelines set service recovery time objectives for critical business services and audits at least every three years.

The MAS technology risk instruments

The TRM Guidelines apply across banks, insurers, capital markets intermediaries, payment institutions, trust companies, financial advisers and insurance brokers. For how Singapore compares with other jurisdictions, see the Global Cybersecurity Regulatory Map.

Notice numbers by sector

MAS's cyber security page lists the replacement notices that took effect on 10 May 2024. Use the new number in policies and attestations; the old number survives mainly in search queries and legacy documents.

Money brokers, credit bureaus, insurance brokers and designated financial holding companies have their own numbers on the same page.

The Technology Risk Management Notice: availability, recovery and incident reporting

The TRM Notices are short. The requirements below are taken from FSM-N03 (insurers), issued on 9 May 2024; the bank notice FSM-N05 follows the same structure.

An IT security incident includes hacking, intrusion or denial of service affecting a critical system, or any system where the security, integrity or confidentiality of customer information is compromised. The December 2025 incident reporting circular says notification should be made "as soon as possible, but no later than the timeline prescribed", followed by the FI Incident Reporting Template on the MAS-Tx platform, with an updated template mandatory from 1 February 2026.

MAS consulted from 10 June to 31 July 2026 on amendments to the TRM Notices. According to a law firm summary, the proposals include IT asset inventories covering cryptographic and open-source components, immutable or offline backups, continuous monitoring of critical systems, and counting "partial or intermittent disruption" toward the 4-hour limit, with a 12-month implementation period after final notices are issued. Track the final text before changing controls.

The Cyber Hygiene Notice: six mandatory controls

FSM-N06 (banks), like the earlier Notice 655, sets six baseline requirements. An entity need not comply only where it cannot control a system directly, through its provider, or by procuring an alternative provider.

A "system" is "any hardware or software that is used by the relevant entity", which brings cloud consoles, SaaS administration and network devices into scope. See the Patch Management Guide for paragraph 4.2.

TRM Guidelines: board oversight and the risk framework

The Guidelines run to 15 chapters plus annexes on application security testing, BYOD and mobile application security. Chapter 3 sets governance expectations.

• Board composition (3.1.2): the board and senior management should include members able to understand and manage technology risks, including cyber threats; the board should receive technology risk training (3.6.3).
• Key roles (3.1.3): a CIO or head of IT and a CISO or head of information security with the right expertise, appointed with at least CEO approval.
• Board duties (3.1.7): oversee the technology risk framework, approve risk appetite and tolerance, review strategy, assess management competence and ensure an independent audit function.
• Senior management duties (3.1.8): establish the framework, maintain policies and standards, define roles and promptly inform the board of significant adverse developments.
• Third-party services (3.4): assess confidentiality, integrity and availability risks before contracting, including for services that are not outsourcing, and monitor providers afterwards.

For reporting technology risk to directors, see the Board Cyber Risk Reporting Guide.

Where identity fits: access control and privileged access (Chapter 9)

Chapter 9 is the identity core of the Guidelines and is where TRM Guidelines access control expectations meet the Cyber Hygiene Notice.

Section 9.2.2 matters for non-human identities: service accounts, API keys and automation credentials often hold the widest privileges and are rarely reviewed. See the Privileged Access Management Guide and the Service Account Security Guide. Chapter 10 adds key management: hardware security modules for sensitive keys (10.2.4), one purpose per key (10.2.6) and revocation of compromised keys and those depending on them (10.2.7).

Cyber resilience: operations, testing and recovery

• IT resilience (Chapter 8): design availability to business need, remove single points of failure, set RTO and RPO, review the disaster recovery plan at least annually and test plausible scenarios, including loss of the primary site, with service providers' DR verified (8.3.4).
• Cyber security operations (Chapter 12): a security operations centre or managed security service (12.2.1), protected logs and behavioural baselines, user behaviour analytics, and an incident response plan with root cause analysis.
• Vulnerability assessment (13.1): frequency set by criticality and exposure, covering configurations, open ports and application weaknesses.
• Penetration testing (13.2): blackbox and greybox testing for online services, testing in production with safeguards, at least annually for internet-accessible systems or after major changes; bug bounties as a complement.
• Adversarial attack simulation (13.4): red team exercises against prevalent threats, with objectives, scope and rules of engagement agreed in advance. See the Red Teaming Guide.

Business continuity and outsourcing

The revised BCM Guidelines, issued on 6 June 2022, ask institutions to "adopt a service-centric approach" and "identify end-to-end dependencies". A law firm summary of the Guidelines describes a 12-month implementation period, a service recovery time objective (SRTO) for each critical business service, annual review of critical services and recovery objectives, audit of the BCM framework and each critical business service at least once every three years, and an annual attestation from senior management to the board. Concentration risk, such as several critical services depending on one provider or one site, should be identified and mitigated. See the Business Continuity and Disaster Recovery Guide.

For outsourcing, banks follow Notice 658 on Management of Outsourced Relevant Services and the Guidelines on Outsourcing (Banks); merchant banks follow Notice 1121; other institutions follow the Guidelines on Outsourcing (Financial Institutions other than Banks). All took effect on 11 December 2024, replacing the 2016 guidelines (revised 2018), and banks submit outsourcing registers using MAS's template. The BeyondTrust breach, where a stolen API key at a remote support provider led to an incident at the US Treasury, shows why section 9.1.8 puts provider access under the same controls as staff. See the Third-Party Risk Management Guide.

How to implement: a phased approach

1. Scope: confirm your licence type and the matching TRM and Cyber Hygiene Notice numbers; update policies that still cite Notice 644 or 655.
2. Critical systems: agree the critical system list with business owners, link each to its critical business service and SRTO, and start a rolling 12-month downtime log.
3. Hygiene gap close (first 90 days): inventory administrative accounts, vault them, enforce MFA on critical systems and internet-facing customer access, and document patch SLAs and hardening baselines with exceptions.
4. Incident drill: rehearse a scenario from detection to MAS notification within 1 hour and a 14-day root cause report, using the current MAS-Tx template.
5. Recovery testing: prove a 4-hour RTO for each critical system at least once every 12 months, including dependencies on service providers.
6. Assurance: run access reviews, penetration tests and an adversarial simulation, then report gaps to the board with remediation dates.

Introduce changes such as MFA enforcement in pilot groups first and keep documented break-glass access for critical systems so an authentication failure does not itself breach the 4-hour limit. See the Break-Glass Account Guide.

Decision guidance

• Notify or not: when in doubt within the hour, notify. A relevant incident turns on severe and widespread impact or material effect on customer service, and early notification can be updated.
• Which accounts need MFA: the Notice sets the floor (critical system admins, internet access to customer information); the Guidelines extend it to sensitive functions and remote access. Many institutions extend MFA to all privileged and remote access.
• Smaller licensees: fund managers and advisers relying on cloud and SaaS providers can use the control exception only where they cannot control a system by any of the three routes, so provider-hosted admin consoles that support MFA are usually still in scope.
• Outsourcing or not: classify the arrangement under the outsourcing instruments; if it is not outsourcing, section 3.4 of the Guidelines still applies.

Detection and measurement

Log administrative and privileged sessions, service account activity, authentication failures and MFA bypass attempts, changes to perimeter rules, and access to customer information stores, and correlate them in the SOC (12.2.5).

• Critical system downtime: rolling 12-month unscheduled downtime per system against the 4-hour limit.
• Notification timeliness: minutes from discovery to MAS notification, and percentage of root cause reports filed within 14 days.
• MFA coverage: percentage of administrative accounts on critical systems and internet-facing customer access paths with MFA enforced.
• Patch latency: median and 95th percentile time to patch by severity, and open exceptions.
• Access review completion: percentage of privileged and service accounts reviewed on schedule, and dormant accounts removed.
• RTO evidence: percentage of critical systems with a successful recovery test inside 4 hours in the last 12 months.

Framework mapping

Common failure patterns

• Policies citing cancelled notices: attestations and control libraries still reference Notice 644 or 655 two years after replacement.
• Counting only full outages: partial or intermittent failures go unlogged against the 4-hour limit, which MAS has now proposed to make explicit.
• Losing the first hour: the incident team investigates before notifying, and the 1-hour clock passes.
• Admin accounts outside the vault: network devices, database administrators and cloud root accounts keep standing credentials without MFA. The CitrixBleed exploitation, which reached ICBC, showed that session tokens stolen from an edge device bypass MFA, so session monitoring is also needed.
• Unreviewed service accounts: section 9.2.2 monitoring is never built, and credentials left unrotated after an incident are reused, as in the Cloudflare Thanksgiving breach.

Practitioner checklist

• Map your licence to the correct TRM and Cyber Hygiene Notice numbers and update every reference.
• Maintain an approved critical system list linked to critical business services and SRTOs.
• Track unscheduled downtime per critical system on a rolling 12-month basis, including partial disruption.
• Prove a 4-hour RTO for each critical system at least once every 12 months.
• Rehearse 1-hour MAS notification and 14-day root cause reporting with the current MAS-Tx template.
• Vault every administrative account and enforce MFA on critical systems and internet access to customer information.
• Monitor system and service accounts and review privileged access regularly with asset owners.
• Apply staff-equivalent access controls to service providers and classify each arrangement under the outsourcing instruments.
• Run annual penetration tests on internet-accessible systems and periodic adversarial attack simulations.

Standards and references

• Monetary Authority of Singapore: Technology Risk Management Guidelines (January 2021)
• Monetary Authority of Singapore: Notice FSM-N03 on Technology Risk Management
• Monetary Authority of Singapore: Cyber Security regulation and notices by sector
• Monetary Authority of Singapore: Notice 644 Technology Risk Management (cancelled)
• Monetary Authority of Singapore: Circular on Financial Institution Incident Reporting
• Monetary Authority of Singapore: Third-Party Risk Management (Notice 658, Notice 1121 and Outsourcing Guidelines)
• Monetary Authority of Singapore: MAS strengthens financial institutions' business continuity to address evolving threats
• Monetary Authority of Singapore: Technology Risk Management Guidelines page

Related NHI Mgmt Group resources: Financial Services Identity Security Guide · Global Cybersecurity Regulatory Map · DORA Guide · Privileged Access Management Guide · Third-Party Risk Management Guide. This guide summarises the MAS Technology Risk Management Guidelines, the Technology Risk Management and Cyber Hygiene Notices, the Business Continuity Management Guidelines and the outsourcing instruments as of 18 October 2026 and is not legal advice.