The MAS Technology Risk Management Guidelines, published 18 January 2021, set out how Singapore financial institutions should govern technology risk, build and run software, control access, and handle incidents. They are guidelines that MAS considers when supervising, and their extent should match the firm's risk and complexity.
Who do they apply to, and how binding are they?
The MAS page lists capital markets firms, insurers, banks, payment institutions and others, including financial advisers. Section 2 of the document says the aim is sound practice, that the extent of implementation should be commensurate with the risk and complexity of the services offered, and that MAS considers the degree of observance with the spirit of the Guidelines when supervising.
It also says they are general guidance, not comprehensive, and do not replace legislation, notices or directions. The MAS page does not state whether they are binding. Read them alongside any notices that apply to your licence, and ask your own counsel which ones do.
What does the document cover?
It runs to 57 pages. The main chapters, per its table of contents, are governance and oversight, a technology risk management framework, project management and security by design, software application development, IT operations, resilience and recoverability, access control, cryptography, data and infrastructure security, cyber security operations, cyber security assessment, online financial services, and audit.
What does it say about governance?
Section 3.1 says the board and senior management must ensure effective controls for the security, reliability and resilience of the IT environment, and that they should include members with the knowledge to understand technology and cyber risks. It expects a CIO or head of IT and a CISO or head of information security with the right expertise, with appointments approved at least by the CEO, and a technology risk management strategy that is established and carried out.
What does it say about third parties?
Section 3.4 says an institution should assess its exposure to technology risk at a third party before signing a contract or partnership, and on an ongoing basis should ensure the third party uses a high standard of care in protecting data confidentiality and integrity and in keeping systems resilient. The document notes some third party services may not count as outsourcing but can still affect the institution if they fail.
What does it say about building software?
This is the part engineering teams should read closely. Section 6.1 asks for:
- Standards on secure coding, source code review and application security testing (6.1.1).
- Coverage of secure programming practices, input validation, output encoding, access controls, authentication, cryptographic practices and error handling (6.1.2).
- A policy and procedure so that third party and open-source code is reviewed and tested before it goes into your software (6.1.3).
- Tracking of updates and reported vulnerabilities for third party and open-source code you have incorporated (6.1.4).
- A strategy for application security validation, which may mix static, dynamic and interactive testing (6.1.6).
- Tracking of all issues found, with major ones fixed before production deployment (6.1.7).
Agile teams are told to keep secure coding and testing standards in force (6.2), and there is a DevSecOps section (6.3).
And operations and incidents?
Patch management (7.4) should fit patches into a timeframe that matches their criticality, and test them before production. Change management (7.5) calls for assessment, testing, review and approval before changes go live. Incident management (7.7) asks for a framework covering handling procedures including cyber incidents, protection of evidence, and clear roles, plus alerts that are actively monitored and regular updates to senior management during major incidents.
What to do
- Confirm with counsel which MAS notices and guidelines apply to your licence.
- Map your engineering standards to section 6.1, and write down the gaps.
- Keep a current inventory of third party and open-source components, and a way to hear about new vulnerabilities in them.
- Define the review step open-source code goes through before it is merged.
- Set patch timeframes by criticality, and record exceptions.
- Make sure major findings block production deployment, and that you can show the log.
- Check that incident plans protect evidence and name owners.
- Review third party risk before contracts and again at set intervals.
Safeguard's SBOM and dependency scanning and its policies and gates can help produce the component inventory, vulnerability tracking and release checks that 6.1.3 to 6.1.7 describe. It does not make a firm compliant on its own.
Quick check
Do the TRM Guidelines require a specific scanner or tool?
No. Section 6.1.6 says a firm may use a mixture of static, dynamic and interactive testing and should review its rules periodically.
Do they cover open-source components?
Yes. Sections 6.1.3 and 6.1.4 ask for review and testing before integration and for tracking of reported vulnerabilities in what you have included.
Sources
- MAS: Technology Risk Management Guidelines page (fetched 18 October 2026)
- MAS: Technology Risk Management Guidelines, January 2021 (PDF) (fetched 18 October 2026)
Last reviewed: 18 October 2026.
