Most incident response plans were built for a slower world. They assume a team has time to investigate, confirm what happened, write it up, and then report, often within a comfortable window of days. Singapore just made that assumption dangerous for the organisations that run its most important systems.
Quick answer: Under Singapore’s updated Cybersecurity Act, owners of Critical Information Infrastructure (CII) must report certain serious cybersecurity incidents within 2 hours of becoming aware of them, followed by a fuller supplementary report within 72 hours. This applies to all designated CII sectors, including energy, banking, healthcare, and transport.
If you own Critical Information Infrastructure (CII) in Singapore, you now have 2 hours to report certain incidents, not 72 hours. For a playbook built around a relaxed timeline, that’s not a small adjustment. It’s a different way of operating. This guide explains what CII Singapore is, what changed, why the old playbook breaks under the new rule, and how to rebuild it so a two-hour clock becomes a process you can actually meet.
What Is CII Singapore?
Critical information infrastructure Singapore refers to the computer systems necessary for delivering an essential service in the country, where a disruption would seriously harm the economy, society, or national security.
A cyberattack that takes down an online shop is a problem for that shop. A cyberattack that takes down a power grid or a banking network is a problem for everyone. So the law treats the second kind of system differently, holding the organisations that run them to a higher standard.
According to the Cyber Security Agency of Singapore, the Cybersecurity Act Singapore provides the framework for designating these systems as CII and gives their owners clear legal duties to protect them.
Those duties cover the CII sectors: energy, water, banking and finance, healthcare, transport, info-communications, media, security and emergency services, and government. If a system is designated as CII Singapore, its owner takes on specific obligations, and one of the most demanding is incident reporting.
Who does this apply to? Any organisation designated by CSA as a CII owner in Singapore falls under these obligations, regardless of whether the organisation is a government agency, a listed company, or a private operator running essential services infrastructure.
What Changed, From 72 Hours to 2
Here’s the part that reshapes how response teams have to work.
Under the updated Singapore Cybersecurity Act, the Cyber Security Agency of Singapore requires CII Singapore owners to report certain incidents within two hours of becoming aware of them.
The 72-hour window hasn’t disappeared. Instead, the law now sets two deadlines, as laid out in the CSA’s reporting forms:
- Within 2 hours, an initial alert to the regulator that something serious may be happening.
- Within 72 hours, a fuller supplementary report with the details.
So the deadline most teams built their playbook around, 72 hours, is now just the deadline for the follow-up. The clock for the first alert has shrunk to two hours.
What sets that clock ticking matters too. It applies to the most serious cases.
- Incidents suspected to be caused by Advanced Persistent Threats (APTs).
- Incidents affecting other systems under the owner’s control, or their suppliers’ systems, that connect to the CII.
In short, the rule targets sophisticated, stealthy attacks and the supply-chain and lateral-movement routes attackers use to reach critical systems, often starting with a single compromised employee login.
This change didn’t happen in a vacuum. In mid-2025, Singapore confirmed it was fighting an APT group known as UNC3886 targeting its critical infrastructure.
Announcing the tighter rules, Minister for Digital Development and Information Josephine Teo warned that the threats facing CII owners were no longer simple ransomware, and that APTs had critical infrastructure in their sights. Her advice was blunt: assume breach, and don’t confront these attackers alone.
The two-hour clock follows from this. APTs hide quietly, often for months, so the sooner the national coordinator hears about a suspected attack, the sooner the country can respond before it spreads.
Also Read: Account Security in 2026: Why Attackers No Longer Need to Break In
Why the Old Playbook Can’t Keep Up
An incident response playbook built for 72 hours isn’t just a faster version of the right process. It’s often the wrong shape entirely. Here’s where it tends to fail under the new clock.
1. Investigation becomes a bottleneck
The old approach usually says to investigate first, confirm what happened, then report. Under a two-hour rule, there isn’t time to fully confirm anything. The new rule deliberately asks for reports of suspected incidents, not confirmed ones. A playbook that waits for certainty will blow the deadline every time.
2. Approval chains are too slow
Many response plans route the decision to report up through several layers of management for sign-off. That’s fine over three days. Over two hours, especially during a night or weekend, a chain that depends on reaching three busy executives is a chain that fails. The authority to report has to be decided in advance, not assembled in the moment.
3. Detection isn’t fast enough
You can’t report within two hours of becoming aware if you don’t become aware for a day. The whole timeline depends on detecting the incident quickly in the first place. Many organisations have monitoring gaps, particularly across the interconnected and supplier systems the new rule specifically covers, that mean they’d learn about an intrusion far too late for the clock to even start on time.
4. Nobody knows who does what
When the deadline was generous, ambiguity about roles was survivable. Under a two-hour clock, any confusion over who confirms, who decides, and who actually files the report is fatal. The playbook has to assign these roles by name, ahead of time.
How to Build a Playbook That Hits 2 Hours
Meeting a two-hour deadline is an operational design problem, not a paperwork one. Here’s how to build a cybersecurity incident response playbook that can actually hit it.
1. Pre-authorise the decision to report
The single most important change. Decide now, in writing, who has the authority to notify CSA, and empower them to do it without hunting for executive sign-off. Define clear, simple criteria for what crosses the threshold, so the on-call person can make the call with confidence at 3am. The goal is to remove every avoidable second between suspicion and notification.
2. Write a two-hour runbook with named roles
Build a dedicated, step-by-step runbook for the two-hour scenario, separate from your slower full-investigation process. It should name exactly who does what. Who confirms the suspicion is credible, who prepares the notification, who makes the call to CSA, and who takes over the deeper investigation in parallel. Print it. Everyone on the rotation should know their part without reading it twice.
3. Prepare the notification in advance
Don’t draft the report from scratch under pressure. Build a template that maps to exactly what CSA asks for in its reporting form, so that filling it in during an incident is a matter of dropping in the specifics, not composing from a blank page. Know the phone number and the form before you ever need them.
4. Close the detection gap
The clock starts at awareness, so faster awareness is everything. This means continuous monitoring that covers not just your core systems but the interconnected and supplier systems the rule now includes.
The way attackers reach CII Singapore systems is usually by moving sideways from a less-protected one, the same lateral-movement path that lets an office breach reach operational technology. Watching those connections is how you spot trouble while there’s still time to report it.
5. Rehearse against the clock
A playbook you’ve never tested is a guess. Run timed drills where the team practises going from “suspicious signal” to “CSA notified” inside two hours. These rehearsals expose the real bottlenecks, the slow approval, the missing phone number, the unclear role, while it’s still just practice. The teams that meet the deadline in a real incident are the ones that have already met it in a drill.
6. Build the supplementary report process too
The two-hour alert is only the first step; the 72-hour supplementary report still has to follow. Make sure your deeper investigation feeds cleanly into that second report, so the fuller picture is ready on time without a second scramble.
Turning a Deadline Into Readiness
The two-hour rule sounds punishing, and for an unprepared organisation, it is. But the deadline isn’t really the challenge. It’s a test of whether your detection, decisions, and cybersecurity incident response work under pressure, or only look good on paper.
In short: a CII Singapore owner that can detect a suspected APT quickly, trigger a pre-authorised reporting decision, and notify CSA within two hours is simply demonstrating a well-built security operation, one that satisfies both the letter and the spirit of the Cybersecurity Act Singapore.
This matters even beyond CII. Tight reporting windows are becoming the regional norm: Indonesia already sets a 72-hour breach-notification clock, and the trend is toward shorter. A playbook ready for two hours is ready for whatever comes next.
Readiness comes down to two hard things, noticing the incident fast enough and responding without hesitation. That’s what Zentara builds. Our Managed SOC monitors your core and supplier systems so the clock starts when the attack begins, not a day later, and we help you build and rehearse the two-hour playbook itself.
Talk to our specialists to see how fast you’d really detect and report an incident today.
