Singapore's November 2026 breach wave: what SPH Media, M1, Doctor Anywhere, Fullerton Health and SIA teach about vendor risk under the PDPA

Short answer. Between 3 and 10 November 2026, five well known Singapore organisations disclosed incidents involving personal data. Singapore Airlines said about 46,000 booking records were affected through its reservation technology provider, Amadeus. M1 said it identified a breach on 30 October that exposed customer names, NRIC or FIN numbers, dates of birth and addresses. Doctor Anywhere said an unknown third party reached a system holding user data, and that its corporate benefits subsidiary, Adept Health, had informed client organisations whose staff were affected. Fullerton Health said a server supporting its Migrant Worker Primary Care Plan was accessed, putting workers' FIN numbers, dates of birth and home addresses at risk. SPH Media said five internal systems were hit between 4 and 8 November, exposing contact data in about 9% of its customer database, and that preliminary findings suggest the attacks may have been AI-enabled.

None of these organisations has published a full root cause. What they share is a pattern that matters to every buyer: the data sat in a vendor platform, a group company acting as an administrator, a standalone programme system, or an application stack built on third-party software. Under Singapore's Personal Data Protection Act (PDPA), the organisation that collected the data stays responsible in every one of those cases. Below: what is confirmed, what is open, what the PDPA and the Personal Data Protection Commission (PDPC) expect, and what buyers can change this month.

At a glance

Each organisation that addressed financial data said payment card and banking details were not involved, or that it had no evidence they were. That limits card fraud. It does little for scams, because names, national ID numbers, dates of birth, phone numbers and addresses are exactly what a convincing scam call needs.

The five incidents, one at a time

Where a fact comes from press reporting rather than the company, we say so.

SPH Media: five systems, one actor, and a suspicion of AI

SPH Media publishes The Straits Times and other titles, so its own disclosure got close coverage. According to Mothership and The Straits Times report carried by The Star, both published on 10 November:

• The first intrusion was detected on 4 November and the most recent on 8 November.
• Five systems were hit, in what the company called "a concerted effort that was carried out by the same threat actor."
• The systems fall into two groups. One group held some personal data. The other held none.
• About 9% of the customer database was affected. The data was mainly email addresses, with some names, mailing addresses and phone numbers. The Straits Times report says some email addresses belonging to employees and corporate customers were also compromised, while Mothership's report says no corporate customer data was affected, so that detail is not settled.
• SPH Media said no payment card details, financial or banking information, passwords or customer account access were compromised, and that its news sites and subscription services were unaffected.
• A spokesman attributed the weaknesses to a mix of software bugs and system configuration.
• The company said that, based on preliminary investigations, it suspects the intrusions could be AI-enabled attacks, and that it is strengthening its ability to detect AI-aided attacks.

On the response, SPH Media said it secured the affected systems, brought in external cybersecurity specialists, applied bug fixes, updated system configurations, tightened its perimeter and raised monitoring. It reported the incidents to the PDPC, the Cyber Security Agency of Singapore and the Infocomm Media Development Authority (IMDA), and lodged a police report. Marketing-Interactive reported on 11 November that IMDA and the PDPC opened investigations and told SPH Media to contain the impact and identify the root cause.

Subscribers received an email warning that the exposed information "could potentially be used for phishing or scam attempts," with advice to watch for unsolicited messages, avoid suspicious links, verify delivery notices through official channels and turn on multi-factor authentication.

Two points matter. The "AI-enabled" label is the company's preliminary suspicion, not a published finding. And the stated cause is the least exotic one there is: software bugs and configuration. Whether those sat in SPH Media's own code, a product it bought, or open source components inside either, has not been said.

M1: a contained breach with a familiar list of fields

M1 said in a news release on 6 November that it identified a data breach on 30 October involving certain customer information, and that the breach "has since been contained." According to MustShareNews, which reported the release on 7 November, the affected data included customer names, NRIC or FIN numbers, dates of birth, mobile numbers, email addresses and residential addresses.

