← Back to blog

August 15, 2026 Cybersecurity & Compliance

Navigating the Expanded Scope of Singapore’s Cybersecurity (Amendment) Act: What CISOs Need to Audit First

The Cybersecurity (Amendment) Act 2024 widened who counts as critical information infrastructure in Singapore. Since key provisions commenced on 31 October 2025, an essential service provider can be held responsible for third-party-owned systems, overseas systems, and virtual systems it relies on but does not own. If your organization delivers or supports an essential service, the first task is not paperwork. It is finding out which systems could now be designated and whether they would survive the scrutiny that designation brings.

This guide explains what actually changed, who is newly in scope, and what to audit first, without requiring any specific product to act on. By the end, you will know which systems to map, which obligations attach once a system is designated, and how to sequence the checks before a regulator does it for you.

Table of Contents

Key Takeaways on the Cybersecurity (Amendment) Act

The points below summarize what changed and what it means for security leaders, before the detailed walkthrough.

The Act now reaches systems you rely on but do not own. A provider of an essential service can be designated as responsible for the cybersecurity of third-party-owned critical information infrastructure.
Location and form no longer shield a system. Overseas systems that support a Singapore essential service, and virtual systems, can now be designated.
Designation is system-specific, not company-wide. The Commissioner designates particular computers and systems, not entire firms or sectors, so the task is to know which of your systems qualify.
Designation brings real obligations. Once a system is CII, its owner faces codes of practice, audit and risk assessment duties, and incident reporting, including a two-hour notification window for certain incidents.
Some regimes are not yet in force. The provisions on entities of special cybersecurity interest and major foundational digital infrastructure were enacted but have not commenced, so do not plan around them as current law.
Testing is how you find out before the regulator does. The obligations are about demonstrable security, not policy documents, and an independent assessment of a newly-in-scope system is the fastest way to see where you stand.

What Changed When the Cybersecurity (Amendment) Act Commenced

The Cybersecurity (Amendment) Act 2024 was passed on 7 May 2024, and key provisions came into force on 31 October 2025. The amendments update the Cybersecurity Act 2018 to reflect how essential services are actually delivered now, through cloud, outsourcing, and cross-border infrastructure rather than only systems an operator owns and runs itself.

Three shifts matter most for security leaders. First, the definitions of “computer” and “computer system” were updated to include virtual computers and virtual systems, so a cloud-hosted system is no longer outside the frame simply because it is virtual. Second, a new regime regulates providers of essential services that rely on critical information infrastructure owned by a third party. Third, the Commissioner of Cybersecurity gained the power to designate systems located overseas where they support an essential service in Singapore. Alongside these, the commencement introduced time-limited designation for systems of temporary cybersecurity concern and monitoring powers over licensed cybersecurity service providers.

The throughline is accountability catching up with architecture. When the original Act was written, an essential service provider generally owned its critical systems. That assumption no longer holds, and the amendments close the gap between who delivers an essential service and who is answerable for the security of the systems behind it. For a security leader, the mental model shifts from “do we own a designated system” to “do we depend on any system, wherever it lives and whoever owns it, that keeps an essential service running.”

The 11 CII Sectors and How a System Actually Gets Designated

Before working out your exposure, it helps to know where the Act looks and how designation actually happens, because a common misconception is that being in a critical sector automatically makes a company a CII owner. It does not.

The Cyber Security Agency of Singapore has worked with sector leads to identify critical information infrastructure across 11 critical sectors: energy, water, banking and finance, healthcare, land transport, maritime, aviation, government, infocomm, media, and security and emergency services. The essential services within these sectors are listed in the First Schedule of the Act.

The important nuance is what gets designated. CII refers to specific computers and computer systems explicitly designated by the Commissioner of Cybersecurity, not whole firms and not whole sectors. A bank is not “a CII.” Particular systems a bank runs, the ones directly involved in delivering an essential service, can be designated as CII, and the obligations attach to those systems and their owner. This is why the audit task is granular: you are not asking “are we in a critical sector,” you are asking “which of our specific systems, and which systems we depend on, meet the designation criteria.”

The Amendment Act widens the pool of systems that can be pulled into that designation, but the mechanism is unchanged. The Commissioner designates a system when satisfied it is necessary for the continuous delivery of an essential service and its loss or compromise would have a debilitating effect. What the 2024 amendments change is that the system no longer has to be owned by the provider, located in Singapore, or physical.

Third Party Owned CII: The Biggest Shift for Essential Service Providers

The most consequential change is the new framework for third-party-owned critical information infrastructure, often shortened to third-party-owned CII. Previously the Act focused on systems owned and operated by the essential service provider. The amendments recognize that essential services now frequently run on infrastructure owned by someone else, typically a large IT, software, or cloud provider.

Under the new regime, the Commissioner can designate the essential service provider, rather than the third-party owner, as responsible for the cybersecurity of a third-party-owned system used to deliver an essential service. This is the point security and legal teams most often miss: the responsibility does not sit with the vendor that owns the box. It sits with the provider that depends on it. Reliance on a third party’s system does not outsource the accountability.

Once designated, the essential service provider must obtain legally binding commitments from the third-party owner. Reported obligations include that the owner will provide information on the design, configuration, security, and operation of the system on request, maintain any prescribed technical or other cybersecurity standards, and notify the provider of material changes affecting the system. In practice this pushes specific security assurances into the contract between the essential service provider and its vendors, and it means the provider needs a way to verify those assurances rather than take them on trust. Enforcement has teeth: where commitments are not obtained or standards are not maintained without reasonable excuse, the Commissioner may order the provider to stop using the system.

There is a contractual reality underneath this that deserves attention. Many essential service providers procure critical systems through group-wide or overseas purchasing arrangements, where the Singapore entity has limited leverage to insert bespoke security clauses. The Amendment Act effectively requires that leverage to exist. If your standard vendor contract does not already grant a right to security information, a commitment to maintain standards, and a duty to notify material change, that contract is now a compliance gap as much as a commercial document. Reviewing critical-vendor agreements against these three commitments is one of the highest-value early actions available.

For a CISO, the practical consequence is a new question to ask of every critical dependency: if a system we rely on but do not own were designated tomorrow, could we produce the design and security information, the contractual commitments, and the evidence of maintained standards that the Act expects? If the honest answer is no, that gap is the work.

Overseas and Virtual Systems Now Within Scope

Two related expansions close the routes by which a critical system used to fall outside the Act.

The first is virtual systems. Because “computer” and “computer system” now include virtual computers and virtual systems, a workload does not escape designation simply because it is virtualized or cloud-hosted. The amendments also clarify that the owner of a virtual CII is responsible for its cybersecurity, not the third-party vendor supplying the underlying physical infrastructure. That distinction matters in a shared-responsibility cloud arrangement, where it is easy to assume the cloud provider carries obligations that in fact sit with you. Under the amended Act, running your critical system on someone else’s hardware does not move the accountability for that system onto them.

The second is location. The Commissioner can designate a system located wholly outside Singapore as CII where its owner is in Singapore and the system would have qualified for designation had it been located here. For multinational groups that run regional or global platforms from outside Singapore to support a Singapore essential service, this is a meaningful reach. A system being hosted abroad is no longer, on its own, a reason it sits beyond the Act.

Together these changes mean the map of what could be designated is wider than many teams assume. The systems to worry about are not only the ones in a Singapore data center under your direct control. They include the cloud workloads, the overseas regional platforms, and the vendor-run systems that keep an essential service running. A useful exercise is to take your existing critical-systems inventory and ask, for each entry, whether it would have been considered out of scope under the old ownership-and-location assumptions. Every “yes” is a candidate the amendments may now have pulled in.

Systems of Temporary Cybersecurity Concern

The amendments also introduced a regime for systems of temporary cybersecurity concern, or STCC. These are systems that warrant time-limited regulatory attention even though they are not permanent critical information infrastructure. A useful way to think about it is a system that becomes critical for a defined period or under specific circumstances, where a compromise during that window would be seriously disruptive. A system supporting a major national event, a temporary platform standing in during a migration, or infrastructure spun up to handle a specific high-stakes situation could all fall into this category.

The Commissioner can require information about such systems and can apply obligations similar in spirit to CII duties for the period of designation. For security leaders, the takeaway is that “we are not a designated CII owner” is no longer a complete answer. A system can attract regulatory duties temporarily, so the exercise of knowing your critical systems and being able to speak to their security has value even for organizations that hold no standing CII designation. The organizations most likely to be caught unprepared are those that treat compliance as a fixed annual state rather than an ongoing capability to account for whatever systems become critical.

What Being a CII Owner Actually Obliges You To Do

Understanding the obligations that attach on designation is what makes the audit-first argument concrete, because every obligation below is something a regulator can ask you to evidence.

Once a system is designated as CII, its owner is subject to the framework the Act and its codes of practice set out. In broad terms this includes complying with the applicable codes of practice and standards of performance, conducting regular cybersecurity audits, carrying out cybersecurity risk assessments, reporting prescribed incidents, and participating in national cybersecurity exercises. The Cybersecurity Code of Practice for Critical Information Infrastructure, currently in its second edition, sets the minimum measures a CII owner is expected to implement, and it is explicit that owners should go beyond the minimum where their risk profile warrants it.

Two obligations deserve particular emphasis for a newly-in-scope operator. The first is auditing. CII owners are required to undergo regular cybersecurity audits, and the Act sets expectations for who may conduct them and how. A system that has never been assessed against these expectations is unlikely to sail through its first one. The second is incident reporting. CII owners must report prescribed incidents to the Cyber Security Agency within tight timeframes, and reporting expectations have been tightened to include suspected advanced persistent threat activity, reflecting the kind of state-linked intrusions Singapore has faced. A two-hour notification expectation applies for certain incidents, which is not a timeframe you can meet with a process you have never rehearsed.

The practical reading is that designation converts assumptions into obligations. Whatever security you believe a system has, designation requires you to demonstrate it, audit it, and stand ready to report when it fails. That is precisely why testing a candidate system before designation, rather than after, is the difference between finding your gaps privately and having them found for you.

What is Not Yet in Force?

It is as important to know the limits of the current commencement as its reach. Certain significant parts of the 2024 Amendment Act were enacted but were not part of the 31 October 2025 commencement, and planning around them as if they were current law would be a mistake.

Two in particular are pending. The provisions relating to entities of special cybersecurity interest, and those relating to major foundational digital infrastructure service providers, have been enacted but left for staged commencement at a later date. The foundational digital infrastructure regime is aimed at entities that large numbers of Singapore businesses depend on for operational needs, and the special cybersecurity interest regime targets systems whose compromise could harm national interests even where they do not fit the traditional CII definition. Both are significant, and both are coming, but neither is a live obligation today.

Scoping your current compliance work to the regimes actually in force, third-party-owned CII, overseas and virtual CII, and systems of temporary cybersecurity concern, keeps the effort proportionate and honest. Track the pending regimes so you are not surprised when they commence, but do not divert scarce security effort into obligations that are not yet law at the expense of the ones that are.

The 2026 Developments Raising the Urgency

The scope changes are the durable part of this story, but they are not the only reason the topic is live in 2026. The wider context is a marked increase in serious, state-linked threats to Singapore’s critical systems, and a regulator responding by raising expectations.

Singapore has been explicit that its critical infrastructure is an active target. The disclosure of state-linked cyber-espionage activity attributed to the group UNC3886 brought this into public view, and officials have noted that advanced persistent threat targeting of Singapore’s critical systems rose sharply in recent years. The response has been a tightening of expectations: newly introduced requirements around reporting suspected advanced persistent threat activity, and a broader signal that critical systems must be able to withstand realistic, sophisticated attacks rather than only satisfy documentation.

Publicly, the direction of travel points toward adversarial testing, attack simulation, and threat hunting becoming expected practices for critical systems rather than optional extras. The exact instruments, editions, and dates are worth confirming against the Cyber Security Agency of Singapore’s own publications before you rely on them, and the strategic picture is clear enough to act on now. The bar for what a designated system must demonstrate is rising at the same moment the Amendment Act has widened what can be designated.

For a security leader, the combination is what matters. A system that is newly in scope and has never been independently tested is exposed on both fronts at once: it may be pulled into designation it was not built to withstand, and the standard it will be judged against is tightening. That is the case for auditing now rather than waiting for a designation letter to force the issue.

What CISOs Should Audit First?

With the scope wider and the bar rising, the sequencing of the work matters more than its length. The following order front-loads the checks that most reduce uncertainty.

Map your essential-service dependencies, including what you do not own. List the systems your organization relies on to deliver or support an essential service, and mark which ones you own, which are third-party-owned, which are virtual or cloud-hosted, and which are located overseas. This map is the foundation, because you cannot assess exposure you have not listed. Include the supply-chain connections that put you in the risk perimeter even if you are not a CII operator yourself, such as serving government or regulated-sector clients or sharing platforms with essential service providers.

Flag the designation candidates. Against that map, identify the systems that could plausibly be designated: third-party-owned systems necessary to an essential service, overseas systems owned by a Singapore entity that would qualify onshore, and virtual systems that were previously assumed out of scope. These are where the new regime bites first.

Check your contractual position on third-party systems. For each third-party-owned candidate, establish whether you could obtain the commitments the Act expects: information on request, maintenance of prescribed standards, and notification of material changes. A dependency where you have no contractual right to security information is a gap you want to find before a regulator does. Where group-wide or overseas procurement has left the Singapore entity without that leverage, flag it as a priority for renegotiation.

Test the candidates, do not just document them. For the systems most likely to be designated, commission an independent assessment that shows whether the security is real, not merely described. Designation brings audit and risk assessment obligations, and a system that has never been tested against a realistic attacker is the one most likely to produce an unwelcome surprise. Scope the test to include the seams between you and your vendors, since those are exactly what the amendments newly reach.

Build the incident-reporting muscle. Confirm you can detect and report a qualifying incident within the required window, including the two-hour notification expectation for certain incidents and the tightened expectations around suspected advanced persistent threat activity. Rehearse it, because a reporting obligation you have never exercised is a reporting obligation you will miss under pressure.

The Scope-to-Action Map for Newly-in-scope Systems

The table below turns the expanded scope into concrete checks. It maps each newly-in-scope category to the question a security leader should ask and the evidence that answers it.

Newly-in-scope category	The question to ask	The evidence that answers it
Third-party-owned CII	Can we obtain and evidence the Act’s required commitments from the owner?	Contract clauses granting information on request, standards maintenance, and change notification
Overseas systems supporting a Singapore service	Would this system qualify as CII if it were onshore, and who owns it?	Ownership mapping, an assessment of the system against designation criteria
Virtual and cloud-hosted systems	Have we correctly split responsibility between us and the infrastructure provider?	A documented shared-responsibility model, tested against the actual configuration
Systems of temporary cybersecurity concern	Could a normally-secondary system become critical for a period, and can we speak to its security?	An inventory that flags time-sensitive critical systems, with security posture recorded
Any designation candidate	Would this system survive the audit and scrutiny designation brings?	A recent independent penetration test with findings closed or risk-accepted

None of these artifacts is exotic. The difficulty is that they must be current, they must match the live systems, and for third-party dependencies they must be backed by a contractual right to the underlying information. That combination is what a regulator, or an incident, will test.

A second table is worth keeping beside the first: the obligations that attach to designation and what each one demands in practice.

Obligation on designation	What it demands in practice
Comply with the applicable code of practice	Implement at least the minimum measures in the Cybersecurity Code of Practice for CII, and more where risk warrants
Regular cybersecurity audit	Undergo periodic audits against the Act’s expectations, conducted by appropriately qualified assessors
Cybersecurity risk assessment	Assess and document the system’s risk profile on a defined cadence
Incident reporting	Report prescribed incidents within required timeframes, including a two-hour expectation for certain incidents and reporting of suspected APT activity
Participation in exercises	Take part in national cybersecurity exercises when called

Penetration Testing and Independent Assessment Expectations

Documentation shows intent. Testing shows outcome. Once a system is designated as critical information infrastructure, its owner faces codes of practice, audit, and risk assessment obligations, and the direction of Singapore’s 2026 guidance points toward realistic adversarial testing as part of meeting them. For a newly in-scope system, an independent penetration test is the fastest way to convert an assumption of security into evidence of it.

Scope matters as much as frequency. A test aimed only at a web front end tells you little about whether a third-party-owned platform, an overseas regional system, or a virtualized workload would withstand a determined attacker who moves laterally, abuses trust between components, and targets the seams between you and your vendors. The systems the Amendment Act newly reaches are often exactly those seams, so the assessment has to be scoped to include them. This is also the pattern behind real-world supply-chain intrusions, where an attacker finds a weaker connected system and works inward rather than attacking the hardened target head-on.

A sequencing point worth keeping: map and tidy first, then test. Testing a system after you have reconciled its ownership, its configuration, and its contractual position gives you findings that matter, rather than a report that restates what a basic review would have caught. The report then becomes part of the evidence a designation audit expects, and reviewers give more weight to a report carrying a named, accountable assessor than to an anonymous tool output.

Choosing that assessor is its own decision, and the questions worth asking a prospective firm are covered in our guide to what to know before choosing a penetration testing vendor. For how independent testing fits a broader compliance program, see SOC 2 Penetration Testing: What You Should Expect Before an Audit. It is also fair to ask whether a prospective firm holds the assurances it recommends to others; CredShields completed its own SOC 2 Type II audit for that reason.

Related read: What MAS Auditors Look for in Your Identity and Access Architecture, which covers how a Singapore regulator treats third-party and vendor access in a neighbouring framework, useful for banking and finance sector operators subject to both.

Frequently asked questions about the Cybersecurity (Amendment) Act

What changed under the Cybersecurity (Amendment) Act in Singapore?

Key provisions that commenced on 31 October 2025 expanded the operational scope of the Cybersecurity Act 2018. The main changes bring third-party-owned critical information infrastructure into scope, allow designation of overseas systems that support a Singapore essential service, treat virtual systems the same as physical ones, and introduce a regime for systems of temporary cybersecurity concern.

Who is responsible for third-party-owned CII?

The essential service provider that relies on the system, not the third-party owner, can be designated as responsible for its cybersecurity. The provider must then obtain legally binding commitments from the owner covering information on request, maintenance of prescribed standards, and notification of material changes. Responsibility for the essential service cannot be outsourced along with the infrastructure.

Which sectors does the Cybersecurity Act cover?

The Act covers 11 critical sectors: energy, water, banking and finance, healthcare, land transport, maritime, aviation, government, infocomm, media, and security and emergency services. Being in one of these sectors does not by itself make a company a CII owner. The Commissioner designates specific systems, not whole firms or sectors.

Does the Cybersecurity Act apply to systems hosted overseas?

It can. The Commissioner of Cybersecurity may designate a system located wholly outside Singapore as critical information infrastructure if its owner is in Singapore and the system would have qualified for designation had it been located in Singapore.

What is a system of temporary cybersecurity concern?

It is a system that warrants time-limited regulatory attention because a compromise during a defined period would be seriously disruptive, even though the system is not permanent critical information infrastructure. During designation, obligations similar in spirit to CII duties can apply.

Are all the 2024 amendments now in force?

No. The provisions relating to entities of special cybersecurity interest and to major foundational digital infrastructure service providers were enacted but were not part of the 31 October 2025 commencement, and remain pending staged commencement. Compliance work should focus on the regimes actually in force.

What obligations does a CII owner have?

A CII owner must comply with the applicable code of practice, undergo regular cybersecurity audits, conduct risk assessments, report prescribed incidents within required timeframes, and participate in national cybersecurity exercises. Incident reporting includes a two-hour notification expectation for certain incidents.

What should a CISO audit first under the expanded Act?

Start by mapping every system your organization relies on to deliver an essential service, including those you do not own, that are virtual, or that sit overseas. Flag the ones that could be designated, check whether you could obtain the contractual commitments the Act expects for third-party systems, and commission an independent penetration test of the highest-priority candidates so you have evidence of security rather than only documentation.