Securing healthcare starts with a conversation

This story is part of GovInsider's Digital Trust & Cybersecurity Champions 2026 Special Report.

An IT team cannot secure an artificial intelligence (AI) tool it does not know its clinicians are using.

But finding out what people are trying depends, in part, on whether they feel comfortable asking for help. 

For Wilfred Soon, Group Chief Information Officer at Singapore's NHG Health, this makes the relationship between clinicians and technology teams part of the organisation's cybersecurity work. 

Staff who want to experiment should feel able to approach IT, he says. 

"You help them do it, rather than obstruct them, and people will start letting you know what they are doing," Soon tells GovInsider. 

He oversees NHG Health's digital strategy and enterprise architecture, supporting the technology used across its hospitals, primary care, and community services. 

Helping clinicians experiment safely 

Clinicians and other staff are attracted to AI tools that could help them with their work, Soon says. 

But some tools are blocked, or cannot be fully used, through the healthcare organisation's protected browsing environment.

Soon's team works with users to explore alternatives, which include encouraging them towards AI platforms provided by GovTech Singapore, or discussing Singapore-based data hosting with a provider when a particular tool is needed.

Soon says healthcare technology leaders should start by maintaining a clear inventory of their systems, including the AI tools being tried across the organisation. 

Organisations can give less attention to the security of test environments than to their live systems, Soon says. “We have very grand plans for our production, but when it comes down to the sandbox, it becomes mediocre.” 

Soon describes securing these test environments and separating them from live operations, so that experimental tools do not inadvertently expose the systems clinicians rely on. 

Bringing security into the design 

When Soon became CIO, one of the first questions he had was how to work with the Chief Information Security Officer (CISO). 

He describes the CIO's operational team as responsible for implementing defences, while the CISO function checks that security requirements are met. 

But he does not want that relationship to begin only after a system has been built. 
 

At NHG Health, the CISO function is involved in project discussions and architectural decisions from "day zero", he says. 

Security specialists can then help shape the design, while the operational team explains how the proposed safeguards would work in practice. 

Together, they can assess whether a requirement is feasible, how much it will cost, how long implementation will take, and whether it needs to be introduced in stages. 

It also means clinicians should not have to deal with conflicting instructions from the CIO and CISO functions about how a system can be used. 

The collaboration extends to preparing for incidents, with teams sharing their understanding of the architecture and identifying potential points of failure before an attack. 

Keeping services running during disruption 

In healthcare, security decisions also need to account for what happens to care when a system becomes unavailable. 

Soon draws on his experience building the National Harmonised Integrated Pharmacy System (NHIPS), through a Synapxe delivery role separate from his NHG Health CIO responsibilities. 

For the pharmacy system, resilience involves both restoring operations after an outage and recovering information that may have been lost, he says. 

These are addressed through recovery time and recovery point objectives. The first concerns how quickly a service should be restored. The second concerns the point to which its data should be recoverable following a disruption. 

To keep services available during maintenance, Soon describes an architecture in which one environment supports the service while another is taken down, with work scheduled during quieter periods where possible. 

For NHG Health's newer systems, Soon also describes work under consideration to help clinicians continue operating safely while technology teams deal with an intrusion. 

Feedback from clinicians helps identify which systems are critical and how services could continue while a threat is contained. 

The aim is to avoid a situation where every intrusion requires the entire service to be shut down, he says. 

Making connected information reliable 

The national pharmacy system illustrates why connected healthcare systems need to exchange information reliably and securely. 

In designing these connections, Soon says critical information, such as drug-allergy updates, is distinguished from less critical exchanges. 

The information must also be understood consistently. NHIPS uses standardised drug vocabulary and dosage units, alongside checks on the structure of data, known as schema validation. 

These measures help prevent staff or connected systems from interpreting medication information differently, he says. 

Protecting those exchanges also means managing risks from connected systems.

Security controls at the pharmacy platform's boundaries are intended to limit intrusion and the unauthorised removal of data if another system is compromised, Soon adds. 

The same concern extends to NHG Health's connections with private general practitioners, which support residents moving between primary, community and specialist care. 

If a partner's system is compromised, the connection may need to be terminated, he says. An alternative way of working with the care provider must then be arranged so that protecting the network does not leave care teams disconnected. 

Reviewing access as needs change 

Within healthcare organisations, access to information needs to reflect staff members' changing responsibilities. 

Clinicians rotate between settings, temporary staff move between institutions and researchers have different information needs, Soon says. 

His team regularly reviews access against roles and removes permissions that are no longer required. 

Soon recommends keeping an inventory of vendors and their access levels, with approval processes and multi-factor authentication for support arrangements. 

Remote access may need to be withdrawn if a vendor is compromised, he says. 

Older systems require a different assessment. Clinicians may still depend on an application even after its underlying platform stops receiving support and security patches. 

Soon describes considering whether those functions can be moved into a larger existing application or rebuilt on another platform. 

This can reduce exposure from unsupported technology while preserving the capabilities staff need. 

When staff explain why they need an old application, or what they hope to achieve with a new AI tool, technology teams can work with them on a safer way forward. 

For Soon, keeping that conversation open helps his team see what needs protecting and how to protect it without losing sight of the care it supports.