M1 said no payment card details, financial or banking information, or customer account access were compromised, and that its services stayed "fully operational." It said it is working closely with the relevant authorities and third-party specialists, that investigations are ongoing, and that it will contact affected customers by email or post. It did not say how many customers were affected or how the intruder got in. The same report, citing The Straits Times, says the PDPC is aware of the incident.

Nothing in the M1 disclosure points to a vendor. It matters here because its data set nearly matches those at Doctor Anywhere and Fullerton Health: name, national ID, date of birth, phone, email, home address. For a scammer, the three are interchangeable.

Doctor Anywhere and Adept Health: when a group company is the processor

Doctor Anywhere, a Singapore-based healthcare group, published an "Important Notice Regarding a Cyber Incident" on its security check page. The notice says the group became aware of a malicious cyber incident involving "unauthorised access by an unknown third party" to a system holding user personal data. It says it contained the incident and engaged an independent cybersecurity and forensic firm, which by 30 October had validated the security fixes and confirmed that the identified vulnerabilities were secured. Investigations continue.

The company says clinical records are not affected, based on the investigation to date, and that services continue as usual. It reported the incident to the PDPC and made a police report.

The supply chain detail sits in one paragraph. Adept Health Pte. Ltd., a member of the Doctor Anywhere group, is a third-party administrator for corporate benefits. It holds personal data of members and employees of other organisations. Doctor Anywhere says it informed those organisations and understands that they have told the affected individuals. That, the notice explains, is why some people heard about the incident from their employer or another company rather than from Doctor Anywhere.

Secondary reporting adds detail we could not check against a primary document, so treat it as reported:

• A customer letter, as summarised by RecordOwl, says the group became aware of the incident on 29 October and lists the affected fields as name, email, phone number, NRIC, FIN or passport number, home address, date of birth, gender, nationality, race, sign-up location and emergency contact details.
• The same summary says Channel NewsAsia reported the incident on 6 November.
• Reports say Adept Health notified Income Insurance on 2 November, and that Income published its own customer advisory saying some of its customers' data may be involved. We could not retrieve Income's advisory directly.
• Malay Mail covered the incident on 7 November, and the PDPC was reported to be aware of it and investigating.

The Adept Health detail is the most instructive part of this whole wave for buyers. An employer that buys corporate health benefits hands employee data to an administrator. The administrator, in turn, keeps it on systems run by its parent group. When that group's system is breached, the employer learns about it from the administrator, and its employees learn about it from the employer. Every hop in that chain is a delay, and every hop is an organisation that has to make its own PDPA assessment.

Fullerton Health: the standalone programme system

On 9 November, Fullerton Health said there had been unauthorised access to a server supporting its Migrant Worker Primary Care Plan, a healthcare scheme for foreign workers in Singapore. According to Malay Mail, which carried The Straits Times report on 11 November:

• The potentially affected information included workers' names, Foreign Identification Numbers (FIN), dates of birth, mobile phone numbers, email addresses and residential addresses.
• The company said no medical records, health information or personal financial details were involved.
• Preliminary findings point to a standalone system supporting the programme, and no other programmes or patients appear to be affected.
• Fullerton said it discovered the incident on 31 October and activated its cybersecurity response procedures.
• Fullerton did not say how many workers may be affected.
• The PDPC was notified and a police report was lodged. Fullerton said it is contacting affected workers and will give guidance on precautions.

"Standalone system" is reassuring for the rest of the business. It also describes the kind of system security programmes tend to under-watch: built for one programme, often by a delivery partner, outside the main patching cadence. We don't know whether that applies here. Ask about your own.

For migrant workers, an exposed FIN number and address carries particular weight. Many may not read English notices easily and are frequent targets of scams that impersonate employers and agents. Notice in languages they read is part of doing this properly.

