_commit_at,_commit_hash,_id,_item,_version,_commit,description,tags,date,pdf-url,nature,title,url,timestamp,pdf-content,decision,_item_full_hash,_changed_columns
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,127,127,1,952,"A warning was issued to CampVision for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of individuals. As a result, the personal data of 106 individuals were compromised through a data breach from an online survey platform. Click here to learn more.","[""Protection"", ""Warning"", ""Education""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---CampVision.pdf,Protection,Breach of the Protection Obligation by CampVision,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-campvision,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1808-B2508
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
CampVision Ltd.

SUMMARY OF THE DECISION

1.

CampVision Ltd (the “Organisation”) engaged SHINE Children and Youth Services
(“SHINE”) to collect evaluation feedback from youths participating in its programmes.
For this purpose, SHINE collected information from the youths on the Organisation’s
behalf, including their names, NRIC numbers, email addresses and schools (the
“Personal Data”). SHINE did this using a platform provided by Typeform S.L.
(“Typeform”), a company based in Spain, which provides online survey services. In
June 2018, Typeform discovered that an unknown third party had gained access to its
server and downloaded information provided by many Typeform users, including
Personal Data collected by SHINE on behalf of the Organisation (the “Incident”).

2.

The Personal Data Protection Commission (the “Commission”) found that Personal Data
of 106 individuals collected by SHINE on behalf of the Organisation had been exposed
to the risk of unauthorised access and disclosure in the Incident. The Commission’s
investigations revealed that there was no written contract between the Organisation and

SHINE setting out SHINE’s obligations with respect to the processing and protection of
Personal Data, which it collected on the Organisation’s behalf. The Organisation also
admitted that it had not conveyed any instructions to SHINE with respect to protection
of the Personal Data. In the circumstances, the Deputy Commissioner for Personal Data
Protection found the Organisation in breach of section 24 of the Personal Data Protection
Act 2012 and decided to give a warning to the Organisation.

