MAS TRM
Technology Risk Management for Singapore financial institutions
The Monetary Authority of Singapore Technology Risk Management Guidelines set the technology and cyber risk expectations for MAS-regulated financial institutions, with the Notice on Cyber Hygiene providing the legally binding baseline. This page covers the four pillars, the cyber security control areas, the testing and adversarial exercise cadence, and the evidence pack a workspace-driven programme keeps in one place.
No credit card required. Free plan available forever.
MAS TRM in context: Technology Risk Management Guidelines for Singapore financial institutions
The Monetary Authority of Singapore Technology Risk Management Guidelines (the MAS TRM Guidelines) set the technology and cyber risk expectations for financial institutions regulated by MAS. The Guidelines were last comprehensively revised in 2021 and operate alongside the MAS Notice on Cyber Hygiene, which makes a focused subset of cyber controls (administrative accounts, security patching, secure standards, malware protection, multi-factor authentication, network perimeter defence) legally binding for the regulated population. The Guidelines themselves are principles-based: they describe the expected outcomes for technology risk management, system resilience, cyber security, and recovery, and the institution evidences how its programme meets those outcomes.
TRM sits inside a wider international picture for financial-sector technology and cyber resilience. For European entities, the Digital Operational Resilience Act sets the comparable obligations, including threat-led penetration testing on critical functions through the TIBER-EU framework. For UK entities, the CBEST scheme applies the same intelligence-led approach under the Bank of England and the Financial Conduct Authority. For Hong Kong entities, the HKMA Cyber Resilience Assessment Framework operates an inherent risk, maturity, and iCAST sequence. For Australian entities, the APRA CPS 234 prudential standard carries the equivalent prudential obligation. For US-supervised institutions, the FFIEC IT Examination Handbook and Cybersecurity Assessment Tool set the federal banking regulator expectations applied by the OCC, the Federal Reserve, the FDIC, the NCUA, and the CFPB. The TRM Guidelines set the equivalent Singapore expectation, with the Notice on Cyber Hygiene providing the legally binding baseline that sits underneath.
In-scope entities: who the TRM Guidelines apply to
The TRM Guidelines apply to all financial institutions regulated by MAS, with the depth of application calibrated by the criticality and sensitivity of the technology assets each institution operates. The Notice on Cyber Hygiene sits underneath as a legally binding instrument that names the foundational controls every regulated institution must operate. The summary below is the working categorisation; the MAS-published Guidelines and Notices remain the authoritative reference for any scope question.
Banks and merchant banks under MAS supervision
Full banks, wholesale banks, merchant banks, and the Singapore branches of foreign-incorporated banks supervised by the Monetary Authority of Singapore. The MAS Technology Risk Management Guidelines apply to the Singapore-licensed entity, including the technology infrastructure that supports customer-facing services, payment clearing, and cross-border financial messaging operated from or routed through Singapore.
Insurers, capital markets services licensees, and financial advisers
Direct insurers, reinsurers, captive insurers, and registered insurance brokers; capital markets services (CMS) licence holders covering fund management, dealing in capital markets products, and custodial services; financial advisers and licensed financial institutions providing investment advisory services. The TRM Guidelines apply across the licensed population, scaled by the criticality and sensitivity of the technology assets the institution operates.
Payment service providers and Major Payment Institutions
Major Payment Institutions and Standard Payment Institutions licensed under the Payment Services Act, including digital payment token service providers within MAS supervisory remit. Payment service providers carry the same obligation to manage technology and cyber risk against the criticality of the customer-facing payment infrastructure, the cross-border flows, and the third-party dependencies the service relies on.
Group functions and outsourced service providers
Group functions, regional service centres, and third-party service providers that operate or process information assets on behalf of a MAS-regulated financial institution sit inside the third-party risk obligations of the TRM Guidelines and the related MAS Outsourcing Guidelines. The licensed institution remains accountable for the technology and cyber risk of services delivered through group entities and third parties, with the assessment evidence retained at the regulated entity level.
The four pillars of the TRM Guidelines
The Guidelines are organised across governance, the risk management framework, system reliability and recoverability, and cyber security controls. The pillars operate together: governance sets the authority and resourcing, the framework sets the operating model, the resilience pillar sets the recoverability target, and the cyber security pillar sets the controls that protect against the threat picture. Treating any one pillar in isolation is the most common structural mistake; MAS examines the institution programme across all four.
Pillar 1: Technology risk governance and oversight
Board and senior management accountability for technology and cyber risk. The framework expects an explicit risk appetite, a named accountable executive (typically the Chief Information Security Officer or equivalent role), board reporting cadence, technology risk committee structure, and independent assurance through internal audit. MAS examines whether the institution operates the programme as a board-level obligation rather than as a delegated technology operations matter.
Pillar 2: Technology risk management framework
A documented framework covering identification, assessment, treatment, monitoring, and reporting of technology risks. The framework defines policies, standards, and procedures across system development, change management, project management, vendor management, and the IT operating environment. Risks are tied back to the criticality of the affected systems and information assets, with a working risk register that is reviewed on cadence and on material change.
Pillar 3: System reliability, availability, and recoverability
Technology resilience requirements covering system reliability, capacity planning, availability targets, recovery time objectives, recovery point objectives, the maximum tolerable downtime for critical systems, and the disaster recovery and business continuity programme. Critical systems carry tighter targets and require stronger evidence of recoverability through scheduled disaster recovery exercises and post-exercise lessons-learned closure.
Pillar 4: Cyber security and resilience controls
Cyber security and resilience controls across access management, secure system development, network and infrastructure security, data protection, vulnerability management, threat intelligence, security monitoring, and incident response. The framework expects defence-in-depth controls aligned to the threat picture against Singapore financial services, with structured penetration testing and adversarial simulation evidencing the controls operate as designed.
Cyber security control areas in detail
Pillar four expands across six control areas the institution evidences as designed, operating, and producing the data the monitoring and audit functions read on a continuous basis. The control areas below are the working catalogue; specific controls and the depth of evidence are calibrated to the criticality of the systems and the sensitivity of the information assets they protect.
Access management and identity controls
Identity lifecycle management, role-based access, privileged access management, multi-factor authentication for sensitive systems and remote access, and periodic access recertification. Privileged accounts carry stronger evidence requirements: vault enrolment, session recording, just-in-time elevation, and removal of dormant privileged access on a documented cadence. The control evidence reads back to the asset register and the criticality classification of the system the access protects.
Secure software development and change controls
Secure software development lifecycle covering threat modelling, secure coding standards, static and dynamic application security testing, software composition analysis, peer review, and pre-production security testing. Change management evidences segregation of duties between development and production, testing in pre-production environments, and rollback plans for critical change. The institution evidences that security testing produces actionable findings and that fixes are applied before production release rather than after a finding becomes an incident.
Vulnerability management and penetration testing
Recurring vulnerability assessments, penetration testing on critical systems, and a managed remediation backlog. Penetration testing on internet-facing systems and critical internal systems is expected on a defined cadence and on material change (new system, significant architectural change, new third-party integration). The institution retains the test scope, the test report, the findings with severity and remediation plan, and the retest evidence in the form MAS can examine without reconstruction.
Network, endpoint, and infrastructure security
Network segmentation, perimeter and internal traffic filtering, endpoint protection, secure configuration baselines, and patching cadence aligned to risk. Cloud-hosted infrastructure inherits these expectations through the cloud security architecture and through the third-party assessment of the cloud service provider; the institution remains accountable for the configuration of the cloud tenancy and the controls layered on top of provider services.
Threat intelligence, monitoring, and detection
Threat intelligence consumption tied to the institution profile, security monitoring across critical systems, log aggregation with tamper-evident retention, alerting and triage workflows, and integration with the incident response programme. The detection capability is examined for coverage (which assets are monitored), for fidelity (the alert-to-incident ratio), and for timeliness (the time from event to triage to escalation).
Data protection, encryption, and confidentiality
Data classification, data loss prevention, encryption in transit and at rest, key management, and the controls that prevent unauthorised disclosure of customer information. The TRM Guidelines align with the Personal Data Protection Act on the personal data dimension, and with the Notice on Cyber Hygiene on the foundational control set; data protection evidence reads back to the asset classification and the regulatory obligations the data attracts.
Vulnerability scanning evidence, penetration test findings, and configuration assessment records sit at the centre of the cyber security and vulnerability management expectations. The penetration testing workflow keeps engagement, findings, and remediation tied to a single record. The scanner result triage workflow covers turning raw scanner output into assessor-ready findings without losing the audit trail. For the analytical view of how a finding ages into a remediation backlog, the aging pentest findings research covers why an open finding that lingers across cycles reads to a regulator as a programme weakness rather than as a delivery delay.
Adversarial exercises, red teaming, and structured testing
The TRM Guidelines expect structured penetration testing on internet-facing systems and critical internal systems on a defined cadence and on material change. Larger institutions and institutions with high-criticality customer-facing services typically run adversarial exercises (red team or scenario-led testing) on top of the recurring pentest programme. Adversarial exercises are not the same as routine penetration testing: they evidence the detection and response capability against realistic threat actor behaviour rather than only enumerating exploitable vulnerabilities. Preparation, execution, and closure are the three phases the engagement record needs to cover.
Preparation phase
- Define the scope around the institution critical systems, the customer-facing services, the cross-border interfaces, and the third-party dependencies that materially affect the threat picture
- Engage with the MAS contact for any institution-specific guidance, especially for material exercises affecting critical systems or production environments, and confirm any notification expectations before live execution
- Form the white team with explicit board mandate, authority to commission and pause the exercise, a documented contact tree, and clear segregation from the in-scope detection and response teams
- Procure penetration testing or red teaming providers with credential evidence, conflict-of-interest checks, and Singapore data residency commitments where the engagement processes regulated information
- Agree the legal pack: rules of engagement, authorisation letter, data handling commitments, indemnity, escalation paths, and the post-engagement attestation template
- Hold the launch meeting with the white team, the providers, and any MAS or internal audit observers, and lock the scope specification before testing begins
Execution and closure
- Threat-informed test plan tied to threat actors realistically targeting Singapore financial services, the in-scope critical systems, and the agreed engagement scope
- Live execution against the production or production-like environment with controlled access, prearranged escalation paths, and a live communication channel back to the white team
- Operator notes, screenshots, attack timestamps, evidence per finding, and the running engagement log captured during execution so the post-engagement record is the working record rather than a rebuilt one
- Triage of high-severity issues during the engagement window so the institution can intervene where the exercise reaches a critical control or threatens production stability
- Replay session pairing the red team and the blue team, walking the attack path together, identifying detection and response gaps, and agreeing remediation actions in writing
- Closure attestation signed by the institution, the testing provider, and any independent observer, retained alongside the test report and the remediation plan as the post-engagement record
For the workflow that runs adversarial exercises from scope to attestation on a single engagement record, the threat-led penetration testing workflow covers the cycle end to end, and the red teaming workflow keeps timestamps, attack paths, and operator notes structured so the closure record is the working record rather than a rebuilt one.
TRM and adjacent frameworks: PCI DSS, SWIFT CSP, ISO 27001, Cyber Hygiene Notice
Most MAS-regulated institutions run more than one framework at the same time. The institution may operate the SWIFT Customer Security Programme on the messaging infrastructure, the PCI DSS standard on the payment card environments, the ISO 27001 information security management system at the entity level, and the NIST Cybersecurity Framework as a control catalogue reference. The Notice on Cyber Hygiene sits underneath the Guidelines as the legally binding baseline, with the institution required to evidence the named controls (administrative accounts, security patching, secure standards, malware protection, multi-factor authentication, network perimeter defence) on a continuous basis. TRM evidence reads against the controls these frameworks already operationalise; the same evidence pack often satisfies more than one regime when the mapping is built into the workspace from the start rather than rebuilt at audit time.
For the wider operational context that a Singapore-licensed institution may run alongside TRM, the banking and fintech security consultancies workspace covers how a service provider delivering TRM, SWIFT CSP, ISO 27001, and PCI DSS work across multiple regulated clients keeps the evidence record consistent without writing the same finding three times.
Evidence the supervisor (and your board) expect
TRM programmes that fail review usually fail because the artefacts are scattered across drives, secure email threads, and screenshots. Build the evidence pack as the work happens, retain raw evidence alongside the structured record, and tie every artefact back to the pillar, the control area, and the owner who produced it. The MAS examination reads the way the underlying record reads.
- Information asset register with classification, criticality, sensitivity, owner, and the controls applied per asset class, refreshed on a documented cadence and on material change
- Technology risk register with each risk tied to the affected systems, assessed exposure, treatment plan, control owner, and the next reassessment trigger
- Third-party register with the assessment of vendors, intra-group entities, regional service centres, and outsourced service providers that operate or process information assets
- Capacity, availability, and disaster recovery records covering recovery time objectives, recovery point objectives, scheduled disaster recovery exercises, and the post-exercise lessons-learned closure
- Vulnerability scanning evidence across the asset register, with findings tied to the relevant assets, severity, remediation owners, and SLA progress per finding
- Penetration test reports with scope, methodology, findings, severity, remediation plans, and retest evidence per finding, attached to the asset register entries the testing covered
- Adversarial simulation or red team exercise pack covering scope, threat-informed test plan, engagement log, replay notes, gap analysis, remediation plan, and closure attestation
- Incident register with detection time, response actions, materiality determination, MAS notification record where the incident reaches the reporting threshold, post-incident review, and lessons learned applied
- Tabletop exercise records demonstrating the incident response plan has been reviewed and tested, with the gaps the exercise surfaced and the closure of those gaps tracked over time
- Internal audit reports covering design and operating effectiveness of technology and cyber risk controls, including third-party-managed assets, with the reliance basis on third-party assurance documented per audit
- Board reporting record showing the cadence and content of technology and cyber risk updates to the board, with the escalation path operating before an incident rather than assembled during one
Where SecPortal fits in a TRM-aligned programme
SecPortal is the operating layer for the TRM programme, not a replacement for MAS, the pentest provider, or the threat intelligence partner. The platform handles scope, role records, findings, replay notes, attestation artefacts, and the closure pack so the work runs as a structured workflow rather than a long encrypted email thread. Compliance tracking maps the TRM evidence pack to ISO 27001, SWIFT CSP, and NIST CSF for institutions that have to satisfy more than one regime from the same body of work.
- Engagement management dedicated to a TRM-aligned testing programme, with the in-scope asset class, the testing cadence, and the assessor or pentester record tracked on a single workspace
- Findings management with CVSS 3.1 scoring, MITRE ATT&CK tagging, and 300+ templates so each pentest, vulnerability, or assessor finding ties to the affected system, the asset register, and the remediation owner
- Compliance tracking that maps TRM control areas to the operationalised controls, alongside related frameworks (PCI DSS, SWIFT CSP, ISO 27001) the institution may already operate against
- AI report generation that turns assessment notes, vulnerability output, penetration test findings, and remediation actions into the audit-ready report and the board-ready narrative without manual rewriting
- External and authenticated scanning to feed the vulnerability management programme with continuous evidence rather than a single audit-time snapshot
- Continuous monitoring with scheduled scans so the asset register carries a coverage record across the year that internal audit and MAS can examine on request
- Findings audit trail with reasons and re-evaluation dates so suppressions, deviations, and risk acceptances are defensible at internal audit, at board review, and at MAS examination
TRM operates as a continuous programme rather than a single attestation. The asset register, the third-party register, the testing cadence, and the audit trail carry value across cycles when each iteration inherits the prior evidence pack rather than rebuilding from scratch. For consultants delivering TRM-aligned work to multiple Singapore-licensed clients, the banking and fintech security consultancies workspace bundles the platform with branded client portals and AI report generation so the deliverable looks as polished as the work behind it.
For programmes that want continuous detection and trend evidence between formal review cycles, the continuous monitoring capability and attack surface management capability produce the cadence and coverage record that the protection and detection control areas read most easily.
Scope and limitations
The MAS TRM Guidelines are operated by MAS and applied by the regulated financial institution. SecPortal is the workspace that holds the engagement, the testing programme, the findings, the remediation record, and the audit trail. Submissions to MAS, incident notifications, and any examination response remain actions the institution takes through MAS-prescribed channels; SecPortal holds the supporting record so the submission is grounded in the evidence pack rather than reconstructed from email and shared drives at the deadline moment.
The TRM Guidelines are principles-based, with the Notice on Cyber Hygiene providing the legally binding minimum baseline. This page describes the structure of TRM and how a workspace-driven programme plays against it; the authoritative reference for the obligations remains the MAS-published Guidelines, the Notices, and any institution-specific guidance the supervisor issues. The control catalogue an institution selects to meet TRM outcomes is the institution decision, evidenced through the asset register, the testing programme, and the resilience exercises across the year.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Governance and oversight
Board accountability for technology and cyber risk, with a named accountable executive, an explicit risk appetite, board reporting cadence, technology risk committee structure, and independent assurance through internal audit. MAS examines whether the institution operates the programme as a board-level obligation rather than as a delegated technology operations matter.
Technology risk management framework
Documented framework covering identification, assessment, treatment, monitoring, and reporting of technology risks. Policies, standards, and procedures across system development, change management, project management, vendor management, and the IT operating environment, with a working risk register reviewed on cadence and on material change.
System reliability and recoverability
Capacity planning, availability targets, recovery time objectives, recovery point objectives, the maximum tolerable downtime for critical systems, and the disaster recovery and business continuity programme. Critical systems carry tighter targets and require stronger evidence of recoverability through scheduled exercises and post-exercise lessons-learned closure.
Cyber security controls and access management
Identity lifecycle management, role-based access, privileged access management, multi-factor authentication for sensitive systems and remote access, periodic access recertification, and the controls that protect against the threat picture targeting Singapore financial services. The Notice on Cyber Hygiene names a foundational subset of these controls as legally binding baseline.
Vulnerability management and penetration testing
Recurring vulnerability assessments, penetration testing on internet-facing and critical internal systems, and a managed remediation backlog. Testing runs on a defined cadence and on material change (new system, significant architectural change, new third-party integration), with scope, methodology, findings, and retest evidence retained per cycle.
Threat intelligence, monitoring, and incident response
Threat intelligence consumption tied to the institution profile, security monitoring across critical systems, log aggregation with tamper-evident retention, alerting and triage workflows, the incident response programme, and the materiality determination that triggers MAS notification and post-incident review.
Third-party risk management
Assessment of vendors, intra-group entities, regional service centres, and outsourced service providers that operate or process information assets. The institution remains accountable for the technology and cyber risk of services delivered through third parties, with the assessment evidence retained at the regulated entity level alongside the MAS Outsourcing Guidelines obligations.
Adversarial exercises and structured testing
Larger institutions and institutions with high-criticality customer-facing services typically run adversarial exercises (red team or scenario-led testing) on top of the recurring pentest programme. The exercise pack covers scope, threat-informed test plan, engagement log, replay notes, gap analysis, remediation plan, and closure attestation.
Evidence pack and audit trail
Asset register, third-party register, technology risk register, vulnerability scan output, penetration test reports, adversarial exercise pack, incident register, tabletop exercise records, internal audit reports, and the board reporting record. The pack is the artefact that defends the programme posture to internal audit, the board, and to MAS examination.
Run a TRM-aligned programme on one defensible record
Hold the asset register, the testing programme, the adversarial exercise pack, and the MAS evidence record in one workspace. Start free.
No credit card required. Free plan available forever.