Fullerton has been here before on the vendor side. In 2023, the PDPC fined it S$58,000 and its booking vendor, Agape CP Holdings, S$10,000 over a 2021 incident. We return to that decision below, because it is the clearest statement of what the PDPC expects when data goes to a vendor.

Singapore Airlines and Amadeus: one vendor, many airlines

On 3 November, Singapore Airlines said about 46,000 booking records may have been affected by a cybersecurity incident involving Amadeus, its reservation technology provider. Per Reuters, as carried by The Star on 4 November:

• The data included customers' names, booking reference numbers, travel itineraries and booking classes.
• For about 620 booking records, email addresses, phone numbers, travel document details and KrisFlyer membership numbers may also have been accessed.
• Amadeus told SIA that bank account and credit card information was not leaked and that bookings were not modified.
• SIA said its own IT systems were not breached, and that it is contacting customers with upcoming travel so they can change their booking reference numbers as a precaution.

Amadeus said it "recently became aware of a vulnerability affecting a travel booking display environment." The Record quoted it saying "Certain booking-display data was accessible through the vulnerability," that there is "no evidence that payment or financial data was accessed," and that it "implemented measures to fix the vulnerability as well as enhanced monitoring and detection capabilities." Cathay Pacific told The Record that Amadeus said the threat actors used "login credentials assigned to its system account."

SIA is one of several carriers. Cathay Pacific reported about 53,000 bookings, Japan Airlines about 92,000 customers, and Korean Air, Asiana and Malaysia Airlines also reported affected data. The New Straits Times reported on 2 November that, per Cathay Pacific and Malaysia Airlines, the affected records date from August 2023 to September 2026, and that airlines were notified on different days: Korean Air and Asiana on 20 October, Japan Airlines on 23 October and Cathay on 28 October. Counts are not directly comparable, because some airlines count bookings and others count customers. Secondary reports citing The Straits Times say the PDPC is aware of the SIA incident and looking into it.

This is the cleanest third-party case in the set. The airline's systems were not touched, a system account's credentials reportedly opened a shared platform, and each airline learned about it on the vendor's schedule.

What nobody knows yet

It is easy to fill gaps with guesses. Here is what remains open as of 14 November 2026, based on the disclosures and reporting above.

• Root causes. No organisation in this set has published a technical root cause. SPH Media's "software bugs and system configuration" and Amadeus's "vulnerability" plus a system account's credentials are the most specific statements so far.
• Whether the incidents are linked. Nothing published connects them. Timing close together is a pattern, not evidence of one actor.
• The AI question. SPH Media's suspicion of AI-enabled attacks is preliminary, with no technical detail released.
• Numbers. Only SIA (about 46,000 booking records) and SPH Media (about 9% of its customer database) have given a scale.
• Whether data has been sold. We found no credible report of any of these data sets offered for sale. If that changes, treat sellers' statements as claims until the organisation confirms them.
• Regulatory outcomes. The PDPC has not published decisions on any of these incidents.

Timeline

Four shapes of third-party risk in one week

Strip out the brand names and this wave shows four ways that "someone else's system" ends up holding your customers' data. Most organisations have all four.

1. The shared vendor platform

SIA's case. One platform serves many customers, and you can't see its code, admin accounts or logs. A system account credential reportedly opened it, and the records span years. Every customer is exposed at once and learns about it on the vendor's schedule. The control that matters most is the contract and the evidence behind it: notice deadlines, privileged account controls and independent assurance.

2. The group company or administrator acting as processor

Doctor Anywhere and Adept Health. A benefits administrator holds data on behalf of employers. It stores that data on systems run by its parent group. From the employer's point of view, the administrator is a third party and the parent group's platform is a fourth party it may never have assessed.

This shape is common in health benefits, payroll, insurance, travel management and outsourced HR. It is also common inside conglomerates, where a sister company "just hosts it for us" without a written processing agreement.

3. The standalone programme system

Fullerton Health's server for one care plan. Systems built for a single programme, contract or campaign often sit outside the main estate. They might be built and run by a delivery partner, they might use a different stack, and they often miss the patching, logging and access reviews the core systems get. "Standalone" limits the blast radius. It also tends to mean "less watched."