",Warning,54437433b71aa75c2e22ffde6236759e61fc677f,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,128,128,1,952,A warning was issued to Tan Tock Seng Hospital for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its patients. 85 Notification letters to patients to reschedule appointments were sent to wrong addresses.,"[""Protection"", ""Warning"", ""Healthcare""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---TTSH.pdf,Protection,Breach of the Protection Obligation by Tan Tock Seng Hospital,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-tan-tock-seng-hospital,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1902-B3372
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Tan Tock Seng Hospital Pte. Ltd.

SUMMARY OF THE DECISION

1.

Tan Tock Seng Hospital Pte Ltd (the “Organisation”) voluntarily informed the Personal
Data Protection Commission (the “Commission”) on 14 February 2019 that it had
discovered on 12 February 2019 that letters sent to 85 patients (the “Affected
Individuals”) to reschedule their appointments with the Organisation (the “Letters”) had
been sent to the wrong addresses (the “Incident”). These Letters contained the names,
NRIC numbers and appointment of the Affected Individuals (the “Personal Data”). Such
letters were usually generated automatically. However, on 12 February the Letters were
generated manually using the mail merge function in Microsoft Word to extract the
Personal Data from a spreadsheet (the “Spreadsheet”) and insert the data in the letters.
However, the staff that had been tasked to generate these letters only selected and sorted
the address field in the Spreadsheet. As a result, the addresses in the Spreadsheet no
longer corresponded to the correct patient information and when the staff ran the mail
merge function, the incorrect addresses were inserted in the letters.

2.

The Commission found that the Organisation did not conduct any checks on the
generation and printing of the letters. A simple random sampling of the letters would

have likely averted the Incident or greatly reduced the number of individuals affected. In
the circumstances, the Deputy Commissioner for Personal Data Protection found the
Organisation in breach of section 24 of the Personal Data Protection Act 2012 and
decided to give a warning to the Organisation. No directions are required as the
Organisation has implemented corrective measures that addressed the gap in its security
arrangements.

",Warning,9ac644185c04bc82207d036718c6b813da4a98e0,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,129,129,1,952,"A financial penalty of $7,000 was imposed on SearchAsia Consulting for failing to put in place reasonable security arrangements to protect jobseekers’ resumes from unauthorised disclosure via its online website.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---SearchAsia-Consulting-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by SearchAsia Consulting,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-searchasia-consulting,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 40
Case No DP-1809-B2790

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012

And

SearchAsia Consulting Pte. Ltd.

… Organisation

DECISION

SearchAsia Consulting Pte. Ltd.

[2019] SGPDPC 40

SearchAsia Consulting Pte. Ltd.
[2019] SGPDPC 40
Yeong Zee Kin, Deputy Commissioner — Case No DP-1809-B2790

24 October 2019

Introduction and Material Facts

1.

SearchAsia Consulting Pte. Ltd. (the “Organisation”) is a recruitment company

established in Singapore which matches job seekers with organisations that are
looking to recruit employees for a specific role. On 26 September 2018, the
Organisation notified the Personal Data Protection Commission (the “Commission”)
of a data breach incident involving the inadvertent disclosure of résumés (the
“Incident”) which were uploaded by individual job seekers to the Organisation’s
website, www.searchasia.com.sg (the “Website”). Specifically, when a search was
conducted on the names or email addresses of affected individuals using an Internet
search engine, the search results would include links to the affected individuals’
résumés which had been uploaded to the Website. These résumés were accessible
by clicking on the listed links.

2.

The Organisation provided job seekers with the ability to upload their résumés

on the Website so that the Organisation could assess their suitability for roles which
the Organisation has been engaged to fill. The résumés would generally include
personal data such as the name, phone numbers, employment history, educational
qualifications, achievements and skillset of the job seekers. In one instance, it was
discovered that a job seeker included additional information such as nationality, date
of birth, marital status and current salary. (The personal data on the affected
individuals’ résumés is collectively referred to as the “Personal Data”.)

1

SearchAsia Consulting Pte. Ltd.
3.

[2019] SGPDPC 40

The résumés uploaded to the Website were intended to only be accessible by

recruitment agents employed by the Organisation. However, in practice résumés
which were uploaded to the Website were stored in a folder (“the Folder”) on the
Website’s server which was not secured by access controls. As a result, these
résumés were indexed by bot crawlers and could be found and accessed by the
general public when a search was done via an Internet search engine.

4.

The Organisation asserted to the Commission that it had instructed its third

party web developer (the “Developer”) to restrict access to the Folder to only 1 of the
Organisation’s employees. However, the Organisation did not provide the Commission
with any documentary evidence supporting its assertion and the Developer, in its
statement to the Commission, denied receiving any specifications on security from the
Organisation. Further, the Organisation had not conducted any checks or tests to
ensure that access to the Folder was restricted or that the data in the Folder was
encrypted. The Organisation admitted that the Developer had not processed any
personal data on its behalf.

5.

In its representations to the Commission, the Organisation stated that it had

asked the Developer whether the résumés uploaded to the Website would be
encrypted and the Developer responded saying that “it was safe”. This does not
detract from the fact that the Organisation did not set out its instructions to the
developer in writing. As stated in Re WTS Automotive Services Pte Ltd [2018]
SGPDPC 26 (at [17]), when engaging a service provider, it is important for the
organisation to clarify their obligations and thereafter documenting them in writing prior
to the provision of services. As set out in Re Smiling Orchid (S) Pte Ltd and others
[2016] SGPDPC 19 at [51]:
“[t]here must be a clear meeting of minds as to the services that the service provider has agreed
to undertake, and this should be properly documented. Data controllers should follow through
with the procedures to check that the outsourced provider is indeed delivering the services.”

2

SearchAsia Consulting Pte. Ltd.
6.

[2019] SGPDPC 40

Further, the Organisation’s failure to conduct any checks on whether or not

access controls were put in place was in itself a breach of its protection obligations:
see Re Tutor City [2019] SGPDPC 5 at [16].

7.

The Organisation also asserted that it had relied on its web hosting and

technical support services provider (“Web Host”), to ensure that the Website had
adequate security features. However, the Organisation had not informed the Web Host
that the contents of the Folder were meant to be protected. Hence, while the Web Host
had performed some security reviews on the Website, they had not been engaged to
advise on or implement measures to protect the personal data stored in the Folder.

8.

After being informed of the Incident, the Organisation undertook the following

remedial actions:
a.

The Organisation requested the Web Host to assist in disabling the
directory listing function of the Website;

b.

The Organisation also engaged an external web developer to add a
mechanism to the Website to help prevent future indexing by search
engine crawlers;

c.

Public access permissions were removed from sensitive file directories
to avoid similar incidents from reoccurring; and
d. The Organisation requested Google to remove the existing cached
copies of the affected individuals’ résumés from its search engine
results.

Findings and Basis for Determination

9.

Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires

organisations to make reasonable security arrangements to protect personal data in
its possession or under its control from unauthorised access, disclosure and similar
risks. While the Organisation had outsourced the hosting of the Website to the Web
Host, it remained in control of the Personal Data. Accordingly, the Organisation was
3

SearchAsia Consulting Pte. Ltd.

[2019] SGPDPC 40

responsible for making reasonable security arrangements to protect the Personal
Data.

10.

The facts of this case, as set out above, clearly show the Organisation’s failure

to make reasonable security arrangements to protect the Personal Data The cause
of the Incident was that the Folder was set to allow access to documents within the
folder to the public without restrictions and the Organisation had not given the
appropriate instructions to its contractors, including the Developer and the Web Host,
to protect the Personal Data in the Folder.

11.

As has been set out in numerous previous decisions issued by the PDPC (see

for example Re Tutor City), one of the fundamental actions an organisation is required
to undertake towards fulfilling its obligation to make reasonable security arrangements
to protect personal data in its possession or under its control is to conduct relevant
tests of their IT environment, including websites, to ensure that personal data has been
adequately protected.

12.

In the circumstances, I find the Organisation in breach of section 24 of the

PDPA.

Outcome

13.

Having found the Organisation in breach of section 24, I have decided to direct

the Organisation to pay a financial penalty of $7,000 within 30 days from the date of
this direction, failing which interest at the rate specified in the Rules of Court in respect
of judgment debts shall accrue and be payable on the outstanding amount of such
financial penalty until the financial penalty is paid in full.

4

SearchAsia Consulting Pte. Ltd.
14.

[2019] SGPDPC 40

Given the Organisation’s remediation actions as set out above at paragraph 8,

I have decided not to issue any other directions.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

5

",Financial Penalty,b892605e222afd2a3621ecbe08ca82ac7ebccbac,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,130,130,1,952,"Directions, including a financial penalty of $90,000, were imposed on Ninja Logistics for failing to put in place reasonable security arrangements to protect customers’ data in relation to the Tracking Function Page on the Ninja Logistics website.  This resulted in customers’ data on the website to be accessible by the public.  Click here to learn more.","[""Protection"", ""Directions"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Ninja-Logistics-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by Ninja Logistics,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-ninja-logistics,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 39
Case No DP-1804-B2020

In the matter of an investigation under section 50(1) of the Personal
Data Protection Act 2012

And

Ninja Logistics Pte Ltd

… Organisation

DECISION

1

Ninja Logistics Pte Ltd
[2019] SGPDPC 39
Tan Kiat How, Commissioner — Case No DP-1804-B2020
14 October 2019

Introduction
1

Ninja Logistics Pte Ltd (the “Organisation”) is a logistics company providing

packaging, delivery and tracking services on behalf of retailers (“Retailers”) to the Retailers’
customers (“Customers”). This case concerns the disclosure of personal data via a delivery
order tracking function on the Organisation’s website (the “Tracking Function Page”).
2

On 23 April 2018, the Personal Data Protection Commission (the “Commission”)

received a complaint that the Tracking Function Page could potentially be used to harvest
personal data of the Customers. By changing a few digits of a Tracking ID, the complainant
could access personal data of another Customer (the “Incident”).
Facts of the Case
3

The Organisation first set up the Tracking Function Page in December 2014 to allow

Customers to (i) enquire on the delivery status of their parcels; and (ii) confirm the identity of
individuals who collect parcels on their behalf (where applicable). Generally, for a delivery,
only a Retailer and the relevant Customers of the Retailer would be provided with a Tracking
ID for parcels sent by the Retailer that were to be delivered by the Organisation to the
Customer.
4

There were 2 types of Tracking IDs used by the Organisation, namely sequential and

non-sequential Tracking IDs. According to the Organisation, the reason for having sequential
numbers in some of the Tracking IDs was for recording and business analytics purposes. Since
the launch of the Tracking Function Page, the Organisation was aware that Tracking IDs could
potentially be manipulated by changing the last few digits of the Tracking ID. While Tracking
IDs with non-sequential numbers may have a lower risk of manipulation, a random generation

2

of any 9 digits that happened to match a valid Tracking ID could still result in unauthorised
access and disclosure of personal data.
5

For a period of approximately 3 months from launch of the Tracking Function Page,

the Organisation unsuccessfully experimented with 2 methods as a second layer of
authentication to the Tracking IDs. These methods involved using either the last 4 digits of a
Customer’s mobile number or the Customer’s last name to verify the identity of the person
using a Tracking ID. According to the Organisation, these methods were not workable due to
difficulties such as the Retailers not having, or not wishing to disclose, the mobile number of
their Customers or the Customers not being able to recall the name they had provided at the
time of purchase. Hence, the Organisation ceased using a second layer of authentication in
2015.
6

At the material time, the Tracking IDs were thus the sole means of using the Tracking

Function Page. Upon the entry of a valid Tracking ID, the following types of information (the
“Disclosed Data”) could be accessed from the Tracking Function Page, depending on the
delivery status of the parcel in question (as indicated below):
(a)

For parcels with a “Pending Pickup” status:
(i)

(b)

(c)

only the Tracking ID;

For parcels with a “On Vehicle for Delivery” status:
(i)

the Tracking ID; and

(ii)

the Customer’s Address; and

For parcels with a “Completed” status:
(i)

the Tracking ID;

(ii)

the Customer’s address; and

(iii)

the name and signature of the Customer or other individual who had

collected the parcel on behalf of the Customer (this was upon clicking on
“Retrieve Proof of Delivery” hyperlink).

3

7

Save for the one-time archival of 2.6 million Tracking IDs on 31 August 2016, the

Organisation did not have any procedures to remove records of completed deliveries from the
Tracking Function Page (i.e. those with the “Completed” status). The Organisation estimated
that, at the time of the Incident, there were 1,262,861 unique individuals with valid Tracking
IDs at the “Completed” status (the “Affected Individuals”).
8

Upon being notified by the Commission of the Incident, the Organisation took the

following remedial actions:
(a)

Removed the Customer’s address for the “Pending Pickup” and “On Vehicle

for Delivery” delivery statuses;
(b)

As of 23 August 2018, the Organisation implemented a system such that

Tracking IDs would expire 14 days after the completion of the delivery1;
(c)

In August 2018, the Organisation engaged a Crest-certified security

organisation for a one-year period to assist with establishing an overarching security
framework with a data protection focus, which includes working out a data protection
training program for the Organisation’s employees who will all receive formal training
on the Organisation’s obligations with respect to the Personal Data Protection Act 2012
(“PDPA”); and
(d)

Engaged a law firm to improve and document the Organisation’s personal data

protection policies.
Findings and Basis for Determination
9

As a preliminary point, the Disclosed Data for parcels with “Pending Pickup” and “On

Vehicle for Delivery” delivery statuses did not include any data that could identify a Customer.
However, the Disclosed Data for parcels with the “Completed” delivery status included the
Customers’ names, address and signature. Hence, such data constituted personal data where it
related to an identified Customer. In particular, the Incident resulted in the exposure of the
following personal data to unauthorised access (the “Exposed Personal Data”):

1

The Organisation has since received feedback from some Retailers requesting to lengthen the validity period of
the Tracking IDs, and is considering lengthening the validity period from 14 days to 45 days, but this has yet to
be implemented.

4

(a)

the names and signatures of Affected Individuals who had signed for parcels

when collecting them; and
(b)

potentially, the addresses of Affected Individuals who were Customers.

Whether the Organisation had contravened Section 24 of the PDPA
10

Section 24 of the PDPA requires an organisation to protect personal data in its

possession or under its control by making reasonable security arrangements to prevent
unauthorised access, collection, use, disclosure, copying, modification, disposal or similar
risks. The Commissioner found that the Organisation had failed to put in place reasonable
security arrangements to protect the Exposed Personal Data for the following reasons:
(a)

First, and as mentioned at [4], the Organisation was aware from the outset that

Tracking IDs may be manipulated and had tried unsuccessfully to introduce a second
layer of authentication. Notwithstanding its knowledge of the risk of unauthorised
access and disclosure of the Exposed Personal Data through manipulation of the
Tracking IDs, there was a glaring failure by the Organisation to operationalise an
effective method of second layer authentication. Given the foreseeable risk of using
Tracking IDs as the sole means of accessing and using the Tracking Function Page, it
is inexcusable for the Organisation to neglect its obligations to implement a workable
security arrangement to protect the Exposed Personal Data. This resulted in the Exposed
Personal Data of a significantly large number of individuals being exposed to the risk
of unauthorised access and disclosure for a period of close to 2 years; and
(b)

Secondly, the Organisation did not have a procedure to remove the Exposed

Personal Data from the Tracking Function Page after the completion of a delivery. The
Organisation could have easily done so by setting a fixed period upon completion of a
delivery after which the Tracking ID would no longer be valid (as they have done after
being informed of the Incident). This would have significantly reduced the risk of
unauthorised access and disclosure to the Exposed Personal Data.
11

Accordingly, the Commissioner found that the Organisation had contravened section

24 of the PDPA.

5

Representations by the Organisation
12

In the course of settling this decision, the Organisation made representations for the

Commissioner to issue a warning in lieu of a financial penalty, or in the alternative, to reduce
the quantum of financial penalty imposed for the reasons set out below.
13

First, on 31 August 2016, the Organisation archived a significant number (2.3 million)

of Tracking IDs. As such, only Tracking IDs issued after 31 August 2016 were accessible at
the date of the Incident (i.e. the Exposed Personal Data was subject to risk of unauthorised
access and disclosure for less than 2 years)2.
14

Secondly, keeping the Exposed Personal Data accessible from the Tracking Function

Page was “well-meaning and intended to be an additional feature of its platform to differentiate
itself from its competitors”, and this allowed the Retailers and their Customers to access such
information as and when required without having to contact the Organisation. Furthermore,
some Retailers may not receive feedback from its customers promptly and would require the
Tracking IDs to be accessible for a longer period in order to respond to feedback or conduct
investigations.
15

Thirdly, the Organisation raised the following factors for the Commissioner’s

consideration:
(a)

The names in the Exposed Personal Data may not be the full names of Affected

Individuals and is “considerably less sensitive and complete than other published
cases”;
(b)

There was only a single finding of breach of one obligation under the PDPA

(i.e. Section 24); and
(c)

There was no evidence to suggest any actual unauthorised access and/or

exfiltration of data leading to loss or damage.

2

Prior to the Organisation providing information in relation to the archiving of Tracking IDs on 31 August
2016, the Commissioner preliminarily found that the Exposed Personal Data was subjected to the risk of
unauthorised access and disclosure for more than 2 years.

6

16

Finally, the Organisation also compared the present case with Re K Box Entertainment

Group Pte Ltd [2016] SGPDPC 1 (“K Box”) and Re Horizon Fast Ferry Pte Ltd [2019]
SGPDPC 27 (“Horizon Fast Ferry”). The Organisation represented that the circumstances of
these 2 cases were far more aggravated in comparison and the financial penalties imposed was
$50,000 in K Box and $54,000 in Horizon Fast Ferry. The Organisation also represented that
Re Challenger Technologies Limited and others [2016] SGPDPC 6 (“Challenger”) is more
similar to the present case, and a financial penalty was not imposed in Challenger.
17

Having carefully considered the representations, the Commissioner has decided to

maintain the quantum of financial penalty set out at [20(a)] for the following reasons:
(a)

While the Organisation did archive 2.6 million Tracking IDs on 31 August

2016, this was a one-off exercise. The Organisation did not have any procedures to
remove records of completed deliveries from the Tracking Function Page (i.e. those
with the “Completed” status). Notwithstanding the archival of the 2.6 million Tracking
IDs, Exposed Personal Data of 1,262,861 unique individuals with Tracking IDs had
been accumulated over a period of close to 2 years. This was not reasonable considering
that the delivery information which Retailers and Customers may want to access would
be for a limited post-delivery period (which was likely to be in the order of weeks rather
than years);
(b)

As for the factors in [15] raised by the Organisation, these had already been

taken into consideration in the Commissioner’s determination of the quantum of
financial penalty; and
(c)

With respect to the Organisation’s representations comparing the present case

to K Box, Horizon Fast Ferry and Challenger, the key distinguishing factor is the
volume of personal data involved. The present case involves over 1 million Affected
Individuals, which far exceeds the number of affected individuals in K Box, Horizon
Fast Ferry and Challenger.3 These cases therefore do not support the Organisation’s
representations for a warning to be issued in lieu of a financial penalty or a reduction
in financial penalty.

3

As compared to 1,262,861 unique individuals in this case, the number of affected individuals was found to be
approximately 317,000 in Re K Box Entertainment Group, 295,151 in Re Horizon Fast Ferry and 165,306 in Re
Challenger Technologies Limited

7

The Commissioner’s Directions
18

In determining the directions to be imposed on the Organisation under section 29 of the

PDPA, the Commissioner took into account the following aggravating factors:
(a)

The Organisation was cognisant of the risks of unauthorised access and

disclosure to the Exposed Personal Data through the Tracking Function Page but failed
to resolve the issue for more than 2 years;
(b)

The Exposed Personal Data of a significantly large number of individuals were

exposed to the risk of unauthorised access and disclosure for close to 2 years; and
(c)

The Organisation failed to remove Exposed Personal Data of a significantly

large number of individuals from the Tracking Function Page when it was no longer
necessary to keep them accessible online.
19

The Commissioner also took into account the following mitigating factors:
(a)

the Organisation was cooperative in the investigations;

(b)

the Organisation had, in effect, adopted an approach consistent with data

protection by design by controlling the amount of information disclosed at different
stages of the delivery process, thereby decreasing the risk of unauthorised access and
disclosure; and
(c)
20

there was no evidence of exfiltration of the Exposed Personal Data.

Having considered all the relevant factors of this case, the Commissioner hereby directs

the Organisation to:
(a)

Pay a financial penalty of $90,000 within 30 days from the date of the directions,

failing which interest at the rate specified in the Rules of Court in respect of judgment
debts shall accrue and be payable on the outstanding amount of such financial penalty
until the financial penalty is paid in full; and

8

(b)

Within 30 days from the date of this direction, implement a reasonable validity

period for the Tracking IDs after completion of each delivery, which should be as
reasonably short as possible while meeting business needs.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

9

","Directions, Financial Penalty",15f399417f152a9a341caa9715008baacdbf0985,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,131,131,1,952,iClick was found in breach of the PDPA for failing to put in place written policies and practices necessary to ensure its compliance with the PDPA. iClick was directed to put in place a data protection policy to comply with the provisions of the PDPA; to develop a training programme for its employees and require them to attend the training.,"[""Accountability"", ""Directions"", ""Information and Communications""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---iClick-Media.pdf,Accountability,Breach of the Accountability Obligation by iClick Media,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-accountability-obligation-by-iclick-media,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1901-B3254
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
iClick Media Pte. Ltd.

SUMMARY OF THE DECISION

1.

Following a complaint against EU Holidays Pte Ltd, (“EU Holidays”), the Personal Data
Protection Commission conducted an investigation to determine whether EU Holidays
had contravened the Personal Data Protection Act 2012 (the “PDPA”). In the course of
investigations, it was found that EU Holiday’s IT vendor, iClick Media Pte Ltd (the
“Organisation”), had not developed any internal policies and practices that are necessary
for it to meet its obligations under the PDPA. In the circumstances, the Deputy
Commissioner for Personal Data Protection found the Organisation in breach of section
12 of the PDPA and decided to direct the Organisation to, within 60 days:

2.

Put in place a data protection policy, including written internal policies, to comply with
the provisions of the PDPA;

3.

Develop a training programme for the Organisation’s employees in respect of their
obligations under the PDPA when handling personal data and require all employees to
attend such training; and

4.

By no later than 7 days after the above actions have been carried out, the Organisation
shall, in addition, submit to the Commission a written update.

",Directions,bf9f246a0db6172bb647c44e87dcaa6e5793dce4,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,132,132,1,952,"Directions, including a financial penalty of $15,000, were imposed on EU Holidays for breaches of the PDPA. The organisation failed to put in place reasonable measures to protect its customers’ personal data and did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Protection"", ""Accountability"", ""Directions"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---EU-Holidays-Pte-Ltd.pdf,"Protection, Accountability",Breach of the Protection and Accountability Obligations by EU Holidays,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-and-accountability-obligations-by-eu-holidays,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 38
Case No DP-1901-B3254

In the matter of an investigation under section 50(1) of the Personal
Data Protection Act 2012

And

EU Holidays Pte. Ltd.

… Organisation

DECISION

1

EU Holidays Pte. Ltd.
[2019] SGPDPC 38

Tan Kiat How, Commissioner — Case No DP-1901-B3254
4 October 2019
Introduction
1

On 14 January 2019, the Personal Data Protection Commission (the “Commission”)

received a complaint that personal data of EU Holidays Pte. Ltd.’s (the “Organisation”)
customers was accessible through its website (the “Incident”).
Facts of the Case
2

Pursuant to a Quotation of Services dated 16 May 2017 (“Contract”), the Organisation

engaged an IT vendor (the “Vendor”) to develop a new website with e-commerce capabilities
(the “Website”). One of the purposes of the Website was to allow the Organisation’s customers
(“Customers”) to make online reservations for tour packages either directly or through the
Organisation’s partner agents. Information relating to travel reservations received from
Customers were stored in 2 web directories. For reservations made directly by Customers on
the Website, the tax invoice generated would be stored in a web directory (“Web Directory
1”). As for reservations made through the Organisation’s partner agents on the Website, the tax
invoice generated would be stored in another web directory (“Web Directory 2”).
3

The scope of work in the Contract did not specify any requirements with respect to the

storage and protection of Customers’ personal data which was collected through the Website.
The Website was launched on 9 December 2017. Since its launch, the Organisation has been
managing the Website, with the Vendor’s role limited to maintenance and technical
troubleshooting.
4

On or around 5 January 2019, a member of the public (“Complainant”) discovered

copies of tax invoices containing Customers’ personal information while browsing for tour
packages on the Website. The Complainant notified the Commission of the Incident on 14
January 2019.
2

EU Holidays Pte. Ltd.

5

[2019] SGPDPC 38

Based on the Organisation’s internal records, from 9 December 2017 to 14 January

2019, tax invoices containing information of 1,077 Customers were exposed to unauthorised
access and disclosure through links to Web Directory 1 and Web Directory 2.1 The information
contained in the invoices include the following personal data (collectively, the “Disclosed
Personal Data”):
(a)

Name;

(b)

Email address;

(c)

Address;

(d)

Contact number;

(e)

Booking date;

(f)

Travel destination;

(g)

Departure date;

(h)

Gender;

(i)

Date of birth;

(j)

Passport details (including number, date of issue and expiry);

(k)

Rooming arrangement (i.e. whether travellers are adults / children and the type

of beds required); and
(l)
6

Amount payable.

Upon being notified of the Incident, the Organisation promptly carried out the following

remedial actions:
(a)

Deleted all tax invoices stored on Web Directory 1; and

(b)

Disabled public access to Web Directory 2.

1

Specifically, the information of 336 Customers were stored in Directory 1 and the information of 741
Customers were stored in Directory 2.

3

EU Holidays Pte. Ltd.

7

[2019] SGPDPC 38

Separately, the Commission’s investigations revealed that the Organisation had not

developed or implemented any internal data protection policies that are necessary for it to meet
its obligations under the Personal Data Protection Act 2012 (the “PDPA”).
Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
8

As a preliminary point, the Organisation owned and managed the Website and had

possession and control over the Disclosed Personal Data at all material times. While the Vendor
had been engaged to develop the Website and subsequently provided maintenance and
technical troubleshooting services, the Vendor had not processed the Disclosed Personal Data
on the Organisation’s behalf. The Vendor was therefore not a data intermediary of the
Organisation, and the Organisation was solely responsible for the protection of the Disclosed
Personal Data under the PDPA.
9

Section 24 of the PDPA requires an organisation to protect personal data in its

possession or under its control by taking reasonable security steps or arrangements to prevent
unauthorised access, collection, use, disclosure, copying, modification, disposal or similar
risks. In the Commissioner’s view, the Organisation failed to put in place reasonable security
arrangements to protect the Disclosed Personal Data as explained below.
10

First, the Organisation failed to assess the risks to the Disclosed Personal Data collected

through its Website and stored in Web Directory 1 and Web Directory 2. The investigations
revealed that the Organisation had left it to the Vendor to put in place the appropriate security
arrangements to protect the Disclosed Personal Data. Consequently, as mentioned at [3], the
scope of work in the Contract did not include any requirements with respect to how the
Disclosed Personal Data was to be stored or protected. The Organisation also did not review
the standard of security of the Website and left it completely to the Vendor. In particular:
(a)

In relation to Web Directory 1, prior to the Incident, since the Organisation did

not provide any instructions to the Vendor on the storage of tax invoices generated from
direct reservations on its Website, it was unaware that such tax invoices were stored in
Web Directory 1 which was publicly accessible. In this regard, the Organisation’s
assertion was that it had intended for these tax invoices to be stored in a backend
4

EU Holidays Pte. Ltd.

[2019] SGPDPC 38

Content Management System which only authorised staff could log into and access. Its
intention was not translated into action.
(b)

In relation to Web Directory 2, the Organisation intended for tax invoices

generated from reservations through its partner agents to be stored in Web Directory 2,
and accessed by partner agents using their respective email addresses and password.
The Organisation asserted that did not intend for Web Directory 2 to be publicly
accessible. However, since the Organisation did not provide any instructions to the
Vendor in relation to access controls for Web Directory 2, none was implemented.
11

What is expected from organisations contracting professional services to build their

corporate websites or other online portals is explained in the Commission’s Guide on Building
Websites for SMEs (revised 10 July 2018). In particular, organisations that engage IT vendors
to develop and/or maintain their websites should emphasize the need for personal data
protection to their IT vendors, by making it part of their contractual terms.2 Given that the
development of the Website was for the purposes of e-commerce (including the collection of
Customers’ Disclosed Personal Data in relation to reservations for tour packages), the
Organisation’s failure to specify clear requirements with respect to the protection of personal
data is particularly glaring in this case.
12

Secondly, and as observed in Re Tutor City [2019] SGPDPC 5 at [21] to [23], where

documents containing personal data have to reside on web servers, folder or directory
permissions are common and direct methods of controlling access and preventing unauthorised
access by public users and web crawlers. Depending on its business needs and circumstances,
the Organisation could have instructed the Vendor to implement any of the following
reasonable technical security measures to protect the Disclosed Personal Data:
(a)

place documents containing the Disclosed Personal Data in a non-public

folder/directory.
(b)

place documents containing the Disclosed Personal Data in a non-public folder

or directory, with access to these documents controlled through web applications on the
server.

2

Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1]

5

EU Holidays Pte. Ltd.

(c)

[2019] SGPDPC 38

place documents containing the Disclosed Personal Data in a sub-folder within

the Public Directory but control access to files by creating a .htaccess file within that
sub-folder. This .htaccess file may specify the access restrictions (e.g. implement a
password requirement or an IP address restriction).
13

In view of the above, the Commissioner found that the Organisation had contravened

section 24 of the PDPA.
Whether the Organisation had contravened section 12 of the PDPA
14

Section 12 of the PDPA requires organisations to develop and implement policies and

practices that are necessary for the organisation to meet its obligations under the PDPA and
communicate information about such policies to its staff.
15

By the nature of its business as a travel agency, the Organisation regularly collects

personal data of customers to fulfil reservations for tour packages. Notwithstanding this, the
Organisation did not have any internal data protection policies to provide guidance to its
employees on the handling of such personal data.
16

In the circumstances, the Commissioner found that the Organisation had contravened

section 12 of the PDPA.
The Commissioner’s Directions
17

In determining the directions, if any, to be imposed on the Organisation under section

29 of the PDPA, the Commissioner took into account the following mitigating factors:
(a)

the Organisation took prompt remedial actions following the Incident;

(b)

the Organisation was cooperative during the investigations; and

(c)

Although the Disclosed Personal Data of 1,077 Customers was at risk of

unauthorised access and disclosure, actual disclosure was only to the Complainant in
respect of Customers’ Disclosed Personal Data in 20 invoices albeit for a period of
more than 1 year.

6

EU Holidays Pte. Ltd.

18

[2019] SGPDPC 38

Having considered all the relevant factors of this case, the Commissioner hereby directs

the Organisation to:
(a)

Pay a financial penalty of $15,000 within 30 days from the date of the directions,

failing which interest at the rate specified in the Rules of Court in respect of judgment
debts shall accrue and be payable on the outstanding amount of such financial penalty
until the financial penalty is paid in full;
(b)

Complete the following within 60 days from the date of this direction:
(i)

Review the security of the Website and implement appropriate security

arrangements to protect personal data in its possession and/or under its control;
(ii)

Put in place a data protection policy, including written internal policies,

to comply with the provisions of the PDPA; and
(iii)

Develop a training programme for the Organisation’s employees in

respect of their obligations under the PDPA when handling personal data and
require all employees to attend such training

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

7

","Directions, Financial Penalty",e42f8ca451f258f74f2ef56d5d97b02110634815,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,133,133,1,952,"A financial penalty of $25,000 was imposed on Singtel for failing to put in place reasonable security arrangements to protect the personal data of users on its My Singtel mobile application.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Singapore-Telecommunications-Limited.pdf,Protection,Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-singtel,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 36
Case No DP-1705-B0781

In the matter of an investigation under section 50(1) of the Personal Data
Protection Act 2012

And

Singapore Telecommunications Limited
… Organisation

DECISION

1

Singapore Telecommunications Limited
[2019] SGPDPC 36

Tan Kiat How, Commissioner — Case No DP-1705-B0781
12 September 2019

Background
1

This case concerns a design issue in a previous version of Singapore

Telecommunications Limited’s (the “Organisation”) “My Singtel” mobile app
(the “Mobile App”), which resulted in the unauthorised disclosure of the personal
data of the Organisation’s customers. The current version of the Organisation’s
Mobile App does not have this design issue as it has been fixed.
2

On 17 May 2017, the Personal Data Protection Commission (the

“Commission”) received information from an anonymous informant alleging that
there was a vulnerability in the Organisation’s Mobile App, which allowed the
informant to access the account details of other customers (the “Data Breach”).
Following an investigation into the matter, the Commissioner found the
Organisation to be in breach of section 24 of the Personal Data Protection Act
2012 (“PDPA”). The Commissioner sets out below his findings and grounds of
decision.

1

Singapore Telecommunications Limited

[2019] SGPDPC 36

Material Facts and Documents
3

The Organisation is a telecommunications company in Singapore. The

Mobile App was developed by the Organisation’s IT team to enable its customers
to track their account information and manage add-on services. Communications
between the Mobile App and the Organisation’s servers are conducted via
Application Programming Interfaces (“API”).
4

The Organisation’s customers can login to the Mobile App via the

following methods:
(a)

Mobile Station International Subscriber Directory Number

(“MSISDN”) login: where a customer’s mobile phone is connected to the
Organisation’s mobile data network (3G/4G), the Organisation’s servers
will verify that the MSISDN and IP address of the mobile phones are
correct before granting the customer access to the Mobile App;1
(b)

One Time Password (“OTP”): through validation of the OTP sent

to customers via SMS and entering it in the Mobile App (“OTP Login
Method”); and
(c)
5

OnePass: by using their OnePass login and password.

Customers that login to the Mobile App via the MSISDN or OTP login

method have access to the following data relating to their own account:

1

Each MSISDN is assigned a unique IP address. When a user logs in to the Mobile App via the
MSISDN login method, the backend server will verify the MSISDN assigned to that IP address.
Once verified, the login attempt will be deemed to be authenticated and the user will be granted
access to the Mobile App.

2

Singapore Telecommunications Limited

[2019] SGPDPC 36

(a)

the mobile number used to access the Mobile App;

(b)

related service plan information (i.e. data, talktime and SMS

usage);

6

(c)

outstanding bill amount;

(d)

bill payment due date; and

(e)

billing account number.

In addition to the data mentioned at paragraph 5 above, customers that

login to the Mobile App via the OnePass method also have access to all the service
information for all Singtel services registered under that Singtel OnePass ID. In
addition, if such customers had opted for electronic billing, they would have
access to the following data relating to their own account:
(a)

the customer’s name;

(b)

the customer’s billing address; and

(c)

all Singtel services and corresponding usage (where applicable)

under the same billing account number.
7

The anonymous informant claimed that the API on the server could be

manipulated by using specialised tools to gain unauthorised access to the account
details of other customers through the following methods:
(a)

The MSISDN is a string of numbers that incorporates within it the

customer’s mobile phone number. By logging in using a legitimate Singtel
account via the MSISDN login method and changing the value in the

3

Singapore Telecommunications Limited

[2019] SGPDPC 36

MSISDN field (i.e. to another customer’s mobile phone number)2 that was
sent from the Mobile App’s API to the Organisation’s servers, the
informant was able to retrieve the account details (such as the billing
account number and billing cycle) of the other customer.
(b)

Thereafter, by logging in using a legitimate Singtel account via the

OnePass method and changing the value in the billing account number and
billing cycle fields, the informant was able to obtain the customer’s bill,
which contains further personal data such as the customer’s name, billing
address and all Singtel services and corresponding usage (where
applicable) under the same billing account number3.
8

The informant accessed four billing accounts and extracted the customer’s

name, billing address, billing account number, mobile phone number as well as
customer service plans (including data, talk time and SMS usage). While there
was no further evidence of unauthorised access, the personal data of
approximately 330,000 of the Organisation’s customers who were using the
Mobile App at the material time were put at risk of disclosure.
9

Although the Organisation had engaged a third party security vendor to

conduct regular security penetration tests on the Mobile App and backend systems
(including the API), the tests had not detected the design issue in the API that led
to the Data Breach and the Organisation was unaware of it.

The subscriber’s mobile phone number was used by the Organisation’s servers to retrieve the
subscriber’s account and billing details.
2

3

As mentioned at paragraph 6 above.

4

Singapore Telecommunications Limited

10

[2019] SGPDPC 36

During the investigation, the Organisation admitted that the Data Breach

was caused by a design issue in the API – the application input4 was not validated
against the login credential used to access the Mobile App before performing the
requested operation (the “Direct Object Reference Vulnerability”). Because all
request parameters sent by the Mobile App to the Organisation’s server during a
valid login session were assumed to be valid, once a user was legitimately
authenticated to initiate a valid login session on the device (via the MSISDN, OTP
or OnePass login methods), the user would be able to intercept and change the
field parameters in the API requests between the Mobile App and the server.
Notwithstanding, the Organisation asserted that such an action was “not
something that a normal user of the App would attempt” and the attacker must be
“technically competent” as the changing of the parameters could only be
performed on a workstation.
11

Soon after it was notified of the Data Breach, the Organisation took

remedial actions to resolve the Direct Object Reference Vulnerability. The
Organisation enhanced the API in order to tightly couple the Mobile App user’s
identifiers to the authenticated session. In this manner, should the parameters be
modified during the same authenticated session such that they do not match the
Mobile App user’s identifiers (e.g. the MSISDN field is changed to another
number and service information such as data usage of that other number is
requested), the user will see an error message and be logged out.

4

Such as the MSISDN for the MSISDN or OTP login method, and the MSISDN, billing account
number, billing payment due date for the OnePass login method.

5

Singapore Telecommunications Limited

[2019] SGPDPC 36

The Commissioner’s Findings and Basis for Determination
12

It is not disputed that the subscriber’s name, billing address, billing

account number, mobile phone number as well as customer service plans
(including data, talk time and SMS usage) are “personal data” as defined in section
2(1) of the PDPA (“Personal Data”). There is also no dispute that the PDPA
applies to the Organisation as it falls within the PDPA’s definition of
“organisation”. The key issue to be determined in this case is therefore whether
the Organisation had complied with its obligations under section 24 of the PDPA.
Whether the Organisation complied with its obligations under section 24 of the
PDPA
13

Section 24 of the PDPA provides that an organisation shall protect

personal data in its possession or under its control by making reasonable security
arrangements to prevent unauthorised access, collection, use, disclosure, copying,
modification, disposal or similar risks. It is not disputed that the Personal Data
was in the Organisation’s possession and/or control.
14

Having considered the material facts, the Commissioner finds that even

though the Organisation had engaged a third party security vendor to conduct
regular penetration tests on the Mobile App and backend systems (including the
API), the Organisation failed to put in place reasonable security arrangements with
respect to the said API to protect the Personal Data.
15

First, by the Organisation’s own admission, the Data Breach was caused

by the Direct Object Reference Vulnerability, which was a design issue in the API.
The Organisation failed to take into account the risk of manipulation to the
parameters sent from the Mobile App’s API to the Organisation’s servers when

6

Singapore Telecommunications Limited

[2019] SGPDPC 36

designing the Mobile App. The validation of parameters (whether input or noninput fields), which could have prevented unauthorised access to the Personal
Data, were not implemented as part of the API’s initial design.
16

The Direct Object Reference Vulnerability is a relatively basic design

issue and well-known security risk that a reasonable person would have
considered necessary to detect and prevent. It was one of Open Web Application
Security Project (“OWASP”) 2013’s top 10 most critical web application security
risks and OWASP recommended, among other things, the usage of Indirect Object
Reference as a prevention method.
17

Furthermore, as highlighted in the Commission’s Guide to Building

Websites for SMEs (at [6.5]), programmers should be aware of the common
website vulnerabilities and adopt the appropriate programming techniques and
practices to ensure that personal data cannot be exposed through such
vulnerabilities. Although the Guide to Building Websites for SMEs sets out key
considerations for the process of setting up a website, the same principles are
similarly applicable when programming a mobile application. This is because the
same issues arise when a server responds to requests from a mobile app as when
it responds to requests from a web browser.
“6.5 Website Programming

6.5.1 When programming the website, programmers should be aware of
the common website vulnerabilities, and adopt the proper programming
techniques and practices to avoid them. Programmers can use the
OWASP Top 10 vulnerabilities list as guide and some common
vulnerabilities include:

7

Singapore Telecommunications Limited

[2019] SGPDPC 36



Injection (e.g. SQL Injection)



Cross-site scripting



Buffer overflows



Poor authentication & session management

6.5.2 Organisations and any engaged IT vendors should ensure that
personal data cannot be exposed, either accidently or by design,
through any such vulnerabilities. The website functions should be
thoroughly tested or scanned for vulnerabilities, before the website is
launched.”

[Emphasis added.]
18

By failing to take into account the risk of manipulation to parameters sent

from the Mobile App’s API to the Organisation’s servers, the Commissioner finds
that Organisation subjected its customers to the risk of actual and potential
unauthorised access of their personal data.
19

At this juncture, the Commissioner would like to deal with the

Organisation’s claim that exploiting the Direct Object Reference Vulnerability
was “not something that a normal user of the App would attempt” and that the
attacker must be “technically competent” as the changing of the parameters could
only be performed on a workstation.
20

While the changing of parameters would require a person to have some

knowledge of the tools and methods for doing so, anyone with working knowledge
of how a mobile app communicates with the servers through an API could have
exploited the Direct Object Reference Vulnerability. The tools and software
required to manipulate the parameters are available online.

8

Singapore Telecommunications Limited

21

[2019] SGPDPC 36

The Organisation was aware that direct object reference vulnerabilities had

been discovered in its Mobile App. Despite having received professional advice
to take precautions against such vulnerabilities, the Organisation omitted to
conduct a full code review on the input and non-input fields and hence failed to
discover the Direct Object Reference Vulnerability that was exploited in this case.
22

As mentioned at paragraph 9 above, the Organisation had engaged a third

party security vendor to conduct regular security penetration tests on the Mobile
App and backend systems.5 The Direct Object Reference Vulnerability was not
detected prior to the Data Breach but a variation of it was found in the October
2015 penetration test (“2015 Penetration Test Report”) and rectified in
November 2015. In the 2015 Penetration Test Report, the security vendor cited
three examples of Direct Object References vulnerabilities in the API
(collectively, the “2015 DOR Vulnerabilities”).
23

During the investigation, the Organisation represented that the 2015 DOR

Vulnerabilities were specific to the API accepting input fields (i.e. parameters
keyed in by users at the user interface level), whereas the Direct Object Reference
Vulnerability did not validate non-input fields (i.e. parameters not keyed in by
users such as automatically generated URL at the backend). As the Organisation
had only conducted a code review for the 2015 DOR Vulnerabilities on APIs
accepting input fields, the Direct Object Reference Vulnerability that caused the
Data Breach was not discovered at the time. However, contrary to the
Organisation’s representation, a review of the 2015 Penetration Test Report
showed that both input and non-input fields were affected by the 2015 DOR

5

At the time of the Data Breach, the most recent penetration tests on the Mobile App and backend
systems were conducted in October 2015 and January 2017.

9

Singapore Telecommunications Limited

[2019] SGPDPC 36

Vulnerabilities, and even non-input fields could be manipulated by the Mobile
App’s call to the API and that this should be remedied.
24

Based on the findings and recommendations in the 2015 Penetration Test

Report, the Organisation ought to have been more diligent in performing a
thorough assessment of the security posture of the API and the server. The
Organisation should have examined all other functions to determine whether they
could be exploited by changing the input parameters and implement the relevant
fixes, but it had failed to do so.
25

For the reasons above, the Commissioner finds that the Organisation is in

breach of section 24 of the PDPA as it failed to make reasonable security
arrangements with respect to the said API to protect the personal data in its
possession and within its control.
26

The Organisation submitted representations after a preliminary grounds of

decision was issued and raised four points. First, the Organisation asserted that it
was reasonable that any request parameters sent by the Mobile App during a login
session was treated as valid without having to re-validate the request parameters
during the session, given that the user was required to be legitimately
authenticated via one of the three login methods. This does not address the Direct
Object Reference Vulnerabilities which could be exploited by a third party.
Paragraphs 15 to 25 above, deal with this point.
27

Secondly, the Organisation asserted that not all of its 330,000 customers’

data was put at risk of disclosure as the informant would have had to use the
correct combination of the mobile number of the customer, the customer’s billing
account number, billing account ID and billing cycle date in order to generate a
bill specific to that customer or a correct mobile phone number to generate the

10

Singapore Telecommunications Limited

[2019] SGPDPC 36

relevant subscription information. The Organisation thus asserts that the decision
should be narrowed to only the 4 accounts that were successfully accessed. The
manner in which the informant was able to access the records of the said 4
accounts is set out above at paragraphs 7(a) and 7(b). While the informant only
accessed 4 accounts, the informant or someone with similar skillset and access to
the same resources could potentially have access to the personal data of all
330,000 subscribers who were using the Mobile App during the material time of
the Incident. In the circumstances, it is correct that the full size of the database
was one of the factors taken into consideration in assessing the financial penalty
quantum.
28

Thirdly, in reference to paragraph 19 above, the Organisation asserted that

the technical expertise required by someone to exploit the Direct Object Reference
Vulnerability was underestimated in this Decision. For the avoidance of doubt, it
is agreed that some level of technical expertise would have been required for
someone to exploit the Direct Object Reference Vulnerability. While this level of
technical expertise is not uncommon, what cannot be ignored is that the
vulnerability is well known and the requisite knowledge, tools and software to
exploit the Direct Object Reference Vulnerability can be acquired online. This
increases the likelihood that someone with the wrong motivation could have
exploited the vulnerability.
29

Finally, the Organisation also restates that the Direct Object Reference

Vulnerability was not detected in the security penetration tests. This is dealt with
at paragraph 21 above.
30

In the circumstances, the Commissioner decided to maintain his finding

that the Organisation was in contravention of section 24 of the PDPA.
Nevertheless, the Commissioner has decided to impose a reduced financial

11

Singapore Telecommunications Limited

[2019] SGPDPC 36

penalty quantum as set out at paragraph 32 below, given that the exploitation of
the vulnerability requires some level of technical expertise.
The Commissioner’s Directions
31

Given the Commissioner’s findings that the Organisation is in breach of

section 24 of the PDPA, the Commissioner is empowered under section 29 of the
PDPA to issue such directions as it deems fit to ensure compliance with the PDPA.
This may include directing the Organisation to pay a financial penalty of such
amount not exceeding S$1 million.
32

Having considered all the relevant factors in this case, the Commissioner

hereby directs the Organisation to pay a financial penalty of $25,000 within 30
days from the date of the Commissioner’s direction, failing which, interest at the
rate specified in the Rules of Court6 in respect of judgment debts, shall accrue and
be payable on the outstanding amount of the financial penalty until the financial
penalty is paid in full. The Commissioner has not set out any further directions
given the remediation measures that the Organisation has already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

6

Cap 322, R5, 2014 Rev Ed.

12

",Financial Penalty,1cfca0515da19cdcbdfd450d34bfa1d3c2583b97,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,134,134,1,952,"A financial penalty of $40,000 was imposed on Marshall Cavendish Education for failing to put in place reasonable measures to protect the personal data of users of its learning management system.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Marshall-Cavendish-Education-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by Marshall Cavendish Education,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-marshall-cavendish-education,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION
[2019] SGPDPC [34]
Case No DP-1704-B0699

In the matter of an investigation under
section 50(1) of the Personal Data Protection
Act 2012
And
Marshall Cavendish Education Pte. Ltd.
…Organisation(s)

DECISION

Re Marshall Cavendish Education Pte. Ltd.
[2019] SGPDPC [34]
Tan Kiat How, Commissioner – Case No DP-1704-B0699
30 August 2019

1.

With the increasing prevalence of ransomware attacks online, this case gives

occasion to restate the importance of making adequate security arrangements to
protect personal data and to limit unnecessary exposure of an organisation’s
computer systems to such potential threats on the internet.

Background

2.

Marshall Cavendish Education Pte Ltd (“MCE”) provided a learning

management system (“LMS”) at www.mconline.com.sg (“Website”) to the
Ministry of Education (“MOE”) schools. This was pursuant to a contract between
MCE and MOE.

3.

On 1 February 2017, ransomware affected a substantial portion of MCE’s

network (“Incident”). On 3 February 2017, MCE informed MOE of the Incident.
The relevant government agencies were notified of the Incident accordingly,
including the Personal Data Protection Commission (“PDPC”). The ransomware
had encrypted the files found on MCE’s servers, including files containing personal
data of individuals stored in the LMS, and made them inaccessible until a payment
was paid to decrypt them.

4.

Investigations revealed that the ransomware was an executable file on 1

server. However, it affected data on 11 servers and network storage devices in
MCE’s network. These 11 affected servers and network storage devices mostly held
teaching material. However, the server in question and a network storage device

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

each held copies of the database of 206,240 active and 44,688 inactive users. The
database held the following personal data of its users, which were mandatory fields
that every user who signed up for accounts on the Website had to provide:

a.

Login ID comprising an individual’s full or partial birth certificate or
NRIC no.;

b.

Name;

c.

School name;

d.

Schooling level; and

e.

Class.

5.

Users could also opt to supply additional personal data using optional fields.

According to MCE, however, users rarely provided such additional information,
which comprised:

a.

Email address;

b.

Address;

c.

NRIC;

d.

Mobile Number;

e.

Father/Mother/Guardian’s Name;

f.

Father/Mother/Guardian’s NRIC/Passport Number;

3

Re Marshall Cavendish Education Pte. Ltd.

6.

[2019] SGPDPC 34

g.

Father/Mother/Guardian’s Occupation;

h.

Father/Mother/Guardian’s Mobile Number;

i.

Father/Mother/Guardian’s Residential Number; and

j.

Father/Mother/Guardian’s Office Number.

MCE found no evidence that the personal data in its servers had been ex-

filtrated. MCE’s internet service provider’s network logs would have captured the
downloading of a database of that size.

7.

However, as access had been gained to MCE’s servers to upload and execute

the ransomware, it meant that the personal data in MCE’s servers were exposed to
unauthorised access. Further, the encryption of the personal data by the ransomware
was an unauthorised modification of the personal data in MCE’s servers.

Causes of the Incident

8.

The primary cause of the Incident was due to a change made to a firewall

rule to allow internet access to the server. This allowed the external perpetrator to
gain entry into the system to upload and execute the ransomware.

9.

MCE had employed a senior system engineer (“SE”) to, amongst other

things, maintain MCE’s servers. The SE was part of the Organisation’s IT team that
also comprised of another system engineer and a manager (“IT Manager”) who
had supervisory duties over the said system engineers. According to the
Organisation, the IT Manager together with the SE and a program manager was also
responsible for managing the services in the Organisation’s datacentre.

4

Re Marshall Cavendish Education Pte. Ltd.

10.

[2019] SGPDPC 34

The SE had found that the backup server’s anti-virus definition was not

updating automatically. The SE thought that the anti-virus’ auto-update function
was not working properly due to the limited or restricted access to the Internet, and
thus the SE changed a firewall rule to allow direct access from the Internet to the
server in question (the “Firewall Rule Change”). The Firewall Rule Change had
lifted the restrictions that were in place to prevent external access to the MCE
backup server and the data it held.

11.

Critically, although the Firewall Rule Change was intended to be temporary,

the SE had failed to reinstate the firewall rule after completing his investigation,
thereby allowing the server to be continuously exposed to internet access. This
increased the risk of an external perpetrator being able to gain entry into the server,
as had transpired in this case.

12.

PDPC’s investigations revealed that the perpetrator had gained entry to the

server through brute force attacks on the server. As a result of these brute force
attacks, the perpetrator had uploaded and executed the ransomware on the server
on 1 February 2017.

Remedial actions by the Organisation

13.

The Organisation subsequently took the following remedial measures:
a. Put in place security arrangements to protect the personal data held in its
servers after assessment of their need for remote internet access;

b. Conducted a review of the existing firewall rules in conjunction with an
assessment of the remote internet needs of the IT system;

5

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

c. Engaged an external auditor to conduct a thorough review and audit of
MCE’s IT system;

d. Strengthened controls over deployment of any program to the Website;

e. Strengthened controls over obtaining of source code and database scripts;

f. Improved handling of any reported defects/issues with the LMS portal;

g. Implemented monthly review of user access rights, including a listing of
product environment users and their accompanying access rights;

h. Strengthened control user access requests to the RDP server and
mechanisms to deal with the deletion of any remote user access requests by
non-active accounts;

i. Improved management of the various types of user accounts;

j. Better defined scope of duty for each system engineering team;

k. Hired an IT security officer to focus solely on cybersecurity; and

l. Strengthened its network security by clarifying various steps or approvals
that need to be performed or obtained before a system engineer can make
any system changes and procedures for follow up actions and management
reporting for all IT security incidents.

6

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

Findings and Basis for Determination

Issue for determination

14.

The issue to be determined is whether MCE had complied with its

Protection Obligation under section 24 of the PDPA in this case.

15.

There is the preliminary issue of whether MCE was a data intermediary for

MOE and whether it could avail itself of the exception under section 4(1)(c) of the
PDPA, which states that Parts III to VI of the PDPA, including section 24 of the
PDPA, shall not impose any obligation on any public agency or organisation in the
course of acting on behalf of a public agency (in this case, MOE). Investigations
disclosed that MCE was a vendor providing IT tools and hosting services for
MOE’s teaching and administrative programmes. MCE was not acting on behalf of
a public agency for the purposes of section 4(1)(c) of the PDPA and is subject to
the full gamut of obligations under the PDPA qua its capacity as a data
intermediary.

16.

Section 24 of the PDPA provides that an organisation shall protect personal

data in its possession or under its control by making reasonable security
arrangements to prevent unauthorised access, collection, use, disclosure, copying,
modification or similar risks (the “Protection Obligation”).

Whether MCE breached section 24 of the PDPA

17.

The personal data in question was stored on MCE’s backup server. It was

in MCE’s possession or under its control. MCE therefore had a duty to protect that
data by making reasonable security arrangements against unauthorised access or
modification.

7

Re Marshall Cavendish Education Pte. Ltd.

18.

[2019] SGPDPC 34

MCE did not fulfil its obligation under section 24 of the PDPA when the

circumstances are viewed in totality. The SE had intended the Firewall Rule Change
to be temporary. However, the SE had failed to reverse the Firewall Rule Change
as he was interrupted by other work matters in the middle of attempting to establish
the reason for the failure of the antivirus software to update automatically. This was
a critical mis-step.

19.

This was exacerbated by the fact that the SE had, at some time prior to this,

already installed remote access software on the backup server. Only the Remote
Desktop Protocol (RDP) server was meant to be configured to be accessible
remotely. However, it appears that the SE had configured the backup server as a
secondary RDP server.

20.

While the Firewall Rule Change in and of itself was a security risk as it

opened the MCE’s backup server to a wide range of possible attacks, the installation
of remote access software on the server and its configuration as a secondary RDP
server would have allowed an attacker a greater chance of success in infiltrating it,
especially where no safeguards were implemented to mitigate this risk. These
threats are real – as has been exemplified in this case where the perpetrator had
managed to use brute-force attacks to gain access to the backup server in order to
upload and execute the ransomware.

21.

As an organisation, MCE bore responsibility for putting in place the

requisite measures to prevent data breaches from taking place. As mentioned in Re
Aviva Ltd [2018] SGPDPC 4, relying solely on employees to perform their tasks
diligently is not a sufficiently reasonable security arrangement, and the organisation
would need to take proactive steps to protect personal data. In this case, the SE was
part of the Organisation’s IT team supervised by an IT Manager. However, it
appears that the IT Manager did not exercise competent supervision over the IT
team. In this regard, the Organisation admitted, through a written statement made

8

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

by the Organisation’s General Manager of Product Development (“GM of Prd.
Devpt.”), that:

a.

User accounts in the data centre for former staff, including that of a staff
who had left in 2014, had not at the material time been removed;

b.

The SE was not familiar with the new firewall and that this may have
contributed to the Incident. If the Organisation was aware of the SE’s
unfamiliarity with the new firewall, the IT manager ought to have
supervised the SE more closely; and

c.

That there were no standard operating procedures in place to document
changes to the firewall configurations and there were no measures in
place to monitor for the installation of unauthorised software. We have
addressed this issue in paragraphs 35 to 37 below in addressing the
representations made by the Organisation.

22.

In these circumstances, the IT Manager may not have been able to

effectively supervise the daily operational actions of the SE.

23.

What is required on the part of the Organisation are practicable steps, and

these can take the form of identifying areas of risks that require higher level
approval and adequate supervision of such risky areas. One such area that ought to
have been identified was the installation of remote access software as every
installation of remote access software is a channel for web-based threats that have
to be guarded against. In this regard, the Organisation did not implement a process
which provided adequate supervisory oversight over the installation of the remote
access software, apart from identifying the installation of remote access software as
an act that required higher level approval. Records of any installation of the remote
access software could also be, but were not, maintained. This would have been a
practicable step that MCE could have put in place. Of course, this cannot prevent

9

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

the situation where the SE wilfully disregarded such a policy and proceeded to
install remote access software on the backup server without authority, but the
analysis of the facts and conclusion on MCE’s liability might well be different had
such supervisory measures been implemented.

24.

Similarly, MCE could also have implemented some form of approval

process for changes to firewall configuration. In this case, a manual record of
firewall changes in a log book or other form of supervisory monitoring, for
example, could have been practicable steps put in place by MCE. This would have
heightened the awareness of the SE that changes to firewall rules cannot be made
in a cavalier manner, and that his actions were subject to scrutiny. Again, this will
not prevent wilful disregard of such control measures but the lack of such
practicable steps deprived MCE room to raise a credible claim that it had put in
place reasonable security measures to protect the personal data.

25.

In addition to the failure of supervision, 15 accounts with remote access to

MCE’s system through the primary RDP server were found during MCE’s postIncident review. MCE reduced this number of accounts to 5. The unnecessary
number of permitted users with remote access to the system pointed to a less than
adequate appreciation of the risk that comes with remote access. This buttresses the
Commissioner’s findings that MCE has not adequately met its section 24 obligation
to protect personal data. The personal data stored on the server was not only subject
to unauthorised access, it was modified without authorisation through the
encryption process of the ransomware.

26.

In the premises, the Commissioner is satisfied that MCE failed to make

reasonable security arrangements to protect the personal data in its servers from risk
of unauthorised access, modification and disposal. The Commissioner therefore
finds MCE in breach of its obligation under section 24 of the PDPA.

10

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

Directions

27.

The Commissioner is empowered under section 29 of the PDPA to give the

Organisations such directions as it deems fit to ensure the Organisations’
compliance with the PDPA. This may include directing the organisations to pay a
financial penalty of such amount not exceeding S$1 million as the Commissioner
thinks fit.

28.

Pursuant to section 29(2) of the PDPA, and the investigation and assessment

of this matter having been completed, the Commissioner is satisfied that MCE did
not make reasonable security arrangements and is in breach of section 24 of the
PDPA.

29.

Having carefully considered all the relevant factors of this case, the

Commissioner hereby directs that MCE pays a financial penalty of S$40,000 within
30 days from the date of the directions, failing which interest shall be payable on
the outstanding amount of such financial penalty.

30.

In assessing the breach as determining the directions to be imposed on MCE

in this case, the Commissioner took into account the following mitigating factors:

a.

MCE was cooperative in the investigations;

b.

There was no misuse of the affected personal data that was reported or
indicated; and

c.

MCE had put in place several remedial measures as indicated at
paragraph 13 above.

11

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

However, the Commissioner had to balance these mitigating factors against the fact
that MCE’s failure to protect in this case led to loss of personal data in the
possession of the organisation to the control of the ransomware attacker.

31.

Representations were made by MCE after being informed of the proposed

decision in this case, submitting that they had complied with the Protection
Obligation under section 24 of the PDPA. In the alternative, MCE requested for a
warning in lieu of a financial penalty or to otherwise reduce the quantity of the
financial penalty imposed.

Compliance with the Protection Obligation under section 24 of the PDPA

32.

In support of the assertion that MCE had complied with section 24 of the

PDPA, MCE made the following representations:

a. By installing remote access software on the backup server and
changing the firewall configuration without higher level approval
from MCE’s IT manager, the SE wilfully disregarded MCE’s IT
security policy;

b. As acknowledged by the Commission at paragraph 23, no
practicable steps can be taken to prevent a situation of wilful
disregard; and

c. MCE had adequate supervisory measures, as seen by the fact that
the Incident was discovered after MCE carried out its routine
monitoring of the system, and MCE subsequently took prompt
action to investigate the Incident.

12

Re Marshall Cavendish Education Pte. Ltd.

33.

[2019] SGPDPC 34

The Commissioner has considered the representations and maintains his

finding that MCE is liable under section 24 of the PDPA for the actions of the SE.

34.

At the outset, it is crucial to note that the breach was not one-off, as the SE’s

installation and usage of the unauthorised remote access software on the backup
sever took place on more than one occasion, but went undetected. In fact, the SE
had fully configured the backup server to function as an RDP server, should the
primary server fail, without the knowledge of his supervisor. This shows the
inadequacy of MCE’s supervisory mechanisms.

35.

It should be noted that the Organisation, through a written statement made

by its GM of Prd. Devpt. on 2 June 2017, had admitted that:

a. “At the time of the incident, there were no measures in place to
prevent system engineers to install unauthorised software, such as
Teamviewer [a remote access software]”; and
b. “They [the IT team] were not required to notify anyone else if
changes were made to the firewall configurations. There are no
standard operating procedures to document such changes.” The
Organisation also admitted that this was a lapse on their part and
have tightened their process following a security audit by their
vendor.

36.

The Organisation in its representations has stated that it had a policy in place

which required the SE to seek higher level approval from the IT Manager for the
installation of remote access software and the Firewall Rule Change. Assuming that
the statement made by the GM of Prd. Devpt. on 2 June 2017 and the statements
made in the representations are true and are consistent with each other, the
reasonable conclusion is that, while there was a policy requiring such higher level
approvals, this policy was not adequately implemented and there was a lack of

13

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

supervision and monitoring over both the installation of remote access software and
the Firewall Rule Change. In practice, the SE was allowed to take whatever action
he deemed fit without any supervisory oversight from the IT Manager or any other
supervisor even if this resulted in compromising the Organisation’s IT security.

37.

In this regard, the fact that the SE was able to wilfully disregard MCE’s

procedures on more than one occasion over a period of time, without this activity
being detected, highlighted MCE’s failure to translate the policy into a process
which sufficiently complies with section 24 of the PDPA. Merely putting in place
policies is insufficient to fulfil MCE’s obligation under section 24 of the PDPA –
MCE must also have taken practicable steps to implement these policies, for
example, as set out above at paragraph 21 through adequate supervision and/or
monitoring.

Imposition of financial penalty

38.

In support of their request that the Commission should issue a warning

instead of a financial penalty or otherwise reduce the quantity of the financial
penalty imposed, MCE made the following representations:

a. The Commission failed to consider all relevant mitigating factors in
arriving at the preliminary decision;

b. The proposed financial penalty is manifestly excessive in light of
previous decisions issued by the Commission for similar or even
more serious breaches; and

c. It would be extremely prejudicial for MCE if the Commission were
to issue a decision and impose penalties on MCE almost two years
after the Incident, as the public may have the misconception that the
Incident took place recently and MCE currently does not have

14

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

reasonable security arrangements to protect personal data that is in
its possession.

39.

MCE raised the following mitigating factors in its representations:

a. There was clearly no loss of personal data;

b. No personal data was accessed by the perpetrator or any third party
and no individual can or will be affected by the Incident;

c. MCE took immediate steps to reduce the damage caused by the
Incident;

d. There were no prior breaches of the PDPA on the part of MCE; and

e. MCE had not acted deliberately or wilfully.

40.

As the personal data had been rendered inaccessible by encryption, MCE

had in fact lost access and control of the personal data. Also, because of the
unauthorised encryption of files containing the personal data, MCE was forced to
delete these encrypted files in accordance with its data protection policy. The main
database was modified because it was encrypted, and there would have been a loss
of new incremental data created during the interval between the last backed up copy
and ransomware attack. Furthermore, personal data was put at risk as the perpetrator
of the ransomware attack could access the personal data if they chose to do so.

41.

Nevertheless, as noted at paragraph 30 above, the Commission took into

account the fact that there was no misuse of the affected personal data that was
reported or indicated, and the fact that MCE had put in place remedial measures
following the Incident. The fact that there were no prior breaches of the PDPA is
not a mitigating factor in itself. On the contrary, if MCE had breached the PDPA

15

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

repeatedly, this would have been an aggravating factor, and it is trite that the
absence of an aggravating factor is not a mitigating factor.

In addition, the

deliberateness or wilfulness of MCE in breaching the PDPA is not a relevant
consideration in this case.

42.

Furthermore, the three cases cited by MCE – Challenger Technologies Ltd

and Xirlynx Innovations [2016] SGPDPC 6 (“Challenger”), Institute of Singapore
Chartered Accounts [2018] SGPDPC 28 (“ISCA”) and Bud Cosmetics [2019]
SGPDPC 1 (“Bud Cosmetics”) are not analogous to the present facts.

43.

Firstly, MCE submitted that only a warning was imposed in Challenger

although the personal data of more than 165,000 individuals was compromised.
However, the personal data leaked in Challenger was limited – it comprised only
individuals’ names, membership expiry dates and accumulated points. However,
the personal data in the present case includes personal data of minors and NRIC
numbers, and is thus of a more sensitive nature.

44.

Secondly, MCE submitted that the personal data compromised in ISCA was

even more sensitive as it included employment records and exam results, however
a financial penalty of only $6,000 was imposed. Employment and exam results are
not treated as sensitive data. Furthermore, the number of affected individuals in
ISCA was substantially lesser – 1,906 individuals as opposed to more than 250,000
individuals in the present case, and the unauthorised disclosure was limited to a
single unintended recipient for a short period of 10 minutes. This consequentially
affects the quantity of the financial penalty imposed.

45.

Thirdly, MCE submitted that in Bud Cosmetics, the Commission imposed a

financial penalty of only $11,000 despite the fact that the Commission found
breaches under sections 12, 24 and 26 of the PDPA. As with Challenger, the
personal data compromised in Bud Cosmetics was not sensitive. Furthermore, the

16

Re Marshall Cavendish Education Pte. Ltd.

[2019] SGPDPC 34

number of affected individuals in Bud Cosmetics was substantially lesser – 2,457
individuals as opposed to more than 250,000 individuals in the present case.

46.

Lastly, the time taken to complete investigations into PDPA breaches and

issue decisions may vary from case to case due to a myriad of factors. The present
case involved substantial technical complexities requiring a longer a period of time
to complete investigations, consider representations and issue the decision. The
present Grounds of Decision clearly state the date of the Incident and the remedial
measures taken by MCE. This would address MCE’s concerns that the public would
be of the view that the incident took place recently or that it has not remediated the
breach.

47.

In view of the remedial measures taken by MCE, no further directions are

necessary.

48.

The Commissioner urges organisations to take the necessary action to

ensure that they comply with their obligations under the PDPA. Appropriate
enforcement action against non-compliant organisations will be taken.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

17

",Financial Penalty,08a8fe2b2bb4c3daaa4126990a15b41870870f01,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"