MAS incident notification works like this: a financial institution regulated by the Monetary Authority of Singapore must notify MAS of a relevant incident within 1 hour of discovering it, and must then submit a root cause and impact analysis report within 14 days. The 1 hour notification is a legally binding obligation, not a guideline, and the clock starts at discovery rather than at the point you understand what happened.
That single design choice is what makes this requirement different from almost every other incident process you have built. Most of those are organised around investigation: detect, triage, analyse, classify, then tell people. An hour does not accommodate that sequence. You will be notifying the regulator while the bridge call is still arguing about which service is degraded.
The Two MAS Incident Notification Obligations
There are two MAS incident notification obligations, and they serve different purposes: the first is a fast alert, the second is the full account.
| Obligation | To whom | Within | Containing |
|---|---|---|---|
| Notification of a relevant incident | MAS | 1 hour of discovery of the incident | Notice that a relevant incident has occurred, on the basis of what is known at the time |
| Root cause and impact analysis report | MAS | 14 days of the incident | The institution's analysis of root cause and of the impact on operations and on customers |
Reading them as a pair resolves most of the anxiety teams feel about the first one. The hour is not asking you to explain the incident; it exists so the regulator learns about a severe disruption in the Singapore financial system at the same time the institution does. The explanation belongs in the 14-day report. Teams that conflate the two do both badly.
What Counts as a Relevant Incident
A relevant incident, for MAS notification purposes, is a system malfunction or IT security incident with a severe and widespread impact on the institution's operations, or which materially impacts its service to customers. Those are the two gates, and either one is sufficient.
Read the second gate carefully, because it is the one most teams underweight. An incident can leave internal operations largely intact and still materially affect what customers can do — payments not settling, a mobile app unable to authenticate, a card authorisation path failing for one issuer range. Severity to the institution and materiality to the customer are separate tests.
Note also what the definition does not say. It says nothing about confirmed data loss, identified root cause, or a scoped blast radius. And a system malfunction qualifies on the same footing as a security incident, so a botched change or a storage failure can be notifiable even though nobody attacked you.
MAS does not publish a severity matrix that mechanically converts your internal P1 into a relevant incident. The judgement is the institution's to make against that wording, and to explain afterwards.
Making the Judgement Call Without a Committee
An hour does not allow for a committee, so the judgement call has to be made by one person against a written test they have already read. The work is to push the judgement out of the moment and into preparation. Three things do that.
Pre-mapped services. Decide in advance which systems, if they malfunction, materially affect service to customers — the payment rails, the authentication path, the core ledger, the customer channels. Keep the list with the on-call runbook, so that when one is down the person on call is checking a list rather than reasoning about materiality from first principles at 2am.
A bias stated in advance. Agree, at board or senior management level, that where the call is genuinely ambiguous the institution notifies. Then the on-call decision-maker is not personally carrying the risk of a notification that turns out to be unnecessary. Without that stated bias, the default behaviour under uncertainty is to wait for more information, and waiting is the one thing the hour forbids.
A short set of questions, not a scoring model. Is a customer-facing service unavailable or materially degraded right now? Is a core operational system malfunctioning in a way we cannot restore within minutes? Do we have indications of an IT security incident touching production? Any yes, and you notify while the investigation continues.
Then document the reasoning as you make the call, even if it is three lines in the incident channel. Defensibility rests on the record of how the call was made, and that record cannot be reconstructed a week later.
Want your 1-hour MAS notification path stress-tested?
Share your work email and we'll walk your on-call escalation against the relevant-incident definition and mark where the hour would actually be lost.
Who Is Authorised to Notify at 3am
Someone must be authorised to notify MAS at 3am without waking a committee first, and that authority has to exist in writing before the incident. This is the control that most often fails in a real event, and it fails quietly: the institution knew the clock and still missed the hour because nobody present believed they were allowed to send it.
Name a standing role, not a person. "The duty incident commander" works; "the CISO" does not, because the CISO sleeps, travels and takes leave. Record the senior management sign-off in the incident management policy so the authority is not re-litigated during the event. Then remove the single points of failure in the path:
- More than one person holds the credentials and the knowledge. If one named individual is the only person who has ever submitted a notification to MAS, you have a dependency on their phone being charged. A rota never exercised at 2am on a Sunday is an assumption, not a control.
- Escalation does not depend on one channel. If the notification path runs through a system the incident could itself affect, it is not a path. Keep an offline copy of the procedure and the contact details.
- Vendors are in the chain. If a provider detects the problem first, your contract must get that signal to your duty commander in minutes — which is why notification clauses sit alongside audit rights in MAS outsourcing expectations.
What You Can Realistically Say in an Hour
Within an hour you can realistically say that an incident has occurred, roughly what is affected, when you discovered it, and that the investigation is underway. That is a legitimate notification. Notifying early with partial information is the design intent of the obligation, not a failure to meet it.
What you will not have, and should not pretend to have, is root cause, confirmed scope, a customer impact count or a restoration time. Write the notification so the provisional facts are clearly provisional. "Authentication for the mobile channel has been unavailable since 02:14 SGT; cause unknown; investigation in progress" is accurate and useful. A guess dressed as a finding is worse, because you will have to retract it in the 14-day report.
Keep a short internal template — time of discovery, affected service, observed effect, current status, contact — so nobody drafts from scratch under pressure.
The Root Cause Analysis Report Due at 14 Days
MAS requires a root cause and impact analysis report within 14 days, and that report is where the full account of the incident belongs. The notification bought you time; the report spends it.
Fourteen days is comfortable only if the material is captured as the incident runs. If evidence collection starts after restoration, you will spend the first week reconstructing a timeline from chat scrollback. Have the incident commander preserve logs, capture decision points with timestamps, and record what was known at each escalation — then the report is an edit, not an investigation.
The two halves are different work. Root cause is engineering: what failed, why it propagated, why detection took as long as it did, and what change prevents recurrence. Impact analysis is business: which customers were affected and how, what transactions were delayed or lost, what was restored and when. Teams routinely deliver a strong root cause section and a thin impact one, because that data lives in operations rather than engineering. Assign both halves on day one, and write the remediation commitments as commitments you will keep — MAS can ask about them later. The reporting pipeline is worth checking off on a MAS TRM compliance checklist.
Detection, Discovery and Where the Hour Disappears
The clock runs from discovery, and the gap between detection and discovery is where most of the hour is lost. Your monitoring may have fired an alert at 02:14; if a human recognised what it meant at 03:40, you have already spent the hour on triage you did not budget for. That makes monitoring quality a direct input to a regulatory obligation rather than an engineering preference. Specifically:
- Alerting on customer-visible symptoms, not only on infrastructure. A queue depth alert tells you something is wrong. A "mobile login success rate has dropped below threshold" alert tells you a customer-facing service is materially degraded, which is the language the definition uses.
- Correlation, so twelve alerts become one incident. An alert storm delays recognition, and the duty commander cannot judge materiality against a wall of noise.
- Coverage of the pre-mapped services. If a system on that list has no synthetic check, your discovery mechanism for it is a customer complaint.
Institutions already running a disciplined incident process for other frameworks have a head start — the structure in an ISO 27001 incident response plan or a SOC 2 incident response plan is compatible, it simply has to be re-timed around a clock that starts before analysis.
Why MAS Notice 644 No Longer Applies
A great deal of online guidance still cites MAS Notice 644 as the current source of these obligations, and it is worth saying plainly: it is not. Notice 644 on technology risk management, issued on 21 June 2013, was cancelled with effect from 10 May 2024. The framework now sits under the restructured notice on technology risk management, referenced as FSM-N05.
The substance of the obligations carried across; what changed is the reference. If your incident management policy, your runbook, your board paper or your vendor contracts cite Notice 644, they are citing a cancelled instrument — the kind of detail a supervisor notices and an auditor flags. The renumbering also touched the Notice on Cyber Hygiene, which teams now encounter as FSM-N06 alongside its original number; see MAS Notice 655 on cyber hygiene.
Check your references against the regulator's own publications at the Monetary Authority of Singapore rather than against a blog post, including this one. The 2024 restructuring made much of the third-party corpus wrong in its citations.
When Other Breach Clocks Run in Parallel
A single incident can engage several notification obligations at once, on entirely different clocks and owed to entirely different recipients. The MAS 1 hour clock is the tightest you are likely to face, but it is not the only one. An institution handling Indian personal data may owe breach intimation under India's DPDP Act in addition to its MAS obligation, on a different timeframe and in a different form — see DPDP breach notification duties for that regime's own requirements. Contractual commitments to enterprise customers, obligations to other jurisdictions' regulators, and card-scheme reporting may all trigger from the same event.
Build the map before the incident: one sheet listing each obligation, its trigger, its deadline, its recipient and its owner. What you are protecting against is the predictable failure mode — the team satisfies the loudest clock and quietly misses one nobody in the room owned.
MAS Incident Notification Questions Teams Ask
These are the MAS incident notification questions teams ask most often once they realise the hour starts before the investigation does.
At discovery of the incident, not at detection by a monitoring system and not when you understand the cause. In practice that means the moment a human in your institution recognises that a relevant incident has occurred. Log that timestamp immediately: it defines the deadline and it is the first fact you will be asked to evidence.
Notifying on the information available and then correcting the picture in the 14-day report is consistent with how the obligation is designed, since it requires notification before investigation has produced answers. The greater exposure sits the other way: delaying while you gather certainty and breaching a binding deadline. Agree the bias toward notifying in advance, at senior management level.
If it is a system malfunction or IT security incident with severe and widespread impact on your operations, or which materially impacts your service to customers, the test is met regardless of whose infrastructure failed — the institution remains accountable for technology risk in outsourced arrangements. The practical requirement is contractual: the provider must notify you fast enough that you can still meet your own clock.
The binding obligation comes from the notice, not the Guidelines. The TRM Guidelines set the expected standard for incident management and MAS takes the degree of observance into account in its supervisory assessment, but they are not law in themselves. The notification deadlines are a legal obligation under the notice — which is why the distinction between a notice and guidelines matters more here than almost anywhere else in the MAS framework.
Make the first hour of an incident a procedure, not a scramble
Book a demo and we'll show how Konfirmity tracks incident timelines, pre-authorised escalation and the evidence your 14-day root cause report will need.
Book a demo
Rehearse the First Hour Before You Need It
The first hour is survivable, but only if the decision, the authority and the path were settled beforehand. Nothing here is hard in the abstract. It is hard at 2am, with partial telemetry, when the person who knows how to submit the notification is asleep and nobody else is sure they are allowed to.
So rehearse it specifically. Not a tabletop about containment strategy — a timed drill that starts with an unannounced alert out of hours and ends when someone authorised has a draft notification ready. That elapsed time is the most useful metric you will get all year.
Then fix what the drill exposed, in this order: who may decide, how they are reached, and what they are given to decide with. Update the policy to cite the restructured notice rather than the cancelled Notice 644 while you are there. For where incident reporting sits among the other domains MAS expects you to cover, start with the MAS TRM Guidelines explained.