4. Your own application, built from other people's software

SPH Media's "software bugs and system configuration." Every modern application is mostly third-party code: open source libraries, frameworks, container base images, managed services and commercial components. A bug in any of them is a bug in your system. A default setting nobody changed is a configuration weakness in your system. This is software supply chain risk, and it is the part buyers can control most directly.

The PDPA doesn't care which of the four shapes caused a breach. The organisation that collected the data and decided what to do with it remains on the hook.

What the PDPA requires

This section is general information, not legal advice. Talk to counsel about your own position.

Who is responsible: organisations and data intermediaries

The PDPA distinguishes between an organisation and a data intermediary, which is an organisation that processes personal data on behalf of another under a contract. The PDPC's Guide to Managing Data Intermediaries sets out the split:

• A data intermediary is directly bound by two obligations when it processes data for the organisation: the Protection Obligation in section 24 and the Retention Limitation Obligation in section 25.
• Under section 4(3) of the Act, the organisation that engaged it has the same obligation "in respect of personal data processed on its behalf and for its purposes by a data intermediary as if the personal data were processed by the organisation itself."
• An organisation may be a data intermediary "even if the contract between the organisations does not clearly identify the organisation as a DI."
• If the intermediary uses or discloses data beyond what it was engaged to do, it takes on all the PDPA's obligations for that data.

Section 24 is the heart of it. It requires an organisation to make "reasonable security arrangements" to protect personal data in its possession or under its control against unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks.

Breach notification under Part 6A

Since February 2021, the PDPA has carried a mandatory breach notification regime. The PDPC's Guide on Managing and Notifying Data Breaches sets out the steps:

1. Assess quickly. Once an organisation has credible grounds to believe a breach has occurred, "whether through self-discovery, alert from the public or notification by its data intermediary," it must assess whether the breach is notifiable within 30 calendar days and document every step.
2. Apply the two tests. A breach is notifiable if it is likely to result in significant harm to individuals, which the regulations deem to be the case for prescribed categories of personal data, or if it is of significant scale, meaning 500 or more individuals. If the count is unknown, the organisation should notify once it has reason to believe the number is at least 500.
3. Notify the PDPC within three calendar days. After determining that a breach is notifiable, the organisation must notify the PDPC "as soon as practicable, but in any case, no later than three (3) calendar days." The guide's example: a determination on 1 January means notification by 4 January.
4. Notify individuals where required, at the same time as or after the PDPC.
5. Data intermediaries must tell the organisation. An intermediary that processes data on another organisation's behalf must notify that organisation of a breach it detects. The PDPC's Guide to Managing Data Intermediaries tells organisations to set up an escalation process so their intermediaries notify them "without undue delay."

That last point is why vendor contracts matter so much. The organisation's 30-day assessment clock starts from credible grounds, which includes a notice from its intermediary. A vendor that sits on an incident for weeks quietly eats your time.

Penalties

Since 1 October 2022, the maximum financial penalty for a breach of the PDPA's data protection provisions is S$1 million or, for an organisation whose annual turnover in Singapore exceeds S$10 million, 10% of that turnover, whichever is higher, as summarised by CMS. The PDPC can also issue directions, and it often requires specific remedial work.

What the PDPC expects when you outsource

The PDPC has been unusually clear, through guides and decisions, about what "reasonable security arrangements" mean when a vendor is involved.

The Fullerton and Agape decision

In Re Fullerton Healthcare Group Pte Limited and Agape CP Holdings Pte Ltd [2023] SGPDPC 5, published on 22 June 2023, the PDPC looked at a 2021 incident. As summarised by Baker McKenzie via Global Compliance News:

