One of the most dangerous assumptions in data protection is this: if the breach happened at the vendor, the main accountability sits with the vendor.
Operationally, that may be partly true. Legally and reputationally, it is rarely enough.
The ransomware attack on Toppan Next Tech ("TNT"), a third-party printing and distribution vendor, is a reminder of how quickly vendor incidents become customer-trust incidents. MAS said in April 2025 that customer information from DBS Bank and Bank of China Singapore had been extracted by the threat actor. Reuters reported that around 8,200 DBS customers and around 3,000 Bank of China Singapore customers were affected. The data involved included names, postal addresses and, in some cases, account-related details. Both banks stated that their core systems were not compromised, but the event still triggered regulatory involvement, customer notification and heightened monitoring.
For a DPO in Singapore, the lesson is not limited to banking. It applies to payroll vendors, print-and-mail houses, CRM partners, website developers, cloud service providers, support desks, outsourced operations and managed platforms.
If a third party handles personal data on your organisation's behalf, your organisation still owns the risk story.
Why this matters beyond finance
Many organisations have improved their internal controls while underestimating the operational sprawl around them.
Statements are printed by an external partner. Forms are processed by a software vendor. Campaign data sits in a marketing platform. Support logs are handled by a managed service provider. Backups are maintained by another party. Customer communications are distributed through external tooling.
Each handoff expands the attack surface. Each one also creates a governance question for the DPO: what personal data is leaving the organisation, who can access it, what security commitments exist, what evidence is reviewed, and how quickly can impact be assessed if the vendor suffers an incident?
The Toppan lesson for DPOs
The striking thing about the Toppan incident is not only that customer information was extracted. It is that the affected data was tied to a vendor process many businesses would consider routine: printing and distributing statements or letters.
Routine processes are exactly where DPOs should pay more attention.
They often involve structured personal data exports, scheduled file transfers, retained copies, shared folders, system integrations and operational staff outside the main business. Over time, these become "business as usual" and escape close review.
That is why a DPO should not ask only whether a vendor passed onboarding. The better question is whether the data flow remains justified, controlled and reassessed over time.
What strong vendor governance looks like
Strong vendor governance starts with data visibility.
Know what categories of personal data the vendor receives, how often, in what format, and for what exact purpose. Know whether the vendor stores a copy, how long it is retained, where it is processed, who can access it, and whether subcontractors are involved.
Then move to evidence.
High-risk vendors should not only promise security in a contract. They should provide current evidence of controls, testing, incident procedures and contact pathways. Where the vendor supports a critical business function, tabletop breach scenarios and notification expectations should be reviewed in advance, not improvised during the crisis.
Finally, review necessity.
Some vendor data flows exist because they were once useful, not because they are still needed. If a partner only needs partial identifiers, do not send the full dataset. If a process can be tokenised, masked, segmented or shortened in retention, reduce it now.
The DPO's practical checklist for third-party incidents
- Map all vendors and service providers that collect, process, store, transmit or print personal data on your organisation's behalf.
- Classify them by sensitivity, volume, business criticality and exposure.
- Review contracts for breach notification timing, audit rights, security obligations, subcontracting terms and data return or deletion requirements.
- Ask whether the organisation can quickly identify which data subjects are affected if a vendor incident occurs.
- Reduce unnecessary data sharing, especially in routine operational processes that have not been reviewed recently.
Why urgency matters
Vendor risk is rarely static. Services change. Products get upgraded. teams move. subprocessors shift. Data exports grow. A process that looked low-risk at onboarding can become high-impact a year later.
That is why DPOs in Singapore should treat the Toppan incident as more than a news event. It is a case study in why operational convenience and privacy accountability can drift apart over time.
The best vendor programme is not the one with the longest checklist. It is the one that keeps data flows visible, proportional and reviewable.
Key takeaways
- A vendor breach can still become your organisation's privacy, trust and communications problem.
- Routine outsourced processes often carry more personal data risk than teams realise.
- Vendor diligence should cover real data flows, retention, access and incident response, not only contract language.
- High-risk service providers should be reviewed continuously, not only at onboarding.
- DPOs should reduce unnecessary third-party data exposure wherever possible.
