REG. VTS-007 CASE WATCH · EDITION 1 SINGAPORE · PDPA 2026
Blog / PDPC Case Watch / Edition 1
Veritos · Singapore

PDPC Case Watch

Edition 1
October 2026
Monthly
By Veritos

PDPC publishes a few decisions and undertakings each month, and many more cases never become public. Case Watch is our way of learning from the ones that do.

Each month we pick a few decisions or undertakings, look at what PDPC actually found, and pull out one practical question for a Singapore SME. Where we go beyond what PDPC found, we say so.

This edition looks at three decisions where the failure sat in routine work: testing a change, closing a test account, applying a patch.

The change meant for one market

Carousell runs an online marketplace in Singapore and several other markets. In 2022 it told PDPC about two unrelated incidents. In the first, a change meant only for property listings in the Philippines added users' email addresses, and for Philippine users their phone numbers, to chat messages across every listing category and market. The data of 44,477 people was disclosed. In the second, a public-facing API launched during a system migration left out a filter, so it returned email addresses, phone numbers and dates of birth that should not have been available. A threat actor scraped it, and data of about 2.6 million users was later offered for sale.

PDPC found that Carousell had negligently breached the Protection Obligation in two ways. Its pre-launch testing was not scoped widely enough, and it had not adequately documented the functional and technical specifications of its software. It imposed a penalty of S$58,000 and directed Carousell to review its testing and documentation processes.

The lesson
A change aimed at one group can reach everyone who shares the same component, and the handover notes often don't say who that is.
How to avoid it
Test what a change could touch beyond its target, and write down what each component is used for and by whom.

Read the full lesson →

The test VPN account nobody looked after

Cortina Watch, which is mainly involved in the retail, import and export of timepieces, branded pens and luxury accessories, reported a ransomware attack to PDPC in June 2023. It had faced multiple brute-force attacks between 30 April and 4 June. On 27 May, a VPN account it used to test access to its live systems was compromised. The attacker reached a password-protected master password file, moved across the servers, copied 5.82 GB of data and deployed LockBit 3.0 ransomware. The personal data of 3,953 people, including NRIC or passport numbers for 234 of them, was posted on the dark web.

Cortina Watch admitted it had not kept up housekeeping on its test VPN accounts and had not put reasonable access controls in place. PDPC noted that default account names such as "Administrator" and "Guest" were in use, that multi-factor authentication was not applied to VPN, firewall or password-file access, and that its password policy required only a minimum of eight characters. PDPC did not impose a financial penalty. It directed Cortina Watch to commission a third-party security audit of its access controls within 60 days.

The lesson
A test account is still a way in, and it stays open until someone is responsible for closing it.
How to avoid it
List every account that can log in remotely, close the ones you no longer need, and put multi-factor authentication on the rest.

Read the full lesson →

The patch nobody asked the vendor to apply

Goldheart Jewelry sells jewellery online and through its outlets in Singapore. In May 2023 it learned that its customer database had been published on an online forum, affecting 41,379 individuals. The cause was a known vulnerability in Magento, the e-commerce platform behind its website. A patch had been available since 13 February 2022 and was not applied until January 2023, eleven months later. A vendor maintained the website. The service agreement said patches were applied on Goldheart's request, although the vendor sometimes applied some on its own initiative.

Goldheart said patching was the vendor's job, and that a Magento specialist acting as its data intermediary could not have been expected to wait for requests. PDPC disagreed. The agreement said patching was done on Goldheart's request, the vendor was not its data intermediary, and the vendor applying some patches unprompted did not cure Goldheart's failure to set out clearly who was responsible for security. The obligation stayed with Goldheart. It found a negligent breach of the Protection Obligation, imposed a financial penalty of S$58,000 and directed a third-party security audit within 60 days.

The lesson
Paying a vendor to maintain your systems doesn't tell you who is watching for patches. Your contract does.
How to avoid it
Read the agreement, name who monitors and who requests patches, and keep a record that it happens.

Read the full lesson →

What the three have in common

In all three, the failure sat in work that looks too small to need an owner: testing a change beyond its target, closing a test account, asking for a patch. Each began with something ordinary: an untested change, an account left open, a patch not applied. Each organisation also admitted the facts and the breach under PDPC's expedited procedure, and the outcomes still differed, from a financial penalty in two cases to directions with no fine in one.

The question we would take from this edition is a plain one: who owns the routine work? That reading is ours, not PDPC's. PDPC decided each case on its own facts.

Sources