• Fullerton shared customer data with Agape, a call centre and appointment booking vendor, through a collaboration platform.
• Agape copied the data to an internet-facing file server for its agents. The server's password protection had been disabled for about 20 months, leaving a public directory listing.
• The data later turned up for sale online.
• The PDPC found that Agape breached the Protection Obligation by failing to carry out reasonable periodic security reviews.
• It also found that Fullerton breached the Protection Obligation. It had not made enough inquiries into how Agape stored, transmitted and retained the data, so it failed to exercise reasonable oversight. It had not limited sharing to data necessary for the service. And it had mistakenly placed data meant only for internal staff on the system shared with the vendor.
• Fullerton was fined S$58,000 and Agape S$10,000.

The lesson for every buyer is direct. "The vendor did it" is not an excuse. The PDPC expects you to know how your vendor stores, moves and keeps your data, to send it only what it needs, and to check.

The data intermediary lifecycle

The PDPC's Guide to Managing Data Intermediaries turns those expectations into a four-stage lifecycle. It is worth reading in full. The points that map most closely to this month's incidents:

Governance and risk assessment. Senior management decides what to outsource. Choose a vendor that can provide protection "commensurate with the volume and sensitivity" of the data, and look for external reviews or certifications.

Policies and practices. A binding contract is the primary tool, and the guide says having no agreement setting out the intermediary's key obligations is a breach of the PDPA. Procedures can require regular patching and "regular penetration tests on IT applications and databases to fix potential vulnerabilities," and an escalation path so intermediaries notify "without undue delay."

Service management. Regular meetings, proactive monitoring by the intermediary (including near real-time database access monitoring for large volumes), audits or independent audit reports, and tabletop exercises.

Exit management. Clear time frames for the intermediary to stop retaining data, and exit audits.

The companion Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data gives sample clauses you can adapt.

It keeps happening through vendors

In April 2025, ransomware at printing vendor Toppan Next Tech put statement data for about 8,200 DBS and about 3,000 Bank of China customers at risk (Insurance Journal). In May 2025, Income Insurance said at least 146 policyholders were exposed after ransomware hit its mailing vendor, DataPost (BeyondMachines). Each time, the bank or insurer's own systems were fine and its customers' data still left through a supplier.

How attackers reach this data

We don't know the entry point in most of this month's incidents. What we can do is map the stated or reported facts to the paths that recur in vendor and application incidents. Treat this as a checklist for your own estate, not a theory about any one company.

A privileged or system account credential. Cathay Pacific said Amadeus told it the attackers used credentials assigned to a system account. Such accounts often have broad access, no multi-factor prompt and little monitoring, so misuse looks like normal machine traffic.

A software vulnerability in an internet-facing application. Amadeus described a vulnerability, Doctor Anywhere refers to "identified vulnerabilities," and SPH Media cites software bugs. In practice that means a flaw in first-party code, an unpatched known vulnerability in a third-party library or product, or weak authorisation on an API that lets one record lead to the next.

Misconfiguration. SPH Media named configuration explicitly, and the Fullerton and Agape decision turned on a file server whose password protection was off for 20 months. Open test endpoints and storage without authentication need no exploit at all.

Long exposure windows. The Amadeus records span August 2023 to September 2026. Old data that is still reachable is still exposable. Retention is a security control.

Speed from automation and AI. SPH Media suspects AI-enabled attacks. Whatever the evidence turns out to be, the practical point stands: attackers can scan, probe and chain weaknesses faster than a quarterly review or an annual vendor questionnaire can keep up with. Five systems in five days is a cadence only continuous testing and monitoring can match.

What affected people should do

If you received a notice from SIA, M1, Doctor Anywhere, an employer using Adept Health, Fullerton Health or SPH Media, start with what that notice says and use the channels it gives. Then:

