MAS Notice 655 is the Notice on Cyber Hygiene for banks, and it is binding. It mandates six baseline security measures — administrative accounts, security patches, security standards, network perimeter defence, malware protection and multi-factor authentication — and failing to implement them is a breach of a legal obligation rather than a supervisory observation.
That is the distinction most coverage gets wrong. The Technology Risk Management Guidelines are guidelines: MAS expects adherence and weighs the degree of observance in its supervisory risk assessment, but they are not law in themselves. A Notice is issued under statute and creates obligations. If you only have budget to get one thing demonstrably right this quarter, the notice on cyber hygiene is the one.
The six measures sound unremarkable until you try to evidence them across a real estate. Then the scope of "every system" starts doing the work.
Why Notice 655 Binds and the TRM Guidelines Do Not
Notice 655 binds because it is a Notice; the TRM Guidelines do not bind because they are guidelines. Both documents describe controls an FI should operate, and both are read closely by MAS, but they sit in different legal categories and failure against them produces different consequences.
Under the TRM Guidelines, a gap is a supervisory finding. MAS expects adherence, and the extent to which you observe the Guidelines feeds into how MAS assesses your risk profile — which matters commercially and reputationally, but it is an assessment, not an enforcement trigger. Under the notice on cyber hygiene, an unimplemented baseline measure is non-compliance with a legal requirement.
In practice this changes who owns the control. Guidelines work tends to live with the technology risk function and gets prioritised against everything else. Notice obligations belong on the compliance register alongside other statutory requirements, with named owners, periodic attestation, and evidence retained on the assumption that someone external will ask to see it. It also changes how you answer a questionnaire: an FI can reasonably describe partial alignment with a guideline and a plan to close the rest, but describing partial implementation of a mandated baseline measure is describing a breach.
MAS Notice 655, FSM-N06 and the 2024 Renumbering
MAS Notice 655 and FSM-N06 are the same notice on cyber hygiene under two reference numbers. The version for banks was issued as MAS Notice 655 on 6 August 2019 and took effect on 6 August 2020. MAS restructured and renumbered its notices in 2024, and the cyber hygiene notice is now also referenced as FSM-N06.
Two consequences follow for anyone researching this. First, parallel notices on cyber hygiene apply to other classes of financial institution — insurers, capital markets intermediaries, payment services licensees — under their own numbers, so 655 specifically is the banking instrument. Check which notice applies to your own licence rather than assuming the number you have seen quoted.
Second, material that discusses Notice 655 without mentioning the restructuring was probably written before 2024. That is not automatically wrong on substance, but it is a signal to verify the reference against MAS's own publication rather than a secondary summary. The same trap catches the technology risk notice that carried the incident reporting obligations, which is why MAS incident notification timelines are so often cited against a cancelled instrument.
Want the six cyber hygiene measures mapped against your actual estate?
Share your work email and we'll send the measure-by-measure evidence list — admin account inventory, patch standard, hardening baselines, perimeter rules, malware coverage and MFA scope — in the form an FI's assessor expects to receive it.
The Six Baseline Measures in MAS Notice 655
The six baseline measures in MAS Notice 655 are mandatory security measures, each phrased to cover the whole estate rather than a sample of it. The MAS cyber hygiene requirements are stated as outcomes, so what follows is what each measure demands, what a thorough implementation looks like, and where partial implementations fall over.
Securing Every Administrative Account
The measure requires an FI to secure every administrative account in respect of any operating system, database, application, security appliance or network device, to prevent unauthorised access to or use of that account.
A thorough implementation starts from an inventory rather than from a tool. You enumerate administrative accounts across all five of those categories, assign each one an owner, and then apply the controls: no shared credentials, no standing administrative rights where just-in-time elevation is possible, credentials vaulted, session activity logged, and recertification on a defined cycle.
Partial implementations cover the identity provider and the cloud console and stop there. Database superuser accounts, the local administrator on appliances, network device enable accounts and application-level super-users sit outside the identity provider and go unenumerated.
You should be able to produce a current inventory of administrative accounts with owners, the control applied to each, the last recertification date, and logs showing privileged sessions being recorded.
Applying Security Patches
The measure requires security patches addressing vulnerabilities to be applied to every system, within a timeframe commensurate with the risk posed by each vulnerability.
A thorough implementation has three parts: a complete system inventory, a documented standard defining how vulnerability risk is rated and what timeframe each rating earns, and reporting that shows actual remediation against that standard. The rating logic needs to account for exploitability and exposure, not severity score alone.
Partial implementations run a scanner and report a count. A scan result is not evidence of patching; it is evidence of scanning.
You should be able to produce the written patching standard, the inventory it applies to, remediation timelines achieved per risk rating, and the exception register for what has not been patched and why. Our walkthrough of vulnerability management evidence covers the reporting shape.
Written Security Standards for Every System
The measure requires an FI to establish and apply written security standards for every system — hardening baselines, in engineering terms.
A thorough implementation means a baseline per system type, derived from a recognised reference where one exists, version-controlled, and enforced by configuration management rather than by instruction. Enforcement is what separates a standard from a document: drift detection and automatic remediation, with accepted deviations recorded as exceptions.
Partial implementations write the baselines and never measure conformance, or cover the standard server build but not the appliances, the legacy application servers or the container images.
You should be able to produce the written standards, the mapping of system types to standards, conformance reports showing current drift, and an approved exception list. The approach is the same one described in secure configuration baselines.
Network Perimeter Defence
The measure requires controls at the network perimeter to restrict unauthorised network traffic.
A thorough implementation defines where the perimeter actually is — which in most FIs now includes cloud VPC boundaries, SaaS egress paths and remote access concentrators, not just the data centre edge — then applies default-deny rules, documented exceptions, periodic rule review, and logging of blocked and allowed traffic.
Partial implementations inherit a rule base nobody has reviewed in years. Rule bases accumulate permissive entries added for a migration that finished, and an unreviewed allow-any rule is a perimeter control in name only.
You should be able to produce a current network diagram showing the perimeter, the rule base with business justification per rule, evidence of the last rule review, and traffic logs.
Malware Protection
The measure requires malware protection measures to be implemented.
A thorough implementation covers endpoints, servers, email and web gateways, and the file transfer paths into the environment, with coverage measured against the known inventory rather than asserted. Detection content needs to be current, and alerts need to reach somebody who acts on them.
Partial implementations report that the agent is licensed for the fleet without reconciling against the asset inventory. The gap is usually servers, build agents and anything outside the standard endpoint build.
You should be able to produce coverage figures reconciled to inventory, content currency reporting, and a sample of detections with the response that followed.
Multi-Factor Authentication on Privileged and Internet Access
The measure requires multi-factor authentication for administrative and privileged access to systems, and for access through the internet to systems holding customer information. A thorough implementation treats those as two separate scoping exercises: every privileged path identified under the administrative accounts measure, and every internet-facing route into a system holding customer information, including staff access, customer-facing portals and API paths.
Partial implementations enforce MFA at the identity provider and assume coverage. Anything that authenticates locally, anything reachable by direct protocol access, and any service account with an interactive path bypasses it.
You should be able to produce the list of in-scope access paths, the factor enforced on each, the exceptions with compensating controls, and authentication logs demonstrating enforcement rather than availability.
Mapping Each Measure to the Evidence It Requires
Mapping each measure to its evidence is the step that turns the notice from a policy statement into an audit position. The table below is the shortest version of what an assessor, an internal auditor, or an FI customer reviewing your access controls will ask you to produce.
| Baseline measure | What evidences it |
|---|---|
| Administrative accounts | Inventory of administrative accounts across OS, database, application, security appliance and network device, with owners, control applied, recertification dates, and privileged session logs |
| Security patches | Written risk-based patching standard, system inventory it covers, remediation achieved per risk rating, exception register |
| Security standards | Version-controlled hardening baselines per system type, system-to-baseline mapping, conformance and drift reports, approved exceptions |
| Network perimeter defence | Current perimeter diagram, rule base with per-rule justification, last rule review record, allowed and blocked traffic logs |
| Malware protection | Coverage reconciled to asset inventory, detection content currency, sample detections with response actions |
| Multi-factor authentication | In-scope access path list for privileged access and internet access to customer information, factor enforced per path, exceptions with compensating controls, authentication logs |
Every row is a document or a report, not a statement of intent. If a measure has no artefact behind it, treat it as unimplemented until it does.
The Risk-Commensurate Patching Timeframe Is Harder Than an SLA
The patching measure sets a risk-commensurate timeframe, not a fixed number of days — and that is harder to satisfy than a flat SLA, not easier. A fixed number tells you what to build. A risk-commensurate obligation makes you define the standard yourself and then defend both the definition and your performance against it.
The obligation has two halves. You owe a documented, risk-based standard: how vulnerability risk is assessed for your estate, what factors feed the rating, and what remediation timeframe each rating carries. And you owe evidence of meeting it — actual remediation times per rating, with the misses explained.
The common mistake is copying a generic severity-to-days table from elsewhere. That gives you a standard you cannot justify, because it was not derived from your exposure, your compensating controls or the systems you actually run. Rating logic that considers whether the affected system is internet-facing, whether an exploit is known to be in use, and what data the system holds is defensible in a way a copied table is not.
The second mistake is setting the standard aggressively to look good. You are measured against your own document, so a standard you meet is worth more than an ambitious one you miss — the MAS TRM compliance checklist is a better place to be ambitious.
Where Administrative Account and MFA Scope Quietly Expands
Administrative accounts and MFA are the two measures with the widest scope creep, because both reach across every operating system, database, application, security appliance and network device you run. Coverage gaps cluster in four places, and they are the same four places in almost every FI we see.
- Service accounts. Non-human accounts with administrative rights, often created for an integration years ago, with static credentials and no owner. They are in scope, and they usually cannot take an interactive second factor — which makes each one an exception requiring a compensating control rather than something to leave unmentioned.
- Break-glass accounts. Emergency access accounts are legitimate and necessary. What makes them a finding is the absence of the surrounding controls: sealed credentials, use triggering an alert, and a post-use review.
- Vendor-held accounts. Administrative credentials held by a managed service provider or software vendor sit inside your scope, whatever the contract says. The institution remains accountable for technology risk in outsourced arrangements, so you need the inventory, the control evidence and the contractual right to verify it — the ground covered in MAS vendor due diligence.
- Legacy systems. Platforms that cannot support modern authentication are the honest hard case. The answer is network isolation, jump-host mediation with MFA at the jump host, and session recording — documented as a compensating control with a decommissioning plan, not omitted from the inventory.
MAS Cyber Hygiene Questions Compliance Teams Ask
These are the MAS cyber hygiene questions compliance teams ask most often once they realise the notice is binding rather than advisory.
Yes. It is a Notice, issued under statute, and legally binding on the financial institutions it applies to. The six baseline measures are mandatory, and non-compliance is a breach of a legal obligation rather than a supervisory observation. That is the opposite of the TRM Guidelines, which MAS expects FIs to observe and factors into its supervisory risk assessment, but which are not law in themselves.
They are references to the same notice on cyber hygiene. It was issued as MAS Notice 655 for banks on 6 August 2019 and took effect on 6 August 2020. MAS restructured and renumbered its notices in 2024, and the cyber hygiene notice is now also referenced as FSM-N06. If a source cites 655 with no mention of the restructuring, it likely predates 2024 — verify the reference against MAS's own publication.
It does not set a number of days. The measure requires security patches to be applied within a timeframe commensurate with the risk posed by each vulnerability, so you define a documented, risk-based standard for your own estate and then evidence that you meet it. A copied severity-to-days table is not a risk-based standard, and an aggressive standard you consistently miss is weaker evidence than a realistic one you meet.
Notice 655 is the banking instrument. Parallel notices on cyber hygiene apply to other classes of financial institution — including insurers, capital markets intermediaries and payment services licensees — each under its own number, with the six baseline measures as the common core. Confirm which notice attaches to your own licence class rather than working from a number quoted elsewhere.
Not directly — the notice binds the regulated institution, not its suppliers. But the institution remains accountable for technology risk in its outsourced arrangements, so FIs push the six measures onto vendors contractually and verify them. Expect to evidence administrative account control, patching, hardening, perimeter controls, malware protection and MFA wherever your systems touch an FI's.
Keep the six cyber hygiene measures evidenced continuously
Book a demo and we'll show how Konfirmity holds each baseline measure against live evidence — admin account inventory, patch performance against your own risk standard, baseline drift, perimeter rule reviews, malware coverage and MFA scope — so the answer is ready when MAS or an FI customer asks.
Book a demo
Build the Evidence Before Anyone Asks
Treat the six baseline measures as six standing evidence obligations rather than six projects. Each one has an artefact behind it — an inventory, a written standard, a conformance report, a log sample — and the work is keeping that artefact current, not producing it once.
Start with the administrative account inventory. It is the prerequisite for the administrative accounts measure and for scoping MFA, it is the measure where gaps are most likely, and building it forces the estate inventory that the patching and security standards measures also depend on. Expect the first pass to find accounts nobody owns.
Then close out the rest with your own risk standard rather than a borrowed one. Once the six are evidenced, the remaining distance to the broader supervisory expectations is smaller than it looks — and if you already run an ISMS, MAS TRM against ISO 27001 sets out which of those controls you can reuse and where the genuine delta sits.
