playbook/antigravity-awesome-skills/skills/fsi-compliance-checker/mas-trm.md

MAS Technology Risk Management (TRM) Guidelines — Engineering Control Reference

Engineering-relevant expectations from the Monetary Authority of Singapore's TRM Guidelines (January 2021), organized for change triage. Section numbers follow the official guidelines. The TRM Guidelines apply to all MAS-regulated financial institutions; they are principles-based guidelines (not prescriptive rules), so findings should be framed as "expectation gaps", and the institution's own TRM-aligned policies take precedence where stricter.

Related instruments to flag when relevant (not summarized here): MAS Notices on Cyber Hygiene (legally binding baseline), Outsourcing Guidelines, and the MAS AI model risk management information paper for AI/ML systems.

Contents

1. Software development & DevOps (§6)
2. IT resilience & availability (§8)
3. Access control (§9)
4. Cryptography (§10)
5. Data & infrastructure security (§11)
6. Cyber operations & monitoring (§12-13)
7. Online financial services (§14)
8. Quick triage table

1. Software Development & DevOps (§6)

Ref	Expectation (summary)	Engineering check
6.1	Secure-by-design SDLC: security requirements defined at the start, not bolted on	Security stories/threat model exist for the feature
6.2	Secure coding standards; code review (peer or automated) before deployment	Review gates; standards documented and enforced
6.3	Source code security: access to repositories controlled; code integrity protected	Repo permissions, branch protection, signed commits where applicable
6.4	Security testing: vulnerability assessment before production launch and after major changes; penetration testing for internet-facing systems	SAST/DAST in pipeline; pen-test cadence for public systems
6.5	Separate environments for development, testing, production; production data not used in non-production without protection	Environment isolation; data masking for test data
6.6	Change management: assessed, tested, approved before production; emergency change procedures with retrospective approval	CI/CD approval gates, change records, rollback plans
6.7	End-of-life/unsupported software identified and risk-managed	Dependency and runtime version currency
—	DevOps note: §6 expectations apply to pipeline automation itself — the pipeline is a production system (access control, audit, segregation of duties in deployment approval)	Who can approve+deploy; pipeline credentials

2. IT Resilience & Availability (§8)

Ref	Expectation (summary)	Engineering check
8.2	Availability targets defined; critical systems' RTO ≤ 4 hours and RPO defined per MAS Notice expectations	Architecture supports the institution's stated RTO/RPO
8.3	Single points of failure identified and addressed for critical systems	Redundancy in new components; multi-AZ/multi-site where critical
8.4	DR plans tested at least annually; recovery procedures current	New components included in DR runbooks
8.5	Capacity management: monitor and plan for demand	Load assumptions documented for new services

3. Access Control (§9)

Ref	Expectation (summary)	Engineering check
9.1	Least privilege and need-to-have for all access; access reviewed periodically	New roles/permissions minimal; review process covers them
9.2	Strong authentication for privileged access; MFA expected for critical system administration	Admin paths MFA-protected
9.3	Privileged access managed: just-in-time where possible, activities logged and reviewed	Break-glass procedures, session recording/audit for admin ops
9.4	Segregation of duties: no single person develops, approves, and deploys to production unchecked	Pipeline approval separation
9.5	Remote access secured (MFA, encrypted channels, device posture)	VPN/zero-trust requirements for any new remote path

4. Cryptography (§10)

Ref	Expectation (summary)	Engineering check
10.1	Strong, industry-accepted algorithms and key lengths; no deprecated crypto	No MD5/SHA-1 for security, no TLS <1.2, AES-128+
10.2	Key lifecycle management: generation, distribution, storage, rotation, revocation, destruction	KMS/HSM usage; no keys in code, config files, or tickets
10.3	Cryptographic key compromise procedures	Key rotation runbook covers new keys

5. Data & Infrastructure Security (§11)

Ref	Expectation (summary)	Engineering check
11.1	Data security throughout lifecycle: at rest, in transit, in use; data loss prevention strategy	Encryption defaults on new stores; egress paths controlled
11.2	Network security: segmentation, defense in depth; critical systems in secured zones	New services placed in correct zones; no flattening of segmentation
11.3	Endpoint and server hardening per standards	Base images hardened; IaC matches hardening baselines
11.4	Virtualization/container security: hypervisor and orchestration hardening	K8s RBAC, pod security, image provenance
11.5	Cloud: institution remains responsible; due diligence, data residency, exit strategy, and MAS Outsourcing Guidelines apply	New cloud services assessed; data residency for Singapore customer data confirmed

6. Cyber Operations & Monitoring (§12-13)

Ref	Expectation (summary)	Engineering check
12.1	Security event logging across systems; logs protected and retained per policy	New components emit security events to central SIEM
12.2	Continuous monitoring and correlation; anomaly detection for critical systems	Alert rules accompany new security-relevant functionality
13.1	Cyber incident response plan; roles defined; MAS notification obligations for relevant incidents (as required by notices — commonly understood as within 1 hour for severe incidents)	New failure modes mapped to incident severity matrix
13.2	Post-incident review and remediation tracking	Incident learnings feed backlog

7. Online Financial Services (§14)

Ref	Expectation (summary)	Engineering check
14.1	Strong customer authentication: MFA for login to online financial services and for high-risk transactions	Customer auth flows; step-up auth for transfers/payee changes
14.2	Transaction signing/confirmation for high-risk transactions; out-of-band notification to customers	Transaction flows notify customers of significant actions
14.3	Session management: timeout, re-authentication for sensitive actions, protection against hijacking	Session config on customer-facing changes
14.4	Fraud monitoring and customer education surfaces	New transaction types covered by fraud rules
—	Anti-scam expectations (post-2022 MAS/ABS measures): kill switch, cooling-off for new payees/devices, transaction limits	Payment feature changes checked against these measures

8. Quick Triage Table

Change type	Check first
New feature touching customer money	§14.1-14.2, §6.1, threat model
Auth/session change	§9.x, §14.1, §14.3
New data store / data flow	§11.1, §11.5 (residency), §10.1
New cloud service	§11.5 + Outsourcing Guidelines flag
CI/CD or repo change	§6.3, §6.6, §9.4
Infra/network change	§11.2, §8.3
New logging/monitoring	§12.1-12.2
Incident-relevant failure mode	§13.1 severity mapping
AI/ML model in decisioning	Flag MAS AI information paper review