1. Assume the listed fields are exposed. For most of these incidents that means your name, national ID or FIN number, date of birth, phone, email and home address. For some Doctor Anywhere users, reportedly, also nationality, race and emergency contact details.
2. Warn the people listed as your emergency contacts, if your notice says those details were included. They never chose to be in the system.
3. Treat unexpected calls and messages that use your real details as suspect. Common pretexts are the airline about a flight change, the telco about your line, a clinic about an appointment, a courier about a delivery, a bank, or someone claiming to be investigating the breach. Hang up and call back on a number you find yourself.
4. Never share passwords, one-time codes or bank details in response to a call, SMS or chat. Doctor Anywhere's notice says: "DA will never ask for your password or ask you to share your bank details over the phone, SMS or chat." Most organisations say the same.
5. SIA customers with upcoming travel: change your booking reference as SIA asks, and distrust booking emails with login links.
6. Turn on app-based or hardware-key multi-factor authentication for email and banking, and watch accounts for new lines or SIM changes.
7. Employers of migrant workers: help your workers read Fullerton Health's notice in their own language, and remind them that real employers and agents won't ask for payment or bank details by phone.

What security, privacy and procurement teams should do

Every organisation in Singapore holding personal data has some version of these four shapes. The goal is to know where your data actually lives, cut what each party holds, find weaknesses in your own software before someone else does, and hear about vendor problems fast.

1. Build the real vendor and processor inventory

Start from money and identity, not procurement's list: recurring payments, single sign-on apps, API integrations, service accounts. For each vendor, record what personal data it holds, on whose systems, and its sub-processors. Include group companies, because "our sister company hosts it" is still outsourcing. Note whether a written agreement sets out its obligations; the PDPC says a missing one is itself a breach.

2. Tier vendors by the data they hold

A small benefits administrator holding NRIC numbers and addresses for every employee is a higher risk than a large design tool holding work emails. Then minimise field by field. Does the wellness programme need NRIC numbers, or would an internal ID do? The Fullerton and Agape decision shows the PDPC treats over-sharing as a failure of the Protection Obligation.

3. Put the PDPC's expectations into the contract

For every intermediary holding personal data:

• Breach notification with a clock. A defined deadline from detection, such as 24 or 48 hours, what the first notice must contain, and how often updates follow. Tie it to your own 30-day assessment and three-day PDPC clocks.
• Privileged and system account controls. Multi-factor authentication for all human admin access, inventory and rotation of service and system account credentials, network restrictions on admin interfaces, and logging of privileged actions.
• Vulnerability management. Patch timelines by severity, regular penetration testing of internet-facing applications, and notice to you when a critical or known-exploited vulnerability affects the service.
• Software transparency. A software bill of materials (SBOM) in SPDX or CycloneDX for software you run or that processes your data, and vulnerability statements when new issues land.
• Sub-processors, assurance and exit. A current sub-processor list with notice of changes, independent reports such as ISO/IEC 27001 or SOC 2, audit rights, certified deletion at the end, and cooperation on PDPC and individual notices.

4. Test your own applications continuously

SPH Media's cause, software bugs and configuration, is the one fully inside a buyer's control. For every internet-facing application that touches personal data:

• Know your components. Keep an SBOM for every application and image, and track vulnerabilities in direct and transitive dependencies, using KEV and EPSS data to prioritise.
• Fix reachable code paths first.
• Test the running application for exposed endpoints, weak authorisation and configuration mistakes that code review misses.
• Scan first-party code for injection and broken access control before release.
• Gate releases that introduce known-exploited components or critical findings.

5. Find the standalone systems

Ask every business unit for systems built for one programme, contract, pilot or campaign. Each needs an owner, a patch cadence, logging, an access review and a retention rule. If a delivery partner runs it, it belongs in the vendor inventory too.

6. Monitor vendors between reviews

Annual questionnaires go stale the day they are filed. Watch for a new known-exploited vulnerability in software a vendor ships or runs for you, an expired SBOM, a lapsed certification, a new sub-processor or a public breach disclosure, and give every alert an owner.

7. Rehearse the day your vendor is breached

Run a tabletop with your top five data-holding vendors. Open with: "Your platform's system account was used to read our customer records for two years. What do you send us in the first four hours?" Then walk your own PDPA steps through to the three-day PDPC notice.

Fix it without waiting for upstream

You can't patch your vendor's platform or speed up its forensics. You can shrink your exposure, close the paths that matter in your own estate, and protect your customers starting today. None of these steps needs a vendor's cooperation.

1. Rotate every credential tied to vendors that hold personal data. API keys, OAuth tokens, SFTP keys and service accounts, starting with travel, benefits, health, HR and payroll. A vendor that can't rotate without downtime is a finding.
2. Revoke integrations and grants you can't explain in your identity provider, collaboration suite and code hosts.
3. Cut the fields you send. Edit integration mappings so NRIC and FIN numbers, dates of birth and home addresses go only to vendors that need them. Change the data feed, not just the policy.
4. Purge old exports and stale records from shared drives, buckets and mailboxes, and ask each vendor to confirm retention for former customers and staff.
5. Generate SBOMs for every internet-facing application that touches personal data and check them against known-exploited vulnerabilities today. Patch or upgrade reachable vulnerable components first.
6. Where an upstream library has no fixed release yet, ship your own fix. Pin to a patched fork, backport the upstream commit into a vendored copy, or replace the component with a hardened build, and note it for reversal when upstream ships.
7. Run a dynamic scan of every public endpoint that serves personal data, including the "standalone" ones, and fix broken authorisation and exposed admin or test interfaces first.
8. Turn on release gates that block known-exploited components and critical findings in anything that handles personal data.
9. Require phishing-resistant MFA on every vendor admin console, remove shared logins, and restrict vendor API access by IP where supported.
10. Pre-draft your PDPA notices: the PDPC notification, the individual notice and a scam-warning one-pager, in the languages your customers and workers read.
11. Brief your contact centre and finance team. Require call-backs on known numbers for any bank detail change.
12. Ask your top ten data-holding vendors three questions this week. What is your breach notice deadline to us, who are your sub-processors, and when did you last rotate the credentials of the system and support accounts that can reach our data?

Each step works whether or not your vendors ever tell you more.

How Safeguard helps with this class of problem

These organisations disclosed their incidents themselves. Our part is helping teams manage the software and vendor supply chain risk that incidents like these expose. These are the generally available capabilities that map to the steps above.

Third-Party Risk Manager (TPRM). TPRM keeps a vendor directory with contracts, SLAs and risk tiers, and gives vendors a self-service portal. You can request SBOMs and other evidence from vendors individually or in bulk, track each request through to validation, and let automated follow-ups chase the stragglers. Each vendor gets a risk score across vulnerability, compliance, component and operational risk, enriched with EPSS and CISA KEV data. Continuous monitoring alerts on new critical vulnerabilities, KEV additions, risk changes and SBOM expiry, and sends them to email, Slack, Teams, PagerDuty or a webhook so they reach an owner.

Application security across your own estate. Safeguard runs software composition analysis across direct and transitive dependencies, static analysis of first-party code, and dynamic testing of verified running targets, so bugs and configuration weaknesses in internet-facing applications surface in one place. Reachability analysis puts the vulnerable code paths your application actually calls at the top of the queue.

SBOMs and vendor software assurance. Safeguard generates and analyses SBOMs in SPDX and CycloneDX and accepts CSAF and VEX documents, so "where do we run this component?" has an answer the day it becomes known-exploited.

Remediation without waiting. Griffin, our remediation model, can open policy-gated fix pull requests for vulnerable dependencies, single or in bulk, and your own CI runs the tests before anyone merges them. Gold Registry offers hardened, signed drop-in artifacts for open source components, which helps when upstream hasn't shipped a fix yet.

Policies and gates. Write organisation-wide policies, including from plain-English prompts, and enforce them at build, CI and release with block, warn, notify or require-approval actions. One example: no release that handles personal data ships with a known-exploited component.

Compliance automation. The compliance suite brings frameworks, controls, evidence, questionnaires, risks and vendors into one place, with Singapore's PDPA among the frameworks covered alongside ISO/IEC 27001, SOC 2 and many others. Teams use it to map vendor oversight and security controls and to keep evidence current. Safeguard itself is SOC 2 Type I and Type II audited, so we answer the same vendor questions we suggest you ask.

Asset discovery. Asset discovery inventories repositories, images, packages, vendors and workloads, which is how standalone systems get back onto the map.

You can see the platform at https://safeguard.sh.

FAQ

What happened in Singapore's November 2026 breach wave?

Between 3 and 10 November 2026, Singapore Airlines, M1, Doctor Anywhere, Fullerton Health and SPH Media each disclosed incidents involving personal data. SIA's data was affected through its vendor Amadeus. Doctor Anywhere's incident also affected client organisations of its benefits administrator, Adept Health. SPH Media said five systems were attacked by one actor between 4 and 8 November.

Was payment card or banking data exposed?

Each organisation said payment card and banking data were not involved or that it had no evidence they were. The exposed data was mainly identity and contact data, which is valuable for scams.

Was the SPH Media attack carried out with AI?

SPH Media said preliminary investigations suggest the attacks may have been AI-enabled. That is a preliminary suspicion. No technical evidence has been released.

What does the PDPA require after a breach?

Organisations must assess within 30 calendar days whether a breach is notifiable, notify the PDPC within three calendar days of deciding it is notifiable, and notify affected individuals where required. A breach is notifiable if it is likely to cause significant harm or affects 500 or more people. Data intermediaries must notify the organisation they process data for.

Is a company responsible if its vendor is breached?

Under the PDPA, an organisation keeps the same protection obligation for data processed on its behalf by a data intermediary as if it processed the data itself. In the 2023 Fullerton and Agape decision, the PDPC fined both the company and its vendor.

How does Safeguard help?

Safeguard helps organisations manage vendor and software supply chain risk with third-party risk management, SCA, SAST and DAST, SBOM-based vendor software assurance, automated fix pull requests, policies and gates, compliance automation covering Singapore's PDPA, and asset discovery.

Sources

All accessed 14 November 2026.

Company notices and statements

• Doctor Anywhere, Important Notice Regarding a Cyber Incident

Regulators and law

• PDPC, Guide on Managing and Notifying Data Breaches under the PDPA, 15 March 2021
• PDPC, Guide to Managing Data Intermediaries, 2020
• PDPC, Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data
• PDPC, Breach of the Protection Obligation by Fullerton Healthcare and Agape CP Holdings, 22 June 2023
• Personal Data Protection Act 2012, Singapore Statutes Online

Press and analysis

• Mothership, SPH Media hit by AI-enabled cyberattacks, 10 November 2026
• The Star, carrying The Straits Times, SPH Media hit by cyberattacks, 10 November 2026
• Marketing-Interactive, SPH Media confirms data breach affecting 9% of its database, 11 November 2026
• Malay Mail, citing The Straits Times, Fullerton Health cyber breach, 11 November 2026
• Malay Mail, Doctor Anywhere reports personal data leak, 7 November 2026
• RecordOwl, Doctor Anywhere data breach summary, November 2026 (aggregator; used only for details attributed to it)
• MustShareNews, M1 says data breach identified and contained, 7 November 2026
• The Star, carrying Reuters, Singapore Airlines says 46,000 booking records affected by Amadeus breach, 4 November 2026
• The Record, Asian airlines announce data breach at IT provider, 4 November 2026
• New Straits Times, Amadeus fixes booking system vulnerability amid airline data breaches, 2 November 2026
• Global Compliance News (Baker McKenzie), PDPC decision on Fullerton and Agape, 3 August 2023
• CMS, Higher financial penalties for breaches of the PDPA from 1 October 2022
• Insurance Journal, Singapore customer data exposed after ransomware attack on vendor of DBS, BoC, 8 April 2025
• BeyondMachines, Income Insurance policyholder data exposed in third-party breach, 29 May 2025