1. Dormant accounts and unreviewed access rights Guidance: TRM Guidelines 9.1

What MAS expects: access granted on a need-to-use basis, a formal process to provision, change and revoke access, and periodic reviews that catch dormant and redundant accounts, with exceptions resolved promptly.

What a gap can look like (fictional example): a 60-person fund manager finds that 14 accounts belong to people who left in the past year, two of them still enabled on the remote access gateway, and no owner can say when access rights were last reviewed.

What good looks like: joiner, mover and leaver processes tied to HR, a scheduled access review signed off by asset owners, and leaver access disabled the same day.

Source: MAS TRM Guidelines, section 9.1 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

2. Missing multi-factor authentication on powerful accounts Binding: Notice FSM-N06 (banks) Guidance: TRM Guidelines 9.1, 9.3

Applicability: quoted from the cyber hygiene notice for banks. Other financial institution types have parallel cyber hygiene notices; check the one for your licence.

What MAS expects: under FSM-N06, banks must implement multi-factor authentication for all administrative accounts on critical systems and for all accounts on any system used to access customer information through the internet. The guidelines also call for strong authentication on remote access generally.

What a gap can look like (fictional example): a payments firm rolls out MFA for staff email but leaves the server administration accounts on passwords alone, because “only IT use them”.

What good looks like: MFA enforced on every administrative account and every remote path into the environment, not just end-user email.

Sources: Notice FSM-N06, paragraph 4.6 – https://www.mas.gov.sg/regulation/notices/notice-fsm-n06 ; MAS TRM Guidelines, sections 9.1 and 9.3 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

3. Patching backlogs and unsupported systems Binding: Notice FSM-N06 (banks) Guidance: TRM Guidelines 7.3, 7.4

Applicability: quoted from the cyber hygiene notice for banks. Other financial institution types have parallel cyber hygiene notices; check the one for your licence.

What MAS expects: under FSM-N06, banks must apply security patches within a timeframe commensurate with the risk each vulnerability poses, and institute controls to reduce risk where no patch is available. The guidelines also expect technology refresh before systems fall out of vendor support.

What a gap can look like (fictional example): a brokerage runs its client reporting on a server the vendor stopped patching two years ago, with no plan to replace it and nothing written down about how the risk is contained.

What good looks like: a patch cycle with named owners, a register of unsupported systems, and compensating controls or a funded replacement date for each one.

Sources: Notice FSM-N06, paragraph 4.2 – https://www.mas.gov.sg/regulation/notices/notice-fsm-n06 ; MAS TRM Guidelines, sections 7.3 and 7.4 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

4. Backups that have never been restore-tested Binding: Notice FSM-N05 (banks) Guidance: TRM Guidelines 8.4

Applicability: the four-hour figures below are quoted from the technology risk notice for banks. Other financial institution types have parallel TRM notices; confirm the requirements for your licence before treating them as your own.

What MAS expects: under FSM-N05, a bank must establish a recovery time objective of no more than four hours for each critical system, validated and documented at least every 12 months, and must keep maximum unscheduled downtime for each critical system within four hours in any 12-month period. Backup success messages are not evidence of recoverability.

What a gap can look like (fictional example): an advisory firm has nightly backups reporting green for years, but the first real restore test fails: the database backup depends on a licence key nobody recorded.

What good looks like: scheduled restore tests against real targets, results documented, and recovery evidence you could show an auditor tomorrow.

Sources: Notice FSM-N05, paragraphs 5 and 6 – https://www.mas.gov.sg/regulation/notices/notice-fsm-n05 ; MAS TRM Guidelines, section 8.4 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

5. Incident response plans that exist only on paper Binding: Notice FSM-N05 (banks) Guidance: TRM Guidelines 7.7, 12.3

Applicability: the deadlines below are quoted from the technology risk notice for banks. Other financial institution types have parallel TRM notices; confirm the deadlines for your licence.

What MAS expects: under FSM-N05, a bank must notify MAS of a relevant incident (severe and widespread impact, or a material impact on service to customers) as soon as possible and no later than one hour after discovering it, and submit a root cause and impact analysis report within 14 days. The guidelines expect a tested incident response process behind that clock.

What a gap can look like (fictional example): a payment services company has a response plan last edited three years ago; the named escalation contact left the firm, and nobody has ever rehearsed who calls MAS or within what time.

What good looks like: a current plan, named roles with deputies, and at least one tabletop exercise a year that includes the regulatory notification step.

Sources: Notice FSM-N05, paragraphs 7 and 8 – https://www.mas.gov.sg/regulation/notices/notice-fsm-n05 ; MAS TRM Guidelines, sections 7.7 and 12.3 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

6. No written security standards for systems Binding: Notice FSM-N06 (banks)

Applicability: quoted from the cyber hygiene notice for banks. Other financial institution types have parallel cyber hygiene notices; check the one for your licence.

What MAS expects: under FSM-N06, banks must maintain a written set of security standards for every system, ensure each system conforms, and institute mitigating controls where a system cannot conform.

What a gap can look like (fictional example): a growing fintech has hardened laptops “the way we always do”, but nothing is written down, so a new engineer’s build differs and no one can say which settings are mandatory.

What good looks like: a short, owned baseline standard per system type, checked at build time and reviewed on a schedule.

Source: Notice FSM-N06, paragraph 4.3 – https://www.mas.gov.sg/regulation/notices/notice-fsm-n06

7. Privileged access that is not logged or monitored Guidance: TRM Guidelines 9.2

What MAS expects: privileged accounts granted only on a need-to-use basis, with their activity logged and reviewed as part of ongoing monitoring, and a managed process for system and service accounts.

What a gap can look like (fictional example): an insurer’s five administrators share one domain admin account, so the logs can never show who changed what.

What good looks like: individually named privileged accounts, logging that is actually reviewed, and service accounts inventoried and rotated.

Source: MAS TRM Guidelines, section 9.2 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

8. IT supplier and outsourcing oversight gaps Guidance: TRM Guidelines 3.4

What MAS expects: third party services managed within the technology risk framework, with the institution keeping responsibility for the risk even when the work is outsourced, and service providers held to the same access and monitoring standards as staff.

What a gap can look like (fictional example): a wealth manager’s outsourced IT provider has standing admin access to production systems, no contract clause covering security duties, and has never been asked for evidence of its own controls.

What good looks like: contracts that name security responsibilities, access scoped and reviewed like staff access, and periodic evidence collected from suppliers.

Source: MAS TRM Guidelines, section 3.4 – https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines