Singapore’s updated Cybersecurity Code of Practice does not designate port and marine-service operators as critical infrastructure. What it does is push cyber obligations outward from CII owners to the systems and vendors connected to them. If your operations system exchanges data with a terminal operator, a port authority platform or another CII owner, that owner is now expected to know your system exists, to account for it in their risk framework, and to report incidents that start on your side. In practice, that means the questions a CII owner’s security team has been asking about their own systems will start arriving at yours.
What did CSA actually announce in July 2026?
CSA announced two documents: a revised CCoP for CII owners and a first CCoP for cloud services, both to be published in the second half of 2026. The update is the first revision since the 2022 edition and is framed around Advanced Persistent Threats and AI-enabled attacks that shorten the time between a vulnerability being discovered and exploited.
According to CSA’s 22 July 2026 press release, the revised Code requires CII owners to maintain a documented cyber resilience framework covering risk tolerance, mitigation, transfer and recovery, reviewed at least annually and owned at board level. It requires oversight of the interconnected systems that communicate with the CII, threat detection across network segments, comprehensive cybersecurity exercise plans, and stronger network management and monitoring. Guidance on adversarial simulation, penetration testing and threat hunting is to follow later in 2026.
The Cloud Services CCoP comes with Companion Guides developed with Amazon Web Services, Google Cloud and Microsoft Azure, explaining how to meet each control with the providers’ native services. For an operator considering moving an ageing on-premise system to cloud, that removes a long-standing ambiguity about what “compliant in cloud” means for a regulated counterparty.
Maritime is one of the eleven CII sectors under the Cybersecurity Act, alongside energy, water, banking, aviation, land transport and others. Which specific systems are designated CII is decided by the Commissioner of Cybersecurity and is not public. Most pilotage, towage, harbour craft and bunkering operators are not CII owners. The point of this post is that the Code now reaches them anyway, through three separate routes.
How does the Code reach a system that isn’t designated CII?
Through three mechanisms that were introduced separately and now stack: incident reporting for interconnected supplier systems, contractual flow-down to third-party providers, and Cyber Trust Mark certification of the CII owner’s non-CII systems.
1. Incident reporting for interconnected systems. The Cybersecurity (Amendment) Act 2024, with key provisions in force from 31 October 2025, widened what a CII owner must report. As law firm Herbert Smith Freehills Kramer summarised the amendments, CII owners must now report incidents affecting systems under their control even when disconnected from the CII, and incidents in external supplier systems interconnected with their CII. CSA’s own release adds that suspected APT-caused incidents and disruptions to essential services must be reported within two hours of the owner becoming aware. A CII owner cannot meet a two-hour reporting duty for a system it cannot see, which is why the Code now asks for visibility over interconnected systems.
2. Contractual flow-down. The same amendments keep the CII owner accountable when it uses third-party providers, and expect it to secure “legally binding commitments such as contracts” that hold those providers to comparable standards. In a port cluster where a marine-service operator’s dispatch, job-card or delivery-note system feeds a terminal or authority platform, that operator is the third party. Expect security schedules, right-to-audit clauses and patch commitments to appear in renewals that never had them.
3. Cyber Trust Mark Level 5 on non-CII systems. On 2 March 2026 CSA announced that CII owners must attain Cyber Trust Mark Level 5 — the highest of five tiers — for the non-CII systems supporting their business operations, by 31 December 2027. CII auditors face the same level by 31 December 2026. The Cyber Trust Mark spans 10 to 22 domains depending on tier, and its 2025 enhancement added cloud, operational technology and AI security. A CII owner certifying its wider estate to Level 5 will look hard at every data feed entering that estate, and at who maintains the system on the other end.
None of these routes makes a marine-service operator a regulated entity. Together they make its systems part of someone else’s regulated estate.
Why does this land on port and marine-service operators now?
Because Singapore’s port is more interconnected than it was at the last Code revision, and the regulator has moved from protecting designated systems to protecting the network around them.
The direction is visible in the port itself. During Safety@Sea Week in August 2026, the Maritime and Port Authority of Singapore (MPA) announced that its Integrated Port Operations Command, Control and Communications system (IPOC), built with the Defence Science and Technology Agency and ST Engineering, is now operational — bringing live data from multiple sources into one real-time view of port activity. Digital bunkering has been mandatory since April 2025, so every bunker delivery already produces an electronic record that leaves the supplier’s system. Pilotage bookings, towage jobs and harbour-craft movements increasingly flow through shared platforms rather than phone calls.
Every one of those links is a data path between an operator’s system and a platform run by an authority or a large terminal operator. The regulator’s logic follows the data: if a compromise on the small end can disrupt or deceive the large end, the large end has to account for it. That is what “visibility over interconnected systems” means in a working port.
A trade-off worth stating plainly: if your system exchanges nothing with a CII owner’s estate, and you are not designated, the direct legal obligations described here do not reach you. What still reaches you is the vendor questionnaire, because your customers and counterparties are working through the same list.
What will a CII owner’s security team actually ask about your system?
They will ask for evidence that the system is governed, not for a security product. In our experience of maintaining operational systems for port and marine-service clients, the questions concentrate on a small set of unglamorous points that a brownfield custom application often cannot answer well.
None of these requires new technology. All of them require the system to be understood and documented, which is exactly what a system three or more years old, built by a vendor who has moved on, tends to lack.
Is this a security problem or a maintenance problem?
For most operational systems in this segment it is a maintenance problem that shows up as a security finding. The security control exists; nobody has run it in years.
An unpatched framework is a patch cadence that lapsed when the original vendor’s contract ended. A shared login is an access review nobody owns. Missing recovery documentation is documentation that stopped being updated at go-live. When we take over a system under our maintenance model, the onboarding phase spends eight to ten weeks mapping how the system actually behaves and bringing its documentation current — the User Requirement Specification, technical design, installation and deployment guide, and test specifications — before steady-state maintenance starts. That documentation set is, almost line for line, what a counterparty’s security review asks to see.
This is also why ISO 27001 practice on the vendor side matters more than the certificate itself. Patch and upgrade governance, access control, versioned documentation and subcontractor controls are the working parts of an ISO 27001:2022 information security management system. When a CII owner asks a marine-service operator “how is this system maintained and by whom”, a vendor that already operates under those controls can answer with records rather than assurances. We wrote about that shift in why ISO 27001 has become a minimum requirement for a maritime software partner; the CCoP update turns it from a buyer preference into a counterparty expectation.
What should an operator do before the Code is published?
Establish, for each operational system, whether it connects to a CII owner’s estate, and whether you could answer the seven questions above with documents rather than memory. That is a few weeks of work, not a programme.
A practical sequence:
- List the systems and their connections. For each custom application in daily use, record every counterparty it exchanges data with. Anything touching a terminal operator, MPA platform or other likely CII owner goes to the top of the list.
- Check the platform versions. Frameworks, runtimes, databases and operating systems, against vendor support dates. End-of-support components are the fastest way to fail a review.
- Locate the source code and deployment knowledge. Confirm you hold the rights and the artefacts to rebuild the system without the original vendor. If you do not, that is the first thing to fix, because no security control compensates for it.
- Write down the recovery procedure and test it once. A documented, timed restore is worth more to a reviewer than a firewall diagram.
- Decide who maintains the system, on what terms. If the answer is “the person who built it, when reachable”, a counterparty will treat that as a finding.
The limit of this list is that it tells you where you stand; it does not close the gaps. Closing them is a maintenance engagement — patching, access clean-up, documentation, a change process — and it is easier to start before a customer’s security review sets the deadline.
Frequently asked questions
Does the Cybersecurity Code of Practice apply to companies that are not CII owners? Not directly. The CCoP binds designated CII owners. It reaches other organisations through the CII owner’s obligations: reporting incidents in interconnected supplier systems, holding third-party providers to comparable standards by contract, and certifying its non-CII systems to Cyber Trust Mark Level 5 by 31 December 2027.
When will the updated CCoP be published? CSA said on 22 July 2026 that the revised CCoP for CII and the new Cloud Services CCoP would be published in the second half of 2026, with technical guidance on adversarial simulation, penetration testing and threat hunting to follow later in the year.
What is Cyber Trust Mark Level 5? It is the highest of the five tiers of Singapore’s Cyber Trust Mark, CSA’s cybersecurity certification for organisations. Tiers cover 10 to 22 security domains; the 2025 revision added cloud, operational technology and AI security. Since March 2026, CII owners must reach Level 5 for the non-CII systems supporting their operations by end-2027.
What counts as an “interconnected system” under the amended Cybersecurity Act? A system that communicates with a designated CII — including systems owned by a supplier or partner. The 2024 amendments, in force since 31 October 2025, require CII owners to report incidents in such systems and to maintain oversight of them, which is why the updated CCoP asks for visibility beyond the CII boundary.
Is a maritime operator’s custom operations software likely to be designated CII? Designations are made by the Commissioner of Cybersecurity and are not published, so no general answer is possible. Most pilotage, towage, harbour craft and bunkering operators are not CII owners. Their exposure comes from connecting to CII owners’ systems, not from designation.
Can a legacy system meet these expectations without being replaced? Usually, yes. The typical gaps — lapsed patching, shared accounts, missing recovery documentation, single-vendor knowledge — are maintenance gaps. They are closed by bringing the system under a governed maintenance process, not by replacing the platform it runs on.
If one of your operational systems exchanges data with a terminal, a port platform or another counterparty likely to be working through this Code, the useful first step is to know what a reviewer would find. Our fixed-fee system health check reads one operational system for exactly these points — platform support status, access and audit controls, integration inventory, recovery documentation and vendor dependency — and hands you a written assessment and roadmap you own whatever you decide next. Request a system health check for your port or marine operations system.
Table of Contents
