Introduction: MAS TRM in Context
The Monetary Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines are the cornerstone of technology and cyber-resilience supervision for financial institutions (FIs) operating in Singapore. First issued in 2013 and comprehensively revised in January 2021, the TRM Guidelines articulate MAS's expectations for how FIs should establish sound and robust technology risk governance, maintain cyber-resilience, and safeguard the confidentiality, integrity and availability (CIA) of information assets and the systems that process them. Although styled as 'guidelines' rather than binding legislation, they are enforced in practice through MAS's supervisory framework: MAS assesses compliance during on-site inspections and thematic reviews, and material deviations attract supervisory action. Crucially, the TRM Guidelines sit alongside the legally binding MAS Notice on Cyber Hygiene (e.g. PSN06, MAS Notice 655, Notice 127, Notice 644 depending on FI class), which mandate six baseline cyber-hygiene measures with the full force of law.
This guide provides an auditor-grade deep-dive into the MAS TRM Guidelines (2021 revision) as a working framework for assessment, gap analysis and remediation. It is written for Chief Information Security Officers (CISOs), Heads of Technology Risk, internal auditors, and consultants supporting FIs through MAS technology-risk supervision, penetration-testing mandates, and cyber-resilience uplift programmes. Throughout, we map TRM expectations to concrete verification steps and evidence so that a compliance team can operationalise the Guidelines rather than merely read them.
Copyright and source note
The MAS Technology Risk Management Guidelines and the associated MAS Notices on Cyber Hygiene are published and copyrighted by the Monetary Authority of Singapore. This guide is an original, independent interpretation authored for educational and advisory purposes. It paraphrases and summarises MAS expectations in our own words and does not reproduce MAS copyrighted text. FIs must always refer to the authoritative documents published on the MAS website (mas.gov.sg) and obtain qualified legal and regulatory advice for their specific licensing class and obligations.
What is MAS TRM
MAS TRM is a set of supervisory guidelines that set out risk-management principles and best-practice standards for the sound management of technology risk by financial institutions. The 2021 revision materially expanded the previous version to address the accelerating threat landscape, the rise of cloud computing, DevSecOps, application programming interfaces (APIs), and third-party and supply-chain risk. The document is organised into thematic chapters that follow the lifecycle of technology risk: governance and oversight, the technology risk-management framework, IT project and change management, operational infrastructure and resilience, cyber security operations, and access and cryptographic controls.
The Guidelines are principles-based and outcomes-focused rather than a prescriptive control catalogue. MAS deliberately avoids being overly prescriptive so that the expectations remain durable as technology evolves; instead, it expects each FI to apply the principles proportionately to the nature, scale and complexity of its business and its risk profile. The board of directors and senior management are held directly accountable: TRM explicitly states that the board and senior management are responsible for the effective oversight of technology risk. This board-level accountability is one of the defining characteristics that distinguishes MAS TRM from purely technical standards.
Two other MAS instruments interlock with the TRM Guidelines and are frequently assessed together. The MAS Notices on Cyber Hygiene are legally binding and mandate six baseline measures: securing administrative accounts, applying security patches, deploying security standards/hardening, implementing network perimeter defence, deploying anti-malware, and enforcing multi-factor authentication (MFA) for administrative and privileged access. The MAS Notices on Technology Risk Management (e.g. Notice 644/655) mandate incident notification and system-availability requirements, including the 'not more than 4 hours of unscheduled downtime within any 12-month period' expectation for critical systems and the requirement to notify MAS of relevant incidents within one hour of discovery.
| Attribute | Detail |
|---|---|
| Full name | MAS Technology Risk Management Guidelines |
| Issuer | Monetary Authority of Singapore (MAS) |
| Current revision | January 2021 (superseding the June 2013 edition) |
| Legal status | Guidelines (supervisory expectations); enforced via inspections. Cyber Hygiene and TRM Notices are legally binding. |
| Region | Singapore |
| Applicability | All MAS-regulated financial institutions |
| Related binding instruments | MAS Notices on Cyber Hygiene; MAS Notices on Technology Risk Management (incident reporting and system availability) |
| Core objective | Sound technology risk governance, cyber-resilience, and protection of CIA of critical information assets |
Who Must Comply
The TRM Guidelines apply to all financial institutions regulated by MAS. Because MAS regulates a very broad set of licensees, the applicability is deliberately wide. The Notices on Cyber Hygiene and TRM carry the specific notice numbers relevant to each licence class, but the underlying expectations are consistent. Proportionality is the operative principle: a systemically important bank is expected to demonstrate far deeper and more mature controls than a small payment-services firm, but both are expected to have proportionate governance, controls and resilience.
| FI category | Examples | Illustrative binding notice reference |
|---|---|---|
| Banks | Full banks, wholesale banks, merchant banks, digital banks | MAS Notice 644 / 655 (Cyber Hygiene 655) |
| Insurers | Direct life/general insurers, reinsurers, captive insurers | MAS Notice 127 (Cyber Hygiene) |
| Capital markets services | Fund managers, brokers, dealers, corporate finance advisers | MAS Notice SFA04-N16 / CMG-N02 |
| Payment services | Digital payment token providers, e-money issuers, cross-border remittance | MAS Notice PSN06 (Cyber Hygiene) |
| Financial market infrastructures | Approved exchanges, clearing houses, trade repositories | Applicable MAS Notice per FMI class |
| Financial advisers & trust companies | Licensed financial advisers, licensed trust companies | Applicable MAS Notice per class |
| Money-changing & designated FIs | Licensed money-changers, designated payment systems | Applicable MAS Notice per class |
- All MAS-regulated FIs must observe the TRM Guidelines as supervisory expectations and can be assessed against them during inspections.
- The Notices on Cyber Hygiene impose six baseline measures as legal obligations on the FIs to which they apply.
- Outsourcing and third-party service providers to FIs are indirectly captured: the FI remains accountable for technology risk even when functions are outsourced, and MAS may exercise inspection rights over material outsourced arrangements.
- Group entities and overseas branches/subsidiaries are expected to align with equivalent standards where they support Singapore operations.
Structure of MAS TRM
The 2021 TRM Guidelines are organised into a set of thematic chapters, each articulating principles and expected practices. The table below maps the major chapters (domains) to their scope. In assessment engagements it is useful to treat each chapter as a control family and to derive verifiable sub-controls from the expected practices within it.
| Chapter / domain | Scope and coverage |
|---|---|
| 1. Overview | Purpose, applicability, proportionality and definitions. |
| 2. Technology Risk Governance & Oversight | Board and senior management accountability, TRM policies, roles of CIO/CISO, technology risk management function, risk appetite, security awareness and competency. |
| 3. Technology Risk Management Framework | Risk identification, assessment, treatment, monitoring; risk register; information asset identification and classification. |
| 4. IT Project Management & Security-by-Design | Project governance, secure SDLC, source-code review, application security testing, DevSecOps. |
| 5. Software Application Development & Management | Secure coding, API development and management, end-user computing, application security controls. |
| 6. IT Service Management | Change management, programme/release management, incident and problem management, service-level management. |
| 7. IT Resilience | System availability, disaster recovery, business continuity, capacity management, backup and recovery. |
| 8. Access Control | Identity and access management, privileged access management, remote access, physical and environmental security. |
| 9. Cryptography | Cryptographic key management, algorithms, certificate management. |
| 10. Data & Infrastructure Security | Data loss prevention, network security, virtualisation and cloud security, endpoint protection, patch management. |
| 11. Cyber Security Operations | Cyber threat intelligence, cyber-attack surveillance, security operations centre (SOC), vulnerability assessment and penetration testing. |
| 12. Cyber Security Assessment | Vulnerability assessment, penetration testing, red teaming / adversarial attack simulation exercises (AASE). |
| 13. Online Financial Services | Customer authentication, fraud monitoring, transaction security for internet and mobile channels. |
| 14. IT Audit | Independent technology audit function, audit planning, coverage and follow-up. |
Master Assessment Checklist
This is the central working section of the guide. It enumerates each TRM domain and translates the MAS expected practices into concrete assessment questions ('What to verify') alongside the artefacts an auditor should collect ('Typical evidence'). Every domain of the 2021 Guidelines is covered. Assessors should treat each row as a testable control and record a rating (met / partially met / not met / not applicable) with a supporting evidence reference.
1. Technology Risk Governance & Oversight
| What to verify | Typical evidence |
|---|---|
| Board and senior management have approved a technology-risk and cyber-security strategy and receive regular risk reporting. | Board/risk-committee charter, approved TRM strategy, board pack minutes showing technology-risk discussion. |
| A technology risk appetite statement exists with quantified thresholds and is monitored. | Risk appetite statement, risk-appetite dashboard, breach-escalation records. |
| A CISO (or equivalent) and technology-risk management function are appointed with clear mandate and independence. | Organisation chart, CISO job description, appointment letter, reporting-line documentation. |
| TRM policies and standards are documented, approved, version-controlled and reviewed at least annually. | Policy library, approval sign-offs, review dates, change history. |
| Security-awareness and competency programmes cover all staff, with role-based training for technology and privileged users. | Training calendar, completion reports, phishing-simulation results, competency matrix. |
| Technology-risk metrics and KRIs are defined, tracked and escalated. | KRI register, monthly risk reports, escalation logs. |
2. Technology Risk Management Framework
| What to verify | Typical evidence |
|---|---|
| A structured risk-management process (identify, assess, treat, monitor) is documented and operating. | TRM framework document, risk-assessment methodology, risk register. |
| Information assets are inventoried, owned and classified by criticality and sensitivity. | Asset inventory / CMDB, data-classification policy, asset-owner assignments. |
| Risk assessments are performed for new systems, material changes and periodically for existing systems. | Completed risk-assessment reports, project risk assessments, review schedule. |
| Risk-treatment decisions (mitigate/accept/transfer/avoid) are approved at the appropriate authority level. | Risk-treatment plans, risk-acceptance sign-offs, residual-risk register. |
| Key third-party and supply-chain technology risks are identified and managed. | Vendor risk register, outsourcing risk assessments, concentration-risk analysis. |
3. IT Project Management & Security-by-Design
| What to verify | Typical evidence |
|---|---|
| A project governance framework enforces stage gates, security sign-offs and risk assessment. | Project methodology, stage-gate approvals, project risk registers. |
| Security-by-design and threat modelling are embedded from the design phase. | Threat-model documents, security requirements specifications, design review records. |
| Independent security testing (SAST/DAST/pen-test) is performed before production release. | Test reports, remediation logs, go-live sign-offs. |
| Post-implementation reviews assess whether project and security objectives were met. | PIR reports, lessons-learned records. |
4. Software Application Development & Management
| What to verify | Typical evidence |
|---|---|
| A secure SDLC with secure-coding standards is defined and enforced. | Secure-coding standard, SDLC policy, developer training records. |
| Source-code review (manual and automated) is conducted and findings remediated. | SAST scan reports, peer-review records, defect-tracking tickets. |
| APIs are developed, secured and managed with authentication, authorisation, throttling and logging. | API gateway configuration, API security standard, API inventory, access logs. |
| End-user computing (EUC) applications are inventoried, risk-rated and controlled. | EUC register, EUC control policy, review records. |
| Segregation between development, test and production environments is enforced. | Environment architecture diagram, access-control matrix, deployment approvals. |
5. IT Service Management (Change, Incident & Problem)
| What to verify | Typical evidence |
|---|---|
| A formal change-management process with CAB approval, testing and rollback plans is operating. | Change tickets, CAB minutes, rollback plans, emergency-change records. |
| Release and deployment management prevents unauthorised code reaching production. | Release calendar, deployment approvals, segregation-of-duties evidence. |
| Incident management classifies, prioritises and resolves incidents within defined SLAs. | Incident tickets, SLA dashboards, major-incident reports. |
| Problem management performs root-cause analysis for recurring or major incidents. | RCA reports, problem records, corrective-action tracking. |
| MAS incident-notification requirements (notify within 1 hour of discovery) are operationalised. | Incident-notification procedure, sample MAS notifications, contact list. |
6. IT Resilience (Availability, DR & BCM)
| What to verify | Typical evidence |
|---|---|
| Critical systems meet the availability expectation (max 4 hours unscheduled downtime per 12 months). | System-availability records, downtime logs, RTO/RPO definitions. |
| Disaster-recovery plans exist, with a geographically separate DR site and defined RTO/RPO. | DR plan, DR site details, RTO/RPO register. |
| DR and BCP tests are conducted at least annually with documented results. | DR test plans, test reports, remediation of test gaps. |
| Capacity and performance management prevents resource-exhaustion outages. | Capacity plans, monitoring dashboards, threshold-alert configurations. |
| Backups are performed, encrypted, tested for restorability and protected from ransomware. | Backup schedules, restore-test evidence, immutable/offline backup configuration. |
7. Access Control
| What to verify | Typical evidence |
|---|---|
| Access is granted on least-privilege and need-to-know, with periodic recertification. | Access-control policy, access-review reports, recertification sign-offs. |
| Privileged access is managed via a PAM solution with just-in-time and session recording. | PAM configuration, privileged-session logs, admin-account inventory. |
| MFA is enforced for administrative, privileged and remote access (Cyber Hygiene baseline). | MFA policy, authentication logs, exception register. |
| Remote access is secured, monitored and restricted to authorised users and devices. | VPN/ZTNA configuration, remote-access logs, device-posture checks. |
| Physical and environmental controls protect data centres and sensitive facilities. | Access-card logs, CCTV records, environmental-monitoring evidence. |
| Dormant, orphaned and terminated-user accounts are disabled promptly. | Joiner-mover-leaver records, account-disablement logs, HR-IT reconciliation. |
8. Cryptography
| What to verify | Typical evidence |
|---|---|
| Approved, strong cryptographic algorithms and key lengths are used; weak/deprecated ciphers are disabled. | Cryptographic standard, TLS configuration scans, cipher inventory. |
| A cryptographic key-management lifecycle (generation, distribution, storage, rotation, destruction) is enforced. | Key-management policy, HSM configuration, key-rotation records. |
| Digital certificates are inventoried, monitored for expiry and renewed in time. | Certificate inventory, expiry-monitoring alerts, renewal records. |
| Keys are protected in hardware security modules or equivalent for high-value functions. | HSM inventory, FIPS 140-2/3 certificates, key-access logs. |
9. Data & Infrastructure Security
| What to verify | Typical evidence |
|---|---|
| Data-loss prevention controls protect sensitive and customer data at rest, in transit and in use. | DLP policy, DLP alert logs, encryption configuration. |
| Network security is layered with segmentation, firewalls and perimeter defence (Cyber Hygiene baseline). | Network architecture diagram, firewall rule reviews, segmentation evidence. |
| Cloud and virtualisation environments are securely configured and continuously monitored. | Cloud security posture reports (CSPM), IaC scans, shared-responsibility matrix. |
| Endpoints are protected with anti-malware and hardened to security standards (Cyber Hygiene baseline). | EDR/anti-malware coverage report, hardening baselines, benchmark scans. |
| Security patches are applied within defined timeframes (Cyber Hygiene baseline). | Patch policy, patch-compliance reports, exception register. |
| Security-standard hardening is applied to servers, databases and network devices. | Hardening standards, configuration-compliance scans (e.g. CIS benchmarks). |
10. Cyber Security Operations
| What to verify | Typical evidence |
|---|---|
| Cyber threat intelligence is collected, contextualised and actioned. | CTI feed subscriptions, threat-briefing reports, IOC-ingestion evidence. |
| A SOC (in-house or outsourced) provides continuous monitoring and detection. | SOC operating model, SIEM use-case catalogue, alert-triage records. |
| Logging is comprehensive, centralised, time-synchronised and retained per policy. | Logging policy, SIEM log-source inventory, NTP configuration, retention settings. |
| Cyber-incident response plans and playbooks exist and are exercised. | IR plan, playbooks, tabletop-exercise reports. |
| Threat-hunting and detection-engineering activities improve coverage over time. | Threat-hunt reports, MITRE ATT&CK coverage matrix, detection backlog. |
11. Cyber Security Assessment (VA, Pen-Test & AASE)
| What to verify | Typical evidence |
|---|---|
| Vulnerability assessments are conducted regularly across the estate. | VA scan schedule, VA reports, remediation SLAs and tracking. |
| Penetration testing is performed on internet-facing and critical systems at least annually. | Pen-test scope, reports, retest evidence, remediation logs. |
| Adversarial attack simulation exercises (red teaming) test end-to-end detection and response for larger FIs. | AASE scope, exercise report, blue-team observations, improvement actions. |
| Findings are risk-rated, tracked to closure and reported to management. | Vulnerability-management dashboard, closure evidence, management reporting. |
12. Online Financial Services & Customer Security
| What to verify | Typical evidence |
|---|---|
| Strong customer authentication (including MFA) protects online and mobile channels. | Authentication design, MFA configuration, step-up-authentication rules. |
| Real-time fraud monitoring and transaction risk-scoring are in place. | Fraud-monitoring rules, alert logs, blocked-transaction reports. |
| Customer notifications and transaction signing are implemented for high-risk activities. | Notification configuration, transaction-signing evidence, cooling-off rules. |
| Anti-phishing, anti-malware and secure-session controls protect customer sessions. | Session-management config, device binding, phishing-takedown records. |
13. IT Audit
| What to verify | Typical evidence |
|---|---|
| An independent IT audit function with adequate competency and mandate exists. | Audit charter, auditor qualifications, independence attestation. |
| A risk-based IT audit plan covers key technology-risk areas over a defined cycle. | Audit universe, annual audit plan, coverage-mapping. |
| Audit findings are tracked to remediation and reported to the audit committee. | Audit reports, finding-tracker, audit-committee minutes. |
| Third-party / outsourced technology arrangements are within audit scope. | Outsourcing audit reports, right-to-audit clauses, assurance reports (e.g. SOC 2). |
Scoping
Scoping determines which systems, environments, data and processes fall within the TRM assessment and, critically, which systems are 'critical systems' subject to the most stringent availability and resilience expectations. Under the TRM Notices, a critical system is one whose failure would materially impact the FI's operations, ability to serve customers, or the safety and soundness of the financial system. The scoping exercise should be evidence-based and reviewed whenever the technology estate changes materially.
- Identify and classify critical systems (systems whose failure materially affects operations or customers) versus non-critical systems.
- Enumerate all information assets and map them to owners, classifications and supporting infrastructure.
- Include cloud and outsourced environments; the FI remains accountable and must define the shared-responsibility boundary.
- Cover the full technology lifecycle: development, test, production, DR and backup environments.
- Include internet-facing assets, APIs, mobile applications and third-party integrations in cyber-assessment scope.
- Document scope decisions, assumptions and exclusions with justification for supervisory review.
Scoping pitfall
A frequent finding is that DR and backup environments, shadow-IT and end-user-computing applications are excluded from scope, then fail during a real incident. Treat any system that stores, processes or transmits customer data or supports a critical business service as in-scope until proven otherwise.
Implementation Approach
A phased implementation lets an FI move from a baseline assessment to sustained, board-assured cyber-resilience. Each phase below lists indicative activities and deliverables.
Phase 1 — Governance & Baseline Assessment
- Activities: Establish board and senior-management sponsorship; confirm CISO/TRM function mandate; perform a TRM gap assessment against all domains; validate Cyber Hygiene baseline compliance.
- Deliverables: Governance charter, TRM gap-assessment report, prioritised remediation roadmap, technology risk appetite statement.
Phase 2 — Risk Framework & Asset Foundation
- Activities: Build/validate asset inventory and data classification; stand up the risk-management process and register; define critical systems and RTO/RPO.
- Deliverables: Asset inventory and CMDB, data-classification policy, risk register, critical-system list.
Phase 3 — Control Uplift
- Activities: Remediate access-control, cryptography, patching, hardening and network-segmentation gaps; deploy PAM and MFA; implement secure SDLC and API security.
- Deliverables: Updated control configurations, PAM/MFA rollout evidence, secure-SDLC standard, hardened baselines.
Phase 4 — Detection & Response
- Activities: Operationalise SOC/SIEM, logging and CTI; build IR playbooks; align incident notification with MAS timelines.
- Deliverables: SIEM use-case catalogue, IR plan and playbooks, incident-notification procedure.
Phase 5 — Resilience & Assurance
- Activities: Test DR/BCP; conduct VA, penetration testing and (for larger FIs) AASE; establish independent IT audit cycle.
- Deliverables: DR test report, pen-test and AASE reports, IT audit plan and findings tracker.
Phase 6 — Continuous Improvement
- Activities: Embed KRIs and management reporting; run continuous control monitoring; feed lessons learned back into the risk framework.
- Deliverables: KRI dashboards, continuous-monitoring reports, annual TRM self-attestation to the board.
Maturity / Capability Model
MAS TRM does not mandate a formal maturity scale, but supervisors and internal assessors commonly rate control maturity to prioritise investment. The five-level model below is a practical capability scale that aligns to how MAS supervisors interpret adequacy under proportionality.
| Level | Descriptor | Characteristics |
|---|---|---|
| 1 | Initial / Ad hoc | Controls undocumented and inconsistent; reliance on individuals; no board oversight of technology risk. |
| 2 | Developing | Basic policies exist; controls partially implemented; reactive incident handling; Cyber Hygiene partially met. |
| 3 | Defined | Documented, approved TRM framework; controls implemented across critical systems; regular risk reporting to management. |
| 4 | Managed & Measured | Controls monitored with KRIs; independent testing (VA/pen-test) routine; board actively oversees technology risk; Cyber Hygiene fully met. |
| 5 | Optimised | Continuous improvement; threat-informed defence with AASE; automation of detection/response; resilience validated through exercises; leading practice. |
Assessment and Audit Approach
- Define objectives and scope: agree the FI class, applicable Notices, critical systems and environments to be assessed.
- Collect documentation: obtain policies, standards, architecture diagrams, prior audit and pen-test reports, and the risk register.
- Assess governance: interview the board/risk committee, CISO and TRM function to confirm accountability and reporting.
- Test controls by domain: walk through each TRM domain using the master assessment checklist, gathering evidence per control.
- Perform technical validation: review configurations, run/verify VA scans, review pen-test and AASE results, sample logs and access reviews.
- Validate resilience: examine DR/BCP test results, availability records and backup-restore evidence against RTO/RPO.
- Assess Cyber Hygiene baseline: confirm the six mandatory measures are met with objective evidence (legal obligation).
- Rate and gap-analyse: assign maturity ratings, identify gaps and rank by risk and regulatory exposure.
- Report and remediate: produce a findings report with prioritised remediation, owners and target dates; track to closure.
- Re-test and attest: retest remediated items and provide management/board attestation of residual risk.
Evidence Request List
The following categorised evidence list accelerates fieldwork. Request these artefacts ahead of the assessment window.
- Governance: board/risk-committee charters and minutes, TRM strategy, risk appetite statement, CISO mandate, organisation chart.
- Policies & standards: TRM framework, security policies, secure-coding, cryptography, access-control, change-management and DR/BCP policies.
- Asset & risk: asset inventory/CMDB, data-classification records, risk register, critical-system list, RTO/RPO register.
- Access & identity: access-review reports, PAM configuration, MFA policy and logs, joiner-mover-leaver records.
- Infrastructure & data: network diagrams, firewall-rule reviews, hardening baselines, patch-compliance reports, DLP and encryption configuration.
- Cyber operations: SIEM use-case catalogue, log-source inventory, CTI feeds, IR plan and playbooks, tabletop-exercise reports.
- Assessments: VA scans, penetration-test and AASE reports with remediation evidence.
- Resilience: DR/BCP test reports, system-availability records, backup and restore-test evidence.
- Third-party: outsourcing risk assessments, right-to-audit clauses, vendor assurance reports (e.g. SOC 2), concentration-risk analysis.
- Audit & incidents: IT audit plan and reports, finding tracker, incident register, sample MAS incident notifications.
Roles and Responsibilities
| Role | Key responsibilities under MAS TRM |
|---|---|
| Board of Directors | Ultimate accountability for technology risk; approve TRM strategy and risk appetite; oversee cyber-resilience. |
| Senior Management | Implement the TRM framework; allocate resources; ensure risk reporting and remediation. |
| CISO / Head of Information Security | Own the cyber-security programme; drive control implementation, threat management and incident response. |
| Head of Technology Risk | Maintain the TRM framework, risk register and KRIs; provide independent risk challenge. |
| CIO / Head of IT | Deliver secure, resilient technology operations; manage change, availability and infrastructure security. |
| Internal / IT Audit | Provide independent assurance over technology risk; report findings to the audit committee. |
| System / Data Owners | Classify and protect assets; approve access; validate controls for their systems. |
| Third-party / Outsourcing Managers | Manage vendor technology risk and assurance; enforce right-to-audit and SLAs. |
KPIs to Track
- Critical-system availability versus the 4-hours-per-12-months downtime expectation.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for cyber incidents.
- Percentage of assets meeting patch-compliance SLAs (critical patches within target).
- Percentage of privileged accounts under PAM and covered by MFA.
- Open high/critical vulnerabilities and average time to remediate.
- Access-recertification completion rate and orphaned-account count.
- DR/BCP test success rate against RTO/RPO targets.
- Phishing-simulation failure rate and security-awareness completion rate.
- Percentage of Cyber Hygiene baseline measures fully met (target 100%).
- Number of MAS-reportable incidents and on-time notification rate (within 1 hour).
Readiness Checklist
- Board-approved TRM strategy and risk appetite statement are in place.
- CISO and technology-risk function appointed with clear mandate and independence.
- Complete asset inventory and data classification maintained.
- Critical systems identified with defined RTO/RPO.
- All six Cyber Hygiene baseline measures fully implemented and evidenced.
- PAM and MFA enforced for privileged, administrative and remote access.
- Secure SDLC, API security and environment segregation operating.
- SOC/SIEM, centralised logging and CTI operational.
- Incident-response plan and playbooks exercised; MAS notification procedure ready.
- DR/BCP tested within the last 12 months with gaps remediated.
- VA, penetration testing and (where applicable) AASE completed with findings closed.
- Independent IT audit plan executed and findings tracked to closure.
Common Gaps
- Board reporting on technology risk is superficial, with no quantified risk appetite or KRIs.
- Asset inventory is incomplete, so unknown or shadow-IT systems escape controls and monitoring.
- Cyber Hygiene baseline is only partially met (e.g. MFA gaps on legacy admin accounts) despite being a legal obligation.
- DR/BCP tests are documented but not truly exercised end-to-end, leaving real recovery unproven.
- Privileged access is over-provisioned, standing and unmonitored, with weak or absent PAM.
- Third-party and cloud responsibilities are ambiguous; the shared-responsibility boundary is undefined.
- Vulnerability remediation lacks enforced SLAs, so critical findings age beyond acceptable windows.
- Logging coverage is patchy or retention is too short to support investigation and MAS reporting.
- Incident-notification procedures are not rehearsed, risking breach of the one-hour notification requirement.
- API and end-user-computing applications are ungoverned and untested.
MAS TRM Mapped to Other Frameworks
| MAS TRM domain | ISO/IEC 27001 | NIST CSF | PCI DSS v4.0 |
|---|---|---|---|
| Technology Risk Governance & Oversight | Clause 5, A.5 | GV (Govern), ID.GV | Req. 12 (governance & policy) |
| Technology Risk Management Framework | Clause 6, A.5.9 | ID.RA, ID.RM | Req. 12.3 (risk assessment) |
| Software Development & Security-by-Design | A.8.25–A.8.29 | PR.PS, PR.IP | Req. 6 (secure development) |
| IT Service Management (Change/Incident) | A.8.32, A.5.24 | PR.IP-3, RS (Respond) | Req. 6.5, Req. 12.10 |
| IT Resilience (DR/BCM) | A.5.29, A.5.30 | RC (Recover), PR.IP-9 | Req. 12.10.1 (continuity) |
| Access Control | A.5.15–A.5.18, A.8.2–A.8.5 | PR.AC / PR.AA | Req. 7, Req. 8 |
| Cryptography | A.8.24 | PR.DS-1/2 | Req. 3, Req. 4 |
| Data & Infrastructure Security | A.8.7–A.8.23 | PR.DS, PR.PT | Req. 1, Req. 2, Req. 5 |
| Cyber Security Operations | A.5.7, A.8.15, A.8.16 | DE (Detect), RS | Req. 10, Req. 11.5 |
| Cyber Security Assessment (VA/Pen-test) | A.8.8, A.8.29 | ID.RA-1, DE.CM | Req. 11.3, Req. 11.4 |
| IT Audit | Clause 9.2 | GV.OV, ID.IM | Req. 12.11 (reviews) |
How CyberSigma helps
CyberSigma is a CERT-In empanelled cyber-security and compliance partner with hands-on experience supporting financial institutions through MAS TRM readiness, Cyber Hygiene baseline compliance, and MAS-aligned penetration testing and adversarial attack simulation exercises. We deliver end-to-end MAS TRM gap assessments across all domains, build board-ready technology-risk governance, remediate access, cryptography, resilience and cyber-operations gaps, and provide independent VA/pen-test/red-team assurance mapped to MAS expectations. Our team also harmonises your MAS TRM programme with ISO 27001, NIST CSF and PCI DSS so a single control uplift satisfies multiple regulators. Talk to CyberSigma to accelerate your MAS TRM readiness with an auditor-grade, evidence-driven approach.
Frequently asked questions
Are the MAS TRM Guidelines mandatory?
The Guidelines set supervisory expectations; the related MAS Notices (e.g., Cyber Hygiene, TRM) impose legally binding minimum requirements.
Official documents
CyberSigma resources
Need help with MAS TRM?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.